Короткая ссылка: WIAD-TeamLead-2019

В конце февраля подряд прошли две конференции 23.02 World Information Architecture Day (#WIAD) в Петербурге и 25-26.02 #TeamLeadConf в Москве. Обе - интересные и содержательные, и с обоих я вел репортаж на facebook. Потом была интенсивная подготовка к #KnowledgeConf, другие конференции и дела, а вот теперь я собрал эти посты в отчеты, потому что в ленте они утонут, а там много было интересного. Думаю, что тем, кто тогда читал мои репортажи эти отчету тоже будет интересно посмотреть. А кто не читал - может составить себе представление о конференциях, или вспомнить, что там было.

WIAD

WIAD-2019

На конференции WIAD я в Петербурге был четвертый раз. Это - одна из площадок международного события World Information Architecture Day, которое проходит в третью субботу февраля по всему миру, более 70 площадок. Каждый год объявляется отдельная тема, и в этмо году было Design for Diversity, проектирование для многообразия. В Питере это организует сообщество UX Spb и там традиционно сильная программа (мои отчеты WIAD-2016, WIAD-2017, WIAD-2018). В этом году была площадка в Москве, но ее сделали позднее и она пересеклась с TeamLeadConf, поэтому подробностей не знаю. Как и в прошлые годы, на конференции вели запись докладов, но они пока не выложены. Следите за группой UX Spb.

Я выступал с докладом Проектирование для многообразия — конструктор и DSL вместо жесткой реализации требований, который как раз пересекается с темой конференции, в котором попробовал поговорить о балансе между реализацией "как написано в требованиях" и универсальными конструкторами, который бы обеспечивал нужную гибкость, при приемлемой сложности реализации и использования.

А теперь - про другие доклады. Наиболее интересный для меня был доклад Лары Симоновой, в комментариях к нему пару недель шло большое обсуждение. Про остальные - сильно короче.

Шейла Шейх о структурировании функций приложения МойОфис

Пост на FB Первый доклад - Шейла Шейх о структурировании функций приложения МойОфис - потому что по мере развития функций становилось все больше, и надо было обновить навигацию. В одиночку на работает, структура одного кажется нелогичным другому. Попробовали получить консолидированное представление простым образом - получили отсутствие согласия и много холиваров. Выработали метод - работа парами дает в целом качественный результат без особых холиваров. И работать лучше бумажными карточками Следующий такт - работа парами, обсуждение на карточках. И делать это должны пользователи, а не разработчики продукта, у разработчиков получается взгляд от реализации, а не от использования. Работу провели, получили еще пару уроков. Во-первых, называть категорию - в последний момент. Иначе она мешает включению новых. Во-вторых, сортировка не менее важна, чем группировка. Пользователи делали большие группы и не хотели их делать, но внутри складывали в нужном порядке, и там получаются неявные подгруппы, а слышая, как они это делают - можно и названия выделить.

Алена Анищенко - тоже про упорядочивание функций - но силами самих разработчиков

Пост на FB Второй доклад Алена Анищенко (SEMrush) тоже про упорядочивание функций - но силами самих разработчиков, на AirTable - - можно делать структуру со справочниками, есть коллективная работа, возможность встроить в документацию и API для загрузки и возможных визуальных представлений. Справочники они выделили, переход к визуальным представлениям потребовал наложить ограничение на глубину иерархии (и, возможно, другие) для обозримости результата. Прототип - есть, но автомат для визуализации еще не написан.

А МойОфис, откуда был первый выступавший проходил это в прошлом году и на объектах, и тоже сейчас пришел к AirTable, об этом в их докладе было.

Нелли Камаева - любопытная эволюция функционала стартапа по ведению заметок

Пост на FB Нелли Камаева - любопытная эволюция функционала стартапа по ведению заметок.

Для начала - заметки. К которым автоматически добавляются тэги. Поняли, что в каждой компании есть свой словарик, при этом одни и те же слова в разных компаниях означают разное - это надо выделять, обучаться, загрузить готовое нельзя.

Потом - управление голосом. Распознание команд и их исполнение. Оказалось, что обязательно надо отвечать, первая версия показывала распознанное на экране, но оказалось, что разговаривать хотят и не смотря на экран. Как они шутят, получилось "Сири для компаний". Прикольно, но оказалось не слишком востребовано. Все-таки люди публично не любят говорить с компьютерами на рабочие темы - слышат то все.

Третий такт - на основе этого подключать голосовое управление к существующим приложениям - для тех, кто проводит время на встречах, где голосом удобнее, чем клавиатурой. Продажи, поддержка. Для поддержки даже удобнее, чем человек-оператор, потому что робот параллельно меняет интерфейс, и делает это быстрее, чем оператор.

У них многое в идеях, крутые ролики, увы, анимированы дизайнером, а не являются запись экрана. Но часть уже работает, она показывала и рассказывала архитектуру. Распознавание речи - на основе google, у тех есть api.

И дальше был достаточно подробный рассказ про внутреннюю структуру, которая в принципе повторябельна даже в собственной разработке, или можно попробоваться взять их платформу и поверх писать свои скрипты, наверное. В примерах было, например, подключение скрипта для таблицы умножения, и там - свои фишечки, например, альтернативные реакции на правильный и неправильные ответы, их должно быть достаточно много.

Вообще такие доклады про незавершенную работу, где много идей обычно на конференциях не очень приветствуются - сначала сделайте, потом рассказывайте. Однако, в области быстрого развития технологий это имеет смысл.

В ответах на вопросы - неожиданный кейс про практическое применение, которое уже есть - делают приложение для общения полицейских с диспетчерами, замену раций. Утверждают, что различия впечатляют :)

