2018-02-11: TeamLead Conf — впечатляющий старт

Из ленты: MaksWiki — Блог:Максима Цепкова [ru]

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

Было очень круто! Спасибо докладчикам, спасибо вам, Олег Бунин, Александр Зиза, Роман Побочий, и всем остальным организаторам за работу над замечательной программой!

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

Дальше в посте — мои заметки про доклады. Хочу отдельно отметить, что потоков было два, а я — один. И в ряде случаев я выбирал между двумя интересными докладами. И иногда даже не мог выбирать, потому что сам делал доклад, и поэтому поэтому пропустил доклад Александра Зиза про поиск тимлида… Так что не воспринимайте написанное далее как полный список хороших докладов конференции. Их — больше.

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

Пост на FB Nikolay Krapivnyy из badoo. В целом очень интересный рассказ о внутреннем устройстве быстро развивающейся компании, выпускающий два релиза ежедневно, на сложном высоконагруженном продукте с достаточно сложной организацией компании. Спасибо!

Пост на FB Nikolay Krapivnyy из badoo. Характерный штрих по темпам современной разработки. Малое изменение за пару дней, а не несколько часов это проблема. В пару дней надо укладывать мини-проект для рекламной компании, а то окно возможностей закроется. Где в enterprise мыслят в таком темпе разработки?

Пост на FB Nikolay Krapivnyy из badoo. Рассматриваем процесс разработки с точки зрения теории массового обслуживания по обработке запросов на разработку и применяем их методы оптимизации. Тут я хочу отметить, что это будет работать для типовых запросов, но плохо работает для сложных. Результаты каждый может наблюдать, когда сталкивается с организацией массового обслуживания в поликлиниках и больницах. И это — системная проблема, потому что и IT-разработка и лечение — умственный труд, плохо поддающийся регламентации, а теория массового обслуживания — для организации труда, который можно регламентировать.

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

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

Пост на FB Евгений Россинский Очень интересный рассказ. У них были команды, сформированные по технологиям (backend, web, разные мобилки), где каждый руководитель был экспертом в технологии, подбирал и выращивал специалистов. Но были проблемы с time to market. И они перешли на команды по value stream. Но при этом разработчики в каждой команде правят общий код на каждой платформы, и релизный цикл — тоже по платформам. Поэтому команды по платформам — восстановились. И сформировалась довольно сложная конструкция, которую Евгений и рассказывал со многими деталями и особенностями организации и коммуникаций.

Пост на FB Nina Scheglova из Lazada (Юго-Восточная Азия, технари в Москве, Въетнаме и Сингапуре) рассказывает про матрицу компетенций тимлида. Я тут подумал, что в IT, да и в другой технических отраслях часто смешивают soft skill, как коммуникационные, эмоциональные и другие компетенции, не связанные с профессиональной работой, с профессиональными компетенциями менеджеров. Ведь менеджер — это тоже профессия, и у нее есть свои hard skill.

А вообще доклад — очень интересен разнообразными практическими примерами, фрагментами матрицы — soft skill гибкого мышления, лидерства в их интерпретации и своими 3 уровнями… Понятно, что полную матрицу в докладе не расскажешь, но в конце презентации они обещали ее опубликовать, вместе со списком источников.

В конце презентации — слайд со ссылками. Матрица тимлида https://goo.gl/zPw4GH еще есть тестировщика, программиста и дизайнера.

В комментариях к посту есть обсуждение содержания матрицы, а еще — обсуждение разницы soft skill и hard skill менеджера, которое я скопирую.

Ekaterina Semenova Hard skills менеджера мы целенаправленно не расписывали — они очень отличаются даже в рамках одной компании. Где-то много-много специфичных инструментов, а где-то — макросы и программирование в Экселе.
Максим Цепков Екатерина, мне кажется, Вы hard skill менеджера понимаете в IT-смысле — как владение определенными IT-инструментами. А я их понимаю по-другому, а именно, как как профессиональные скилы менеджера. Они ведь есть. То есть деление на soft skill и hard skill — не по тому, используются ли какие-то технические средства, а потому, что hard skill связаны с профессией (дисциплиной), а soft skill — от нее не зависят. Менеджер — это профессия, а менеджмент — дисциплина и у нее есть свой набор hard skill, которых учат, обучая менеджменту.
Ekaterina Semenova Теперь я поняла о чем Вы. С такой трактовкой понятий получается довольно интересно. С одной стороны у тимлида должны быть hard skills команды (программирование/ тестирование). И возможно Вы правы, когда разработчик переходит в тимлиды — его скилл, например, коммуникации становится hard skill’ом. Это можно будет обсудить отдельно.
Максим Цепков Там тонко. Возьмем аналитика. У него есть soft skill коммуникации и умение писать тексты, и есть hard skill проведения интервью (с фиксацией результата), в котором коммуникация и написание текстов — важная составная часть. Наверное, что-то аналогичное и здесь.
Ekaterina Semenova Ага. И прокачать можно видимо оба скилла

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

