Внешний CTO для команд с подрядчиками: один понятный рабочий процесс

Почему команды с подрядчиками быстро расходятся

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

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

Ревью ломается по той же причине. Pull request висит открытым, потому что автор отметил не того человека — основателя, а не того, кто хорошо знает этот участок кода. Кто-то другой думает, что коллега посмотрит его завтра. Завтра превращается в три дня, и спринт сдвигается из-за причины, которую никто не планировал.

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

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

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

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

Что внешний CTO исправляет первым

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

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

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

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

Для блокеров нужен таймер, а не расплывчатая жалоба в чате. Хорошо работает простой путь эскалации:

• Владелец репозитория получает первое сообщение и быстро пытается разблокировать работу.
• Если проблема все еще мешает через несколько часов, подключается CTO или tech lead.
• Если исправление меняет объем, бюджет или сроки релиза, решение принимает продукт или основатель.

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

Настройте правила репозитория, которым все смогут следовать

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

Начните с названий веток. Выберите один шаблон и не усложняйте его. feature/, fix/ и hotfix/ с коротким названием задачи или тикета — этого достаточно. Если один человек создает new-login-flow, другой использует bug123, а третий пушит прямо в main, ревью быстро превращается в путаницу, а релиз-ноты — в работу детектива.

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

Правила окружений должны храниться в одном общем документе, а не в чьей-то памяти. Соберите базовые вещи в одном месте: какие переменные обязательны, какие значения должны оставаться локальными, чем staging отличается от production и кто может что-то менять. Это особенно важно, когда несколько подрядчиков работают параллельно, потому что одна неверная правка в env может заблокировать тестирование для всех.

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

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

Сделайте code review коротким и предсказуемым

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

Таймер ревью исправляет больше, чем ожидает большинство команд. Поставьте цель вроде 24 рабочих часов на первый ответ и 48 рабочих часов на финальное решение для обычных изменений. Это не значит, что каждый PR обязан сливаться за день. Это значит, что никто не должен ждать в тишине.

Большие PR только усугубляют проблему. Когда одна ветка меняет 20 файлов, затрагивает миграции и переписывает тесты, проверяющие откладывают ее до свободного часа. Но свободный час часто так и не появляется. Задайте лимит размера до merge. Если изменение слишком большое для проверки за 15–20 минут, разделите его на несколько меньших PR.

Несколько правил помогают ревью двигаться:

• Назначайте основного проверяющего и запасного проверяющего для каждой части кодовой базы.
• Просите авторов добавлять в каждый PR короткие заметки о тестировании: что проверили и что еще нужно проверить вручную.
• Задайте лимит размера PR по числу файлов или строк и требуйте разбивать изменения, если он превышен.
• Относитесь к срокам ревью как к правилам команды, а не как к личной просьбе.

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

Заметки о тестировании тоже экономят время. Проверяющему не нужно каждый раз спрашивать: "Ты проверил это локально?" Достаточно одного короткого блока в описании: проверен login flow, сверены ответы API, миграция проходит без ошибок, на мобильном UI изменений нет. Это дает проверяющим контекст за секунды.

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

Планируйте релизы до начала работы

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

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

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

Короткий план релиза должен отвечать на четыре вопроса:

• когда команда выкатывает изменения
• когда рискованную работу нужно перестать менять
• кто отвечает за rollout
• как команда делает rollback

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

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

Инструкции по откату должны быть написаны простым языком. Фраза "откатить, если нужно" бесполезна, когда люди под давлением. Запишите точные шаги. Укажите, какую версию восстановить, какую команду или действие выполнить, что проверить после rollback и кого нужно уведомить.

Простой пример: спринт начинается в понедельник, релиз — в четверг, рискованные backend-изменения замораживаются в среду в полдень, а tech lead отвечает за выкладку от деплоя до тех пор, пока трафик не станет нормальным. Если после релиза растет число ошибок checkout, владелец откатывается на предыдущий тег и предупреждает команду. Это специально сделано скучным. Скучные релизы обычно и есть хорошие.

Настройте эскалацию по понятным шагам

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

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

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

Каждое сообщение о блокере должно быть коротким и конкретным:

• задача, которая заблокирована
• что человек уже пробовал
• какой репозиторий или сервис задействован
• риск для спринта или релиза
• какая помощь нужна сейчас

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

Чат хорошо подходит для быстрых ответов, но ему нужен лимит по времени. Если через 15–20 минут обсуждение никуда не движется, переходите к короткому звонку с минимальным числом людей, которые могут принять решение. Держите встречу короткой. Команде не нужен долгий митинг о блокере. Команде нужно решение.

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

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

Представьте небольшой стартап с одним внутренним продакт-менеджером и двумя агентствами. Одно агентство отвечает за веб-приложение. Второе — за API и cloud-работы. У них один backlog, но работают они по-разному, поэтому мелкие разрывы превращаются в пропущенные передачи задач.

В понедельник внешний CTO начинает спринт с того, что назначает одного владельца на каждую задачу до начала любой работы. PM по-прежнему задает приоритеты, но у каждого пункта есть понятный технический владелец, проверяющий и цель релиза. В четверг никто не спрашивает: "А кто это должен был проверить?" — потому что ответ уже существует.

CTO также задает несколько простых правил на неделю:

• frontend-задачи должны ссылаться на API-задачу, от которой они зависят
• у каждого pull request должен быть один основной проверяющий и один запасной
• все, что меняет endpoint, env var или миграцию, в тот же день попадает в релиз-ноты

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

Исправление занимает 20 минут. Backend-разработчик пока возвращает старое поле и добавляет новое за версией-флагом. Frontend-команда обновляет свою задачу и продолжает работу. PM не нужно бегать между командами, чтобы понять, что произошло.

Пятница — это момент, где команды обычно удивляются. В этот раз их останавливают релиз-ноты. В них видно одну миграцию базы данных, один новый secret в production и одно изменение ответа API, которое осталось за флагом. PM видит, что выходит в релиз, support понимает, что может повлиять на пользователей, и выкладка проходит без лишних сообщений в последний момент.

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

Ошибки, из-за которых хаос возвращается снова

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

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

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

Релиз-ноты слишком часто пропускают для мелких изменений. Это выглядит незначительно, пока support не спрашивает: "Что изменилось?" — и никто не может ответить за две минуты. Потом до пользователей доходит баг, а команда тратит полдня на чтение коммитов, поиск зависимостей и споры о том, кто что трогал.

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

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

Командам не нужно больше процесса, чем это. Им нужен один и тот же процесс каждую неделю.

Быстрая проверка перед следующим спринтом

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

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

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

Представьте небольшой стартап с одним backend-подрядчиком, одним frontend-подрядчиком и основателем, который все еще утверждает релизы. Во вторник приходит обновление платежей. Владелец репозитория подтверждает правила веток, проверяющий знает, что у него есть время до конца дня, а релиз-нота сообщает, какой feature flag нужно выключить, если ошибки checkout начнут расти. Если проверяющий не отвечает вовремя, подрядчик эскалирует вопрос инженерному руководителю через два часа, а потом CTO через четыре.

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

Что делать дальше

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

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

Простой первый шаг выглядит так:

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

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

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

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