Сотрудничество UX-дизайнера и NLU-инженера. Екатерина Юлина, Дарья Сердюк

Пост на FB Сотрудничество UX-дизайнера и NLU-инженера. Екатерина Юлина, Дарья Сердюк - история о том, как стартует сотрудничество, первый подход оформления пользовательского интерфейса в высокотехнологичном продукте для Natural Text Processing. В условиях ограниченного времени - построение точечных прототипов. Любопытная история постепенного взаимопонимания и получения легких решений для первых шагов. И ценно именно этим - в условиях малых ресурсов можно сделать существенные и важные шаги. Сейчас ресурсов всегда недостаточно, чтобы сделать "по полной, как положено по учебникам", и многие под этим предлогом отказываются даже сделать первый шаг - мог, все равно бесполезно. Нет, полезно, и если первый шаг делать профессионально - получается реальный эффект.

ИА управления проектом - Сергей Петров

Пост на FB ИА управления проектом - Сергей Петров. Версия информационной архитектуры проекта, с контекстами, ролями, мотивацией сотрудников и многими другими составляющими. Полезна как начальный вброс, но была бы, на мой взгляд, гораздо полезнее, если бы была соотнесена с известными моделями и содержала ссылки. Потому что моделей много - OMG Essence, Archimate, включающий как расширение motivation model и многие другие. Если бы это было сделано, то дальше слушатели могли бы сознательно углубляться и детализировать.

Что ценного в докладе - это удержание одновременно идеальной картины и происходящего в реальности, наблюдение и измерение зазором между ними. Это - важный фокус, которому не так много уделяют внимания, именно в формате управления зазором, а не тотального приведения к идеальной картине.

Meta-IA: Информационная архитектура изменяющихся систем - Лара Симонова

Пост на FB Meta-IA: Информационная архитектура изменяющихся систем - Лара Симонова. У Лары есть компетенция, которая меня восхищает. Она умеет строить весьма детализированные модели больших фрагментов мира, и потом структурно представлять эти модели в своих докладах. Это резко контрастирует с принятыми идеями упрощения до единственной картинки или основной идеи, эта детализация - очень интересна. В этом докладе Лара представила конструкцию размышлений об изменчивости мира и о создании устойчивых архитектурных конструкций в изменяющемся мире. Дальше - мой краткий конспект.

Мы берем мир, выделяем интересующую нас область, строим там информационную архитектуру, онтологию (хотя это слово в докладе не звучало). А дальше - мы смотрим на взаимодействие человека с миром в этой области и у нас появляется идея продукта, то есть идея создания средства, которое это взаимодействие поменяет желаемым образом. И проектируем продукт, его информационную архитектуру, реализуем,тестируем и позиционируем, с учетом рынка, дорабатываем.

Теперь вопрос: ИА - это скелет. Как сделать ИА, устойчивую к изменению мира. Лара рассказывала модель, как с этим работать. Модель взята из статьи, название которой я не записал, но в презентации посмотрю.

Мир - сложный, его можно рассматривать через разные призмы/проекции. Например, через призму человека, включая культуру. Или через организационно-управленческий. Через тренды и моду, через технологии, через законы природы. Выбор призм задает контекст продукта, он - важен. Границы продукта определяются уже в выбранных проекциях. Если пропустишь призму, может получиться неустойчивая архитектура.
В призмах есть рестрикторы - ограничение то, что надо учесть при решении. Рестриктор продукта отсекает людей от его использования.
В мире есть слои, которые обладают разной скоростью изменения: природа - культура - регулирование - инфраструктура и технологии - экономика - мода и искусство. Изменения идут во всех слоях одновременно, но в своем темпе.
И рестрикторы позиционированы в этих слоях, исходя из этого можно предполагать их устойчивость.

И в докладе был ретроспективный пример о том как это работает - Международная классификация болезней из книги Sorting Things Out - там это сквозной пример. Классификация возникла с 19 века для целей определения карантиров и предотвращения эпидемий. Сейчас 11 версия, меняем каждые 10 лет. 3 тома - гайд и указатель. И интересно посмотреть как раз эволюцию этой классификации за 110 лет. и увидеть там слоевые изменения.

Лара в рассказе рассмотрела рестрикторы уровня природы. (1) Изменение популяции - проявляется через изменение нормы веса и изменение уровня сахара, который квалифицирован как диабет, границы меняются. (2) Изменение агентов, мутация вирусов сказывается на болезнях и далее меняет квалификацию. В презентации разобраны другие слои и сводная таблица, и это тоже я планирую внимательно посмотреть.

А пока - огромное спасибо Ларе за доклад.

Лара Симонова Спасибо, Максим, за резюме! Единственный комментарий. Модель из статьи включает только стратификацию мира по слоям со скоростями. А призмы и рестрикторы это уже конструкты из моей головы) Статья вот: https://jods.mitpress.mit.edu/pub/issue3-brand

В комментариях к посту развернулось большое обсуждение.

Александр Турханов "Призмы" - это viewpoints из ISO42010. "Рестрикторы" - это concerns из ISO42010.

