Заметки техлида

Привет. Меня зовут Петр, я корпоративный архитектор в компании Xsolla. До этого я 3 года был техлидом первой в компании распределенной команды.

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

Каждый совет обязателен не к слепому следованию, но к самостоятельному осмыслению.

Кто такой техлид в Xsolla

В нашей компании разработка выполняется в рамках продуктовых команд. Обычно в команде есть следующие специалисты:

• Product owner;
• Техлид;
• Разработчики;
• Тестировщики;
• Аналитики;
• Технические писатели.

Также в команде могут присутствовать дизайнеры, маркетологи и другие специалисты. Видно, что команды у нас являются кросс функциональными.

Техлид выполняет следующие обязанности:

• Scrum mastering;
• Работа над продуктом (в том числе собственно кодирование): реализация фичей, обеспечение качества, оперирование продуктом (например, обработка возвратов заказов, выгрузка отчетов и т.д.);
• Обеспечение технического качества продукта;
• People management.

Эти пункты достаточно объемные сами по себе, поэтому суммарно набор обязанностей и зон ответственности у лидера команды большой.

Note: здесь и далее я буду использовать слова “техлид” и “лид” в качестве синонимов.

Советы

Совет 1. Знай свою методологию.

Каждая команда работает по какой-либо методологии разработки, будь то kanban, scrum или что-то иное. Каждая такая методология призвана решать проблемы и достигать цели. Для этого она предоставляет принципы, которым необходимо следовать, и инструменты, которые необходимо использовать.

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

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

Совет: найдите пару хороших книжек или курс, которые помогут в достаточной мере углубиться в материал. Я рекомендую интенсив от ScrumTrek и курс по скраму от Ионов&Партнеры.

Совет 2. Знай не только свою методологию.

Этот совет относится к коммуникациям с другими командами: в рамках компании могут применяться несколько методологий.

Самая распространенная в продуктовых командах, где необходимо итеративное движение и максимально быстрое получение обратной связи — это, конечно же, scrum, он используется в 41% команд (согласно исследованию). В сервисных командах (например администраторы, технические писали), где работа носит “потоковый” характер — kanban.

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

Совет 3. Учи команду работать по scrum/kanban (нужное подчеркнуть), хоть и учить придется долго.

В данном случае речь идет про реальное принятие командой ценностей выбранной методологии. Я расскажу про scrum, т.к. в моей команде мы работали именно с ней.

Основная цель итеративной разработки продукта — максимально быстро доставлять минимальный объем бизнес ценности. Со стороны разработки это выглядит следующим образом — за итерацию (например, за 2 недели), выкатывать работающий продукт или его часть (например, одну фичу). Особенность в том, что этот кусочек должен реально работать.

Давайте разберем на примере. У нас есть очень большая фича, которая технически состоит их трех компонентов: backend, frontend и мобильное приложение.

Плохой вариант — сначала сделать один компонент, потом второй, потом третий. Например, как на картинке ниже:

Здесь мы сначала реализуем и выкатываем backend, затем frontend и затем обновляем мобильное приложение. И только после этого фича считается доставленной.

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

Обратный этому подход — доставка части фичи, сразу по всем трем компонентам.

В данном случае торт-фича разрезается не горизонтально, а вертикально.

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

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

Совет 4. Знай свои инструменты

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

Помню, когда я только стал техлидом, я увидел у своего начальника Evernote (или что-то такое) с тысячей заметок и чуть в обморок не упал. Буквально через пару месяцев я купил на свои кровные годовую подписку на Notion, чтобы там разместить все, что моей душеньке угодно. Однако на этом инструменты не заканчиваются. Необходимо на должном уровне использовать все, что необходимо для выполнения своей работы и работы в команде:

1. Календарь: обязательно настройте уведомления о всех важных мероприятиях на всех рабочих устройствах: в браузере, на телефоне и даже чтобы на часах показывались нотификации. Тут я люблю говорить, что голова не для того, чтобы все это помнить, а для того, чтобы думать.
2. Notion: шикарный инструмент, поражающий своей гибкостью. В нем можно вести список заметок, kanban-доски, календари и еще кучу всего. Там я фиксирую множество заметок: как рабочих, так и личных. Там же кстати у меня находится публичная “книжная полка”.
3. Инструменты коммуникации.
   - На текущий момент мы пользуемся инструментами из GSuite: Google Chat — для текстовой коммуникации, Google документы — для написания документации, и Google Meet — для аудио- и видеосвязи. Он нас полностью устраивает.
   - Но нельзя забывать о запасном варианте в наше беспокойное время. В моменты, когда не работает основной инструмент, мы использовали Discord, сейчас же используем его на постоянной основе.
