Перед масштабированием команды разберитесь с ответственностью и хаосом релизов

Почему найм новых людей может сделать хаос еще больше

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

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

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

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

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

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

Где обычно ломается ответственность

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

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

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

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

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

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

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

Как шум в roadmap расползается по команде

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

Если все срочно, roadmap — это фикция.

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

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

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

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

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

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

Как выглядит хаос релизов на практике

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

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

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

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

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

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

Что исправить первым, шаг за шагом

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

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

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

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

Ужесточите решения по roadmap

Проводите одно еженедельное обсуждение roadmap и держите его коротким. Решайте, что остается, что сдвигается и что останавливается.

Финальное слово должно быть у одного человека. Это может быть основатель, руководитель продукта или Fractional CTO, но команда должна знать, кто принимает решение. Если за решение никто не отвечает, каждый громкий запрос снова пролезает в roadmap.

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

Докажите это до найма

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

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

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

Простой пример из растущего стартапа

У B2B SaaS-стартапа было четыре человека на продуктовой стороне: основатель, один продуктовый дизайнер и два инженера. Выручка начала расти, клиенты просили больше функций, и основатель решил сразу нанять еще двух инженеров.

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

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

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

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

На месяц подключили Fractional CTO, и он ввел несколько простых правил. У каждой продуктовой области появился свой владелец. Из roadmap убрали побочные запросы, у которых не было причины со стороны клиента или выручки. Релизы перевели на простой еженедельный ритм с одним человеком, который утверждал финальный чек-лист. Задачи поддержки стали частью того же плана, что и фичи.

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

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

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

Ошибки, которые удерживают команду на месте

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

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

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

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

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

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

Хорошее решение обычно простое. Дайте каждой области одного владельца. Сократите активные приоритеты до короткого списка. Замораживайте объем работ ближе к дню релиза. Назначьте каждому человеку одного прямого руководителя. Ведите работу в одной основной системе.

Команда может какое-то время жить в беспорядке. Но расти на этом беспорядке она не сможет.

Быстрая проверка перед наймом

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

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

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

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

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

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

Эти проверки почти ничего не стоят, но быстро показывают настоящие узкие места.

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

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

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

Держите план простым:

• Выберите одну сломанную область.
• Назначьте одного владельца.
• Запишите правило на одной странице или короче.
• Проверьте его в одном реальном спринте.

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

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

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

Oleg Sotnikov занимается такой работой через oleg.is. Он работает как Fractional CTO и советник для стартапов, с опытом в software engineering, лидерстве в стартапах, инфраструктуре и AI-first operations, поэтому советы остаются близкими к ежедневной работе.

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