Как управлять командой без техлида
Исследования bigtech-компаний постоянно подтверждают, что команды с техническими лидерами показывают значительно лучшие результаты:
- Существенно меньше багов в продакшене
- Быстрее принимают технические решения
- Реже сталкиваются с архитектурными проблемами
Но что делать, если техлида в команде нет, а найти его прямо сейчас невозможно?
Типичный сценарий
PM без технического бэкграунда получает команду из 5+ разработчиков. Что происходит дальше:
- Разработчики часами спорят о простых задачах
- Обсуждают масштабирование для проекта с 10 пользователями
- Придумывают корнер-кейсы, которые никогда не случатся
- Задачи обсуждаются, но не делаются
Главная ошибка, которую совершает большинство PM
Попытка изобразить из себя техлида. Лезть в технические обсуждения, пытаться принимать архитектурные решения :)
В результате разработчики бесятся от некомпетентности, падает доверие, управлять процессом становится ещё сложнее.
Что бы посоветовал я:
1. Станьте диспетчером, а не изображайте эксперта. Ваша задача — организовать процесс принятия решений, а не принимать их самостоятельно. Назначайте ответственных за конкретные технические решения, фиксируйте договоренности, следите за выполнением.
2. Ограничивайте пространство для споров. Сократите время на обсуждение маленьких фич. Назначаете ответственных за компоненты, они могут принимать решения без общих обсуждений.
3. Привлекайте внешнюю экспертизу. Обычно экономия на переделках значительно больше, чем траты на консультации внешних экспертов. Ребята с уже набитыми шишками помогают избежать проблем и сильно ускоряют разработку продуктов.
4. Декомпозируйте. Любая задача должна укладываться в 1-2 дня. Маленькие задачи сложнее переусложнить и проще контролировать. Аналитик может ставить функциональные куски в виде пользовательских историй, а до задач в 1-2 дня декомпозировать может уже сам разработчик.
5. Внедрите технические чекпоинты. Перед началом работы разработчик описывает подход к решению задачи в 3-5 предложениях. Это помогает выявить зависимости и потенциальные проблемы до того, как он начнет писать код. Помогает убедиться, что вы одинаково понимаете итоговый результат.
Главный вывод
Вы не можете снизить техническую сложность задач. Но можете минимизировать организационный хаос и снять с разработчиков непрофильную когнитивную нагрузку. У нас у всех есть не так много часов на подумать каждый день, не нужно тратить их на то, что пользы не принесет.
Фокусируйтесь на том, что умеете лучше всего: планировании, коммуникации и контроле исполнения, снимайте с ребят непрофильные задачи, управляйте процессом и модерируйте споры, это поможет вам поднять производительность команды.
Исследования bigtech-компаний постоянно подтверждают, что команды с техническими лидерами показывают значительно лучшие результаты:
- Существенно меньше багов в продакшене
- Быстрее принимают технические решения
- Реже сталкиваются с архитектурными проблемами
Но что делать, если техлида в команде нет, а найти его прямо сейчас невозможно?
Типичный сценарий
PM без технического бэкграунда получает команду из 5+ разработчиков. Что происходит дальше:
- Разработчики часами спорят о простых задачах
- Обсуждают масштабирование для проекта с 10 пользователями
- Придумывают корнер-кейсы, которые никогда не случатся
- Задачи обсуждаются, но не делаются
Главная ошибка, которую совершает большинство PM
Попытка изобразить из себя техлида. Лезть в технические обсуждения, пытаться принимать архитектурные решения :)
В результате разработчики бесятся от некомпетентности, падает доверие, управлять процессом становится ещё сложнее.
Что бы посоветовал я:
1. Станьте диспетчером, а не изображайте эксперта. Ваша задача — организовать процесс принятия решений, а не принимать их самостоятельно. Назначайте ответственных за конкретные технические решения, фиксируйте договоренности, следите за выполнением.
2. Ограничивайте пространство для споров. Сократите время на обсуждение маленьких фич. Назначаете ответственных за компоненты, они могут принимать решения без общих обсуждений.
3. Привлекайте внешнюю экспертизу. Обычно экономия на переделках значительно больше, чем траты на консультации внешних экспертов. Ребята с уже набитыми шишками помогают избежать проблем и сильно ускоряют разработку продуктов.
4. Декомпозируйте. Любая задача должна укладываться в 1-2 дня. Маленькие задачи сложнее переусложнить и проще контролировать. Аналитик может ставить функциональные куски в виде пользовательских историй, а до задач в 1-2 дня декомпозировать может уже сам разработчик.
5. Внедрите технические чекпоинты. Перед началом работы разработчик описывает подход к решению задачи в 3-5 предложениях. Это помогает выявить зависимости и потенциальные проблемы до того, как он начнет писать код. Помогает убедиться, что вы одинаково понимаете итоговый результат.
Главный вывод
Вы не можете снизить техническую сложность задач. Но можете минимизировать организационный хаос и снять с разработчиков непрофильную когнитивную нагрузку. У нас у всех есть не так много часов на подумать каждый день, не нужно тратить их на то, что пользы не принесет.
Фокусируйтесь на том, что умеете лучше всего: планировании, коммуникации и контроле исполнения, снимайте с ребят непрофильные задачи, управляйте процессом и модерируйте споры, это поможет вам поднять производительность команды.