24-25.09 в Петербурге прошла Saint TeamLeadConf - вторая из серии конференций для тимлидов команды Олега Бунина. Первая была в феврале в Москве, и я рад отметить, что качество конференции в Петербурге оказалось столь же высоким. Два дня очень насыщенных докладов, показывающих актуальную повестку управления командами в IT, включая лидерство, мотивацию и развитие персонала.
Я знаю, что меня читает довольно много тренеров и коучей, которые не входят в IT-сообщество. И я рекомендую им смотреть записи этой серии конференций (сейчас доступно видео за февраль, через некоторое время выложат эти записи), потому что повестка управления командами в IT будет становиться повесткой для управления в других отраслях по мере прихода цифрового мира, то есть почти завтра. Особенно это актуально для тех, кто работает или планирует работать с IT-компаниями - надо знать и понимать своих клиентов. Понятно, что смотреть много видео - требует затрат, но можно для начала познакомиться с этим моим отчетом, статьей организаторов с конспектом и видео части докладов по итогам февральской конференции и моим отчетом о ней, а потом уже решить для себя, стоит ли смотреть.
Я хочу отметить, что уровень осознанного управления, с применением знаний по лидерству, психологии, мотивации, а также применению разнообразных метрик - высокий, и это проявляется уже на уровне управления командой или группой, а не только на уровне компании или уровне профессиональных тренеров, консультантов и коучей. Конечно, на конференции были представлены лучшие доклады. Но при этом большинство выступающих не занимает топовых позиций, то есть можно говорить, что это соответствует уровню верхней трети сообщества тимлидов, а не фронтиру.
И, в частности, отмечу, что использование метрик для процесса и оценки команды, включая softskill является уже повседневным инструментом, при этом люди активно конструируют собственные наборы метрик с учетом специфики конкретной компании, подразделения или проекта. Используя при этом различные источники и литературу, но именно конструируя на их основе, а не механически перенося к себе прочитанное. И это делают тимлиды, а не только менеджеры высокого уровня или профессионалы из HR. Отмечу, кстати, что применяется термин "метрики" или "показатели", а не "KPI", потому что "KPI" достаточно сильно коннотирует с механическим использованием показателей для расчета зарплаты или оценки персонала и эта коннотация обесценила термин. При этом в IT такой механический расчет зарплаты точно не применим. Метрики и показатели должны оценивать здоровье команды и разворачивающихся процессов, сигнализировать о проблемах, а не служить однозначной оценкой.
Еще отмечу, что управление с учетом ценностей сотрудников так же является повседневным инструментом. И мой доклад Разделение ответственности в IT-командах - практики бирюзовых организаций на каждый день (SaintTeamLeadConf-2018) слушатели воспринимали и обсуждали после доклада в практическом залоге применения практик, а не просто интересного знакомства, разбирая кейсы в компании и варианты ответов.
Приведу отзыв Олега Бунина. Максим Цепков посещает множество конференций, много знает и активно делится опытом. На Saint TeamLead Conf он нам рассказал о бирюзовой организации. Все ей интересуются, живо обсуждают, но чаще всего разбираются плохо и живых примеров не видели. Сегодня мы поняли, каково это, когда ответственность за решения на исполнителе.
Впечатляющая картина организации процесса вокруг ценностей была в докладе Евгения Пешкова из Додо-пиццы. Их пока немного, 60 человек и они рассчитывают, что LeSS, который они используют, позволит им управлять до 200-250 человек. А Юля Курапатенкава из Spotify рассказывала о структуре, которую они строят для компании, в которых счет племен из 100-200 человек сильно превышает десяток - появляется достаточно сложная структура. Подробнее об этом можно прочесть дальше, в моих заметках по докладам.
Н, наконец, замечу, что на конференции был отдельный трек по управлению знаниями в IT-компаниях, где было много интересных докладов.
Дальше будут мои заметки, которые я публиковал во время докладов. Отдельно отмечу, что в них - только пловина докладов конференции, потому что она идет в два трека. И мне часто хотелось пойти на оба параллельных доклада. Так что не надо думать, что мои заметки показывают все содержание конференции. А еще я хочу поблагодарить Олега Бунин за высокую оценку заметок: "Если хочешь быть в курсе деталей лучших докладов самых крутых IT-конференций - подписывайся на Максим Цепков, его конспекты мы неоднократно использовали в своей работе!" А еще - пожелать дальнейших успехов Олегу Бунину и всей команде конференции!
Пост на FB Yuliya Kurapatenkava Spotify. Превосходный рассказ про устройство spotify изнутри и его эволюцию в процессе роста. Рассказ на английском, потому что многие термины не переводятся на русский. И этот подход - правильный, в начале был словарь терминов, тоже по-английски, и эти объяснения вносят важные акценты, которые не сохраняются в переводных описаниях, которые я читал.
Они масштабируются, и структура реально сложная и многоуровневая:
Но, отмечу, что на схемах она еще и не полностью выдержана. Отчасти потому, что она быстро меняется, и накладываются разновременные конструкции.
Для координации работы - многофокусное управление по целям, которое ведут разные лидеры:
И эта конструкция требует не просто хороших коммуникативных навыков для решения вопросов, она требует эффективной договороспособности разных лидеров в рамках общих целей.
В конце был вопрос: а как же самоорганизующаяся команда, на схемах почему-то много менеджеров и лидеров? Ответ: оказалось, что самоорганизующаяся команда очень плохо масштабируется на большую организацию (много трайбов). Опыт показал, что они работают из уровня трайба, а не уровня компании целиком, а для растущей команды с внешними инвесторами важно показывать показатели динамики роста. Поэтому идет усложнение структуры, и постоянные эксперименты над новой структурой, отказ от практик, показавших неэффективность, например, отдельного agile коуча для команды. Но при этом они следят за сохранением существовавшей культуры и ценностей.
Кстати, энтропия - играет. Доклад был по скайпу - Юля заболела и не смогла приехать. В начале доклада связь вырубилась, была пауза. И в ходе ответов на вопросы ряд критических фраз пропадало. Следуя за Стругацкими (За миллиард лет до конца света) это свидетельствует о ценности доклада.
Пост на FB Стас Михальский Не договоренность сорвана, если релиз не выпущен, а договоренность была неверная, проваленная, и поэтому ее не смогли сделать. Все работа: заключение договоренностей и их выполнение, в них заключено все остальное.
Обязательство или обещание? Обещание - субпродукт, это уведомительное сообщение. А Обязательство - я беру на себя. Обязательство без обещания - много лучше, чем обещание без обязательства. И именно это проявляется в жизни.
Примеры: писать комментарии в коде, следить за актуальностью инфы в вики, прочесть книжку, вести учет времени, закончить релиз к среде. Все это важнее текущей культуры кодирования, потому что обеспечивает развитие человека. А вот договориться, чтобы человек реально прочитал-проработал книгу - сложно.
Договоренности срываются. Внезапно и на финише. Виды срывов: провал, формальное выполнение, подмена. Но мы не всегда регистрируем это как сорванную договоренность.
Пример: раскидывание 40 часов времени за неделю произвольно из головы по задачам. С моей точки зрения, пример очень спорный, потому что неявно полагается, что распределение времени из головы даст недопустимую погрешность. А это, вообще говоря, требует проверки и статистического подтверждения. Опыт говорит о том, что экспертные оценки, особенно если их корректировать по обратной связи и учат учитывать когнитивные искажения, являются достаточно точными для целей статистики.
Каждодневный контроль требует много времени. И плохо работает в IT - он вымрет.
Прочная договоренность основана на обязательстве и заключена с обязательным человеком. Надо повышать цену слова. Надо разговаривать с людьми об обязательстве. Договоренности нельзя изменить в одностороннем порядке. Но можно пересматривать.
Мощная метафора: разработчик как бизон. Уздечки не существует, он должен хотеть пойти в нужном направлении.
Обсуждение в комментариях.
Пост на FB Александр Зиза Коммуникации. Национальная коммуникация. Вокруг - мир.
В комментариях к посту общезначимость этих тезисов подвергалась сомнению, но в контексте доклада было понятно, что Александр говорит из своего опыта работы и взаимодействия с компаниями разных стран (он работал в американских компаниях), а основное назначение было - показать культурные различия, которые необходимо учитывать в коммуникации и работе с сотрудниками. И помнить, что конкретные методики и техники, описанные в книгах и учебниках, часто неявно подразумевают некоторую национальную культуру и могут при переносе в другой контекст работать вовсе не так, как ожидалось. И эту роль они выполнили.
Принципы эффективной коммуникации.
От себя замечу, что эти практики - принесены из классического менеджмента, они там отработаны. И они, с одной стороны, нужны и полезны в IT. Однако, надо помнить о двух моментах. Во-первых, они отработаны на задачах, имеющий низкий уровень неопределенности, а в IT это не так: написание кода - НИОКР, а не производство. Во-вторых, они отработаны в условиях профицитного рынка персонала, когда сотрудник чувствовал давление рынка и угрозу увольнения. А в IT рынок труда - дефицитен, и риск их ухода при излишнем давлении - высок..
Супервайзер сотрудника - ты в коммуникации показываешь пример - фокусировки на теме, выдерживания позиции. И сотрудник учится этому параллельно с основной коммуникацией. Это - базовый уровень, и именно его часто не выдерживают.
Психология: любое предложение прежде всего рассматривается с точки зрения "а не служит ли оно целям моей эксплуатации". Книга "Человек и ситуация".
Надо будет посмотреть на методику исследования, характеры коммуникаций, по которым шел анализ. Потому что моя версия: есть обратная зависимость между таким восприятием и уровнем доверия. А здоровой компании уровень доверия весьма высок. И тогда играют другие аспекты.
Тренинг по продажам для разработчиков. В результате разработчики научились торговаться за сроки выполнения задачи. А в замысле было совсем другое :)
Позиция коуча - не директивные указания, а работа через вопросы. Не давать советов без предметного вопроса от разработчика.
Модератор - не узнавать очевидное решение, отложить его на потом. Останавливать в себе шаблоны и узнавания. Не прерывать человека, пока он рассказывает ситуацию, слушать его видение, получить слабые сигналы. Увидеть тихого человека, у которого есть идея решения.
Конструкции мне понятны, но я не согласен, что такая коммуникация - наиболее эффективна, во всяком случае при жестко-тотальном применении.
В конце совет: Любой навык прорабатывается три недели. Три навыка: тотальный фокус, не советовать, не узнавать. Фиксировать оценками на каждой встрече самооценку. И в конце каждого слота - эссе о том что достиг.
Пост на FB Jane Goleva Обучение в IT. Схема.
Схема была пройдена на конкретном кейсе, где речь шла об обучении устройстве системы, одна общая лекция в замысле развалилась на разные мероприятия для разных аудиторий, у которых еще разная мотивация.
Там дальше были очень конкретные кейсы выявления проблем, которые должно решить обучение. Как от запроса "научим маркетологов SQL, чтобы они не роняли базу" приходить к конкретному полезному обучению. Или запрос на обучение обратной связи тимлидов преобразовать к фокус-встречам тимлидов для обмена опытом, и при этом фиксации хороших практик и подходов.
Пост на FB Alexey Kataev. Метрики команды. Skyeng 2015 - он один из 5 разработчиков. Сейчас - 15 команд и 68 разработчиков. И все работают удаленно. Одна команда была сапсаном, которая везла в прод. А сейчас есть вопросы.
Дальше был рассказ про метрики, которые помогают отвечать на эти вопросы. При чем не только про те удачные метрики, которые они используют, но и про неудачные пути и варианты с указанием на проблемы. Например, для измерение velocity по спринтам не получилось, потому не у всех есть спринты, у всех разные единицы измерения, а единообразие процессов - слишком дорого для получения метрик. Поэтому они пошли всего лишь на унификацию планов продуктов, и меряют, насколько команда его выполняет.
Из любопытного. Метрика "сколько мы выкатили", поддержанная ботом, который каждую неделю это пишет - гораздо лучше мотивирует, чем информационно та же самая метрика, фиксирующая, насколько мы опаздываем. А проанализировав, насколько факт трудоемкости превышает оценку, они нашли трудоемкость, с которой оценка становится пальцем в небо и потому нужно дополнительное исследование и декомпозиция. У них - 12 часов.
Они оценивают технический долг - есть полный список, по которому все разработчики ставят важность, по топ-20 из них есть оценки, и потому можно экспертно оценить остальное. И они смотрят динамику.
А задача, чтобы все команды были сапсанами должна решаться на старте команды. Для чего нужен review опытного тимлида по становящимся процессам и чек-листы, особенно если в команде тимлид новый. Это - дорого по времени, но окупается. Плюс чек-листы, как и в остальных случаях.
Пост на FB Max Babich. Управление знаниями через модели компетенций. Прикольное и содержательное введение в работу компетенциями на примере фильма Матрица, когда Тринити и Нео планировали с Пифией как вытащить Морфеуса.
Оценить уровень владения. Баллы, простые уровни. Чтобы не запутаться :) Например: не знаю, слышал, есть теория, есть практика. Хотите запутаться - добавьте "могу обучить" :)
Самооценка. Только если ясно, что от самооценки зависят деньги - убирайте. А еще она сильно искажается из-за эффекта Данинга-Крюгера.
Для обучения новичков лучше назначать не одного наставника, а несколько, разных для разных навыков. Это позволяет снизить нагрузку для наставника и выделить интересные им фокусы. А еще, когда наставников много - то человек обучается разнообразной коммуникации. И это - дополнительный бонус.
Да, чтобы компетенции оценивать - надо иметь матрицу компетенций, ее надо создать. В докладе ссылок не было, но я знаю минимум одну развивающуюся систему, которую можно использовать для старта https://sfia-online.org Еще есть российские проф.стандарты, но они гораздо менее удобны.
Развитие в процессе работы. За счет модели компетенций мы понимаем, какие задачи будут способствовать обучению. И важно, чтобы новичок их делал, а эксперт только помогал и/или проверял. А без модели держать фокус обучения - сложно.
Пост на FB Светлана Новикова и Константин Кафтан - очень интересный доклад про матрицу компетенций из одной компании но двух совершенно разных подразделений: одно на техподдержке, другое - разработка на Lua, которые работают в разных business unit. И общая канва наполнена сильно разными примерами, которые как раз позволяют оценить спектр возможных путей, показать их разнообразие. В команде Lua разработчикам нужна знать бизнес-предметку, и они погружали нового человека полгода, а хотелось - быстрее. Составление матрицы компетенций в результате позволило сократить этот срок до 2 месяцев, пересмотрев программу подготовки и выделив core-часть. А еще - нашли энтузиастов и драйверов по разделению знаний, и только 1 из 40, кто не хотел делиться своими уникальными компетенциями. И, совершенно неожиданно, нашли профит для кодирования: функционал, который надо вынести в серверные библиотеки и не изобретать велосипеды.
Пост на FB Евгений Пешков. Додоверие. Ценности и принципы в компании Додо Пицца. Про ценности Додо Пиццы я многое слышал, они часто выступают. Но узнать изнутри - понимаешь важные акценты и общую атмосферу компании. Атмосфера - это очень важно, и она в докладе была передана замечательно. Слушатели заглянули в изумительный новый мир.
А по фактуре - они небольшие, 60 человек, у них сейчас LeSS, который обеспечивает организацию, и они полагают, что до 200-250 человек он потянет. Они быстро растут вместе с компанией, это период по Адизесу называется "Давай-давай", когда результативность важнее эффективности, и на стоимость процесса не сильно обращают внимание. Много практик XP, очень любят парное и коллективное программирование, особенно для функционала, который делается "по-новому" - чтобы все понимали реализацию. Общее владение кодом. Обязательна работа в полях - в пиццериях, на кухне и курьерами, используя свои приложения и понимая все косяки, и это - общий подход в Додо для всех руководителей тоже.
В комментариях состоялось интересное общение и Димой Безуглым.
Психологические механизмы это и есть не честность с собой ... А преукрашивание истории на публику , ведет к появлению новых персонажей в этом чудном мире. Только вот в соответствии с когнитивной ошибкой "выжившего" мы никогда не увидим их докладов на конференциях ...
Мы с Евгением еще поговорили на конференции, я объяснил, что я подразумеваю под рисками культуры, которая у них есть, судя по рассказу. Но, как я уже написал в комментарии Диме, в целом с отношением к инженерным практикам у них все в порядке, так что, скорее, тут вопрос про поиск конкретных практик, направленных на предотвращение потенциальных проблем, но не препятствующих росту.
Пост на FB Andrey Timonich Tinkoff.ru. Рассказ компании, для которой процессы и ценности в IT - средство, а не цель. Поэтому они собирают хорошие практики из разных источников в целостную структуру, ориентированную на производительность разработчиков с выходом в состояние потока, на совершенствование мастерства и ощутимые результаты труда. Что важно - при такой сборке появляются те самые ценности, которые звучат и в докладах тех компаний, которые на ценности делают ставку. И получается, что новая конструкция процессов и ценностей в IT уже общепринятая практика и почти гигиенический стандарт. И это - круто и вдохновляет.
Пост на FB Анатолий Панов. Рассказ человека, которому впервые пришлось нанимать тимлидов - до этого он нанимал только разработчиков, а тимлиды росли внутри. И теперь Анатолий по свежим следам рассказывает о процессе, который получился. Он близок к книге Джефф Смарт и Рэнди Стрит "Кто. Решите вашу проблему номер один", на которую Анатолий ссылается, но наполнен IT-спецификой. И поможет другим сделать тот же переход.
Пост на FB Евгений Кот. Рассказ о ситуации, когда ведущий разработчик становится тимлидом и становится несчастным - и как с этим справиться. Был роскошные перформанс под музыку о том, как наступает Адъ. Наваливаются совсем другие дела, а потом ты слышишь от разработчиков "Зачем ты смотришь код, ты же его уже не пишешь...".
А потом - тезис о том, что тимлиды - ветка развития, параллельная профессиональной. Тут я хочу заметить, что в 19 веке сформировались две школы менеджмента — английской и немецкой. Англичане растили менеджеров из джентльменов, без профессионального образования, и полагали, что джентльмен может управлять чем угодно. И эту модель восприняли американцы, школа MBA — продолжение этого. А в Германии руководители росли из профессионалов, и эту же модель восприняла Россия, и потом Советский Союз. IT тут в сложной ситуации, потому что чистые менеджеры без технического бэкграунда не могут руководить. Но при этом для профессиональной менеджерской подготовке в наше время нет времени, возможности и желания - поэтому люди учатся в темпе проекта и доклад был именно об этом.
Дальше были антипаттерны тимлидов, которые часто проявляются в жизни "сами собой". Такие тимлиды руководят, но являются тупиком в смысле развития. И они подробно разобраны, почему это так, и как именно можно иначе. Советы начального уровня - ограничь или исключи технические работы, это теперь не твое; структурируй работу; ограничь синхронные взаимодействия и открой канал асинхронных; прочти Дорофеева про time management.
А в заключении - концепт ikigai - найди смысл жизни, который у каждого свой.
Пост на FB Тимур Павлов, Positive Technologies. Рассказ о том, как выпуская года назад релиз они не уложились в сроки на 2 месяца. Анализ показал, что много времени ушло на исправление багов, и разработчики не успели сделать функциональные фичи. Из этого были извлечены уроки и Тимур рассказывал о пути, который они прошли за два года, внедренных практиках и решенных проблемах - там было несколько этапов процесса.
Пост на FB Серёжа Попов. Рассказ о компании, которая действует как школа обучения. Берут студентов-джуниоров, прогоняют их через проекты, они через 2-3 месяца выпускаются, приходят следующие. Делают верстку. В команде 3 джуна, тестировщик и наставник, они делают проект, 15 проектов сейчас. Начинали с другой структуры, и тестировщик появился не сразу. В управлении еще есть руководитель проекта, который снимает с Сергея часть задач, и тимлид команды наставников. В целом успешно развиваются.
Они не не зависимы, а ассоциированы с html-академией. Но работают как отдельный бизнес по экономике.
Любопытен список проблем у джунов, который они выявили и решают.
Про макеты: Проблема в том, что для целей обучения даваемые студентам макеты стремятся делать очень качественными и понятными, и это разительно контрастирует с реальными макетами, получаемыми от заказчиков. Настолько, что студенты психуют, столкнувшись с реальностью. А те, кто учит - еще и совершенствуют макеты, увеличивая отрыв.
Из уроков: что нельзя делать:
Очень важный опыт, который они дают - работа над реальными проектами. Работа с реальной версткой и макетами, большим количеством правок, дедлайнами и т.п. Они объясняют, что реальная жизнь - такова, и помогают включиться. И устроившиеся потом на работу - осознают полезность такой подготовки.
В общем "тяжело в учении - легко в бою" здесь работает.
Пост на FB Виктор Никишин из tinkoff.ru рассказывал про то, как они выделяли тимлидов из мидл-разработчиков. Интересно, что они во многом переоткрыли разделение ответственности менеджера в Scrum на Product Owner и Scrum Master, компетенции тимлида - не в hard skill, а в soft skill. Однако, они использовали другую модель - стили руководства Адизеса, и посмотрев на потребности пришли к тому, что тимлид должен иметь компетенции AI, а не PE, и именно так выбирали кандидатов. В целом - успешно, за полгода получилось, начав с команды в 10 человек получить 7 команд, в которых только один тимлид пришел готовым, остальные выросли внутри. При этом процессы в командах разные: Scrum, Kanban, Scrumban, без Agile - процессы выбирает сама команда. А сами команды - распределенные и многие удаленные, включая тимлидов.