Управление ИТ-проектами: что придёт на смену текущему подходу?
07 Апр 2015
В последнее время всё больше высказывается сомнений в правильности проектного подхода при внедрении информационных систем. Среди проблем, которые называют разработчики:
- Ориентация на краткосрочную перспективу. Команде проекта не придётся иметь дела с ИС, сделанными в рамках проекта, ведь команда расформировывается после окончания проекта. Зачастую с продуктом потом просто не удобно работать.
- Службе ИТ-поддержки, как правило, не хватает ресурсов, они перегружены и, вдобавок, они не получают поддержки от команды проекта, так как, зачастую, к моменту обнаружения проблемы её уже просто нет.
- Команда проекта не участвуют в анализе проблем разработанной информационной системы и зачастую не мотивирована должным образом участвовать в мониторинге или подробно вести «логи», чтобы проблему было легче обнаружить и решить.
- Команда проекта делает ограниченное число релизов/обновлений и не замотивирована к созданию надежной системы тестирования.
Также отмечается, что проекты зачастую оптимизируются в части расходов за счёт других процессов, и, соответственно за счет цепочки создания стоимости. А учитывая, что большая часть цепочки создания стоимости компании находится за пределами конкретного проекта, то, соответственно, менеджеры проектов не несут за нее ответственности.
Кроме того, при объединении работ в проекты, обычно связывают ценные функции продукта с менее ценными, чтобы создать «жизнеспособную» версию продукта. Однако, в таком случае, получается, что среднее время внедрения функции никак не коррелирует с её приоритетом.
Почему же ИТ-подразделения продолжают использовать проектный подход при разработке ИС? Ответ прост – процессы бюджетирования, принятые в организациях, спроектированы для работы с проектами, и руководители ИТ-проектов и Офисы управления проектами знают, как работать с ними.
Если у проектного подхода столько минусов, то что можно предложить взамен?
Шаг 1: «Разукрупняем» проекты
Ключевой элемент трансформации – «разукрупнение» проектов и расположение элементов продукта в порядке убывания стоимости задержки их внедрения (более подробно рассмотрено в этой статье).
«Стоимость задержки – это потенциальные расходы несвоевременной реализации бизнес-требований в единицу времени»
Такой подход позволит стейкхолдерам оперативно определять приоритеты и наиболее ценный функционал получать быстрее, тем самым максимизируя ценность.
При такой модели меняется роль Офиса управления проектами. Вместо того, чтобы проходить этапы проектирования, бизнес-анализа и утверждения, Офис управления проектами будет совместно со стейкхолдерами задавать очередность входящих требований, анализировать их стоимость задержки. Этот процесс определения ценности каждого требования позволит обнаружить «Чёрных Лебедей» – функционал, который привносит значительно больше ценности нежели остальные бизнес-требования. На графике можно увидеть распределение стоимости задержки для каждого бизнес-требования после выполнения этого шага (в соответствии со статьей, указанной выше).
Эта модель также работает в соответствии с подходами Тейлора, в которой менеджеры, аналитики и системные архитекторы решают какие бизнес-требования реализовывать в каком порядке и какую архитектуру использовать, а инженеры действуют согласно плану. Такая модель исключает из планирования команды непосредственных разработчиков, наиболее полно владеющих информацией о продукте. Ещё одним недостатком этой модели является то, что она оперирует показателями эффективности управления проектом (соблюдение сроков, содержания, качества и бюджета) больше, чем показателями ценности для заказчика.
Шаг 2: Исследуем проблему вместе
При планировании (определении списка требований, архитектуры информационной системы…) часто используется следующая последовательность шагов:
- Определяются желаемые результаты
- Определяются стейкхолдеры и заинтересованные лица
- Генерируются идеи решения проблемы
- Из альтернативных решений выбираются ключевые.
Эту схему можно визуализировать в виде Карты Влияния (Impact Map):
Разработчики чаще всего получают пользовательскую историю, требование, задачу в виде единственной ветви Карты Влияния. Но далеко не факт, что выбранная ветвь содержит решение, ведущее к наибольшей ценности для заказчика.
Создание продуктов, которые не приносят требуемой ценности, является основным источником перерасхода в компании. Исследования показывают печальную статистику: от 60 до 90% идей не улучшают тех показателей, которые призваны были улучшить. А согласно данным Microsoft лишь 1/3 ведёт к статистически значимым улучшениям показателей, 1/3 не показала статистических значимых улучшений, а ещё треть вообще привела к явному и весьма ощутимому ухудшению показателей. Претворение в жизнь инициатив, не ведущих к улучшению желаемых показателей, не только является пустой тратой ресурсов компании (в первую очередь времени), но также увеличивает сложность системы таким образом, что потом её сложнее модифицировать и поддерживать.
Любую идею о добавлении функции, архитектурного решения или улучшения стоит принимать как гипотезу и проверять на практике, прежде чем внедрять. Эксперименты занимают время, но эти затраты на поиск решения не сопоставимы с издержками принятия неверного решения.
Для повышения эффективности использования Карты влияния, в её разработке должны участвовать кросс-функциональные команды, включающие в себя всех основных стейкхолдеров. Затем эти Карты должны распространятся среди всех команд разработчиков, чтобы они понимали контекст и окружения принятого решения и желаемые результаты.
Задача менеджеров компании – создать условия, в которых команды разработчиков смогут проводить эксперименты, чтобы найти пути достижения желаемых результатов, а также отклонять нерабочие идеи и продвигать решения, показавшие свою эффективность. Внедрение этого коллективного подхода к разработке продукта, развитию архитектуры и улучшению процессов – отличительная особенность нового типа бережливых организаций.
Оригинал: http://radar.oreilly.com/2015/03/what-should-replace-the-project-paradigm.html