В поисках ответов почему проваливаются проекты

Немного лирики

Я уверена, что большинство специалистов в информационных технологиях (менеджеры, разработчики, аналитики, специалисты по продажам и т.д.) достаточно часто, если не постоянно, сталкиваются с непониманием заказчиков продуктов/услуг, владельцев бизнеса того, зачем им вообще нужен бизнес-анализ, «мифическая» фаза диагностики, документ о видении и границах проекта (Scope and Vision Document), структурная декомпозиция работ (WBS), спецификация требований или какие-то там пользовательские истории… Мне даже нравится искренне непонимающий и недоверчивый взгляд и улыбка («эй, ребята, похоже нас пытаются развести на дополнительный объем работ...») собеседников на первых встречах, которые повторяют как мантру одну и ту же фразу: «Это все понятно… Но нам нужны только разработчики.»

Отчасти, я понимаю их непонимание: бизнес-анализ сам по себе никому не нужен и самые лучшие требования (полные, связные, непротиворичивые, трассируемые и т.д.) тоже никому не нужны… И даже конечный продукт, самый лучший, без дефектов, с самым лучшим дизайном интерфейсов и Usability тоже не нужен… Я серьезно… Не нужен, если он в конечном итоге не удовлетворяет потребности бизнеса и не решает проблемы причастных/заинтересованных лиц (не востребован конечными пользователями).

Так вот потребности, проблемы и решение определяет или оценивает их влияние, целесообразность и т.д. только бизнес-аналитик. И требования для разработчика с целью реализации решения формулирует тоже он. Разработчик же занимается только реализацией решения, подлежащего автоматизации, т.е. созданием продукта/системы информационных технологий. В его область компетенции не входит оценка его (решения) целесообразности и иных аспектов, относящихся к бизнес-анализу.

Я сейчас не утверждаю, что на проекте обязательно должны быть бизнес-аналитик и спецификация требований (техническое задание). Все зависит от перечня условий и потребностей конкретного проекта.

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

Я говорю об объективной оценке слов заказчика “я знаю” и “я хочу”. Ведь между тем “что я хочу” и тем “что мне действительно нужно и что я могу себе позволить” может быть огромная пропасть. “Заказчик захотел автомобиль, спроектировал самолет, а денег есть только на велосипед”- подходящая метафора для иллюстрации положения вещей на проекте информационных технологий. Что делать разработчику, задача которого состоит в реализации решения, а не в поиске того самого решения проблемы заказчика, оценке его возможности и формировании перечня его желаний в виде списка требований к выбранному решению?

Считаю большой стратегической ошибкой менеджмента проекта решение о включении задач бизнес-анализа (или исключение их из рассмотрения вообще по настоянию заказчика) по умолчанию в перечень задач, например, разработчика или менеджера проекта.

Только факты и выводы

В подтверждении своих слов привожу далее статистику (что может быть красноречивее цифр?) по провалам проектов.

По данным отчета The Standish Group за 2015 год (в исследуемую выборку попало около 50 тысяч проектов по всему миру) около 70% проектов закончились провалом или спорно.

По данным отчета The Standish Group за 2014 год только в США ежегодно тратится 250 миллиардов долларов на разработку программного обеспечения, реализуется около 175 тысяч проектов. Многие из этих проектов заканчиваются провалом или спорно.

Ниже привожу частичные данные по исследованию 8380 проектов из указанного выше отчета:

• около 83% проектов закончились провалом или спорно;
• только 15,5 % проектов уложились или не превысили бюджет более, чем на 20%;
• в 25,2% проектов бюджет был превышен более, чем в 2 раза;
• только 13,9 % проектов уложились или не превысили сроки более, чем на 20%;
• в 47,8% проектов сроки были превышены более чем в два раза;
• только в 7,3% проектов был реализован весь запланированный функционал;
• в 49% проектов функционал был реализован в пределах 25-74%.

По результатам исследований The Standish Group главный фактор успеха и провала проектов – требования, а также иные аспекты (вовлечение пользователей, реалистичные ожидания, ясное видение цели), которые ассоциируются с бизнес-анализом.

Требования – это результат бизнес-анализа, стоимость ошибок которого исчисляется сотнями миллиардов долларов в год в мировом масштабе [4].

Коэффициенты роста стоимости ошибок в процессе разработки требований приведены ниже [3]:



Данные таблицы обработаны и адаптированы автором первоисточника [3] из большого количества работ.

Например, стоимость исправления ошибки, равная 1000 $ на этапе разработки требований, может вырасти до 10000-100000 $ на этапе эксплуатации.

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

Источники:

1. Standish Group 2015 Chaos Report — Q&A with Jennifer Lynch.
2. The Standish Group Report, 2014.
3. McConnell, Steve, 2012: Code Complete.
4. Business Analysis: The Evolution of a Profession By Kathleen Barret, IIBA President and CEO.