Совмещение традиционного и гибкого типов управления проектом

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

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

Рис. 1

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

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

• $80 -145 миллиарда в год тратится на провалившиеся и отмененные проекты (The Standish Group International, Inc.)
• 25% - 40% трат на проект были выброшены в результате переработки (Carnegie Mellon)
• 50% продуктов были "сняты с конвейра" (Gartner)
• 40% проблем были найдены пользователями (Gartner)
• Слабо и недостаточноопределенные приложения привели к постоянным несоответствиям между бизнесом и информационными технологиями. Это послужило причиной для провала 66% проектов, при этом их общая стоимость в США составляет $30 миллиардов каждый год (Forrester Research)
• 60% - 80% ошибок в проекте могут быть адресованы плохо собранным требованиям клиента, анализу и управлению (Meta Group)
• Почти две трети всех проектов в области информационных технологий проваливаются либо встречают множество проблем. (См. рисунок ниже, отображающий результаты опроса в 2006, CHAOS.)

Рис. 2

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

Метод гибкого управления проектом (Agile)

Для проектов, которые включают в себя значительный программный компонент, традиционный метод управления проектом может быть не столь эффективным, поскольку требования могут оказаться смутными, изменчивыми. В качестве альтернативы вы можете использовать метод гибкого управления проектом (Agile Project Management - APM), не так давно получивший популярность на рынке. Данный метод достаточно итеративный и периодичный процесс, во время которого разработчики и участники проекта активно работают вместе над пониманием сферы деятельности, а также определяют нужды, которые нужно реализовать, и придать приоритеты функциональности.

Гибкие методы используются тогда, когда присутствуют следующие условия:

• значение проекта четко обозначено,
• клиент активно участвует на протяжении всего проекта,
• клиент, дизайнер и разработчики находятся рядом
• возможна пошаговая разработка, основанная на функциях
• допустима визуальная документация (карточки на стене в противоположность формальной документации). Смотрите Рис. 3

Рис.3

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

Среда применения гибкого метода управления проектом

Гибкий метод разработки проводится совместно с маленькой группой, располагаемой в том же здании. Основная команда обычно состоит из двух разработчиков, которые занимаются написанием кода попарно (полноценное управление качеством) клиента/пользователя, архитектора (-ов) в области ИТ, бизнес -аналитика - и руководителя проекта. Работы выполняются на протяжении серии сессий, где команда пишет код, затем тестирует рабочие модули системы, и затем процесс повторяется. При этом уровень документации сведен к минимуму, поскольку команда в основном полагается только на неформальное общение в пределах команды.

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

Компоненты гибкого метода

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

1. Визуальный контроль. Этот метод планирования основан на карточках, расположенных на стене, которые помогают команде в организации рабочего процесса. К примеру, одна успешная команда расположила на стене карточки различных цветов и видов, которые обозначали элементы конечного продукта. Те элементы, которые были спланированы, разработаны, протестированы и уже выпущены были одного цвета, а те, которые были спланированы, разработаны, протестированы, но еще не выпущены (при этом, уже готовы к выпуску) - были другого цвета. Команда смогла с легкостью изучить положение дел для каждого набора элементов. Визуальный контроль обеспечивает одинаковое виденье проекта каждым из участников.
2. Высокопроизводительные команды, расположенные рядом. Гибкий метод разработки подразумевает, что все участники команды расположены рядом, включая клиента/пользователя, желательно в одной рабочей комнате. Такой подход значительно улучшает качество координирования и сообщения. Тем не менее, это может создать некоторые культурные изменения для разработчиков, ведь поскольку руководители проекта ответственны за собрание высокопроизводительной команды, то члены должны уметь работать, сотрудничая.
3. Разработка, основанная на тестах. В случаях, когда клиенту сложно определить свои требования и нужды, команда разработчиков зачастую использует метод, основанный на тестах продукта. Это требует большого количества шагов между определением нужд, планированием, разработкой и тестированием. Команда почти всегда разрабатывает план тестов, параллельно определяя требования - если требование не удается протестировать, то оно недостаточно разработано. Такой подход может быть использован в традиционном методе разработки, что сделает требования полными, точными и тестируемыми.
4. Адаптируемое управление. Все члены команды постоянно адаптируются под условия. Благодаря динамической среде руководитель проекта должен представлять собой лидера, а не человека, отдающего поручения. Вместо того, чтобы выдвигать  жесткие требования группе, он должен установить командные рабочие отношения, определяя основные правила и направления сотрудничества. Участники команды будут приспосабливаться друг к другу на протяжении  всего проекта, применяя при этом полученные на предыдущем цикле знания и тем самым улучшая методы, что непременно хорошо скажется на проекте.
5. Совместная разработка.Гибкая методология разработки основана на сотрудничестве  среди всех участников команды для получения хороших результатов, объективных мнений и реализации всех полученных знаний на следующем этапе разработки. Это одно из преимуществ данного метода - постоянные объективные мнения и улучшения. Руководитель проекта завершает начальное планирование, а бизнес-аналитик определяет и дает приоритеты элементам разрабатываемого продукта вместе с клиентом и специалистами. Далее, команды проекта сотрудничают, работая над дизайном, разработкой, тестированием и переработкой версии, полученной на каждом предыдущем этапе. Такое сотрудничество с клиентом ведет к успешному проекту.
6. Разработка, основанная на элементах разрабатываемого продукта.Такая система разработки значительно снижает сложность проекта и позволяет командам сфокусироваться на каждом элементе в отдельности. К примеру, одна команда сотрудников работает над элементом #4 - и их волнует только это. Они не заботятся об элементах #1-3. Об этом волнуются бизнес-аналитик и руководитель проекта, который обеспечивает то, что следующий элемент в списке имеет наивысший приоритет, основываясь на его ценности в бизнесе и уровне риска. Зачастую компоненты с высоким риском либо ключевые части инфраструктуры разрабатываются в первую очередь, а затем уже всему остальному дается приоритет на основании значимости в бизнесе. Целью является построение компонентов, основанных на функциональности, но имеющих одностороннюю зависимость с основной системой, поэтому специализированные компоненты являются независимыми друг от друга и могут быть созданы в любом порядке, либо параллельно.
7. Руководство и сотрудничество в противоположность указам и контролированию. Принцип гибкого метода разработки  независим от времени и тесно связан с лидерством. Он предусматривает больше шагов к установлению лидерства, чем традиционный метод управления. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта. В дополнение, руководитель проекта исключает все барьеры между командами в проекте.
8. Перевод фокуса с затрат на прибыль. Элементам дается приоритет на основе значимости в бизнесе, к примеру, высокий уровень дохода и доля рынка. В обязанности бизнес-аналитика входит обеспечение того, чтобы команда по разработке проекта  не углубилась чересчур в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности. В то время как руководитель проекта заботится о затратах, бизнес-аналитик фокусируется на общей стоимости полного владения продуктом, что включает в себя не только затраты на сам продукт либо его установку, но и последующее использование системы после установки.
9. Усвоение полученных уроков. После каждого цикла команда должна усвоить все полученные навыки и знания для того, чтобы улучшить процесс следующего цикла. Обучаясь, участники адаптируются к работе других коллег и работают вместе над улучшением производительности команды.

Предлагаемые преимущества гибкого метода управления проектом

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

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

Возможно ли использование метода гибкого управления проектом?

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

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

Kathleen Hass