Сам доклад - это гармонизированный по ISO42010 фреймворк разработки продукта. Очень интересно методически сделана последовательность предъявления концепций, это всегда большая проблема.

Анатолий Левенчук (Anatoly Levenchuk) обрати внимание на последовательность предъявления в презентации

https://channelkit-assets.s3.amazonaws.com/uploads/attachment/file/4500/2019_IA_of%20evolving_systems.pdf

Лара Симонова Как здорово, спасибо большое за референсы, почитаю. Не успела пока найти и изучить источники, хотя очевидно, что они должны существовать.

Анатолий Левенчук Alexander Turkhanov мы когда-то сильно рубились с urbansheep по поводу "информационной архитектуры" из раннего web (я требовал предъявить хоть какое-нибудь своё понятие в этой предметной области, не заимствованное откуда-нибудь -- а этого, понятно, не было). Поэтому у меня обычно заранее скепсис к этому предмету. Вот тут чуток подробней (в комментах и по ссылкам), хотя я там тоже в тоске говорю, что непонятно, во что людей тыкать, чтобы мозг включали -- https://ailev.livejournal.com/249643.html, и это 2004 год, 15 лет назад!

Ну и тут в комментируемой презентации: терминология довольно эзотерическая, как справедливо замечено. Начиная с того, что описано моделирование данных, а потом произвольно ввёрнуто слово "архитектура" (а не архитектурная часть результатов проектирования куда?). Насчёт "контейнера для опыта", так это прагматический поворот

Международная классификация болезней тут очень специфический объект, ибо это предмет политических разборок, нужный для определения инвалидностей (пенсии! деньги!) и лицензирования (врачебные специальности и большая фарма).

Про последовательность предъявления и предлагаемый "процесс" -- там есть довольно произвольные моменты, типа "призм" (среда, природа, человек, законы, тренды, технологии -- это явно не viewpoints, это произвольно выбранный классификатор. Viewpoints там это какие-нибудь средства для выражения concerns типа "физиология"). То есть для меня это очередной ad hoc набор удобных эвристик-классификаторов (и, конечно, любимые "матрицы" рассмотрения двойных-тройных и т.д. классификаций -- типа призмы-рестрикторы-слои), а насчёт системности я бы сильно сомневался.

Александр Турханов Анатолий Левенчук доклад должен называться "Метод создания онтологии в DDD". Его, конечно, еще доделывать, но сам заход на мой взгляд, верный. С event storming и BORO все равно проблемы, нужны новые заходы.

Анатолий Левенчук Ну да. Набор эвристик и случайных классификаторов для DDD. Типа тризовских "а теперь представьте вашу систему микроскопических размеров. А теперь -- наоборот, огромной. Не появилось ли новых идей?" )))

Максим Цепков Не, метод создания онтологий и DDD был у Лары на предыдущих конференциях, с wiad-2017 у меня даже сохранилась ссылка https://www.facebook.com/lara.simonova.the.ia/posts/1261251240609758 на ее пост, и там была интересная практическая задача сопряжения различных стандартных публичных онтологий в единую модель, при том, что создатели об этом не заботились особо.

А здесь фокус был именно на то, как делать устойчивые к изменениям в условиях развития модели.

Александр Турханов Максим Цепков устойчивость онтологии к изменениям определяется как полнотой классификатора и логики онтологии.

Возьму для примера две устойчивые онтологии PMBOK Guide и SEMAT. В одном случае объектом онтологии являются практики, в другом альфы. И в том и в другом случае классификаторы покрывают все возможные ситуации в реальной жизни, но один исходит из парадигмы фокуса на действиях, другой из парадигмы фокуса на рабочих продуктах.

Но обе онтологии построены на иерархичных полных классификаторах, отвечающих условно критериям качества пирамиды Минто ВИСИ/MECE, взаимного исключения и совместного исчерпывания.

Претензия Анатолия, как я понял, в том что (мета)-классификатор доклада критериям качества не отвечает, нет иерархичности, объекты в нем не одного типа, и он неполный, поэтому не может быть устойчивым.

Мне, повторюсь, интересен здесь заход на последовательность объяснения.

Юрий Пахомов Очень бы удивился если бы увидел как работает ИТ продукт с мировоззренческими настройками😅

Прапион Медведева Мне понравилось почти до самого конца, все слова правильные. МКБ в этом контексте немного удивила. Была уверена, что призмы и рестрикторы из стандартов.Ну и как бы ничего не мешает делать произвольную upper-ontology

Анатолий Левенчук Prapion Medvedeva как бы мешает: согласовывать своё произвольное (и заранее плохо известное всем остальным) мировоззрение с мировоззрениями всех окружающих будет сложней. Крис Партридж указывает в некоторых своих работах, что upper ontology состоит из многих взаимоувязанных посылок обычно, и кривые upper ontology с плохо совместимыми посылками обычно очень плохи в мэппинге на них других онтик и онтологий. И я бы сказал, что в рассматриваемой работе не upper ontology, а произвольно взятая эвристическая онтика: набор каких-то удобных классификаторов. Вот для чего именно удобных, это можно обсуждать.

Прапион Медведева Анатолий Левенчук это правда. Но это технические детали!)

Максим Цепков Онтики, онтологии - это все одни специалисты строго различают, а другие видят непрерывный спектр различных понятийных представлений о мире разной степени общности.

