Founder-built SaaS: от героического кодинга к shared ownership

Почему code review перестает быть достаточным

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

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

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

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

Возьмем изменение в биллинге. Разработчик открывает PR, и сам код нормальный. Более сложный вопрос — риск. Нужно ли добавить еще одну проверку перед списанием денег с клиентов? Если ответ на это знает только основатель, review перестал быть review. Он стал узким местом для решений.

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

Как выглядит heroic coding в повседневной работе

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

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

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

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

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

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

Что теряет команда, когда все решает один человек

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

Стоимость здесь не только в задержке. Релизы становятся напряженными, потому что все знают: одна пропущенная деталь вечером или в выходные вернется к основателю. Люди спешат за финальным approval, а потом замирают во время выкладки. Через какое-то время разработчики перестают ощущать обычную ответственность, потому что все равно ожидают, что основатель снова откроет каждое решение.

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

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

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

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

Как превратить решения в простую систему

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

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

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

Потом сгруппируйте эти решения в несколько понятных областей. Product decisions охватывают scope, приоритет, запросы клиентов и компромиссы. Code decisions охватывают review, тесты, рефакторинг и технический долг. Release decisions охватывают cutoff, approvals, rollback и реакцию на инциденты.

Для каждой области нужен default. Defaults останавливают мелкие споры еще до того, как они начнутся. Для продуктовой работы новые запросы могут ждать следующего планирования, если только они не блокируют выручку. Для кода можно требовать тесты для биллинга, auth и изменений данных, но разрешать небольшим UI-правкам двигаться быстрее. Для релизов можно выбрать одно окно развертывания в неделю и избегать выкладок в пятницу, если только проблема не срочная.

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

Нужен и короткий rule for escalation. Эскалируйте только тогда, когда решение меняет roadmap, создает риск для безопасности или закона, затрагивает крупных клиентов или может вызвать серьезный простой. Все остальное остается у владельца.

Именно так engineering decisions становятся спокойнее. Люди перестают просить разрешения на рутинную работу. Релизы меньше походят на драму. Основатель по-прежнему занимается редкими важными решениями, но больше не тратит неделю на десять разных форм одного и того же вопроса.

Релизный ритм, который снижает стресс

Большинству небольших SaaS-команд не нужна еще большая скорость. Им нужно меньше сюрпризов в день релиза. Спокойный release routine снижает панику, уменьшает число ошибок и делает команду менее зависимой от одного человека, который должен помнить все.

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

Простой недельный ритм

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

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

Обычно такой ритм выглядит так:

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

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

Перед выкладкой

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

Записывайте rollback steps до релиза, а не после провала. Делайте их короткими и конкретными. Какую версию откатывать? Кто это делает? Сколько времени это должно занять? План rollback превращает плохой релиз из кризиса в 10-минутную задачу.

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

Как shared ownership работает на практике

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

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

Хорошо работает простая схема. Разделите продукт на несколько понятных областей, например billing, onboarding или admin tools. Дайте каждую область не одному, а двум людям, чтобы никто не стал узким местом. Меняйте дежурного по review каждую неделю, чтобы один и тот же человек не проверял каждый pull request. Разрешите коллегам сливать маленькие безопасные изменения без ожидания основателя. Держите продуктовые и технические решения в одной общей заметке, чтобы потом можно было проверить причину.

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

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

Что все еще остается у основателя

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

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

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

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

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

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

У support тоже важная роль. Если два или три клиента жалуются на один и тот же checkout bug, support не оставляет это где-то в чате. Они рано фиксируют закономерность, включая план, браузер и точный шаг, на котором люди застряли. Это дает инженеру понятную точку для теста и показывает основателю, является ли проблема небольшим fix или рискованным billing change.

Релизный ритм остается намеренно скучным. Команда выкатывает по вторникам и четвергам. Во вторник идут исправления, которые пришли из support tickets в начале недели. В четверг — более мелкие продуктовые обновления и любая работа по billing, которая прошла тесты без проблем.

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

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

Shared ownership обычно начинается именно так. Никто не отказывается от ответственности. Команда просто перестает отправлять каждое решение через одного уставшего человека.

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

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

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

Еще одна ловушка — менять процесс каждую неделю. В понедельник любое изменение требует двух reviewers. На следующей неделе hotfix уже идет без review. Потом для AI-generated code появляется отдельный путь. Когда правила постоянно двигаются, люди перестают доверять процессу и снова спрашивают основателя, что считается на этот раз. Так каждое мелкое решение снова попадает в один inbox.

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

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

AI tools могут ускорять работу, но они же создают путаницу, если использовать их без правил review. Если один разработчик вставляет output AI прямо в production code, а другой переписывает все вручную, качество становится случайным. Лучше работает простое правило: используйте AI для черновиков, рефакторинга или поиска тестов, но пусть human reviewer проверяет логику, безопасность и edge cases.

Когда такие ошибки накапливаются, основатель и становится процессом. Это не масштабируется и никому не приносит удовольствия.

Быстрая проверка перед каждым релизом

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

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

Используйте пять проверок:

• Коллега, который не делал изменение, может объяснить его простыми словами.
• Кто-то протестировал самый частый путь пользователя плюс один неудобный edge case, который может быстро подорвать доверие.
• Команда знает, как откатить релиз за минуты — rollback, feature flag или простой deploy шаг, который всем понятен.
• Support, sales или тот, кто общается с пользователями, знает, что изменилось и какие вопросы могут появиться в тот же день.
• Один человек принимает финальное решение по scope, чтобы в последний момент под давлением не пролезли лишние вещи.

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

Представьте небольшую SaaS-команду, которая выкатывает новый billing screen в пятницу днем. Код выглядит чисто. Потом support узнает об этом из злых сообщений, кнопка отмены на мобильном не работает, а steps for rollback никто не помнит, потому что последние несколько релизов делал только основатель. Это не проблема программирования. Это проблема ownership.

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

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

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

Начните с чего-то обычного: приоритета бага, решения о go/no-go для релиза или момента, когда pull request нужен второй взгляд. Если основатель отвечает на один и тот же вопрос три раза в неделю, задокументируйте именно его.

Хорошо работает простой двухнедельный спринт:

1. Запишите одно правило принятия решения на одной странице. Сделайте его простым. Укажите, кто решает, какие входные данные важны и когда основатель должен не вмешиваться.
2. Запланируйте один небольшой релиз с фиксированным scope. Не добавляйте ничего лишнего в последний момент.
3. Задайте команде прямой вопрос: «Где вы все еще ждете меня?»
4. Проведите релиз по новому правилу. Следите за задержками, переделками и моментами, когда кто-то все еще по привычке просит разрешения у основателя.
5. Разберите последние две недели. Посмотрите, что стало быстрее, что ощущалось спокойнее и что по-прежнему зависит от одного человека.

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

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

Если одни и те же узкие места продолжают всплывать, помощь со стороны может ускорить изменения. Oleg Sotnikov на oleg.is работает со стартапами и небольшими командами над техническим ownership, привычками релизов и практичными AI workflows, что может помочь основателям выйти из середины каждого решения. Такая поддержка лучше всего работает, когда команда уже понимает, где застревает, и хочет практичное решение.

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