Критерии успешности проекта
В этой статье предполагается, что заказчик не принадлежит к биологическим видам «Пильщик Бюджета Обыкновенный» и «Карьерист-Паразит Корпоративный».
Часто приводимое определение успешности:
- В срок
- В рамках бюджета
- С заданным функционалом и приемлемым качеством (заказчику понравилось).
Определение Коберна (дано по книге «Agile Software Development» / “Быстрая разработка программного обеспечения»):
- Проект завершился выпуском продукта. Я не спрашиваю, был ли он завершен в срок и уложился ли в бюджет, важно, что ПО выпущено в свет и начало использоваться.
- Руководство проектом сохранилось. Руководителя не уволили за то, что он натворил.
- Команда, работавшая над проектом, собирается таким же образом работать снова.
Это очень разные определения, но есть нечто, что их роднит .
Рассмотрим пример. Пусть это будет полугодовой проект заказной разработки по внедрению складской системы. Стоимостью проекта триста тысяч долларов.
Первая группа критериев важна для менеджера, заключающего контракт со стороны исполнителя и для владельца фирмы исполнителя. При их невыполнении будет испорчена репутация фирмы. Вторая группа критериев важна, для группы разработки непосредственно делающей проект. Посмотрим на схему:
Оба вышеприведенных определения успешности проекта – внутренние. Теперь попробуем дать внешние определения.
Определение конечного пользователя:
- Приложением удобно пользоваться. Мы просто влюблены в него.
- В целом, на работу тратится меньше времени.
- Стало меньше досадных мелких ошибок. И я, заведующий складом, спокойно сплю по ночам.
А что скажет бизнес заказчика? Не будем торопиться. Предположим, через месяц после начала проекта исполнитель делает встречное предложение:
В принципе, мы можем сделать проект, удовлетворяющий всем трем группам критериев. Через 5 месяцев у вас будет требуемый функционал заданного качества, ваши сотрудники будут довольны и наша команда будет рада работать с вами дальше. И проектные риски минимальны. Мы уже двадцать раз все это делали. Но. Мы тут немного посчитали и нашли, что ваш профит от этого проекта – 100 тысяч долларов в год. Что, согласитесь, не очень много. Предлагаем вам другой вариант. Давайте вместо этой системы складского учета мы попробуем написать систему управления складскими запасами. Честно предупреждаем, что риски будут высоки. Почти наверняка:
- Проект будет тянуться около года.
- Это будет стоить не менее полумиллиона, но сколько точно мы пока не знаем.
- Трудоемкость обслуживания новой системы будет выше.
- Новая система будет сложна в обслуживании и вам понадобится дополнительное обучение.
- Возрастут требования к квалификации персонала.
- Скажем честно, есть шанс, примерно в одну четвертую, что мы не сможем сделать этот проект.
Заказчик подумал, да и согласился.
В итоге:
- Проект тянулся почти два года (превышение по срокам в 2 раза).
- Потребовал два миллиона долларов (превышение по бюджету в 4 раза).
- Система регулярно падает и ее пока «ведут на костылях».
- Пользовательский интерфейс чудовищен и сотрудники заказчика выражают свое недовольство в простой и понятной форме.
- Даже возросшая после переобучения квалификация персонала не может уберечь от мелких досадных ошибок и завсклада носит с собой валокордин.
- Проект потребовал огромного напряжения от проектной команды. Уволился ПМ и часть разработчиков.
Теперь проект не соответствует всем вышеперечисленным группам успешности. Но вложения отбились через полгода после внедрения, и сейчас система устойчиво приносит порядка пяти миллионно долларов в год бизнесу заказчика.
Был ли проект успешен для заказчика? Видимо да. Значит, мы имеем еще одно определение успешности:
- Проектные риски были в пределах нормы по отрасли [например, вероятность досрочного закрытия менее 50%].
- Затраты на проект + совокупная стоимость владения отбились за приемлемый срок [например, год].
Это определение успешности бизнеса заказчика. Ну а поскольку, проекты существуют только потому, что их заказывают, то без выполнения этой группы критериев остальные теряют ценность. Они тоже важны. Они могут быть необходимы. Но последняя группа критериев - центральная.
PS. Существенная часть проектов (на мой взгляд, более половины) начинается и продолжается с заведомым и известным нарушением последней группы критериев. При этом неважно, к какому типу (заказная, коробочная, внутренняя) относится разработка.
PSS. История про систему учета складских запасов не совсем вымышленная. Она по частям собрана из реальных историй.
PSSS. Есть еще группа критериев, относящаяся к “закулисным заинтересованным лицам”. Но она не так интересна.