30-дневный план передачи управления инженерией, когда основатели отходят в сторону

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

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

Сначала это почти не заметно. Один разработчик уже все сделал и ждет ответа по объему задачи. Другому нужно одобрение pull request. Третий спрашивает, выйдет ли релиз сегодня или на следующей неделе. Каждый вопрос по отдельности кажется мелочью, но все они упираются в одно и то же место.

Так появляется скрытая очередь. Работа не блокируется потому, что она сложная. Она блокируется потому, что только один человек может сказать «да».

Небольшой стартап может почувствовать это уже через несколько дней. Утром основатель на созвонах с клиентами, поздно вечером заходит в Git и пропускает два запроса на одобрение. QA не может закрыть тестирование. Релиз сдвигается на день. Потом поддержка спрашивает, можно ли выпустить срочный фикс вместе с тем же релизом, и теперь уже трое ждут одного ответа.

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

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

Обычно на это указывают несколько признаков:

• pull request’ы висят без движения, пока основатель их не посмотрит.
• Релизы зависят от одного финального сообщения или встречи.
• Продуктовые вопросы ждут следующего разговора по roadmap.
• Инженеры просят одобрения даже для обычных решений.

Решение — не в новых встречах. Нужна четкая передача ответственности в фиксированном порядке, чтобы управление ушло от основателя, а ежедневная работа перестала копиться в одном inbox.

Сначала определите порядок передачи, еще до первого дня

Большинство передач ответственности ломаются еще до старта, потому что команда переставляет задачи, но не решает, кто принимает каждое решение. До первого дня нужно разложить реальную недельную работу основателя, а не просто посмотреть на название его роли в оргструктуре. Запишите все решения, которые все еще попадают к основателю: одобрение слияний, разрешение на релизы, доступы к сервисам, шаги найма, компромиссы по roadmap и статусы.

Обычно список длиннее, чем ожидают. Основатель может говорить: «Я вмешиваюсь только когда это нужно», а на деле одобрять pull request’ы, отвечать на вопросы по инфраструктуре, разруливать споры о продукте и менять объем спринта три раза в неделю. Если эти моменты остаются размытыми, команда продолжает ждать именно этого человека даже после начала передачи.

Передавайте ответственность в таком порядке:

• сначала согласования
• потом доступы и права на репозиторий
• затем решения по roadmap
• и только потом отчетность

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

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

Составьте две колонки: «переходит сейчас» и «останется у основателя на время». Будьте прямыми. Одобрение релизов может перейти в первый день, production access — на восьмой, а квартальное планирование — остаться у основателя еще на две недели. Так вы избежите главной проблемы передачи: все думают, что она уже произошла, но никто не понимает, что именно изменилось.

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

Дни 1–7: сначала передайте согласования

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

Начните с точек согласования, которые чаще всего тормозят работу:

• production-релизы
• срочные решения по hotfix
• небольшие инженерные траты, например инструмент, увеличение облачных ресурсов или короткую задачу подрядчика

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

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

Сразу задайте и время ответа. Для основателей это часто важнее, чем кажется. Если люди не знают, когда получат ответ, они продолжают проверять чат и откладывают работу. Практичное правило — 30 минут на вопросы по hotfix в рабочее время и 4 рабочих часа на обычные согласования. Если этот срок проходит, подключается назначенный запасной ответственный.

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

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

Дни 8–14: передайте права на репозиторий и владение кодом

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

Начните с полной проверки доступов в Git, облачных аккаунтах, CI и пакетных хранилищах. Многие помнят про основной репозиторий и забывают о местах, которые на самом деле блокируют релиз: контейнерные registry, аккаунты приложений, DNS, хранилище секретов или аккаунт, который может откатить неудачный деплой.

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

• У кого есть admin-права в Git и кто может менять правила веток?
• Кто может одобрять и сливать изменения в production-ветки?
• Кто может ставить теги релизов и публиковать пакеты?
• Кто может запускать деплой и кто может откатывать его назад?
• Какие токены, боты и сервисные аккаунты все еще принадлежат основателю?

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

Дальше выведите личный аккаунт основателя из рутинных процессов. Аккаунт основателя не должен владеть CI-runner’ом, держать единственный токен для публикации в npm или PyPI или быть встроенным в deploy-скрипт, которого все боятся касаться. Замените личные учетные данные общими командными аккаунтами, сервисными аккаунтами или документированными bot-пользователями.

Затем простыми словами опишите владение кодом. Решите, кто отвечает за каждый репозиторий, кто ревьюит какие области и кто принимает финальное решение по слиянию. Если один человек владеет backend, другой — mobile, а новый лидер отвечает за релизные решения, так и скажите. Тишина создает очередь.

Многие стартапы сталкиваются с проблемой в день релиза. Команда заканчивает исправление, но только основатель может поставить тег релиза и опубликовать пакет. Это не техническая проблема. Это проблема владения. К концу 14-го дня основатель должен быть необязателен для обычной инженерной работы, а не участвовать в каждом деплое.

Дни 15–21: передайте продуктовые и roadmap-встречи

К третьей неделе команда уже может выпускать код без основателя, но все еще замирает, когда меняются приоритеты. Обычно это происходит не в репозитории, а на встречах. Если основатель по-прежнему ведет sprint planning, backlog review и еженедельный roadmap-call, люди продолжают ждать финального ответа.

Переводите эти встречи каждый раз в одном и том же порядке. Сначала sprint planning, потом backlog review, потом roadmap-call. Первые две встречи формируют ближайшие несколько дней работы. Последняя — ближайшие несколько недель. Когда все три встречи ведет кто-то, кроме основателя, команда перестает воспринимать каждое решение как требующее особого одобрения.

