TeamLeadConf-2019

Ссылки сюда (2) →

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

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

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

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

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

Как измерить производительность программиста? 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

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

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

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

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

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

Советы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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