Вопрос, который ставился в докладе, и который на самом деле интересен - это как строить рабочую онтику, реализуемую в рамках системы так, чтобы она оказывалась относительно устойчивой в процессе развития системы вслед за изменениями мира в лице предметной области, с которой система работает.

Ответ "через построение всеобщего полного классификатора, который учтет все будущее развитие" - не принимается, потому что такой классификатор еще никто не смог построить. Это как раз точка зрения на конструкцию НЕИЗМЕННОГО мира, восходящая, к Аристотелю или еще кому из древности, и предполагающая, что мы можем построить онтологию включающую не только прошлое и настоящее, но и все мыслимое будущее. Современный ответ - нет, не можем.

Если ретроспективно посмотреть на стандарты, рассматривая их как примеры онтик и онтологий, то оказывается, что все они устаревают. но при этом оказывается, что одни из них содержат очень жесткие ограничения и связывают по рукам и ногам, а другие получается достраивать и перестраивать. При этом. что задачу полноты классификации авторы всех стандартов решали. Далее вопрос - можем ли мы что-то сказать о характере этих изменений и. соответственно, учесть опыт тех стандартов, которые оказались удачными, онтики которых оказались относительно устойчивыми к изменениям мира. Для этих целей и была проанализирована МКБ как онтика, развитие которой насчитывает уже полтора века, и которая регулярно обновляется, чтобы быть адекватной практическим целям. Если на эту тему есть более серьезные исследования и идеи, чем приведено в докладе - давайте ссылки.

Александр Турханов Лара Симонова ну вот в качестве старта можно взять ту же http://15926.org это стандарт промстроя.

Александр Турханов Максим Цепков дал ISO15926 как стартовый пример.

Илья Баиметов ИА это Domain Model (as in Domain Driven Design)? Или отличается?

Максим Цепков ИА это "Информационная Архитектура". Трактовки понятия, на самом деле, разные. Один вариант - Domain Model или Domain model + онтологию предметной области (словарь понятий и связи между ними), без привязки к информационной системе.

Альтернативный вариант, возникший в раннем web как структура информации (контента), представляемой на сайте означает совокупность информации представляемой в системе для пользователей, и в случае контекстно-нагруженных систем, сайтов и приложений это может сильно отличаться от domain model.

Илья Баиметов Maxim Tsepkov ну я в данном контексте спрашивал - то есть не то, что на веб сайте. То есть все-таки доменная модель.

Как обеспечить доступность интерфейса. Валерия Курмак из Сбербанка

Пост на FB Как обеспечить доступность интерфейса. Валерия Курмак из Сбербанка увлеченно рассказала о том, как они обеспечивают доступность. Проводили специальное исследование о реальных проблемах. Неожиданно оказалось, что инвалиды хотят не обслуживаться на дому, а приходить в отделения - им важна коммуникация. Что инвалиды - разные, и им важны различные аспекты. И даже у инвалидов по зрению множество разных видов нарушений, и когда вы всерьез занимаетесь доступностью - это многообразие надо учитывать при тестировании. Фокус был не на технических решениях, а на обеспечении самого процесса, налаживании коммуникаций, объяснении разработчикам. На базовом уровни платформы обеспечивают доступность через ScreenReader, и в этом режиме телефон проговаривает все, что есть на экране. И важно, чтобы приложение нормально отрабатывало в этом режиме, а для этого нужна корректная верстка, должны быть подписаны все кнопки и так далее. И элементы экрана должны быть контрастны (не менее 4.5:1), что, правда, приходит к конфликту с представлениями дизайнеров, потребовали сделать более темный зеленый и убрать оранжевый. И если ваш набор типовых элементов обеспечивает доступность, и вы учитываете эти элементы при разработке, то это - небольшие накладные расходы, можно не рассматривать это как отдельную ветвь доработки, а включать в DoD основного потока.

Но вот тестирование доступности - это уже сложнее из-за налаживания коммуникаций. Они приняли на работу слепого тестировщика для экспертного тестирования, зовут респондентов для пользовательского тестирования, потмоу что эксперт уже слишком погружен в контекст приложения и не может выполнять роль неподготовленного пользователя. И надо, чтобы команды разработки были готовы к коммуникации с такими людьми. Об этом в докладе было много и с конкретными примерами.

Анна Абрамова - карта ответственности в проекте

Пост на FB Анна Абрамова в своем экспресс-выступлении рассказала простую карту, на которой можно работать, структурируя ответственность в проекте. Три слоя: бизнес - дизайн - реализация, визуально пирамидка. Три фокуса: текущая работа, внешняя среда (она меняется) и управление, как контуры вокруг пирамидки. И две половинки - Исполнитель и Заказчик, потмоу что у Исполнителя есть свои бизнес-цели, а у Заказчика - своя техническая среда, об этмо часто забывают. И дальше на этой карте можно не только выделять свои области и работать в них, но и проводить сопряжение по границам со смежниками, потому что типичные проблемы - с дырами ответственности или наоборот, с тем что человек видит реализацию в выполнении чужой работы, например, бизнес хочет напрямую писать требования.

Александр Овчаренко - о катастрофах из-за плохого usability

Пост на FB Александр Овчаренко из Wärtsilä Digital Technology рассказывал про разные случаи, когда плохой usability приводил к реальным катастрофам с судами, самолетами и автомобилями. Проблема - поставлена, но решений не было.

Впечатления Кирилла Улитина о WIAD

