Признаки узкого места у техлида, которые основателям стоит отслеживать

Как это выглядит до срыва сроков

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

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

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

Мелкие решения начинают скапливаться в очередь. Один разработчик ждёт, чтобы переименовать поле. Другой ждёт, пока можно разбить задачу. Кто-то ещё ждёт деплоя, потому что только один человек чувствует себя вправе принять окончательное решение. Каждая такая пауза по отдельности не выглядит серьёзно. Вместе они тормозят всю команду.

Это легко заметить в обычной рутине. На стендапах всё чаще звучат фразы вроде «жду ревью», «нужно согласование» или «заблокировано, пока не решим». Планёрки заканчиваются открытыми вопросами, которые закрыть может только один человек. Pull requests собирают комментарии, но до завершения их никто не доводит.

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

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

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

Почему сильный техлид становится узким местом

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

Сначала такое доверие кажется безопасным. Потом всё больше работы ложится на один стол.

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

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

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

Основатели часто добавляют трафика, даже не желая этого. Клиент просит изменение — основатель пишет техлиду. Продажи слышат жалобу — основатель пишет техлиду. Разработчику нужно решение по объёму работ — снова то же самое. Вскоре изменения продукта, технические решения и срочные исправления оказываются в одной очереди.

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

Со стороны команда всё ещё выглядит занятой. Люди планируют, оценивают и двигают тикеты. А внутри слишком много задач остаются наполовину готовыми и ждут одного человека.

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

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

Какие цифры основателям стоит отслеживать каждую неделю

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

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

• Измеряйте, сколько дней проходит между «готово к ревью» и «ревью начато». Если работа ждёт по два или три дня, прежде чем её кто-то посмотрит, команда ждёт внимания, а не строит продукт.
• Считайте, сколько pull requests остаются у одного и того же ревьюера. Если большинство ждёт одного человека, он уже стал воротами, даже если он очень сильный.
• Считайте срочные исправления, которые врываются в плановую работу. Несколько — это нормально. Если они появляются каждую неделю, лид, возможно, слишком много времени тратит на тушение пожаров.
• Отмечайте, какие задачи может оценить или утвердить только один человек. Если планирование зависит от одного лида, замедление начинается ещё до того, как кто-то сел писать код.
• Сравнивайте число начатых и завершённых задач каждую неделю. Если команда открывает десять пунктов, а закрывает четыре, работа накапливается быстрее, чем уходит из системы.

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

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

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

Сигналы в планировании и передаче задач

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

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

Ещё один сигнал — чем заканчиваются встречи. Если люди уходят со словами «надо уточнить у Alex» или «позже разберёмся», передача уже слабая. Хорошее планирование заканчивается понятным владельцем и следующим шагом. Если этого нет, работа начинает дрейфовать, а тот же вопрос всплывает на следующей встрече.

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

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

Поддержка делает узкое место ещё очевиднее. Появляется запрос от клиента, и плановая работа отодвигается, потому что лид должен посмотреть баг, определить приоритет и решить, как его исправлять. Иногда срочная работа нормальна. Постоянная перетряска — нет.

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

Как проверить, что один человек тормозит выпуск

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

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

Используйте короткий аудит:

1. Запишите каждую задачу, которая застопорилась больше чем на день.
2. Рядом с каждой задачей отметьте, кто её разблокировал.
3. Посчитайте решения, которые может утвердить только техлид.
4. Спросите трёх инженеров, что они могли бы выпустить на этой неделе без этого лида.
5. В пятницу сравните, что команда планировала, и что реально было выпущено.

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

Простой пример делает это очевидным. Допустим, команда запланировала на неделю 12 задач и закончила 7. Из 5 сдвинувшихся 3 ждали ответа техлида по дизайну, 1 — ревью кода, и ещё 1 — одобрения релиза. Это не случайная задержка. Одна роль тормозит выпуск.

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

Вопрос к инженерам — часто самый честный тест. Спросите каждого отдельно, не в группе. Если ответы звучат как «я могу писать, но не могу сливать, выпускать или решать», выпуск зависит от одного человека сильнее, чем это признаёт оргструктура.

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

Простой пример стартапа

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

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

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

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

Цифры говорят сами за себя. Четыре разработчика завершают код, но трое из них ждут ревью больше 48 часов. Лид касается почти каждого тикета в спринте. Один инцидент в проде съедает полдня и откладывает несколько ревью на следующее утро. Дата релиза наступает, а большая часть работы всё ещё почти готова, но не выпущена.

Релиз сдвигается с пятницы на вторник. Никто в команде не выглядит ленивым. Никто не сидел весь спринт без дела. Задержка возникает на последней миле. Завершённая работа просто не проходит финальные проверки достаточно быстро.

Если тот же рисунок повторяется два спринта подряд, дело не в мотивации. Команда построила систему, в которой один человек тормозит выпуск.

Ошибки, которые совершают основатели в ответ

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

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

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

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

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

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

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

Быстрые проверки на ближайшие две недели

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

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

• Посмотрите на pull requests, которые ждут ревью. Если больше половины из них висят на одном человеке день и дольше, этот человек и есть ворота потока.
• Отслеживайте срочные отвлечения. Каждый раз, когда инциденты в проде, запросы клиентов или вопросы в последний момент уводят одного и того же лида в сторону, фиксируйте это. Если так происходит каждую неделю, плановая работа никогда не идёт спокойно.
• Попросите трёх инженеров простыми словами объяснить следующий релиз. Если сделать это без догадок может только один человек, команда зависит от одного переводчика.
• Две недели наблюдайте за рутинными решениями. Если инженеры всё ещё спрашивают разрешение на нейминг, мелкие решения по дизайну или обычный выбор инструментов, значит, они на самом деле не владеют своей работой.
• Считайте работу, которая уже написана, протестирована и всё ещё не в проде. Если готовые тикеты копятся перед релизом только потому, что один человек должен их утвердить или упаковать, выпуск уже замедляется.

Один небольшой эксперимент делает это ещё понятнее. На неделю дайте другому старшему инженеру утверждать малорисковые изменения, а кому-то ещё — вести release notes или обычный шаг деплоя. Потом сравните время цикла и количество отвлечений. Если работа сразу пошла быстрее, дело не в усилиях. Контроль сидит на одном месте.

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

Что делать дальше, если проблема реальна

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

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

Потом распределите работу, которая создаёт больше всего ожидания. Оценки, ревью и дежурства по инцидентам — обычные точки давления. Дайте у каждой чётко обозначенного владельца и запасного. Лид по-прежнему должен решать самые сложные вопросы, но он не должен быть первой остановкой для каждого тикета, каждого pull request и каждого прод-алерта.

Короткая встреча по перезапуску поможет, если держать её приземлённой:

• Кто может утверждать обычную работу без вопроса к лиду?
• Кто даёт оценки по каждой продуктовой области?
• Кто отвечает первым во время инцидентов на этой неделе?
• Какие решения всё ещё требуют лида и почему?

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

Если команда всё ещё вязнет, помочь может внешний fractional CTO. Свежий взгляд может посмотреть на планирование, поток ревью и обработку инцидентов без старых привычек. Именно такую работу делает Oleg Sotnikov на oleg.is как fractional CTO и startup advisor. Цель простая: пересобрать роли, передачи и ожидания по выпуску, чтобы обычный прогресс больше не зависел от того, онлайн ли один человек.

Если через месяц те же самые задержки всё ещё завязаны на одном имени, узкое место никуда не делось.