Критерии успешности проекта

В этой статье предполагается, что заказчик не принадлежит к биологическим видам «Пильщик Бюджета Обыкновенный» и «Карьерист-Паразит Корпоративный».

Часто приводимое определение успешности:

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

Определение Коберна (дано по книге «Agile Software Development» / “Быстрая разработка программного обеспечения»):

  • Проект завершился выпуском продукта. Я не спрашиваю, был ли он завершен в срок и уложился ли в бюджет, важно, что ПО выпущено в свет и начало использоваться.
  • Руководство проектом сохранилось. Руководителя не уволили за то, что он натворил.
  • Команда, работавшая над проектом, собирается таким же образом работать снова.

Это очень разные определения, но есть нечто, что их роднит .
Рассмотрим пример.  Пусть это будет полугодовой проект заказной разработки по внедрению складской системы. Стоимостью проекта триста тысяч долларов.

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

qcedu.PNG
Оба вышеприведенных определения успешности проекта – внутренние. Теперь попробуем дать внешние определения.

Определение конечного пользователя:

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

А что скажет бизнес заказчика? Не будем торопиться. Предположим, через месяц после начала проекта исполнитель делает встречное предложение:

В принципе, мы можем сделать проект, удовлетворяющий всем трем группам критериев. Через 5 месяцев у вас будет требуемый функционал заданного качества, ваши сотрудники будут довольны и наша команда будет рада работать с вами дальше. И проектные риски минимальны. Мы уже двадцать раз все это делали. Но. Мы тут немного посчитали и нашли, что ваш профит от этого проекта – 100 тысяч долларов в год. Что, согласитесь, не очень много. Предлагаем вам другой вариант. Давайте вместо этой системы складского учета мы попробуем написать систему управления складскими запасами. Честно предупреждаем, что риски будут высоки. Почти наверняка:

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

Заказчик  подумал, да и согласился.
В итоге:

  • Проект тянулся почти два года (превышение по срокам в 2 раза).
  • Потребовал два миллиона долларов (превышение по бюджету в 4 раза).
  • Система регулярно падает и ее пока «ведут на костылях».
  • Пользовательский интерфейс чудовищен и сотрудники заказчика выражают свое недовольство в простой и понятной форме.
  • Даже возросшая после переобучения квалификация персонала не может уберечь  от мелких досадных ошибок и завсклада носит с собой валокордин.
  • Проект потребовал огромного напряжения от проектной команды. Уволился ПМ и часть разработчиков.

Теперь проект не соответствует всем вышеперечисленным группам успешности. Но вложения отбились через полгода после внедрения, и сейчас система устойчиво приносит порядка пяти миллионно долларов в год бизнесу заказчика.
Был ли проект успешен для заказчика? Видимо да. Значит, мы имеем еще одно определение успешности:

  • Проектные риски были в пределах нормы по отрасли [например, вероятность досрочного закрытия менее 50%].
  • Затраты на проект + совокупная стоимость владения отбились за приемлемый срок [например, год].

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

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

PSS. История про систему учета складских запасов не совсем вымышленная. Она по частям собрана из реальных историй.

PSSS. Есть еще группа критериев, относящаяся к “закулисным заинтересованным лицам”. Но она не так интересна.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.