Технический дью-дилидженс и узкое место в решениях фаундера

Почему это быстро вызывает тревогу

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

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

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

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

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

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

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

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

Что смотрят проверяющие

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

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

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

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

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

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

Где проявляется узкое место

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

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

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

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

Обещания клиентам делают проблему ещё заметнее. Фаундер или sales lead говорит клиенту: «Да, мы можем сделать это в этом месяце». Потом поставка сдвигается, потому что команда не может изменить объём работ, мягко отказать в кастомной доработке или пересмотреть сроки без согласования. Обещания дают быстро. Исполнение — нет. Покупатели это несоответствие замечают сразу.

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

Простой пример из продуктовой команды

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

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

Ничего не ломается драматично. Работа просто замедляется.

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

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

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

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

Как описать и исправить поток решений

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

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

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

Достаточно простой карты ответственности. Продукт может решать компромиссы по роадмапу в пределах понятного влияния на выручку или сроки. Инженерия может отвечать за сроки релиза, приоритет багов и выбор инструментов внутри бюджета. Найм может принимать решения на pass/fail, когда уже есть заметки по интервью. Финансы могут одобрять расходы ниже фиксированного лимита. Операции могут разбирать исключения для клиентов, инциденты и продление договоров с вендорами.

У фаундера всё равно должны оставаться некоторые решения. Смысл в том, чтобы обозначить границу. Запишите, когда фаундер обязан подключаться: сделки выше определённой суммы, senior-наём, изменения архитектуры с риском для безопасности или условия договоров с необычными рисками. Всё остальное должно двигаться без личного «зелёного света».

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

Как передать полномочия, не теряя контроль

Большинству фаундеров не стоит делегировать самые большие решения первыми. Сначала делегируйте повторяемые.

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

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

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

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

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

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

Ошибки, которые команды совершают перед дью-дилидженсом

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

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

Другая ошибка — документировать линии подчинения, но пропускать правила принятия решений. В компании может быть head of product или engineering manager на бумаге, но никто не понимает, кто может задержать релиз, одобрить покупку инструмента или отклонить кастомную фичу ради одного шумного клиента. Этот пробел замедляет команду сильнее, чем ожидают многие фаундеры.

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

Простой пример хорошо это показывает. Стартап из восьми человек повышает своего senior engineer до VP of Engineering, но фаундер по-прежнему утверждает каждый деплой, подрядчика и изменение архитектуры. На бумаге владение выглядит нормально. На дью-дилидженсе за пять минут видно, что скорость решений всё ещё зависит от доступности одного человека.

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

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

Быстрая проверка перед встречей

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

Перед встречей используйте короткую проверку:

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

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

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

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

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

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

Согласование релизов — частая точка старта. Если каждый деплой ждёт, пока фаундер проверит тикет, прочитает сводку и скажет финальное «да», команда не является самостоятельной. Передайте это решение engineering lead или product owner, запишите правило и отслеживайте cycle time в следующие несколько недель.

Держите изменение маленьким и измеримым:

• назовите нового владельца решения
• назовите запасного
• запишите лимит их полномочий простыми словами
• зафиксируйте cycle time до и после передачи

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

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

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