Fractional CTO после того, как проект фрилансера перестал масштабироваться

Когда проект, сделанный фрилансером, перестаёт работать для команды

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

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

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

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

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

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

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

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

Первые признаки, что вы потеряли контроль над релизами

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

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

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

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

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

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

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

Что задокументировать в первую неделю

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

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

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

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

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

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

Небольшая команда SaaS обычно может сделать это за несколько дней. Один общий документ часто быстро показывает настоящую проблему: команде не нужен ещё код. Ей нужен контроль.

Как вернуть контроль над релизами за 30 дней

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

1-я и 2-я недели

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

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

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

Сделайте чек-лист релиза достаточно коротким, чтобы им действительно пользовались:

• Проверьте точные изменения в этом релизе.
• Запустите тесты и быстро проверьте основной путь пользователя.
• Убедитесь, что откат всё ещё работает.
• Опубликуйте короткую заметку о релизе для команды.

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

3-я и 4-я недели

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

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

Как говорить о рисках без драмы

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

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

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

Для каждого срочного риска добавьте простой пример затрат или простоя. Избегайте расплывчатых формулировок вроде плохой архитектуры или технического долга. Лучше сказать: если сломается webhook оплаты, платящие пользователи могут потерять доступ; или только один разработчик знает шаги деплоя, поэтому больничный может задержать релиз на три дня.

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

Письменные решения делайте короткими. «Принимаем этот риск до июля» — достаточно. «Исправляем доступ к деплою в этом спринте» — достаточно. Эти заметки не дают одному и тому же спору возвращаться на каждом совещании.

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

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

Реалистичный план на шесть месяцев

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

Месяцы 1–3

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

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

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

Месяцы 4–6

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

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

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

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

Пример: небольшой SaaS после передачи проекта подрядчиком

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

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

Fractional CTO подключается и притормаживает процесс. Вместо обещания большого переписывания они вводят одно окно релизов в неделю. На первый взгляд это мелочь, но ритм меняется быстро. У команды появляется фиксированный день для выкладки, фиксированный день для тестирования и правило, что срочные исправления всё равно проходят через один чек-лист, прежде чем кто-то отправит код.

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

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

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

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

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

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

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

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

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

Просите короткие письменные записи после каждой передачи дел и каждой попытки релиза. Фиксируйте последние изменения, известные баги, ручные обходные пути и кто отвечает за каждый открытый вопрос. Скучно? Да. Всё равно полезно.

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

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

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

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

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

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

• Может ли ваша команда выкатывать изменения без исходного фрилансера?
• Контролирует ли компания репозиторий кода, облачные аккаунты, DNS и домен?
• Может ли кто-то объяснить три главных риска поставки на одной странице?
• Понятно ли, что должен дать следующий 90-дневный период в обычных бизнес-терминах?

Если хотя бы на один вопрос ответ «нет», не считайте это кадровой проблемой. Это проблема процесса. Команда не может нормально планировать, если доступы разделены, релизы зависят от памяти, или никто не может сказать, какой риск первым ударит по выручке.

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

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

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

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

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