Часть видео опубликована на Хабре с конспектом докладов. 
В июне все видео были опубликованы на сайте конференции

Два дня, 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-шников). Фидбэк надо Не принимать, но учитывать - это лишь одно мнение. И ты решаешь, насколько измениться. Учила фидбэку в клубе спикеров, где желающие готовились выступать на конференциях. Поэтому фидбэк - публичный и экологичный. Например, правило трех плюсов: не нашел их - молчи. А нашел - можешь высказаться. Но критика - в залоге, что можно улучшить, конструктив, а не негатив. И много-много других мыслей про фидбэк.