4. Инструменты управления проектами.
   Даже после того, как я перестал быть лидом команды, мне иногда необходимо поработать с каким-либо проектом. Для этого я в основном использую JIRA/Confluence (если проект внутри компании), Trello/Google Docs (если проект предполагает участников вне компании);

Суммарно можно сказать, что инструменты (в т.ч. те, что я описал выше) призваны решить множество проблем и без того непростой задачи разработки ПО. Умелое использование инструментов поможет эффективно решать свои задачи тебе и твоей команде.

Совет 5. “Меняй, замеряй, проверяй, повторяй”

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

Это же должна понимать и команда, и вы все вместе должны работать над улучшениями, в том числе улучшения процессов разработки.

Необходимо понимать, что нельзя улучшить всё и сразу. Масштабные изменения требуют большого количества времени.

Еще один пункт, на котором я заострю внимание — это “замеряй”. Важно понимать, какая сейчас ситуация, как было до изменений и как стало после. Это позволяют отследить различные метрики.

Вот, что я бы стал измерять в первую очередь:

• Процент доставки задач;
• Метрики процесса обеспечения качества:
  - Количество пропущенных на прод дефектов;
  - Количество обращений пользователей;
  - Количество возвратов из тестирования;
• Метрики процесса разработки;
  - Lead time;
  - Cycle time;

Также могут помочь другие метрики: количество возвратов из код-ревью, причины возврата из тестирования.

Совет 6. “Меняй, замеряй, проверяй, повторяй. Team edition”

Одним из самых больших вызовов для меня было научить команду непрерывному улучшению. Кто-то вообще не понимает, зачем это надо, кто-то отнекивается, мол “да не нужно это всё”, а кто-то вроде понимает, но делает вообще не то (например, работают над вещами, улучшение которых не повлияет на эффективность работы команды от слова совсем).

Проще всего начать работать (реально работать) над зафиксированными экшенами с ретроспективы. Ясно-понятно, что команде необходимо сначала показать, что это такое, какова реальная цель этого ритуала. И после введения ретроспективы обязательно контролировать процесс — как минимум валидировать экшены. Это прививает правильное отношение.

Далее команде следует показать, что надо не только решать проблемы, но и улучшать текущие показатели. Чтобы понимать, что именно улучшать и есть ли прогресс, нужны какие-то метрики.

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

Совет 7: “Знай людей в своей компании”

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

Вот список людей, про которых стоит знать и почему:

1. Руководитель разработки — решение основных вопросов именно по разработке;
2. Руководитель IT-департамента — решение вопросов по инфраструктуре, покупке лицензий, оборудования, выдачи доступов;
3. Юристы — согласование договоров (с аутсорсерами, подрядчиками);
4. Кадровики — запрос/получение данных по своим подчиненным;
5. Бухгалтеры — решение всех вопросов, связанных с зарплатой, иногда получение различных справок, информации для банков;
6. HR — всё, что касается найма. Иногда помогают решить конфликты;
7. Административный департамент — решение вопросов организации офиса, рабочего пространства, организации командировок (проезд, проживание). Возможно, в твоей организации люди из данного департамента могут помочь с организацией обучения (покупка книг и стримов, поездки на конференции);
8. Офис-менеджер — помощь с курьерской службой (в 2021 году это крайне актуально)

NOTE: Роли выше — это примерное отражение того, с чем сталкивался я. В каждой конкретной компании роли, которые помогут с вопросами, могут отличаться.

С этими ребятами стоит познакомиться и запомнить их в самое ближайшее время после заступления на роль лида (если ещё не знали) и рассказать о них своей команде т.к. у команды может возникнуть проблема, которую необходимо будет решить, а в случае непонимания того, к кому можно обратиться, получим потенциальную фрустрацию разработчиков — “я не знал, к кому идти”, кучу вопрос — “а что тут, а где то”, или же трату времени на поиск нужного человека.

Совет 8: “Дружи с PO/менеджером”

Product owner или менеджер (в зависимости от ролей в компании) — тот человек, который больше всего общается с лидом. В рамках реализации проекта/продукта в их силах принять сложное решение, совершить манёвр и прийти к успеху. И по моему опыту, если у этих двух людей хорошие отношения, суммарные их усилия приносят бОльший результат.

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

