Недавно в одном из проектов произошла ситуация, которая заставила меня глубоко задуматься о роли технического лидера. Product owner, взявший на себя обязанности техлида, на вопрос о деталях архитектуры ответил: «Не помню, ну не помню я… не знаю, как ты всё это помнишь, а я нет».
Эта фраза стала отправной точкой для размышлений о том, почему попытки совмещать роли без полного погружения в контекст проекта приводят к провалу. И дело тут не в плохой памяти или недостатке способностей — проблема кроется в фундаментальном непонимании того, что значит быть техническим лидером.
Миф о «высокоуровневом» управлении
В современной IT-индустрии существует опасное заблуждение: многие считают, что можно эффективно управлять техническим проектом, оставаясь на «высоком уровне абстракции». Мол, достаточно понимать общую картину, а детали — это уже забота разработчиков.
Такой подход особенно соблазнителен для владельцев продуктов и менеджеров, которые решают взять на себя роль техлида. Им кажется, что можно совместить стратегическое видение продукта с техническим руководством, не погружаясь глубоко в архитектурные решения и технические детали.
Но реальность жестока: техническое лидерство требует не просто понимания, а глубокого владения всем контекстом проекта. И вот почему.
Что на самом деле должен знать техлид
Технический лидер — это не просто старший разработчик с хорошими soft skills. Это человек, который держит в голове полную техническую картину проекта:
Архитектурные решения: Почему выбрана именно такая архитектура? Какие были альтернативы? Какие компромиссы пришлось принять? Как различные части системы взаимодействуют между собой?
История изменений: Почему код выглядит именно так? Какие проблемы решались в процессе развития проекта? Какие технические долги накопились и почему?
Бизнес-логика в деталях: Не просто «у нас есть корзина и оформление заказа», а понимание всех edge cases, специальных условий, интеграций с внешними системами.
Технические ограничения: Какие есть bottlenecks в производительности? Какие лимиты у используемых сервисов? Где находятся точки отказа системы?
Планы развития: Как текущая архитектура позволяет масштабироваться? Какие рефакторинги запланированы? Как новые фичи впишутся в существующую систему?
Цена незнания контекста
Когда техлид «не помнит» или «не знает» ключевые аспекты проекта, начинается цепная реакция проблем:
1. Невозможность постановки задач
Без глубокого понимания архитектуры и логики проекта техлид не может корректно сформулировать техническое задание. Каждая новая задача превращается в минное поле:
- Новая функциональность может конфликтовать с существующей архитектурой
- Оценки сроков становятся фантазией, а не реальным планированием
- Разработчики тратят время на объяснение, почему предложенное решение не подходит
2. Превращение разработчиков в технических писателей
Вместо написания кода программисты вынуждены:
- Писать длинные объяснения, почему предложенный подход не сработает
- Документировать то, что техлид должен знать по умолчанию
- Участвовать в бесконечных совещаниях для прояснения контекста
- Самостоятельно принимать архитектурные решения без должной координации
3. Деградация проекта
Без сильного технического лидерства проект начинает «расползаться»:
- Появляются дублирующие друг друга решения
- Растёт технический долг из-за quick fixes без понимания последствий
- Архитектура становится всё более запутанной и несогласованной
- Новые разработчики не могут быстро включиться в работу
4. Потеря доверия команды
Разработчики быстро понимают, когда их техлид не владеет контекстом. Это приводит к:
- Снижению мотивации («зачем стараться, если руководство не понимает, что мы делаем»)
- Появлению «теневого» технического лидерства среди разработчиков
- Конфликтам при попытках техлида принимать решения без понимания последствий
Почему совмещение ролей — это ловушка
Product owner, решивший стать техлидом, сталкивается с фундаментальным противоречием. Эти роли требуют разного типа мышления и разного фокуса внимания:
Product Owner думает о:
- Потребностях пользователей и бизнеса
- Приоритетах развития продукта
- Метриках и KPI
- Конкурентном окружении
Техлид погружен в:
- Техническую реализацию и ограничения
- Качество кода и архитектуры
- Производительность и масштабируемость
- Технический долг и рефакторинг
Попытка удержать в голове оба контекста одновременно — это как жонглировать бензопилами. Рано или поздно что-то пострадает. И обычно страдает именно техническая сторона, потому что бизнес-задачи кажутся более приоритетными и понятными.
Уроки из практики проектирования
Изучая передовые практики создания технических заданий и управления разработкой, становится очевидным: успешные проекты чётко разделяют роли и ответственности. Вот ключевые принципы:
1. Каждый остаётся в рамках своей экспертизы
Владелец продукта определяет ЧТО нужно сделать и ЗАЧЕМ. Технический лидер определяет КАК это будет реализовано. Попытки одного человека ответить на все вопросы приводят к посредственным решениям в обеих областях.
2. Глубина важнее широты охвата
Лучше иметь техлида, который досконально знает один проект, чем руководителя, который «немного в курсе» десятка проектов. Контекст и детали — это не то, что можно освоить по диагонали.
3. Документация не заменяет понимания
Даже самая подробная документация не может заменить глубокого понимания проекта. Техлид должен не просто знать, где найти информацию — он должен понимать взаимосвязи, историю решений, потенциальные проблемы.
4. Время на погружение — это инвестиция
Когда новый техлид приходит в проект, ему нужно время на полное погружение. Это не «потерянное» время — это инвестиция в будущую эффективность всей команды.
Как правильно организовать техническое лидерство
Для небольших проектов
Если проект небольшой (до 3-4 разработчиков), техлидом может быть один из senior-разработчиков. Он продолжает писать код, но также:
- Принимает архитектурные решения
- Проводит code review
- Планирует техническую часть развития
- Коммуницирует с product owner’ом
Для средних проектов
При команде 5-10 человек техлид уже пишет меньше кода, но всё ещё должен быть погружен в техническую реализацию:
- Проектирует архитектуру
- Решает сложные технические вопросы
- Менторит junior и middle разработчиков
- Участвует в найме
Для крупных проектов
В больших командах может быть несколько техлидов по направлениям, но каждый из них всё равно должен глубоко понимать свою часть системы:
- Общий архитектор системы
- Техлиды по компонентам/сервисам
- Эксперты по отдельным технологиям
Что делать, если вы оказались в роли «парящего» техлида
Если вы узнали себя в описании техлида, который «не помнит» детали проекта, вот план действий:
1. Признайте проблему
Первый шаг — честно признать, что вы не владеете контекстом на должном уровне. Это не стыдно — это отправная точка для улучшения.
2. Выделите время на погружение
Заблокируйте в календаре время для глубокого изучения проекта:
- Изучите архитектурную документацию
- Пройдитесь по ключевым частям кода
- Поговорите с разработчиками об истории принятых решений
3. Делегируйте или откажитесь от роли
Если совмещение ролей не позволяет полноценно погрузиться в технический контекст:
- Найдите сильного техлида в команде
- Сосредоточьтесь на своей основной роли
- Стройте правильную коммуникацию между ролями
4. Измените подход к управлению
Если вы остаётесь в роли техлида:
- Перестаньте «парить» над проектом
- Регулярно синхронизируйтесь с командой
- Участвуйте в технических обсуждениях
- Держите руку на пульсе изменений
Заключение: контекст — это всё
Технический лидер, который «не помнит» ключевые аспекты проекта — это оксюморон. Невозможно вести команду, не зная, куда идёшь. Невозможно принимать архитектурные решения, не понимая существующую архитектуру. Невозможно оценивать сроки, не зная технических деталей реализации.
Попытки совместить роль product owner’а и техлида без полного погружения в оба контекста — это путь к провалу проекта. Либо делайте одно дело хорошо, либо найдите способ полноценно освоить оба направления. Полумеры здесь не работают.
Помните: в IT-проектах дьявол кроется в деталях. И техлид, который эти детали «не помнит», обрекает проект на медленную, но неизбежную деградацию. Команда заслуживает лидера, который понимает, что делает. Проект заслуживает руководителя, который знает его как свои пять пальцев. А если вы не готовы к такому уровню погружения — лучше честно остаться в рамках своей основной роли и найти того, кто сможет взять на себя техническое лидерство по-настоящему.
В конце концов, как метко подметил опытный разработчик: «Чем дальше, тем такому техлиду, «парящему» вне контекста проекта, всё невозможнее и невозможнее будет поставить даже простую задачу, чтобы она не противоречила либо логике, либо архитектуре». И это не преувеличение — это неизбежная реальность проектов, где роли размыты, а ответственность распылена.
Будьте профессионалами. Знайте свой проект. Или найдите того, кто будет знать.