И в заключении - впечатления Кирилла Улитина. Отвел вчера WIAD 2019 — СПб — 23 февраля 2019, впечатления смешанные:

Выступать по чужой презентации (для открытия) это плохая идея, потому что раз не ты ее делал, никакой связи с презентацией нет, стоишь на сцене и видишь эти картинки как в первый раз, хоть глядел в нее весь вечер накануне. В начале, как водится, тупил и волноваться.
Так как все открытия обычно это довольно скучно, но тем не менее они стоят в программе, и помимо формальностей, мне кажется зашло неплохо, что я вспомнил предыдущие года, свой первый WIAD, где было совершенно космическое интервью с реальным архитектором, который строит здания, у которого возникли сложности с типологией клозета и клиентом-бандитом, поприветствовал старожилов и немного потроллил IA как термин за которым каждый понимает свое.
В этом году нас было почти в 2 раза больше чем в прошлом, пришло 120 человек!
Идея со сбором фидбека от Yury Solonitsyn с помощью бумажной анкеты для участия в розыгрыше призов, это грандиозно, я никогда в жизни не получал так быстро тонну фидбека.
Впечатления от сервиса introwise сложно пока оценить, хоть там и зарегилось около 45 человек, общение было вялое, к счастью в кулуарах было жарко.
Максим Цепков (Maxim Tsepkov) вел текстовую трансляцию мероприятия, можете просмотреть его вчерашние посты, это очень здорово! Спасибо!

Спасибо Yury Solonitsyn, Сергей Кривой (Sergey Krivoy), Julia Kryuchkova, Грише за пультом, всем спикерам, участникам и компании Semrush за площадку

TeamLead Conf

TeamLeadConf-2019

Конференция TeamLeadConf первый раз прошла всего год назад в Москве и сразу оказалась очень интересной, содержательной и востребованной (мой отчет TeamLeadConf-2018). В сентябре она была в Петербурге (мой отчет TeamLeadConf-2018-Spb), а в феврале - снова в Москве и собрала сильно больше тысячи участников. Потому что конференция реально представляет передний край управления командами в IT, и это - актуально.

Я выступал с докладом Модели softskill для тимлида, в которой был обзор разных моделей, которые полезно знать: типов личности MBTI, командных ролей Белбина, типов менеджмента по Адизесу вместе с его жизненным циклом компании, ситуационного лидерства в двух вариантах, развития команд Такмана, краткий обзор развития моделей мотивации, включая нейрофизиологическую модель Хелен Фишер и модель ценностей Спиральной динамики. Но основная цель - показать, что модели - достаточно зрелые и формальные, чтобы их стоило использовать, подобно тому, как разработку стоит вести на фреймворках.

А теперь - о докладах. Только надо отметить (пост), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера в митапе по управлению знаниями, посвященному новой #KnowledgeConf (26.04 в Москве), которая обещает быть очень интересной - это я уже пишу как член ПК, отбиравший доклады. О ней же я рассказывал в интервью RadioQA (второе фото). Но доклады будут доступны в записи, а хорошее общение - бесценно.

OKR: инструкция по применению. Егор Толстой

Пост на FB: OKR: инструкция по применению. Егор Толстой. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.

А дальше в докладе много техники, как это устроено. Полная прозрачность, которая и есть основная цель OKR. Квартальный ритм, примерно месяц в начале квартала по нескольку часов в неделю у команды. Интегрирован с Agile, цели спринта должны быть позиционированы относительно OKR и на демо это показывают. Как планировать, как формулировать цели, и так далее - смотрите доклад, когда опубликуют.

А это - те заблуждения и ошибки, которые они осознали.

Надо менять цели каждый квартал - нет надо сохранять преемственность
Брать, что хочется сделать и натягивать метрики любой ценой.
В OKR все, чем занимается команда - нет только фокус.
В первые кварталы ходила цель "научиться измерять". Это может быть на первом шаге, и не факт, что OKR, а не фон
Цель - не актуальна, но мы доделываем для OKR - не надо
Бесит цель, которую я не знаю, что не выполню. Надо сменить парадигму, от синдрома отличника избавляемся. Но цели в целом достижимые
Цели не спускаются сверху, а вырабатываются командой - сопричастность, плюс понимание реальной зоны.

Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify

Пост на FB: Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.

А дальше был рассказ про устройство круга роста разработчиков (на фото).

Compensation review в начале года 2 месяца, когда менеджеры пробуют построить разработчиков
Continious planing 1:1 - постоянно, еженедельное обновление. В этмо процессе она одна на 16 инженеров.
development talks - обсуждения достижений, 2 и 4 кварталы
talent snapshot - последние два месяца, соотнесение разработчиков между собой по многим параметрам

В вопросах было, надо ли всех тянуть. Ответ - зависит от человека. Есть серьезные интроверты, которым хорошо, и они становятся все более профессиональные сами. Их не нужно push, им нужна только информация и они сами принимают решение. Есть сплюшки - они ленивые, им хорошо, у них есть потенциал. Их сложно выявить, но вот с ними важно работать.

Дальше - вектора развития и градации по ним, много примеров.

Критерии роста в техническом направлении - все в softskill области, а не технике.

Не верят в звезд, которые лично обеспечат успех. Важно ставить успех команды выше индивидуального
Постоянное улучшение. Слежение за трендами мира.
Стали публичной компанией - и надо думать о цене разработки. Почему важно скейлить и рефакторить.
Accountability каждого человека

