Внешнее техническое руководство для продуктов, разработанных подрядчиком

Почему эта проблема остаётся скрытой

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

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

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

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

Как выглядит владение кодом

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

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

Владение начинается с доступа. Ваша компания должна иметь мастер-доступ к нескольким вещам:

• исходный репозиторий и права администратора
• сервера, облачные аккаунты и инструменты деплоя
• домен и записи DNS
• аккаунты магазинов приложений
• логи, мониторинг и бэкапы

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

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

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

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

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

Как проявляется страх релизов

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

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

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

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

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

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

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

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

Где начинается рост расходов

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

Начните с разбиения расходов на понятные категории: облачные расходы на серверы, хранилище, базы данных и трафик; платежи поставщику за разработку, поддержку и ретейнеры; инструменты для мониторинга, тестирования, аналитики, email, поиска и CI; и аварийные работы: срочные исправления, ночные деплои и восстановление после инцидентов.

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

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

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

Более очевидный сигнал — когда для каждой новой функции нужна ещё одна платная подписка. Простому поиску не всегда нужен отдельный поисковый сервис. Базовому email-потоку не всегда нужна новая система автоматизации. Иногда новый инструмент оправдан. Чаще — команда просто накапливает покупки вместо чётких технических решений.

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

Простая проверка, которую основатель может провести за неделю

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

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

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

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

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

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

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

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

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

Реалистичный пример

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

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

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

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

Обновление цен заняло девять дней. Исправление логина потребовало ещё двух релизов, потому что Alex не хотел трогать логику аутентификации и оплаты в одну неделю. Никто из команды основателя не мог проверить его план, протестировать патч самостоятельно или откатить, если что-то пойдёт не так. Вот как в реальности выглядит страх релизов: люди избегают мелких изменений, потому что не доверяют системе.

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

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

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

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

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

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

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

Скриншоты дают ложное чувство безопасности. Скрин репозитория Git, облачной панели или CI-пайплайна — это не доступ. Основатели должны просить живую проверку. Может ли кто-то из вашей команды сейчас зайти в систему? Видят ли они последний код? Могут ли они просмотреть историю деплоев, биллинги и тревоги без запроса к поставщику? Если нет — у вас нет реального контроля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда основателям нужен второй взгляд от того, кто не участвовал в первоначальной сборке. Oleg Sotnikov at oleg.is делает такую работу в роли fractional CTO и startup-советника, с акцентом на практические передачи, бережную инфраструктуру и AI-first команды разработки. Для компаний, которым нужно вернуть контроль без превращения исправления в большой внутренний проект, такой внешний взгляд часто достаточен, чтобы отличить исправимый беспорядок от продукта, требующего глубокого ребилда.