Книги для тимлида: как организовать работу команды

Когда инженерной экспертизы уже недостаточно

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

Поэтому книги для тимлида стоит выбирать по затруднению, которое повторяется в команде. Один руководитель впервые проводит личные встречи. Другой умеет обсуждать развитие сотрудников, но каждую неделю теряет план из-за срочных просьб. Третий видит, как готовые изменения копятся перед проверкой. Этим читателям нужны разные главы и разные действия после чтения.

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

Что читать о роли, а что — об организации работы

The Manager’s Path Камиллы Фурнье подойдет для разбора перехода от инженера к техническому руководителю. В оглавлении издателя O’Reilly есть наставничество, роль tech lead, управление людьми, личные встречи и обратная связь. Это разумный выбор, если главный вопрос связан с изменением собственной роли и отношениями с сотрудниками.

На этом сайте представлена книга Егора Ганина «Как приготовить проект: Рецепты для создания успешных продуктов и команд». Ее имеет смысл рассматривать, когда требуется организовать совместную работу: описать ожидаемый результат, договориться об очередности, согласовать загрузку и сообщать об изменениях. Главы 3, 5 и 7 позволяют пройти эту цепочку последовательно. Главы 8 и 9 дополняют ее информированием и правилами взаимодействия.

Эти книги отвечают на разные вопросы. Для разговора о карьере и управлении людьми полезен маршрут Фурнье. Для разбора срыва недельного плана можно начать с конкретных разделов Ганина. Если же затруднение связано с архитектурой, алгоритмом или устройством языка, потребуется соответствующая техническая литература.

Сначала проверить право менять очередь

В главе 5 «Приоритизация» есть полезная последовательность проверки. Прежде чем выбирать метод оценки задач, стоит понять, кто распоряжается очередью. Когда любой соседний отдел может напрямую поставить разработчику срочную задачу, приоритеты на общей доске быстро становятся условностью. Руководитель отвечает за срок, но не управляет поступающей работой.

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

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

Пример: срочное исправление посреди недели

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

Первое действие — уточнить масштаб сбоя и назначить ответственного за его устранение. Затем нужно показать, какие договоренности меняются. Для этого достаточно короткой записи, которую увидят разработка, проверка и владелец продукта.

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

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

Как перестать быть единственным диспетчером

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

Правила срочных обращений следует обсудить с командой и смежными руководителями. Например, кто принимает сообщение о сбое, где фиксируется решение и кто предупреждает о переносе. В главе 9 «Устав» правила связаны с реальным поведением руководителей. Документ теряет смысл, если тимлид сам регулярно обходит согласованный порядок.

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

Что проверить после первого чтения

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

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