И что важно, и характерно для IT - рост в spftskill обвешан метриками, которые получаются из анализа потока задач и коммитов в git, о деталях Yulia рассказывала год назад. Примеры из доклада

Onboarding. Метрика. У них некоторый уровень 10th change и они трекают достижение этого уровня. Он от 30 дней до 3-6 месяцев в разных типах команд, и они сокращают.
Метрика T-shapeness. Back-end, machine learning, ... 4 штуки - считают по коммитам в разных частях и коду, использованному в них. От 12% до 20-25%
соотношение legacy refactoring к новому коду
тенденции сотрудничества в code review. Все хотим code review. В метрике - как быстро делают (4-5 часов - долго), объем реинжиниринга и так далее.

Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy из Badoo

Пост на FB: Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.

Я от себя отмечу, что умение работать со сроками и подобные soft skill - это горизонтальная планка для T-shape людей. То есть в идеале, конечно, она достаточно жирненькая горизонтальная палочка, у некоторых превращающаяся в ножку, но практически фишка именно в том, чтобы процессы позволяли держать правильный баланс.

Дальше - описание процесса. У них следующая задача назначается на свободного разработчика. В требованиях обязательно сформулированы критерии завершенности. И дальше фаза оценки, встреча для согласования требований, в том числе, поиск оптимума между функционалом и стоимостью реализации. Потом - оценка зависимостей, согласование со смежниками.

Важный этап - review срока. Если тимлид предлагает свой срок, то он при этом и забирает ответственность. Так что нужно спрашивать, а не предлагать.

В таск трекере - поле с актуальным сроком, поля с описанием ситуации. По сути, работа со сроками вынесена в отдельный трек сообщений по задаче. И отчеты по ним.

Советы.

Главное - помнить, что в требованиях - задача и гипотеза о ее решении, а не решение, которое гарантированно ее решает. И это надо разделять. И вообще, предлагать минимальное решение.
Концепт оптимистичного срока - сколько нужно, если все пойдет по плану. То есть сроки - едут, и это - оптимально и правильно при долгосрочном сотрудничестве. Но! заказчик должен принимать это, если не принимает - работют другие методики, они есть.
Ограничения: деньги, время, качество. В разных проектах у них разная подвижность, в одних важен функционал, в других - сроки. Со всеми ситуациями - разная работа, когда есть риск их нарушения. Включая вариант поставитб технический долг для быстрого решения как отдельный контролируемый процесс.
Неопределенность. Что делать, если вообще скорость решения неизвестен. Пример - запускали видеострим без экспертизы. Тогда они выделяют первый исследовательский шаг, и именно на него ставят срок. И так двигаются, пока количество неопределенностей не уменьшится достаточно для оценки. При запуски видеострима они исследовали разные технологии и фреймворки.
Инфраструктура. Для бизнесовых задач - по максимуму используем готовые технологии. Инновации идут отдельным потоком, и часто сопряжен с реинжинирингом: решение работает для бизнеса, но есть гипотеза, что на другом фреймворке будет сильно лучше - проверим.
Когнитивные искажения ошибки планирования - занижение времени на задачу. Боремся через эффект сегментирования: оцениваем целиком, и оцениваем кусочки.
Здравый смысл важнее процессов.

Если вы даете разработчику самому ставить оптимистичный срок, нельзя наказывать за невыполнение. Потому что он начнет закладывать. Все что можно - поддерживать.

Сергей Добриднюк А почему работа со сроками это soft skills ? Я думал самый что ни на есть hard skills. Анализ прецедентов, создание цепочек производство, работа по планированию и балансировке ресурсов, решение оптимизационной задачи классическими математическими методами.. Тут все инженерия и математика, а ни разу ни социология.. И такие проекты есть - например в авиации - скоп проекта может составлять миллионы работ, а в атомной отрасли - сроки до 20ти лет планируются. И что интересно - все отлично может попасть и в сроки, и в бюджеты

Максим Цепков По определению softskill как skill, переносимых между предметными областями, который не зависит от профессиональной специализации. Для профессионального менеджера это, естественно, не только soft, но и hard skill, но в докладе речь шла именно о том, что все разработчики начинают работать со сроками, а тимлид - их учит и использует. При этом тимлид в IT - это не профессиональный руководитель, это пограничный уровень.

Ведение кросс-командных проектов. Павел Аксёнов из ozon

Ведение кросс-командных проектов. Павел Аксёнов из ozon. Проблемы - понятны: много стейкхолдеров, разные инструменты ведения задач и документации у разных команд, координация планов, сквозное тестирование. Дальше был рассказ, как это все вести, со всякими приемчиками и техниками. На верхнем уровне абстракции все это известно давно, но вот арсенал инструментов - меняется, например, чатики - относительно свежий и до конца не отрефлексированный инструмент с точки зрения того, что именно в него выносить и как это влияет на остальное. Впрочем, этого в докладе не было. Рассказ был построен на основе их карточки ведения проектов. Многое - известно и понятно: примерный план проекта, протоколы встреч, бизнесовый чеклист запуска. Из интересного.

Открытые вопросы по встречам. - они даже важнее чем план!
Управление ожиданиями - синхронизация ожиданий заказчика и исполнителя. Для заказчика есть много скрытой работы, "сделать кнопочку оплаты" часто просто сделать кнопочку, а не подключить платежный гейт. А у разных бизнесов - разные цели.

