Проверка аутсорсинговой инженерии стартапа без слепых зон

Почему это быстро становится проблемой

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

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

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

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

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

Устные обещания этого не решают. «Мы перенесём всё позже» не равно подписанным контрактам, владению аккаунтов, логам доступа и ясному плану передачи. Diligence быстро становится сложной, потому что аутсорсинговая инженерия часто сначала работает на доверии, а бумажная работа идёт потом. Инвесторы хотят наоборот.

Что компания должна контролировать сейчас

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

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

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

Держите под контролем:

• Git-репозитории и аккаунты публикации пакетов с админ-доступом компании
• Производственный облачный аккаунт, DNS и настройки доменов в аккаунтах, принадлежащих компании
• Права администратора для тикетов, документации, мониторинга и аналитики
• Одна внутренняя папка для контрактов, счетов, заметок по архитектуре, правил по креденшалам и контактов поставщика

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

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

Если хотите быстро проверить — попросите одного человека внутри компании проверить доступ ко всем системам за один день. Любая найденная дыра — реальная проблема для diligence.

Как провести ревью за неделю

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

Начните с полной карты системы в день 1. Попросите поставщика перечислить каждый продукт, сервис, репозиторий, облачный аккаунт, домен, базу данных, инструмент аналитики, почтовый ящик поддержки и админ‑панель, связанные с компанией. Рядом с каждым элементом укажите владельца, метод входа и имеет ли компания или поставщик админ-доступ.

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

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

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

День 4 используйте, чтобы собрать доказательства базовой работы по безопасности. Попросите текущий список доступа, место хранения бэкапов, дату последнего теста восстановления, заметки по инцидентам и краткое описание процедуры вывода инженеров из проекта. Не принимайте «у нас есть бэкапы» как ответ. Спросите, когда в последний раз восстанавливали, и кто это проверял.

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

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

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

Пропишите права на ревью в бумагах

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

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

Документы должны покрывать четыре пункта простым языком:

• Ваша компания владеет кастомным кодом, дизайнами, документацией и прочими работами, созданными для проекта после оплаты.
• Ваша компания может по запросу просматривать репозитории, тикеты, техническую документацию, записи тестов и заметки по деплоям.
• Поставщик должен предоставлять доступ в установленное время, например в течение 1–3 рабочих дней во время diligence, перехода или спора.
• То же право доступа применяется при передаче, а не только пока контракт активен.

Не прячьте это в расплывчатой клаузе о сотрудничестве. «Поставщик будет разумно содействовать» — слабая формулировка. «Поставщик предоставит доступ только для чтения к репозиториям и проектным записям в течение 2 рабочих дней» — гораздо лучше.

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

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

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

Держите контроль релизов в компании

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

Установите правило для основной ветки заранее. Решите, кто может мержить, и держите эту группу маленькой. В большинстве стартапов самый чистый подход прост: команда аутсорсера открывает pull request, а один внутренний владелец утверждает финальный merge. Если у вас ещё нет инженерного лидера, основатель и один доверенный советник могут держать эту роль, пока вы не наймёте инженера.

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

Практичная настройка обычно включает несколько правил:

• Защитите main-ветку и блокируйте прямые пуши.
• Разрешайте мержи только с именованных аккаунтов, которыми управляет компания.
• Храните секреты деплоя в хранилище компании, а не в менеджере паролей поставщика.
• Тестируйте шаги отката перед каждым крупным релизным циклом.
• Записывайте каждый релиз с указанием владельца, времени и краткого описания изменений.

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

Откат — это место, где слабые настройки показывают себя сразу. Сделайте dry‑run до того, как он понадобится. Запушьте мелкое изменение, откатите его и запишите точные шаги. План отката, который никто не тестировал — это просто запись в документе.

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

Попросите доказательства работы по безопасности

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

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

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

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

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

Несколько записей обычно дают достаточно:

• Недавний обзор доступа к продовым системам
• Доказательство последней ротации секретов
• Заметки о последнем тесте восстановления бэкапа с указанием времени
• Короткий список задач с выявленными уязвимостями и датами закрытия

Даты закрытия важны. Без конца открытые задачи по безопасности обычно означают, что никто за ними не отвечает. Хочется видеть путь: от обнаружения до фикса и проверки, с именем рядом с каждой ступенью. Это показывает, что аутсорс-команда умеет управлять риском сейчас и передать более чистую систему позже.

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

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

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

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

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

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

Тон переговоров с инвестором меняется. Вместо «Наше агентство этим занимается» основатель может сказать: «Компания владеет аккаунтами, агентство имеет ограниченный доступ, и у нас есть 60‑дневный план передачи остального». Этот ответ звучит спокойно, потому что он конкретен.

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

Ошибки, которые вызывают тревогу

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

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

Другой красный флаг — когда чат становится единственным источником записей. Slack, Telegram и email подходят для повседневной работы, но они слабая замена письменным решениям, заметкам по деплойам и записям доступа. Во время diligence беспорядочная история в чате не ответит на простые вопросы вроде «кто одобрил прод‑изменение» или «где хранятся секреты».

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

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

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

Те же сигналы появляются снова и снова:

• компания не может деплоить без одобрения поставщика
• доступы живут в личных аккаунтах
• знания об архитектуре живут только в чате
• контракты не явно передают IP
• никто не может объяснить, как сменить поставщика за 30–90 дней

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

Короткий чеклист перед стартом diligence

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

Используйте это как быстрый пред‑чек:

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

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

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

Ваши следующие 90 дней

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

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

Простой 90‑дневный план передачи часто лучше гигантской миграции:

• День 1–30: назначьте внутреннего владельца, соберите все рукбуки, замапьте окружения и убедитесь, что аккаунты компании держат ключи для релизов, доступ к хостингу и мониторингу.
• День 31–60: перенесите поддержку, мелкие фиксы и реакцию на инциденты в компанию. Держите поставщика вовлечённым, но ваша команда должна выполнять работу и обновлять документацию.
• День 61–90: передайте исполнение релизов владельцу компании или первому внутреннему инженеру, а поставщик наблюдает и закрывает пробелы вместо того, чтобы управлять процессом.

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

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

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