Совет 9: “Используй компетенции других людей”

Уже сейчас, спустя почти 4 года после того, как я начал управлять командой, я осознал, что знай я этот совет в то время, много могло пойти по другому (быть лучше, в частности). Но нет. А все вот почему: техлид в зоне своей ответственности имеет достаточно много вещей, но все знать не представляется возможным, и иногда банально необходимо спросить совета, попросить подсказать, как решить ту или иную проблему, или задачу.

В частности:

• Уже спустя время я обращался к своим крутым HR’ам для решения сложных задач управления людьми;
• Я попросил нашего QA-лида провести аудит процессов обеспечения качества в команде. В результаты мы получили большущий чек-лист с улучшениями по направлениям, которым команда пользовалась для улучшения процессов обеспечения качества.

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

Совет 10: “Твои подчиненные — *твои* подчиненные. Тебе их хвалить, тебе их ругать”

Каждый твой подчиненный действует в рамках команды, за которую несешь ответственность именно ты. Соответственно, фидбек о работе команды дают тебе (либо всей команде сразу), но никак не какому-то одному человеку.

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

Совет 11: “Расставание с людьми”

Принимая на работу человека, нельзя сказать, что он 100% вольется в команду. Конечно, не стоит сбрасывать со счетов необходимость хорошего онбординга, эмоциональной ситуации в команде и так далее. Но! Есть люди, которые просто не подходят команде/компании в силу характера или каких-то других причин (ситуативных, например). В такой момент надо четко понимать, что если не получается решить проблему с человеком — с ним надо расставаться. Увольнение — это радикальная мера, тяжелое решение, но такие решения надо уметь принимать. Обратное чревато ухудшением эмоционального климата в команде, существенное снижение производительности людей, срывы сроков и вот это все.

Совет 12. Будь готов к увольнению сотрудника.

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

Вот, что может поджидать команду в случае увольнения человека:

• Снижение производительности команды и, как следствие, срыв сроков, снижение качества, увеличение техдолга;
• Снижение мотивации;

Возможные варианты решения проблемы:

• Внутренний аутсорс (помощь коллег из других команд с достижением целей);
• Внешний аутсорс;
• Переработки в команде;
• Развитие текущих сотрудников, в том числе и той же специализации, что и ранее уволившийся, так и для людей другой специализации. Например, делаем из frontend’ера fullstack-разработчика.

Также необходимо подумать насчет долгосрочного решения проблемы:

• Найм нового сотрудника;
• Создание “горячего пула” потенциальных сотрудников;

Не забудьте предупредить всех заинтересованных в поставке лиц (product owner/manager в частности).

Работа с негативными последствия для мотивации команды — более сложная.

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

Совет 13: “Стандарты, регламенты, чек-листы”

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

Самый распространенный пример — code style, который в 2021-ом году завести очень просто и так же просто проверять автоматически.

Если code style — это вещь, которая экономит время, то вот пример чек-листа, написанного “кровью”: разработчик внес изменения в несколько endpoint’ов API, описал изменения в тикете и отдал тестировщику. Тестировщик проверил на тестовом окружении, на предбоевой среде. Выкатили на прод — получили факап. Причина — не проверили один из методов API, т.к. разработчик просто забыл про него написать.

Еще один пример: человеку говорят, что в этом спринте он проводит ретроспективу. А он не знает как и начинает спрашивать: что, где, когда? В следующем спринте уже с другим человеком может возникнуть такая же ситуация.

По отношению к договоренностям можно сформировать следующий чек-лист:

• Создайте понятный способ фиксации договоренностей (например, шаблон страницы в Confluence);
• Обсуждайте вносимые в договоренности изменения;
• Располагайте информацию там, где ее можно найти, используйте лейблы и теги;
• Важные договоренности стоит включить в онбординг новых сотрудников;

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

Совет 14: “Сохраняй фокус: доставка целей, обеспечение качества, архитектура, people management, саморазвитие”

Роль техлида/тимлида разнится от компании к компании и в каждом конкретном месте может иметь меньше или больше зон ответственности.

Мне приходилось иметь дело с большим объемом обязанностей. Основная опасность в этом случае — сместить фокус на что-то определенное и перестать уделять внимание остальному Что делал я?

Составлял список крупных “блоков”, за которыми надо следить:

1. Доставка целей продукта;
2. Технические задачи;
3. Обеспечение качества;
4. Управление командой.

