Техническое планирование на pre-seed до найма или аутсорса

Почему ранняя работа над продуктом идёт не по плану

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

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

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

Небольшой пример это хорошо показывает. Основатель говорит: «Нам нужен booking SaaS для сервисного бизнеса». Звучит понятно, пока команда не задаст несколько обычных вопросов: кто может создавать записи? Клиенты платят онлайн? Нужны ли сотрудникам календари и права доступа? Нужны ли владельцу отчёты или админ-панель? Будут ли email- или SMS-напоминания?

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

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

Короткий план не уберёт все сюрпризы. Но он делает кое-что лучше: даёт всем одну и ту же стартовую точку. Уже это может сэкономить недели и уберечь от болезненного первого счёта.

Уложите продукт на одной странице

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

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

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

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

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

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

Этого уже достаточно, чтобы начать полезный разговор с фрилансером, агентством или Fractional CTO. И этого достаточно мало, чтобы вы действительно обновляли документ по мере изменения идеи, а она почти наверняка будет меняться.

Нарисуйте систему простым языком

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

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

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

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

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

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

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

Пропишите предположения по delivery по шагам

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

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

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

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

Дальше запишите, что команда должна строить с нуля. Будьте конкретны. «Кастомная логика бронирования» полезно. «Работа на backend» — нет.

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

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

Составьте список рисков, с которым можно работать

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

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

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

Затем добавьте одно действие к каждому серьёзному пункту. Одно действие, а не план спасения. Так список остаётся полезным.

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

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

Пример: небольшой booking SaaS

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

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

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

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

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

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

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

Это и есть тот короткий brief, который Fractional CTO должен вернуть до того, как кто-то начнёт оценивать спринт. Если уже первый черновик выглядит перегруженным, значит scope всё ещё слишком широкий.

Ошибки, которые рано съедают деньги

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

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

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

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

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

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

Один простой принцип помогает: сначала оплатите короткий системный план, а уже потом — delivery. Хороший план фиксирует scope, проговаривает предположения, называет риски и показывает, кто чем управляет. Это стоит намного меньше, чем переделка после поспешного найма.

Короткая проверка перед наймом или аутсорсом

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

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

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

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

Список предположений важнее, чем многим основателям кажется. Запишите всё, что может изменить разработку: сначала mobile web, пока без кастомных ролей, один платёжный провайдер, только английский язык, ручная админ-поддержка для крайних случаев. Такие решения могут сэкономить недели.

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

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

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

Теперь ваши заметки должны сложиться в brief, который другой человек сможет прочитать за 10 минут и обсудить за 30. В этом и смысл: убрать догадки до того, как вы начнёте тратить деньги на команду, агентство или поспешный первый спринт.

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

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

Затем отправьте brief кандидатам или агентствам и задавайте более сильные вопросы. Не просите только смету и сроки. Спросите, где они видят слабые места в вашем плане, что бы они убрали и какое предположение проверили бы первым. Сильный исполнитель будет спорить со scope. Слабый — просто проставит цену напротив каждой строки.

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

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

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