Пост на FB Alexey Kataev skyeng. Вовлеченность обеспечивает общение, а не сидение в одной комнате. Поэтому hangout, камеры и много совместных встреч по работе и даже online-игры.

Пост на FB Alexey Kataev skyeng. Крутая практика работы с тех.долгом — рефакторинг митап. Разработчики вывешивают карточки о всех костылях, которые ему известны. Потому что это — распределенное знание. Дальше уже понятно — обсуждение, превращаем в таски и приоритизируем. А входной митап — круто.

Пост на FB Артур Орлов. 8 стратагем тимлида — клевый доклад о правильных паттернах поведения тимлида, стилизованных под китайские стратагемы. Много уроков — известно опытным, но для тех, кто тимлид недавно — они не очевидны. И подача очень классная.

  • Не стоит бросаться на все амбразуры самому — герой всегда остается один…
  • Когда задачи сообразны навыкам и компетенциям — не возникает обманутых ожиданий
  • Формируй культуру бесстрашных ошибок
  • Разработка и тестирование — одна команда, объединяй, а не разъединяй!

И так далее…

Артур выложил презентацию https://goo.gl/gF7o4q

Пост на FB Артур Орлов В ответе на вопросы о способах передаче знаний — много практик, а вот «написать документацию» — не звучит. Спрашиващий развивает тему и получает явный ответ: «документация без человека все равно не позволяет все понять, это уже пройденный этап».

В комментах к посту развернулась дискуссия по этому поводу. Мне кажется, она интересна, и я ее сюда скопирую.

Максим Шаломович На мой персональный взгляд — одно из самых спорных высказываний в докладе. Возможно, спрашивающий и докладчик сильно по-разному понимают документацию.
Максим Цепков Я думаю, скорее, у спрашивающего паттерн, что документировать — это передать знания. Есть такой. Но неверный, это весьма ограничено работает. И Артур это уже знает :)
Артур Орлов Согласен с тем, что высказывание спорное, постараюсь прояснить, свой ответ. Насколько я понял вопрос, он касался документирования знаний по собственно написанному коду, и вот в этом случае, на мой взгляд, она избыточна — код и так должен давать понять что и как он делает. Что касается документации того, что не имеет отражения в коде — то, конечно, она может быть полезной, если понятно, какие задачи она решает. Задокументированный стайлгайд и какие-то базовые принципы, например — очень полезная штука, хоть и не большая.
Максим Шаломович Ну хорошо, давайте конкретизируем. Документированные требования (например, несколько юзкейсов уровня всей системы, «черный ящик», и много юзкейсов уровня каких-нибудь подсистем/компонентов/элементов, «белый ящик»)? Документированная архитектура хотя бы уровня структуры, ответственности элементов и интерфейсов взаимодействия? Документированные принципы разработки для отслеживания архитектурных решений a-la тех, что пропогандирует Саймон Браун (для устранения разрыва между моделями и кодом)? Что-то из этого по Вашему мнению и (или) опыту нужно для сохранения и передачи знаний?
Максим Цепков Я вмешаюсь в дискуссию… Тезис был не в том, что документация не нужна. Тезис был в том, что для сохранения знаний необходимо организовывать специальную коммуникацию в команде, когда знания передаются от человека к человеку, а документация сама по себе передачу знаний не обеспечивает. Если мы этот тезис принимаем (а я считаю его справедливым), то вопрос о документации становится вторичным, и ее количество и формы определяются участниками коммуникации — им что-то легче описать, чем запомнить и они это делают.
Артур Орлов Да, все именно так. Собственно, потому мне кажется работающим принцип, что лучшая документация создается тем человеком, которому она понадобилась, он получил ответы на свои вопросы в команде, зафиксировал. Тогда это действительно «работающая» документация )
Максим Шаломович Максим Цепков, я принимаю тезис, несмотря на то, что живу в мире заказной разработки по ГОСТ 34, и вопрос документации для меня, как правило, определяется контрактными обязательствами))) Мне интересно именно из опыта команд, ориентированных именно на сохранение и передачу знаний — какая документация в этом им реально помогала (перечисленные мной в предыдущем комментарии примеры). С одной стороны я понимаю, что архитектурная документация (от HLD до моделей уровня кода) в первую очередь нужна архитектору, поэтому ее с трудом можно назвать эффективным способом передачи знаний от архитектора/аналитика разработчикам (в этом плане совместная работа и шаринг знаний реально должны работать лучше). С другой стороны не могу не заметить, что в крупных распределенных (во всех смыслах) проектах ротация разработчиков и даже лидов довольно высокая. И передача знаний без какого-то персистентного ее хранения (к которому я не отношу голову разработчика :-)), наверное, невозможна. Понятно, код должен быть максимально понятным, но код — это продукт реализации, до которого есть много других шагов (анализ, дизайн — пусть и в максимально легковесном варианте, в рамках гибких ЖЦ). А что еще поможет?
Максим Цепков Я тоже живу в мире заказной разработки, и для части заказчиков мы делаем документацию по ГОСТ или их внутренней нормативке, так что мне это знакомо. Архитектурная документация точно нужна. И ротация разработчиков действительно довольно высокая. Но при этом опыт устная традиция в команде/группе/подразделений является одной из форм живого персистентного хранения. Об этом говорит мой практический опыт в IT, я наблюдаю это у многих заказчиков. Например, составление годовой отчетности ни в одном крупном банке не выполняется по регламентам, хотя они кое-где встречаются, но при этом традиция — живет. А дисциплина Управления знаниями. с которой я знаком, говорит, что это — правильно, что определение, какие знания делать явными и сохранять в артефактах, а какие держать на устной традиции — предмет управления.