Далее каждый элемент списка разбивал на более мелкие блоки:

1. Доставка целей продукта:
   - Цель 1;
   - Цель 2;
   - Уровень прогнозируемости;
   - Емкость (capacity) команды;
2. Технические задачи
   - Оперирование;
   - Технический долг;
   - Актуальность стека;
3. Обеспечение качества:
   - Баги на фронте;
   - Баги на бекенде;
   - Баги на десктопной версии;
   - Автоматизация тестирования;
4. Управление командой:
   - Эмоциональная составляющая;
   - Развитие людей;
   - Культура команды.

По каждому крупному блоку я строил радар-диаграмму и смотрел, что происходит.

Пример для блока “доставка целей продукта”:

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

Для регулярности такой проверки я ставил себе в календаре время с периодичностью примерно раз в 2 недели и проверял все эти блоки.

Совет 15: “Эскалация как способ решения проблем”

Эскалация, согласно Google’у — “это обращение менеджера проекта к высшим должностным лицам (лидерам) с целью привлечения для решения проблемы”.

Во времена управления командой стояла одна простая цель — доставлять бизнес-ценность. Как это будет сделано — зависело от меня.

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

Рассмотрим две ситуации.

Ситуация 1. Нанимаем аутсорс-компанию для масс-теста нашего ПО. И вдруг юристы, которые должны были еще вчера прислать подписанный договор, начинают молчать. Ждем день, два — все равно молчат, а еще и на сообщения не отвечают.

Идём к своему начальнику, он разруливает ситуацию (возможно, тоже эскалируя). Радуемся.

Ситуация 2. Пилим мобильное приложение, которое должно работать, в том числе на планшетах под Android. Для тестирования заказали партию девайсов. А они всё не едут и не едут. Что здесь может сделать лид? Снова эскалируем до своего руководителя.

Здесь следует обратить внимание на следующий момент: эскалация может осуществляться не только до своего начальника. В ситуации с юристами (да и при взаимодействии с другими отделами в принципе) есть еще один вариант: можно обратиться к руководителю человека, с которым не получается договориться.

Совет 16: “Используй все возможные ресурсы”

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

В 2021-ом году существует множество других вариантов на случай, если команда не справляется:

• Аутсорс — нашли исполнителя где-нибудь на upwork’е или fl.ru, отдали ему постановку задачи и ждем решение;
• Аутстафф — нашли людей из вне на временную основу и взяли к себе в команде с погружением во все процессы;
• Заказная разработка — как аутсорс, только находите не одного человека, а команду, в которую входит и тестировщик, и аналитик, и менеджер, и разработчик;
• Внутренний аутсорс — как аутсорс, только ищем исполнителя задачи внутри компании.

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

Например, я часто сталкиваюсь с заказом полного тестирования ПО у внешней компании. В таком случае в общем случае мы получим достаточно много ресурсов и различных стендов тестирования (например, десктопные платформы, мобильные устройства и т.д.), однако этот способ требует большего контроля. Полное тестирование можно провернуть и внутри компании, если воспользоваться поддержкой QA-техлида, но тут можно упереться в ограничения, отсутствующие у варианта с внешним тестирования, но в плане контроля проводиться он будет легче.

Другой пример — необходимо немного доработать и развернуть open-source продукт на Java, а в команде разработчики, которые владеют только C++. Что делать в этом случае? Идём на фриланс-биржу, выбираем подходящих разработчиков, платим немного денег и получаем результат.

Совет 17: “Умей говорить НЕТ”

Да, надо так говорить. В случаях, когда хотят навязать, когда хотят, что бы взяли ответственность за то, чего сделать не сможешь и так далее. Даже любимому product owner’у надо говорить нет. Особенно если пытаются напихать задач сверх меры, а у вас там техдолг огнем горит.

Однако! Однако просто так говорить “НЕТ” не очень-то и красиво, т.к. менеджменту не очень-то и понятно, с чем связаны такие ограничения. Хорошей стратегией в таком случае будет все тоже “НЕТ”, но с дополнением в виде других вариантов реализации задачи — например привлечение аутсорса для повышения емкости команды, или уменьшение набора фич к ближайшему релизу.

Совет 18. Готовь онбординг летом, а нанимай зимой :)

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

Что это включает в себя:

• Формальное знакомство с командой (формальное и неформальное);
• Знакомство с продуктом;
• Знакомство с процессами;
• Знакомство с кодовой базой и инструментами;
• Выдача техники и доступов к инструментам;
• Выполнение самых первых задач;
• План на испытательный срок;
• Менторство на период испытательного срока.

