Бесконечная разработка: феномен 90% готовности — 2 июня 2026 г. в 06:09:00.944
Бесконечная разработка: феномен 90% готовности «Первые 90% разработки занимают 90% времени, а оставшиеся 10% — ещё 90% времени» – классическое допущение, с которым неизбежно сталкивается каждый РП в НИОКР. Уже знакомый нам кейс: значительная часть изделия практически реализована, есть экспериментальные изыскания в составе проекта. РП докладывает о том, что проект на финальной стадии готовности 80–90%. Проходит месяц — картина не меняется, потом еще месяц — картина та-же, потом еще и еще... Со стороны бизнеса эта хрестоматийная ситуация выглядит так: месяц за месяцем РП ориентирует команду и стейкхолдеров на почти полную готовность, а в итоге продукт выходит на рынок с урезанным функционалом или со значительным опозданием. Все это не только снижает коммерческую эффективность продукта, но и неизбежно подрывает доверие бизнеса к R&D. Почему так происходит? 1. Ошибочные подходы к планированию не учитывают неопределенность, ресурсные конфликты, статистику и риски: технологические и операционные. Ирония – промахи оценки принято списывать на «высокую неопределенность», хотя в самих расчетах она не учитывается. Как правило оценка происходит «по ощущениям» инженеров, что всегда приводит к оптимистичным планам. Как решаем: TRL + OPM3 (см. предыдущую серию постов), FMEA-практики. 2. Не установлены критерии готовности НИОКР – как итог: статус «готово» дается на основании когнитивных искажений, и для каждого это означает разное. Решение: окончание этапа – не «по ощущениям», а на основании акта/протокола по завершению испытаний, фиксация ЖЦ, внедрение «ворот» (Stage-Gate). 3. Позднее выявление проблем –> как следствие дорогостояще переработки (в 2–3 раза превышают даже пессимистичные сценарии). Решение: FMEA-практики на ранних этапах, как обнаружение потенциальных отклонений конструкции и производственной технологии, учет исторической базы инцидентов и рисков предыдущих изделий. 4. Кроме того, зачастую работает простой человеческий фактор: стремление РП сообщать руководству только хорошие новости. Это приводит к искажению данных, когда РП, сам того не осознавая, транслирует неверную интерпретацию. Возвращаясь к нашему кейсу: всё это время готовность проекта следовало оценивать не в 90%, а по минимальной готовности критического узла. Такой результат дает не «средняя температура по больнице», а оценка TRL каждого компонента и степени влияния критических узлов на проект. Подробнее о методе расчета - в следующем посте. Именно такие объективные цифры являются основанием для пересмотра проекта на уровне портфеля: риски, ресурсы, бизнес-эффект, после чего бизнес встаёт перед реальным выбором: ждать полной готовности и сдвигать запуск либо выводить продукт с ограниченным функционалом, перенеся доработки в серию или новую версию. Методика расчета и как РП правильно транслировать состояние проекта бизнесу – в следующих постах 📈