Как принимаются слабые решения в сложных проектах

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

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

Одна даёт рамку для реального решения. Другая — документ, который хорошо выглядит на совете директоров.

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

Никто не может внятно сказать, при каком результате решение будет пересмотрено. Если никакие данные не способны изменить позицию — это уже не анализ. Это оформление заранее выбранного курса.

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

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

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

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