, ISO 9000. Процессы, порождаемые данными методами, считались бюрократизированными, медленными, противоречащими стилю командной работы, принятой у инженеров, создающих ПО». Сторонники иногда называют этот подход «бережливое управление проектами» по аналогии с «бережливым производством». Причины, по которым в мире появились гибкие методы, описаны в главе 1: значительное превышение сроков и бюджета, неспособность добиться заявленных характеристик продукта в большинстве ИТ-проектов. Облегченные методы по ИТ-проектам включают:
1) быструю разработку приложений;
2) параллельную разработку приложений;
3) экстремальное программирование;
4) SCRUM>7.
Подробное рассмотрение этих методов не является нашей целью.
Я все же с изрядной долей скептицизма воспринимаю объяснения типа «традиционное управление проектами не подходит для ИТ-проектов» как причину появления облегченных, или гибких, методов. От людей, по-настоящему, профессионально разбирающихся в управлении проектами (имеющих сертификат РМР), я подобных заявлений не слышал. Так, Дэвид Андерсон [8, с. 55] пишет:
«В традиционном подходе при запуске проекта главная задача — четко определиться с содержанием, зафиксировать бюджет (включая людей и ресурсы) и дату окончания работ. На этом основании стоит классическая модель управления проектами PMI, поддерживаемая тяжеловесными методами контроля качества ISO 9000... что создает для менеджеров ИТ-проектов наихудшие условия при разработке софта. Существующая модель управления проектами по PMI/ ISO 9000 устарела» (с. 60).
Несмотря на то, что далее Андерсон демонстрирует искусный подход к внедрению ССРМ в ИТ-проектах, по моим личным наблюдениям за ИТ-компаниями, столкнувшимися с трудностями при реализации проектов, многие из них не понимают традиционной методики, а если и применяют ее, то неправильно. Основные ошибки: неполное исходное определение содержания проекта (например, нет иерархической структуры работ) и использование неэффективного процесса управления изменениями или вообще полное отсутствие такового. Часть методов, которые называют альтернативой тяжеловесным технологиям РМВОК, на самом деле в этом своде знаний описаны. Наиболее яркий пример — подход «ускоренная спиральная разработка прототипов». И хотя гибкие методологии довольно эффективны в работе небольших команд над несложными системами программного обеспечения, я считаю, что в отношении масштабных проектов они играют скорее вспомогательную роль и не заменяют комплексных подходов, описанных в РМВОК и ОРМ3.