Пост на FB Andrew Minkin Учат ответственности стажеров — делают внутренний сервис, через который люди в команде заказывают себе еду в офис :) И они видят, что такое проект в продакшн и зачем надо тестировать. И ущерб конкретный показывают — негатив. Да еще просрочки пробуют вешать на них кормление офиса…

Пост на FB Andrew Minkin Если хочешь научить — надо сделать ситуацию для обучения, и то, что он не прав — должен сказать не учитель, а среда. Например, если не пишет документацию — отдай его проект на развертывание другому, не знакомому с проектом. И покажи, что с докой было бы гораздо проще обоим.

В комментариях было обсуждение про эффективность подобной методики.

Эдуард Галиаскаров А практическое воплощение этой умной мысли есть?
Andrew Minkin Могу поделиться опытом как я делаю это в команде. Через несколько месяцев смогу поделиться как я это сделаю в учебном центре. Если конечно у меня получится :)
Эдуард Галиаскаров Интересно, конечно. Я пытался разыграть ситуацию: один студент пишет проектную документацию, другой ее реализует. При этом оценивается только проект, который соответствует проектной документации. В результате стал врагом номер один, похерителем гениев и талантов. Так что пока не решаюсь на повторные эксперименты :)
Игорь Бородихин Нужно измерять эффективность команды с применением этого метода и без, на короткой и длинной дистанции. Может внезапно получиться, что кроме издевательств над джунами (что само по себе неплохо в рамках их профессионального роста) для бизнеса никакого профита такая методика не приносит.
Максим Цепков Игорь, как раз рост джунов и был целью данной методики — потому что все это делали в рамках стажировки кандидатов в компанию. Эффективность стажировки компания меряет — количество и уровень сотрудников, которые пришли в компанию после стажировки против количества трудозатрат сотрудников компании на стажировку. И это — была не первая стажировка, которую компания проводит, так что они смотрят динамику, а эти методы как раз способ обеспечить эффективность для бизнеса.
К сожалению, в социальной сфере нельзя поставить чистый эксперимент: сдублировать команду, потом к одной копии применять некоторый метод обучения, а к другой — его не применять, или применить другой, и дальше сравнить результат. Поэтому такие предложения — не реализуемы.

Пост на FB Начало второго дня #teamleadconf Александр Киселев (Alexandr Kiselev) и Сергей Семенов (Sergey Semenov) — очень правильный доклад про метрики, измеряемые по коду и jira. Идея в индикативных метриках, разработанных под каждую проблему, которые привлекают внимание для разбора ситуации. В докладе — набор проблем и метрики для них. Индивидуальные проблемы — разработчики, которые почти не делают, или наоборот перерабатывают, или не дожимают задачи. Командные проблемы — недостаточно продумывание задачи, неравномерное знание о коде в команде, плохой onboard новых разработчиков, накопление технического долга. У них — стартап готового продукта, который это меряет. Но метрики — понятны, можно и самим мерить :)

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

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

Пост на FB Григорий Петров (Voximplant). Любопытный доклад, смесь физиологии мозга и работы со смыслами. Коммуникация, у менеджера проблема бизнеса из-за сроков разработки или бага, он приносит это сообщение, а разработчика опознает это как «менеджер ругается». Чтобы не было — надо формулировать сообщение так, чтобы оно не опознавалась как социальное взаимодействие двух людей, а как призыв выполнить социально принятый процесс. Например, переоценить сроки, или обсудить проблему. И много разных других приемчиков, включая использование и учет конотаций.

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

Пост на FB Круглый стол по выращиванию тимлидов. У Авито была практика «тимлид в кредит» — за знания. Отказались, потому что много людей выгорало: пытались продолжить писать код, но при этом еще работать как тимлид, не хватало сил. Теперь смотрят выявляют неформальных лидов, предлагают подтянуться и стать формальными.

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

Пост на FB Оценка задач Дмитрий Симонов (Dmitriy V. Simonov) В докладе много про разные скрытые факторы, которые оценку увеличивают и приемы ее уменьшения. Например, devops — профи наладит инфраструктуры выкатки и автотестов, сократив многократно сроки этих этапов. Нет своих — ищите. А терки в команде могут увеличить работы многократно. Например, по поводу правильной расстановки скобок у if. Многое решается регламентами, например, code style. Или по взаимодействию другими командами — чтобы зафиксировать взаимные ожидания.

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

Источник