Управление проектом разработки по
Единственный способ разработать программное обеспечение – это инициировать проект по его созданию.
Считалось и считается до сих пор, что проекты в среде высоких технологий, к которым относится и разработка программного обеспечения, очень трудно планировать и выполнять, и что доказательство этого – низкие показатели успешности таких проектов.
Еще в 70-годах Фредерик Брукс сделал утверждение, что несмотря на все достижения в области создания аппаратных и программных средств, не было никакого соответствующего развития ни в технологии, ни в методике управления, которое позволило бы выполнять программные проекты вовремя, в пределах согласованного бюджета и требований к качеству конечного продукта. Все разработчики программного обеспечения охотно согласились с этим утверждением, потому что с виду оно очень походило на правду. Казалось очевидным, что методы, доказавшие свою эффективность в строительстве или кинематографии совершенно точно не сработают в условиях плывущих требований, быстро развивающихся технологий и нерегламентированного жесткими рамками творческого процесса создания ПО. Как писал в своей книге «Серебряная пуля» Фергус О’Коннэл: «Мы искали развития. Поскольку компьютер и программное обеспечение были новы, мы думали тогда, что нужна некая новая вещь, чтобы работать с ними. По какой-то причине мы никак не могли себе представить, что могли бы сработать старые вещи».
Статьи и книги, посвященные созданию программного обеспечения, уделяли повышенное внимание различным аспектам разработки (методологиям управления жизненным циклом программных проектов) и практически не касались вопросов общей дисциплины управления проектами – проектного менеджмента. Ошибочность такого подхода демонстрируется хотя бы тем фактом, что общие (не связанные с IT) теории и практики управления проектами развиваются существенно дольше, чем индустрия программного обеспечения и от этого нельзя просто отмахнуться. Практика успешных IT-проектов доказывает, что управление определяет успех или неудачу в большей степени, чем технологические преимущества.
Как только разработка программного обеспечения перестала быть уделом одиночек, а превратилась в один из видов коллективной работы, направленной на достижение определенной цели в условиях ограничений по срокам, объемам финансирования или численности команды разработчиков, по отношению к ней все чаще стали звучать определения «программный проект», «проект создания ПО», «проект разработки». И это вполне естественно. Интуитивно все понимают, что «проект» есть некая совокупность упорядоченных действий, направленных на получение конкретного результата. Мы реализуем проект, когда работаем над программным продуктом – будь это новое, хоть и небольшое, приложение с ограниченным кругом пользователей или система класса ERP.
Создание программного обеспечения невозможно без постоянного взаимодействия разработчиков с внешней бизнес-средой, профессиональными менеджерами, специалистами в области финансов и т.п. Обсуждая с ними проект, степень его готовности, ассоциированные с ним ресурсы и другие характеристики, IT-специалисты обычно не задумываются над вопросами согласования терминологии, считая, что уж они-то наверняка, лучше знают, что такое программный проект.
Зачастую разработчики уверены, что знают об ожиданиях пользователей по отношению к разрабатываемой программной системе гораздо больше, чем сами пользователи и именно на этой уверенности пытаются выстраивать свои взаимоотношения с заказчиками. Иногда это приводит к взаимному непониманию между представителями заказчика и исполнителя (а именно исполнителями являются IT-специалисты по отношению к бизнесу), которое может завести проект в тупик, особенно если к разнице в ожиданиях добавляется еще и разница в концепциях и понятиях.
Существует и другая проблема: все чаще руководством IT -проектов и самих IT -подразделений в организациях занимаются профессиональные управленцы, на которых “айтишники” смотрят с высоты своего технократического снобизма, а зря. Что стоит за терминами «критический путь», «риски», «бюджетирование», «планирование работ»? IT -специалисты часто не только не понимают, но и не хотят понимать этого. А ведь это вопросы, решение которых непосредственно влияет на реализацию программных проектов.
Еще один интересный факт заключается в том, что проведенные исследования ничего не могут сказать о влиянии на успешность проектов факта применения формальных методологий разработки ПО, зато они четко показывают влияние уровня компетенции менеджеров проектов на результат. Успешное завершение и, тем более, спасение тонущего проекта тем вероятнее, чем большим кругозором обладает менеджер проекта, пришел ли он в IT как «чистый управленец» или вырос из среды разработчиков.
Чем сложнее бизнес-задача, чем важнее программный проект, направленный на ее решение, тем чаще мы оперируем общими управленческими понятиями и применяем знания и навыки, характерные для общего менеджмента и, конечно же, проектного менеджмента, т.е. «управления проектами».
Поэтому прежде чем приступить к изучению специфики программных проектов, мы начали рассматривать общие понятия проектного менеджмента, которые позволят выстроить некоторую общую систему координат и дадут возможность всем участникам дискуссии говорить на одном языке.
Мы рассмотрели подходы к определению термина проект, рассмотрели его признаки, общую модель проекта, понятие управление проектом, системную модель проектного управление, основные блоки системы управление проектом, классификацию. Продолжим.