План технического оздоровления на первую неделю в стартапе

Почему первая неделя часто идёт не так

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

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

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

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

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

Кого опрашивать в первую очередь

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

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

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

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

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

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

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

Что спрашивать у тех, кто выпускает

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

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

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

Короткий набор вопросов работает лучше:

• Где последний релиз ждал дольше всего?
• Что обычно ломается в последние 24 часа?
• Какое согласование замедляет простые изменения?
• Что вы пропускаете, когда дедлайн поджимает?

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

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

Просите по одному конкретному примеру на каждый вопрос. "Пайплайн медленный" слишком общо. "Наша сборка заняла 47 минут во вторник, а потом упал флейки UI‑тест" — полезно. К концу этих бесед обычно одна проблема всплывает снова и снова. Исправьте её в первую очередь.

Что спрашивать у поддержки

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

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

Держите разговор простым:

• Какая проблема возвращается, даже после того как кто‑то сказал, что её исправили?
• Какой баг больше всего злит или путает пользователей и заставляет их уходить?
• На какие клиентские вопросы поддержке приходится ждать инженера, прежде чем ответить?
• Где срывается передача и клиент остаётся ждать без ясного владельца?

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

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

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

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

Выберите один узел, а не пять

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

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

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

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

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

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

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

План ремонта на первую неделю

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

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

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

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

К третьему дню выберите одну точку торможения и опишите фикс простыми словами. Держите его узким. "Убрать ручное одобрение релиза для низкорисковых багфиксов" — понятно. "Улучшить процесс доставки" — размыто и обычно бесполезно.

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

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

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

Простой пример из небольшой SaaS‑команды

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

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

Поддержка первой почувствовала задержку. Клиент спрашивал: "Это исправлено?", а поддержка могла лишь отвечать: "Инженеры проверяют." Два дня спустя могли дать ответ. Такие ожидания делают простой баг гораздо хуже.

Первый ремонт был маленьким и грубым. Команда назначила одного ответственного за релиз на неделю и ввела ежедневное окно релизов в 16:00.

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

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

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

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

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

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

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

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

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

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

Быстрые проверки, прежде чем двигаться дальше

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

Первый ремонт должен оставить короткий след доказательств. Работа по релизам должна занимать меньше времени. Поддержка должна тратить меньше времени на выяснения. Задачи должны перестать сидеть в разрыве между командами. Если ничего из этого не изменилось — фикc, вероятно, ещё не завершён.

Несколько проверок обычно показывают правду быстро:

• Релизы теперь заканчиваются быстрее, чем неделю назад. Даже падение с 2 часов до 45 минут имеет значение.
• Поддержка получает ответы быстрее и с меньшим количеством «туда‑сюда» с инженерами.
• Один человек владеет фиксом, принимает решения и закрывает вопросы, вместо ожидания общего согласия.
• Команда перестала использовать одну повторяющуюся «заплатку», например ручной деплой, скопированный шаблон сообщения или таблицу в спредшите.
• Меньше задач простаивают при передаче между продуктом, инженерией, QA или поддержкой.

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

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

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

Что делать после первого ремонта

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

Запишите три вещи простыми словами:

• что вы изменили
• что стало быстрее или спокойнее
• что всё ещё тормозит команду

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

Не выбирайте следующую точку по интуиции. Измерьте этот ремонт несколько дней. Посмотрите одну–две метрики, которые соответствуют решённой проблеме: время от пулл‑реквеста до продакшна или число тикетов, которые лежат без движения более 24 часов.

Если число сдвинулось — продолжайте. Если нет — возможно, вы лечили симптом, а не причину.

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

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

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

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