Оценка осуществимости: пять тестов и как пройти их за день

Что на самом деле решает оценка осуществимости

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

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

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

Пять тестов

Стандартная рамка — TELOS: Technical, Economic, Legal, Operational, Scheduling. Пять независимых тестов, и смысл этой структуры в том, что любой из них дисквалифицирует. Предприятие, блестяще прошедшее четыре и провалившее пятый, не осуществимо на четыре пятых. Оно неосуществимо.

1. Технический — можно ли это построить?

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

Честная версия этого теста задаёт три вопроса. Какой самый сложный отдельный компонент и выпускал ли его кто-нибудь? От чего система зависит из того, что вы не контролируете — API, источник данных, поставщик модели, лицензия? И что происходит с продуктом, когда эта зависимость меняет условия?

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

2. Экономический — сходится ли арифметика?

Это тест, убивающий больше всего предприятий, — и тот, который чаще всего подменяют таблицей, растущей на 20% в месяц, потому что так росла ячейка выше.

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

• LTV/CAC 3.0 — общепринятое определение здорового. Около 1.5 — точка, ниже которой окупаемость становится арифметически невозможной с учётом оттока и маржи.
• Окупаемость CAC за 18 месяцев — стандартный ориентир ранней стадии. После примерно 36 месяцев модель перестала быть бизнесом.

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

У рыночной половины экономического теста свой режим отказа. Один отчёт аналитика — это не доказательство; это одна оценка с датой публикации и методологией, которую вы не видите. Объединять несколько лучше, но только если честно обрабатывать расхождения: отбрасывать явные выбросы и считать набор оценок, опубликованных с разницей в годы, устаревшим, а не усреднять по изменившемуся рынку. Реализация INITE Studio отбрасывает выбросы дальше 3σ от медианы начиная с четырёх источников и помечает набор, в котором годы публикации разнесены больше чем на пять лет.

3. Юридический — разрешено ли это?

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

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

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

4. Операционный — сможете ли вы это вести?

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

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

5. Календарный — переживает ли график зависимости?

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

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

Где классический шаблон ломается на софте

Пять тестов формализовали для капитальных проектов — заводов, мостов, закупок систем. Два допущения не переносятся.

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

Поэтому аудит INITE Studio взвешивает свои линзы по стадии, а не применяет одну фиксированную формулу. На стадии идеи соответствие проблемы и решения несёт 35% веса, а тракция — 5%: измерять там нечего, и притворяться иначе — просто добавлять шум. На поздних стадиях распределение смещается к доказательствам, которые к тому моменту существуют.

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

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

По той же причине стоит явно сказать, что требуется для положительного результата. Аудит INITE Studio возвращает GO только когда одновременно выполнены четыре условия: композитная оценка не ниже 80, ноль красных флагов, средняя уверенность по линзам не ниже 0,6 и ни одного неразрешённого противоречия между линзами. Не хватает одного — вердикт REFINE или KILL. Не потому, что идея плоха, а потому, что уверенного ответа пока нет.

Чем это не является: четыре соседних артефакта

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

Чаще всего подменяют бизнес-планом и proof of concept, и обе подмены дороги одинаково: они отвечают на более узкий вопрос, а к ним относятся так, будто они ответили на широкий. Работающий прототип доказывает технический тест и ничего не говорит об экономическом, юридическом и операционном. Отполированный план доказывает, что кто-то умеет писать.

Кто её проводит и конфликт, который никто не называет

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

Три практических защиты.

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

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

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

Типовые провалы

Шесть повторяющихся и как каждый выглядит снаружи:

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

Разобранный пример

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

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

Экономический — вторым. Пусть около 9 000 клиник подходящего размера на трёх рынках, правдоподобный ACV €4 000 и продажи, требующие человека в цикле. Это SAM около €36 млн и CAC, не имеющий формы самообслуживания. При ACV €4 000 и валовой марже 70% месячная валовая прибыль с клиента около €233, значит окупаемость за 18 месяцев допускает CAC примерно €4 200 со всеми затратами. Полевые продажи это уверенно превысят, а телефонные могут уложиться. Тест не проваливается: он говорит, что ограничением является канал, и теперь канал надо доказать, а не предположить.

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

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

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

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

Для программного продукта работает такая последовательность:

1. Сначала напишите условия остановки. До любых доказательств. Три-пять штук, каждое с метрикой, порогом и датой. Это двадцать минут, и они определяют, будет ли честным всё остальное.
2. Юридический тест первым, если область регулируемая. Он может закончить исследование, и это единственный тест, который нельзя обойти, построив иначе.
3. Экономический тест вторым. LTV/CAC, окупаемость и размер рынка, собранный из нескольких источников, с оставленным на виду расхождением, а не усреднённым.
4. Технический и операционный вместе. Они взаимодействуют: техническое срезание угла обычно проявляется как операционные затраты.
5. Календарный последним, против последовательной цепочки, и затем перезапуск экономического теста с графиком, растянутым в полтора раза.
6. Пишите решение, а не оценку. «Идём», «переделываем» или «стоп» — и конкретные доказательства, которые это изменили бы.

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