Изменения

{{Conf-Ref}}

Два дня, 08-09.02.2018 был на новой конференции Олега Бунина для тимлидов [http://teamleadconf.ru/ TeamLead Conf]. 474 участника, и два трека очень хороших докладов. Очень высокий уровень по содержанию, по подготовке докладов, по компоновке программы. Я был на многих конференциях, достаточно много знаю в IT, так что ситуация, когда доклады в каждом слоте несут ценную для меня информацию, вызывают размышления - редкость. Тут было именно так. И, надеюсь, дальше будет не хуже. Потому что путь от разработчика к тимлиду - это актуальная тема. Я, кстати, специально не пишу "руководитель команды", потому что современный тимлид - он не классический руководитель. И вообще тимлиды - они очень разные, прежде всего потому, что компании - разные, у них очень разное распределение ответственности и обязанностей между сотрудниками, и, как следствие, очень разные тимлиды. И это разнообразие было в полной мере представлено на конференции.

'''Началась конференция''' очень грамотной раскаткой докладов: Nikolay Krapivnyy из badoo рассказывал про рост компании от десятка до сотен, а за ним Георгий Могелашвили из Booking.com рассказывает про рост IT от 400 до 1500. [https://www.facebook.com/mtsepkov/posts/1653855594671388 Пост на FB].

[https://www.facebook.com/mtsepkov/posts/1653843668005914 Пост на FB] '''Nikolay Krapivnyy из badoo'''. В целом очень интересный рассказ о внутреннем устройстве быстро развивающейся компании, выпускающий два релиза ежедневно, на сложном высоконагруженном продукте с достаточно сложной организацией компании. Спасибо!

[https://www.facebook.com/mtsepkov/posts/1653842334672714 Пост на FB] Nikolay Krapivnyy из badoo. Рассматриваем процесс разработки с точки зрения теории массового обслуживания по обработке запросов на разработку и применяем их методы оптимизации. Тут я хочу отметить, что это будет работать для типовых запросов, но плохо работает для сложных. Результаты каждый может наблюдать, когда сталкивается с организацией массового обслуживания в поликлиниках и больницах. И это - системная проблема, потому что и IT-разработка и лечение - умственный труд, плохо поддающийся регламентации, а теория массового обслуживания - для организации труда, который можно регламентировать.

[https://www.facebook.com/mtsepkov/posts/1653865344670413 Пост на FB] '''Георгий Могелашвили (Georgiy Mogelashvili) из Booking.com'''. Были команды с TeamLead и Product Owner, и они решили сделать команды без teamlead - потому что бурный рост, их не хватит. Эксперимент. Получилось. Георгий рассказывает, как разложились обязанности teamlead - решение конфликтов, фидбэк сотрудникам, выставление оценки. Реально интересно. Фидбэк, например, дают парами друг другу по графику. А оценки все ставят всем за круглым столом - и работает без конфликтов. Но все это - не само, bootcamp для команды и помощь на старте. В принципе, автономия сработала. Но возникают проблемы с ротацией сотрудников - сработавшиеся команды откатываются; ростом сотрудников без поддержки и engagement (они измеряли по google research perfect team). В результате teamlead вернулся, но в ограниченном объеме - он подключается только в ситуациях необходимой поддержки. Называется это servant leader. Основной фокус теперь - рост людей, но он отстраивает среду для этого, а не сам это делает. Так что в целом эксперимент говорит о том, что команда без Team Lead работает хуже, чем с ним, однако, автономность возможна, особенно в короткую, а помогать надо точечно.

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

[https://www.facebook.com/mtsepkov/posts/1653890824667865 Пост на FB] '''Евгений Россинский''' Очень интересный рассказ. У них были команды, сформированные по технологиям (backend, web, разные мобилки), где каждый руководитель был экспертом в технологии, подбирал и выращивал специалистов. Но были проблемы с time to market. И они перешли на команды по value stream. Но при этом разработчики в каждой команде правят общий код на каждой платформы, и релизный цикл - тоже по платформам. Поэтому команды по платформам - восстановились. И сформировалась довольно сложная конструкция, которую Евгений и рассказывал со многими деталями и особенностями организации и коммуникаций.

[https://www.facebook.com/mtsepkov/posts/1653913957998885 Пост на FB] '''Nina Scheglova''' из Lazada (Юго-Восточная Азия, технари в Москве, Въетнаме и Сингапуре) рассказывает про матрицу компетенций тимлида. Я тут подумал, что в IT, да и в другой технических отраслях часто смешивают soft skill, как коммуникационные, эмоциональные и другие компетенции, не связанные с профессиональной работой, с профессиональными компетенциями менеджеров. Ведь менеджер - это тоже профессия, и у нее есть свои hard skill.

: '''Максим Цепков''' Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов - важная составная часть. Наверное, что-то аналогичное и здесь.

: '''Ekaterina Semenova''' Ага. И прокачать можно видимо оба скилла

[https://www.facebook.com/mtsepkov/posts/1653959287994352 Пост на FB] '''Alexey Kataev skyeng'''. В целом очень хороший доклад про распределенную команду - как нанимать, как организовать общение - чтобы в целом команда работала не просто не хуже, а лучше обычной работающей в офисе. И в докладе - евангелизм удаленной работы, которая лучше обычной.

[https://www.facebook.com/mtsepkov/posts/1653949771328637 Пост на FB] Alexey Kataev skyeng. Крутая практика работы с тех.долгом - рефакторинг митап. Разработчики вывешивают карточки о всех костылях, которые ему известны. Потому что это - распределенное знание. Дальше уже понятно - обсуждение, превращаем в таски и приоритизируем. А входной митап - круто.

[https://www.facebook.com/mtsepkov/posts/1653987751324839 Пост на FB] '''Артур Орлов. 8 стратагем тимлида''' - клевый доклад о правильных паттернах поведения тимлида, стилизованных под китайские стратагемы. Много уроков - известно опытным, но для тех, кто тимлид недавно - они не очевидны. И подача очень классная.

: '''Максим Шаломович''' Максим Цепков, я принимаю тезис, несмотря на то, что живу в мире заказной разработки по ГОСТ 34, и вопрос документации для меня, как правило, определяется контрактными обязательствами))) Мне интересно именно из опыта команд, ориентированных именно на сохранение и передачу знаний - какая документация в этом им реально помогала (перечисленные мной в предыдущем комментарии примеры). С одной стороны я понимаю, что архитектурная документация (от HLD до моделей уровня кода) в первую очередь нужна архитектору, поэтому ее с трудом можно назвать эффективным способом передачи знаний от архитектора/аналитика разработчикам (в этом плане совместная работа и шаринг знаний реально должны работать лучше). С другой стороны не могу не заметить, что в крупных распределенных (во всех смыслах) проектах ротация разработчиков и даже лидов довольно высокая. И передача знаний без какого-то персистентного ее хранения (к которому я не отношу голову разработчика :-)), наверное, невозможна. Понятно, код должен быть максимально понятным, но код - это продукт реализации, до которого есть много других шагов (анализ, дизайн - пусть и в максимально легковесном варианте, в рамках гибких ЖЦ). А что еще поможет?

: '''Максим Цепков''' Я тоже живу в мире заказной разработки, и для части заказчиков мы делаем документацию по ГОСТ или их внутренней нормативке, так что мне это знакомо. Архитектурная документация точно нужна. И ротация разработчиков действительно довольно высокая. Но при этом опыт устная традиция в команде/группе/подразделений является одной из форм живого персистентного хранения. Об этом говорит мой практический опыт в IT, я наблюдаю это у многих заказчиков. Например, составление годовой отчетности ни в одном крупном банке не выполняется по регламентам, хотя они кое-где встречаются, но при этом традиция - живет. А дисциплина Управления знаниями. с которой я знаком, говорит, что это - правильно, что определение, какие знания делать явными и сохранять в артефактах, а какие держать на устной традиции - предмет управления.

[https://www.facebook.com/mtsepkov/posts/1654087517981529 Пост на FB] '''Andrew Minkin''' Учат ответственности стажеров - делают внутренний сервис, через который люди в команде заказывают себе еду в офис :) И они видят, что такое проект в продакшн и зачем надо тестировать. И ущерб конкретный показывают - негатив. Да еще просрочки пробуют вешать на них кормление офиса...

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

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

[https://www.facebook.com/mtsepkov/posts/1654779121245702 Пост на FB] Начало второго дня #teamleadconf '''Александр Киселев (Alexandr Kiselev) и Сергей Семенов (Sergey Semenov)''' - очень правильный доклад про метрики, измеряемые по коду и jira. Идея в индикативных метриках, разработанных под каждую проблему, которые привлекают внимание для разбора ситуации. В докладе - набор проблем и метрики для них. Индивидуальные проблемы - разработчики, которые почти не делают, или наоборот перерабатывают, или не дожимают задачи. Командные проблемы - недостаточно продумывание задачи, неравномерное знание о коде в команде, плохой onboard новых разработчиков, накопление технического долга. У них - стартап готового продукта, который это меряет. Но метрики - понятны, можно и самим мерить :)

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

[https://www.facebook.com/mtsepkov/posts/1654799507910330 Пост на FB] '''Григорий Петров (Voximplant)'''. Любопытный доклад, смесь физиологии мозга и работы со смыслами. Коммуникация, у менеджера проблема бизнеса из-за сроков разработки или бага, он приносит это сообщение, а разработчика опознает это как "менеджер ругается". Чтобы не было - надо формулировать сообщение так, чтобы оно не опознавалась как социальное взаимодействие двух людей, а как призыв выполнить социально принятый процесс. Например, переоценить сроки, или обсудить проблему. И много разных других приемчиков, включая использование и учет конотаций.

[https://www.facebook.com/mtsepkov/posts/1654969334560014 Пост на FB] '''Егор Толстой Performance review в Avito'''. Масштаб - 1500 оцениваемых, около 10к оценок, в среднем каждого оценивает 9-11 человек. Системе - 3 квартала, один квартал - эксперименты, два квартала по полной. И при этом одна оценка - 10 минут у респондента, 4 часа в квартал. Понятно, что оцениваемый и его менеджер тратят больше. И отдельные метрики, которые показывают, что оценка работает как процесс, позволяет выявить системные сбои (вернее, дает гипотезы о них). Мне довольно интересно сопоставить с нашей, которой уже много лет, и которая развивается. Масштаб у нас сильно меньше. Но вот идея, что главное - не оценка, а развернутый отзыв - она есть и очень важна. Интересно, что в Авито все начинается с самооценки, а еще оцениваемый сам формирует массив профилей ожиданий от него (дает ссылки), по соответствию которым и надо оценивать. И они отдельно разбираются с ситуациями, когда респондент оценивает не по этому профилю. а по собственным ожиданиям. А еще в авито были интересные эксперименты по анонимности: начинали с полностью анонимной обратной связи, и поэтапно двигаются к тому, чтобы сделать ее открытой.

[https://www.facebook.com/mtsepkov/posts/1654970017893279 Пост на FB] '''Круглый стол по выращиванию тимлидов'''. У Авито была практика "тимлид в кредит" - за знания. Отказались, потому что много людей выгорало: пытались продолжить писать код, но при этом еще работать как тимлид, не хватало сил. Теперь смотрят выявляют неформальных лидов, предлагают подтянуться и стать формальными.

Вообще круглый стол был большим и интересным, в телеграм-чате https://t.me/teamleadconf выложены фотки с досок (фиг долистаешь, но можно поиском "круглого стола"). Кстати, сам чат уже переименован в '''Боль Тимлида''' и обсуждение кейсов продолжается.

[https://www.facebook.com/mtsepkov/posts/1655001791223435 Пост на FB] '''Оценка задач Дмитрий Симонов (Dmitriy V. Simonov)''' В докладе много про разные скрытые факторы, которые оценку увеличивают и приемы ее уменьшения. Например, devops - профи наладит инфраструктуры выкатки и автотестов, сократив многократно сроки этих этапов. Нет своих - ищите. А терки в команде могут увеличить работы многократно. Например, по поводу правильной расстановки скобок у if. Многое решается регламентами, например, code style. Или по взаимодействию другими командами - чтобы зафиксировать взаимные ожидания.

[https://www.facebook.com/mtsepkov/posts/1655051124551835 Пост на FB] '''1000 и 1 фидбэк Jane Goleva''' (Lamoda, в inhouse 300 IT-шников). Фидбэк надо Не принимать, но учитывать - это лишь одно мнение. И ты решаешь, насколько измениться. Учила фидбэку в клубе спикеров, где желающие готовились выступать на конференциях. Поэтому фидбэк - публичный и экологичный. Например, правило трех плюсов: не нашел их - молчи. А нашел - можешь высказаться. Но критика - в залоге, что можно улучшить, конструктив, а не негатив. И много-много других мыслей про фидбэк.

{{wl-publish: 2018-02-11 02:29:44 +0300 | MaksTsepkov }}