Что важно: карточка ценна, когда ей пользуются. Если вы пользуетесь другим инструментом - не делайте формальную карточку. Проблема на внедрении была именно в том, что карточку не воспринимали как основную страницу, это надо через культуру.

Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза

Пост на FB: Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза. Заметки с доклада.

Коммуникация просто на основе опыта не слишком конструктивна: у разных людей - разный опыт, и они слабо сравнимы. А вот когда мы переводим опыт в ценности и смыслы, то коммуникация возможна и конструктивна, их можно соотносить.

Я с этим не согласен, потому что с ценностями и смыслами другие проблемы: одни и те же слова у разных людей означают разное. Поэтому коммуникация всегда нужна на обоих уровнях, ценности и смыслы надо иллюстрировать примерами из опыта.

Неосознанные люди. Человек служебный/исполнение -- Исполнительный/знания -- Мотивируемый/задачи -- Вовлекаемый/смыслы.

Развитие начинается с рефлексии. Надо зафиксировать разницу: что я хотел, где хотел оказаться и где оказался. В реальной жизни часто позиции где хотел и где достиг не различаются.

Путь исполнения: Ценности и смыслы -- Цели и задачи -- Знания компетенции -- Исполнение GTD. При рефлексии мы восстановили ценности и смыслы, а потом пошли через них смотреть по цепочке в обратную сторону: Исполнение -- Знания и компетенции -- Цели и задачи -- Ценности и смыслы. Последний такт - это какие ограничения были в моих ценностях, которые ограничивали меня при постановке целей и задач. Это надо осознать. А еще есть такт рефлексия над рефлексией.

Если человек умеет рефлексировать - он становится саморазвиваемый и самомотивируемым. И только такой может развивать и мотивировать других. И тут резкий контраст с традицией психотерапевтов и психоаналитиков - они явно заявляют, что сам себя адекватно рефлексировать не можешь, нужен внешний специалист. И настаивают в профессиональном кодексе, чтобы у каждого психотерапевта свой психотерапевт был, чтобы его собственные проблемы не влияли на лечение пациентов.

Андрей Кузнецов Рефлексия обычно включается поздно и сопровождается бурными эмоциями. Психотерапевты работают с тенденциями и страхуются заранее

Максим Цепков Да, и в этом проблема - не входит компетенция рефлексии в базовый набор образования. А сейчас - она необходима как рабочий процесс, потому как основа развития.

Из типологии неосознанных людей появляется пять областей работы тимлида с разной эффективностью (циклы условны)

развитие исполнения сотрудников 1:1
развитие проф.компетенций 1:3
формирование стандартов и регламентов 1:5
работа над развитием сотрудников 1:10

И был такт про команды из осознанных людей, разделяющих ценности компании и самоорганизующихся.

В ответах на вопросы - тезис о том, что человек в принципе сопротивляется развитию. И тут контраст с мнением многих педагогов школ развития, таких как Монтесорри о том, что это традиционная система воспитания и образования делает его таким. А ребенок изначально - любопытен и инициативен, и надо это не подавлять, а поддерживать.

В комментариях. Denis Vizigin Максим Цепков рефлексия — слишком общий ответ. Сложно стать руководителем, например страны, просто за счёт рефлексии

Максим Цепков Да, но БЕЗ рефлексии стать хорошим руководителем, и не только страны, а гораздо более скромных масштабов, точно не получится.

Юрий Пахомов Ценности и смыслы не надо ни во что переводить. Тем более в слова. А что касается опыта профессионального то коммуникация и рефлексия могут быть очень полезными если есть общая цель Но коммуникацию и рефлекс ию нужно уметь организовывать

Максим Цепков Для коммуникации ценности и смыслы приходится переводить в слова, или комиксы, или другие образы. И никуда от этого не деться. Прямой интерфейс между мозгами пока недоступен :)

Юрий Пахомов Толковый собеседник по любому поможет выйти на уровень рефлексии более высокий чем достижим без него. Но есть и психотерапевты сознательно или бессознательно тормозящие собств рефлексию пациента чтобы доить его вечно😂

Максим Цепков Ну, это есть разные психотерапевты, так же как разные юристы. Как в том анекдоте: приходит стажер к шефу и говорит "Я закончил дело этого клиента, все решил! - Ты идиот, этот клиент кормил нас 10 (20, 50) лет!"

Во имя нового продукта. Евгений Россинский

Пост на FB: Во имя нового продукта. Евгений Россинский год назад рассказывал о том, как ivi из функциональных подразделений к Value Stream команды выпуска конечного продукта. А в этом году у них встала задача существенно переписать весь продукт с изменением архитектуры, чтобы обеспечить новые возможности бизнеса, в частности повсеместное управление общей рекомендательной системой и переход на дизайн-систему при том, что платформенно-независимые стеки им не подходят. Они попробовали ее сделать, сохранив value stream - оно не получилось, потому что зоны ответственности за продукт по value stream не делятся, коммуникации когда делаем новый продукт нужны функциональные, синхронизация рассыпалась. Они провели большую ретроспективу, выявили много боли. В том числе, связанной с тем, что для разработки нового продукта нужно тщательное архитектурное проектирование и документирование. И в результате поняли, что value stream хорош по развитию готового приложения, но плох для разработки с нуля. В результате они вернулись к функциональному подразделению компании. При этом, естественно, вернулись все боли, которые ранее полечил value stream и, более того, местами пришлось перейти на ручное управление доработкой старого продукта - полностью остановить ее было невозможно. А еще возник дефицит ответственных архитекторов, оказалось, что хотя многие разработчики мечтали про рефакторинг, далеко не все идеи рефакторинга оказались рабочими. Это компенсировали подключением QA, которые обеспечивали детализацию постановок до нужного уровня и консультации по ним - сделали Летучие отряды возмездия. В целом, начав в апреле они к октябрю сделали основные релизы. И после этого - снова вернулись к value stream, к январю к ним вернулись. В целом был большой стресс, но они справились, горды результатом и постепенно переходят в себя. В целом очень интересная динамика развития.

