Проектная работа Артёма Андриянова, тимлида в компании «DNS Технологии» и выпускника курса Team Lead

Когда команда растёт, управлять ей непросто.

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

Цель №1 – снизить оперативную нагрузку на руководителя
Проблема: на оперативную деятельность уходит до четырёх часов в день

Тимлид в нашей компании – это играющий тренер. 

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

  1. Исполнитель не участвует в планировании.
  2. Людям свойственно ошибаться. Когда нет коллективного обсуждения (например, покера планирования), сроки выполнения приходится часто сдвигать. Это портит планы заказчика.
  3. Тимлид думает о деталях реализации [проекта], а не о проблемах команды.
  4. При анализе загрузки команды, учитываются плановые часы, которые закладывает исполнитель. Разница между плановыми и фактическими показателями ~ 30%, так как исполнитель тоже ошибается и, опять же, анализирует трудозатраты в одиночку.

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

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

Цель №2 – плановая подготовка новых руководителей
Проблема: стратегия активного роста числа сотрудников

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

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

<strong>Проект «Разделение одной команды разработки на две» курса «Team Lead»</strong>

Путь к целям

Шаг 1. Подготовить лидов
Необходимое условие для разделения одной команды на две – лиды. Чтобы выявить лидов и согласовать договорённости, потребовалось две недели. Сейчас лид – это отдельная роль. Выбор «техлид или тимлид?» сотрудник делает ближе к созданию новой самостоятельной команды. Выбирать правильно помогает именно опыт управления. 

Шаг 2. Подготовить команду к разделению
На это ушло два месяца: некоторым разработчикам нужно было изучить инструменты своих будущих команд.

Шаг 3. Подготовить процессы (в том числе для заказчиков)
Чтобы работа была «прозрачной», мы разделили бэклог на две части. За каждой частью следило по одному ответственному сотруднику от заказчиков. Также зафиксировали договорённости о том, как работать с бэклогом, и правила взаимодействия с заказчиками. Описали процесс разработки в целом.

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

Шаг 4. Развить у лидов профессиональные и гибкие навыки
Чтобы от обычного лида перейти к роли техлида или тимлида, нужна минимум четвёртая категория из пяти. То есть уровень senior. Помните? Тимлид – играющий тренер! Поэтому с каждым лидом мы согласовали план профессионального развития. Система «грейдов» в полной мере не учитывает гибкие навыки. И чтобы их прокачать, мы запланировали отдельные мероприятия для каждого лида. 

Итог: составили план развития профессиональных и гибких навыков на ближайшие полгода.

Шаг 5. Помочь лидам расти
Что нужно, чтобы сформировать команду?

  • лид
  • квалифицированные сотрудники
  • распределённые роли
  • выстроенные правила
  • общее пространство знаний
  • фокус на результате
  • высокий уровень доверия

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

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

Мой инструментарий

• Личные встречи 

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

• План развития лидов по системе грейдов. Позволяет сотрудникам фокусироваться на важных вещах и в динамике отслеживать продвижение к цели.

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

• Делегирование. Обеспечивает профессиональный рост сотрудников, повышает доверие.

Итоги

<strong>Проект «Разделение одной команды разработки на две» курса «Team Lead»</strong>

Заявка – формализованное техническое задание. При декомпозиции заявки разработчики создают задачи с максимальной длительностью до 16 часов (обычная длительность – 4-10 часов).
Lead-To-Market. Метрика = {Среднее количество дней от принятия заявки в работу до перевода в тестирование}. То есть как быстро группа реализует потребности бизнеса.
Эффективность. Метрика = {Количество задач, переведённых в тестирование} / {часы всей группы}. Показывает, какую долю задачи группа решает за отведённый час по табелю. Важная метрика для оценки в динамике.

Мы начали полноценно разделять команды с июля 2022 года. Как и ожидалось, скорость разработки немного уменьшилась: лиды уделяли время работе с очередями, взаимодействию с заказчиками и ресурсному планированию. Эта просадка видна в метрике Lead-To-Market. То есть скорость реализации потребностей бизнеса несколько снизилась.

Но.

Качество декомпозиции – улучшилось (см. метрику «Эффективность»), вырос уровень ресурсного планирования в целом. 

Планы развития 

  • Переход от временной оценки заявок к сложностной: от часов к story points
  • Документация и тестирование
  • Удалёнка для всех разработчиков

Проблемные точки

  1. Переход от оценки в часах к story points. Метрики в компании одинаковы для всех групп разработки и настраиваются на уровне CTO. Нужно будет «прикрутить» новую оценку, так как текущая система поддерживает только «почасовку»; собрать статистику за пару месяцев, выполнить анализ, и с анализом идти к группе CTO, чтобы они одобрили внедрение сложностной оценки в систему трекинга задач. Важный момент: делать оценку нужно коллективно.
  2. В культуру направления необходимо внедрить практику работы с документацией и автоматизированное тестирование. На моём уровне такое продвигается сложно; планирую привлечь CTO моего направления в роли «крёстного отца». Одобрение всех CTO здесь не нужно.
  3. Сейчас работать удалённо могут [только] сотрудники из других городов и те, кто тратят много времени на дорогу.  В качестве эксперимента можно переводить [и других] сотрудников на удалённую работу. Если переход к story points покажет положительный результат, то удалёнка станет полноценной заменой офису. А значит – география найма расширится.

Заключение

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

Стратегия «Разделяй и властвуй» высвободила мои возможности. Направлю их на более качественную работу в роли тимлида, на новые проекты. Теперь я не хочу останавливаться на достигнутом. Продолжу делегировать лидам, начну вовлекать лидов в решение проблем команды, в собеседования; буду привлекать в качестве экспертов на собраниях.

<strong>Проект «Разделение одной команды разработки на две» курса «Team Lead»</strong>