У каждой встречи должен быть понятный владелец. Во многих стартапах sprint planning лучше вести руководителю инженерии, потому что там нужно решать вопросы объема, пропускной способности команды и блокеров. Backlog review и roadmap-call обычно ведет продуктовый лидер, потому что именно эти встречи превращают запросы клиентов в приоритеты. Если обе роли совмещает один человек, это тоже нормально. Важно только, чтобы все понимали, кто принимает решение в комнате.

Простой ритм встреч работает хорошо:

• Sprint planning: ведет руководитель инженерии
• Backlog review: ведет продуктовый лидер
• Еженедельный roadmap-call: ведет продуктовый или инженерный лидер
• Проверка с основателем: раз в 2 недели, по фиксированному графику

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

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

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

Дни 22–30: проверьте новую схему

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

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

Хорошо работает простой тест. Проведите релиз как обычно, а потом посчитайте каждый раз, когда кто-то просит помощи у основателя. Чаще всего команды находят одни и те же слабые места:

• у кого-то все еще нет admin- или production-доступа
• два человека считают, что решение принадлежит им обоим
• никто не отвечает за встречу, которую раньше вел основатель
• инженеры просят продуктовые решения, потому что roadmap все еще кажется неясным
• менеджер избегает решения и передает его наверх

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

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

На 30-й день проведите короткий разбор с основателем, руководителем инженерии и продуктовым владельцем. Держите разговор простым и задайте четыре вопроса:

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

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

Простой пример из небольшого стартапа

У небольшого SaaS-стартапа с восьмью сотрудниками была очень знакомая проблема. Основатель все еще одобрял каждый pull request, каждое изменение в продакшне и каждое обновление roadmap. Никто не хотел создавать узкое место, но команда постоянно ждала одного человека, который одновременно разговаривал с клиентами, нанимал людей и привлекал инвестиции.

К понедельнику паттерн уже был очевиден. Разработчик закончил исправление бага утром, открыл pull request, а потом ждал до вечера, пока основатель его прочитает. Дизайнер хотел небольшое изменение в продукте, но roadmap оставался замороженным, пока основатель не подключался к еженедельному созвону. Работа двигалась, потом останавливалась, потом снова двигалась.

Команда решила проблему, меняя владение поэтапно, а не сразу всем разом.

На первой неделе они сначала передали согласования. Основатель перестал быть стандартным одобряющим для обычной инженерной работы. Техлид и один senior engineer начали одобрять pull request’ы, release notes и обычные решения по деплою. Основатель по-прежнему оставался в курсе, но только по рискованным изменениям вроде платежных потоков или вопросов безопасности.

Вторая неделя была посвящена правам на репозитории. Техлид получил права на слияние в основных репозиториях и стал тем, кто мог разблокировать релизы без ожидания. Одно это изменение сильно сократило пустое время. Разработчики больше не держали готовую работу часами только потому, что основатель был на sales call.

На третьей неделе команда передала продуктовые встречи. Продакт-менеджер начал вести roadmap-call, собирая input от поддержки и инженеров до встречи, а не во время нее. Основатель по-прежнему давал бизнес-контекст, но перестал в реальном времени решать каждое небольшое изменение приоритета на созвоне. Встреча стала короче, а команда уходила с четкими владельцами.

К 30-му дню основатель подключался только к ежемесячному разбору. Техлид отвечал за поток кода. Продакт-менеджер отвечал за roadmap-call. Инженеры знали, кто может одобрять, кто может сливать изменения и кто может менять приоритеты. Ничего волшебного не произошло. Команда просто перестала ждать.

Обычно именно в этом и состоит реальная победа. Вам не нужна большая реорганизация. Вам нужно меньше пауз и более чистое владение.

Ошибки, которые замедляют передачу

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

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

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

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

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

• кто одобряет релизы
• кто может менять доступ в production
• кто отвечает за приоритеты backlog
• что все еще требует участия основателя
• когда эскалировать и к кому

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

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

Короткий чек-лист и следующие шаги

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

Прежде чем считать передачу завершенной, проверьте базовые вещи:

• Один человек отвечает за релизы, hotfix, доступ для вендоров и изменения в production.
• Один человек отвечает за права на репозитории, изменения правил веток и запросы на доступ.
• Один человек ведет roadmap-встречи, фиксирует решения и разруливает споры по приоритетам.
• Команда знает, когда спрашивать, а когда действовать. Она спрашивает про изменения бюджета, резкие изменения объема и исключения по безопасности. Она действует при обычных исправлениях, запланированных релизах и работе, которая укладывается в согласованные лимиты.
• Основатель больше не участвует в регулярных релизных созвонах и большинстве инженерных встреч. Он подключается только тогда, когда его мнение действительно меняет решение.

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

Обычно это проявляется в мелочах. Разработчик хочет сделать merge, но ждет, потому что неясны правила защищенной ветки. Продакт-менеджер откладывает roadmap-call, потому что никто не знает, кто может убрать фичу. Релиз сдвигается на день, потом еще на один. Проблема почти никогда не в усилиях. Обычно она в неясной власти принимать решения.

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

Настоящая проверка очень проста: основатель может уйти на несколько дней, а поставка все равно продолжается.

Если переход все еще кажется хаотичным, может помочь внешний оператор. Oleg Sotnikov на oleg.is предлагает услуги Fractional CTO для стартапов, которым нужно более четкое владение, более сильные инженерные процессы или более аккуратный уход от инженерии, управляемой основателем. Короткий разбор ролей, доступов и владельцев встреч может показать узкие места еще до того, как они превратятся в еще один месяц задержек.