Методология как конструктор: инструкция по сборке. Филипп Дельгядо

Пост на FB: Методология как конструктор: инструкция по сборке. Филипп Дельгядо] начал с цитаты: "Все методологии основаны на страхе: вы боитесь чего-либо, и делаете методологию, чтобы этих страхов избежать" - Кент Бек

Человек, который может полгода делать отчеты и не сойти с ума - редкая компетенция :)

Вообще доклад был о том, как собирать методику из разных практик. Стартуя как раз от страхов, они же риски, и от желаний. На примере реального проекта платежной системе, который разрабатывался с чистого листа. И за 9 месяцев они поменяли три процесса, для фазы начальной разработки, потом на внедрение, потом на этапе эксплуатации. Содержание я пересказывать не буду, потому что оно прекрасно все, там много неожиданных вишенок, помимо демонстрации сборки конкретной методики, а также проектирования и реализации процессов смены методики.

В финале было три убеждения-афоризма.

Люди важнее процессов
Результаты важнее привычек
Убеждение эффективнее приказов

И одна из страшных привычек - привычка к карго-культу.

И мне очень понравился набор практик фазы начальной разработки.

Право на Зачем - всякий имеет право спросить.
- Очень важно записать правило - некоторые с детства боятся.
- Уменьшается объем задач и увеличивается мотивация.
До трех не обобщать - и для разработки
IDE Driven Development - то, что позволяет IDE - то и делаем.
- А что не поддерживается (например аспекты) - не делаем.
- Дописывали специальный код, чтобы call-стек акторов посмотреть
Пятничный тортик вместо ретроспективы. Потому что с ранее незнакомыми людьми в команде ретро не получится.

Стас Фомин Похоже сильно пересекается с его предыдущим докладом → если кто хочет посмотреть → http://0x1.tv/20181012AB

Филипп Дельгядо Не очень сильно пересекается, я старался. На SECR я в основном говорил про смену методики, это где-то треть-четверть доклада с TeamLeadConf. Но некоторые практики я повторяю как можно чаще, просто потому что так скорее они станут самоочевидными.

Стас Фомин Ну, пока они неочевидны, и местами вызывают странные реакции

Филипп Дельгядо Ну, не бывает докладов, которые всем нравятся. Если бы были бы обоснования - то может быть к реакции можно было бы как-то отнестись, а без этого конкретных вопросов реакция вообще неинтересна ) Но SECR реально странная конференция, кто бы спорил )

Сергей Добриднюк IMHO мотив "наемника" , у предпринимателя страх другого рода.. Ну не знаю как сказать поточнее - ну типа - вы можете взять в руку таракана ? Нет не страшно, и даже не опасно , но как то ... противно. Можно ли назвать это страхом ? Или это драйв, которые отвергает страх как ресурс, заменяя его "противностью" оказаться слабаком или упустить ситуацию из под контроля. Опять же собственник-предприниматель при всем уважении к процессному подходу - частенько сам же его и нарушает, ища в этом новые возможности. Зачем ему "бетонировать" процессы, если завтра об них можно расшибиться ?

Филипп Дельгядо Ну, вообще можно заменить слово страх на "сильная негативная эмоция". Содержание не изменится, а вот читаться будет хуже. Все-таки доклады (и популярные книги) больше про "запоминаемость", чем про "корректность".

Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров

Пост на FB: Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.

Системно, с деталями, например, про базовые качества:

Ответственность. Спросите об ошибке
- Когда увиливает - не страшно, пробуйте раскрутить
- Антипаттерн - когда ответственность сваливает на других
- Позитивно - когда ошибка понята и отрефлексирована и была соломка подстелена
Спросите о результатах, которых достигли за несколько лет
- Если 5 лет "работу работал" - значит ориентирован на процесс, а не на результат. Нужны и те и другие, но для разных задач
Увлеченность. Спросите про хобби и увлечения.
- Если увлеченный человек не увлечен работой - это ваш провал.
Парадигма общения. Были ли у сотрудника конфликты, и как он выходил
- 5 парадигм: win-win, win-lose, lose-win, lose-lose, WIN (им не важно, что вокруг)
- У каждого человека есть парадигма для стабильных условий, и скрытая, проявляющееся в жестком стрессе.
- Скрытую парадигму тоже стоит выявить - как раз через разговоры о конфликтах

Аналогично было про профессиональные качества.

Про проблемы лучше начать с новичков - они еще не привыкли к проблемным местам. Начинать лучше с проблем команды, а не бизнеса - иначе тебя воспримут не как тимлида, а воспримут как kpi-менеджеру.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 00:14, 6 апреля 2019 • нет комментариев

2019-04-06: Собрал отчеты по февральским WIAD и TeamLeadConf