Несколько замечаний:

Чем лучше подготовитесь к онбордингу нового человека, тем меньше времени этот онбординг займет. В частности, уделите внимание подготовке материалов для самостоятельного изучения.

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

Я знаю одного крутого лида, который оформил видео презентации для ознакомления с продуктами. Это нереально круто.

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

Совет 19. Следи за эмоциональным состоянием команды

Возможно, это не очевидно, но если работник не в лучшем расположении духа, он и работать будет не очень эффективно.

Хороший техлид должен понимать, что творится с каждым его подчиненным. На помощь приходят тет-а-тет встречи/созвоны и неформальное общение.

Если техлид понимает, что происходит с человеком, он может использовать это для улучшения работы команды или для предупреждения возможных проблем.

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

Пример. Однажды я увидел, что у человека начались проблемы на работе — задачи не очень охотно закрываются, тикеты переносятся из спринта в спринт. Как оказалось, человеку разонравилась специфика продукта, и в скором времени он нашел работу по другой специализации (мы пилили десктоп, а он ушел в разработку встроенных систем). Фишка здесь в том, что я рано узнал об этом и вот эта фора позволила мне подготовиться к уходу сотрудника еще тщательнее.

Совет 20. Работай над повышением уровня команды

Развивать компетенции других людей сложно, но необходимо. Основная трудность — понять мотивацию людей и правильно подбирать форму развития компетенций.

За время управления командой я выработал модель, в которой разделил всех людей на два класса:

• “Фанатики”
• “Ремесленники”

Фанатики — люди, для которых их работа — это хобби. По моему мнению среди разработчиков людей этого типа большинство (да чего уж, я сам себя причисляю к таковым). Такие люди любят обсуждать новые технологии, новшества последнего стандарта их любимого ЯП. Такие люди часто не против ночью по пилить свой pet-проект или по изучать что-то новое.

Ремесленники — люди, для которых их работа — это просто работа. Придя домой, они не садятся кодить pet-проект, а тратят время на другие хобби, на другие занятия.

Замечу следующее — отношение к фанатикам или ремесленникам никак не влияет на качество выполняемой работы.

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

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

Далее хочу рассказать уже про конкретные варианты обучения:

• Курсы и тренинги: купили и не надо заморачиваться. На что обратить внимание:
  - Если это большой курс (такие встречаются на OTUSe в частности), по 5 месяцев и более, его очень сложно проходить. Не каждый такое выдержит. Но с другой стороны, такие курсы, исходя из большого набора рассматриваемых тем, очень хорошо систематизируют знания. Их хорошо покупать для людей, которые только входят в тему (джуниоры);
  - Тренинги — история про какую-то локальную проблему или задачу. Редко они охватывают большой круг вопросов с нужной детализацией. Пригодится для точечного повышения компетенций.
• Конференции:
  - Похожи на тренинги тем, что охватывают локальные вопросы, но с достаточной глубиной. В 2021-ом большое количество конференций проводится online, потому цены не такие большие, как раньше, однако возможность задать вопрос спикеру или что-то обсудить после выступления все еще присутствует;
  - Конференции плохо подходят для изучения какого-то определенного вопроса или решения конкретной проблемы. Они подходят скорее для общего расширения кругозора, изучения чужого опыта, заведения знакомств.
• Приглашенный консультант — дорого, но если все сделано правильно — эффективно:
  - Зачастую консультантов зовут, когда в команде/компании не хватает своих компетенций, а решить проблему надо;
  - Если организуете консультацию, подготовьтесь к ней заранее. Чем лучше подготовка (начиная с банального списка вопросов и заканчивая организацией приезда консультанта в офис), тем лучше будет результат.
• Книги:
  - Редко эффективны, потому что содержат много материала. В этом они похожи на длинные курсы. Приходится работать над повышением мотивации для прочтения, особенно если книга большая;
  - Иногда может быть эффективно обсуждение глав книги (итеративное чтение), это поможет закончить книгу.
• Различное внутреннее обучение:
  - Различные ката;
  - Обсуждение техник и принципов;
  - Возможные домашние задания;
  - Если настроить команду, могут хорошо работать.

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

Заключение

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

Не могу не отметить также тот факт, что будучи лидером ты можешь развить людей в твоей команде, стать им лучше, круче.

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

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