Начало реализации проекта

Время до рынка (time-to-market) имеет решающее значение, но сама разработка продукта занимает только часть времени от момента высказывания идеи до ее успешной реализации. Часто бывает, что само начало разработки сопряжено с определенными усилиями, и этот период простоя сам по себе проблема и является частью процесса под названием технико-экономическое обоснование (feasibility study).

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

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

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

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

Блистательный пример

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

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