36
В больших проектах можно назначить члена группы, контролирующего
систему взаимоиспользования информации.
Контроль проекта состоит из обеспечения выполнения проекта в
соответствии с планом и принятия мер при выявлении любых отклонений от
плана.
Необходимо использовать план проекта для мониторинга и контроля
вашего проекта. В течение процесса контроля может понадобиться изменить
план проекта и другие документы, такие как требования и функциональные
спецификации.
Регулярное проведение обзорных совещаний,
позволяет контролировать прогресс проекта. «Следуйте данным
советам для обеспечения эффективности обзорных совещаний:
Проведите неформальное обсуждение с основными членами группы
перед совещанием.
Самостоятельно проведите детальный обзор проекта – тщательно
изучите все задачи, которые нужно выполнить в течение следующих 3 – 6
недель. Это поможет выявить проблемы, которые нужно обсудить во время
совещания.
Разошлите программу совещания всем его участникам.
Если на совещании нужно принимать решения, обеспечьте присутствие
на совещании человека, имеющего право принятия решений.
Каждый проект имеет проблемы, которые можно разделить на
следующие категории:
Людям: в группе не хватает навыков, требуемых для правильного
выполнения действий проекта. В этом случае необходимо:
Обучить команду проекта, если это позволяют график и бюджет
проекта. В идеале требования к такому обучению должны определяться и
включаться в план проекта при подборе членов проектной группы.
37
2) Обдумать вызов стороннего консультанта или разработчика.
Если проект отстает от графика:
Необходимо рассмотреть приоритеты задач и проверить, все ли из них
на самом деле необходимы.
Не приниматься за дополнительные задачи. Это проще сказать, чем
сделать, но бывают ситуации, когда нужно говорить «нет».
Расходы на проект превышают установленный бюджет:
Необходимо регулярно отслеживать расходы в течение всего проекта,
чтобы заранее знать о любых возможных перерасходах средств.
Масштаб проекта продолжает изменяться. Причины многих проблем
проекта таковы:
Плохое определение масштаба – масштаб и цели
проекта неопределенные. Вероятно, некоторые заинтересованные лица на
самом деле не читали требования к масштабу.
Плохое планирование – действия нечеткие, процессы плохо
документированы, риски не были точно выявлены, и к ним не подготовились,
руководителю проекта не хватает опыта, коммуникации по проекту
неэффективны, и т.д.
Опытные руководители проектов часто определяют управление
изменениями проекта как одну из самых сложных проблем, с которыми
сталкивается руководитель проекта. Сама сущность проектов делает
изменения неизбежными. Изменения часто влияют на бюджет и график
проекта (и иногда на его результат). Чтобы справиться с изменениями, можно
использовать следующую формальную процедуру контроля над изменениями:
Когда кто-либо просит об изменении, которое, возможно, повлияет на
проект, руководителю необходимо настоять на том, чтобы инициатор заявки
подал письменный запрос на изменение, используя шаблон для запроса на
изменение.
38
Менеджер рассматривает влияние изменения на расходы, график,
производительность и результат проекта. Рассматривает, что произойдет, если
не внедрить изменение.
Руководитель принимает или отклоняет изменение – в зависимости от
важности изменения, можно привлечь членов группы и/или спонсора проекта
к принятию решения. Если изменение было отклонено, сообщает об этом
подателю заявки и всем заинтересованным сторонам.
Если изменение было принято, оно документируется, и изменяется план
проекта, чтобы учесть влияние изменения на график, бюджет и результат
проекта.
Сообщается новость о принятии изменения и о его влиянии подателю
заявки и всем заинтересованным сторонам (включив изменения в следующее
совещание по обзору проекта).
Третий этап жизненного цикла любого проекта- завершение проекта.
Процесс закрытия означает конец проекта. Чтобы избежать затягивания
проекта и обеспечить его четкое завершение, менеджеру необходимо сделать
следующее:
Определить оставшуюся работу и обеспечьте ее завершение.
Начать освобождать сотрудников, если они успешно выполнили
назначенную им работу.
Завершить все административные задачи, такие как получение
окончательных утверждений и транзакции (счета).
Получить окончательное утверждение от спонсора проекта и от других
ключевых заинтересованных лиц проекта относительно закрытия проекта –
проведите официальное совещание о закрытии проекта. В конце совещания
разошлите документ о закрытии проекта, сообщающий об окончании всех
действий проекта и об официальном принятии результатов проекта.
39
Лично поблагодарите всех членов группы и их руководителей за их
работу. При необходимости можно сообщить оценку работоспособности
членов группы их руководителям.
В конце проекта пишется отчёт об оценке завершённого проекта. Он
может содержать следующие разделы:
Продуктивность проекта: сравнение того, что было достигнуто в
рамках проекта, с тем, что было в исходном плане (расходы, график и
результат). Объясняются все отклонения от исходного плана.
Оценки членов группы (должны быть конфиденциальными): содержит
оценку работоспособности членов группы в течение проекта.
Полученные уроки: содержит информацию о том, что работало и что не
работало в течение проекта.
Рекомендации для будущих проектов.
«Любая организационная система, проект не является исключением,
представляет собой сложную систему обязанностей в процессе созидательной
деятельности». [46;182] Управление проектом, само по себе, является
основной функцией проекта, как динамической системы. Однако эта основная
функция может быть представлена некоторыми ее составляющими, иначе
говоря, подфункциями. Можно выявить наиболее общие подфункции
управления проектом, относящиеся к любому проекту.
В процессе осуществления проекта и управления им во всех
подсистемах и на всех фазах жизненного цикла выполняются определенные
системные функции, такие как: Планирование – деятельность, направленная
на разработку плана. Планирование как функция управления включает
определение стратегий, политики, процедур для реализации проекта.
Планирование в проектной среде можно определить как предварительную
проработку и выбор прогнозных решений по реализации проекта в условиях
различных альтернатив, базирующихся на знании предметной области и
40
возможных неопределенностей (рисков) реализации проекта. При этом, в
контексте управления проектами планирование включает также процессы
организации осуществления планов, корректировки планов и контроля за их
выполнением. В управлении проектами планирование воплощает в себе
организующее начало всего процесса реализации проекта. Планирование
охватывает все фазы проектного цикла и является непрерывным процессом.
Она начинается с участия проект-менеджера в процессе разработки концепции
проекта, продолжается при выборе стратегических решений выполнения
проекта и разработке его деталей, включая составление конкретных
предложений, заключение контрактов, выполнение работ, и заканчивается
лишь при завершении проекта. Принятые в процессе планирования решения
должны обеспечить реализуемость проекта в заданные сроки и минимальной
стоимостью и затратами ресурсов и при высоком качестве выполнения работ.
Одна из основных целей планирования – интеграция участников проекта для
выполнения комплекса работ, обеспечивающих достижение конечных
результатов проекта. Планирование является основой контроля, учета и
оперативного управления.
Контроль жизнедеятельности проекта – функция управления проектом,
включающая процессы наблюдения за ходом реализации проекта с целью
проверки соответствия фактического выполнения запланированным
показателям, предусмотренным планами, контрактами, соглашениями и т.д.
Функция контроля проекта выполняется на всех фазах и во всех его
подсистемах и включают: контроль издержек, контроль сроков и
продолжительности работ, контроль качества, контроль рисков, контроль
бюджет проекта, контроль выполнения решений, контроль
материальнотехнических запасов по проекту и т.д.
Мотивация. Процесс побуждения в личности желания работать для
достижения целей организации при одновременной реализации его
41
собственных целей. Следует различать мотивацию, как исследование
побудительных причин действий человека, и мотивацию, как способ
воздействия на поведение человека. Ранее исследование этой проблемы
являлась уделом преимущественно специалистов, однако, в связи с бурным
развитием и усложнением социальных и экономических отношений,
радикальным усложнением коммуникаций, возникла настоятельная
необходимость создания таких технологий мотивации, которые были бы
достаточно эффективны, в то же время, применимы в повседневной практике
деловых отношений. За последние 40 лет мотивация как прикладная область
знаний развивалась особенно активно и, как следствие этого, появился целый
ряд упрощенных теоретических моделей, основанных на результатах
психологических исследований.
Оперативное управление. Процесс практического воплощения
программ и проектов в каждой из областей деятельности, изменения и оценки
результатов, а также сравнения достигнутых результатов с поставленными
целями. Оперативное управление можно рассматривать и как
самостоятельную подсистему управления, и как одну из основных функций
управления проектом. В этой связи целесообразно обозначить подсистему как
«управление изменениями», а функцию как «оперативное управление».
Таким образом, управление проектами, используя современные
научнотехнические и экономические знания, разнообразную технику
управления, специальные организационные формы и проектно-
ориентированные структуры, позволяет принимать соответствующие решения
на протяжении всего жизненного цикла проекта.
Из всего выше сказанного, можно сделать вывод, что управление
проектом это сложный процесс, имеющий ряд характерных особенностей. На
каждом этапе жизненного цикла проекта реализуются все функции управления
проектом, но они имеют свои особенности.
42
1.3 Особенности Agile-методологии
Agile, как методология, был призван решать две проблемы: первая
проблема называется time to market, это срок вывода нового продукта на
рынок, а второе - это время на принятие решений, то что мы называем time to
decision.
К 2000-м годам IT-индустрия была подвержена бюрократизации, как и
индустрия разработки программного обеспечения к компьютерам. Появился
Rational Unified Process, его часто приводят в пример как самый
забюрократизированный процесс разработки ПО, в котором более 140
артефактов, ролей и обязанностей. Однако, мировое сообщество развивается с
быстрым темпом, поэтому встал большой вопрос: «как можно в
забюрократизированной системе разработки программного обеспечения
делать инновационные программные продукты?»
В 2001 году состоялась первая встреча людей в области разработки
программного обеспечения, руководитель проектов, руководители компаний,
которые занимались разработкой. Каждый привез с собой различные подходы
к реализации продуктов и они обсудив, решили посмотреть: «а что же общего
есть в их подходах к разработке инновационных продуктов?»
Были сделаны выводы, что общими оказались ценности, которые они
вкладывали в свои системы разработки инновационных продуктов, и в
результате этой встречи родился Agile Manifesto.
Agile Manifesto состоит из четырех ценностей и 12 принципов.
Информация о нем хранится на сайте agilemanifesto.org. Там детально описан
процесс появления Agile-манифеста, сам Agile-манифест, его переводы на
разные языки и 12 принципов, на которых стоит остановиться подробнее.
4 ценности Agile Manifesto:
1. Люди и их взаимодействие важнее процессов и инструментов.
Процессы и инструменты – не являются самоцелью, и если мы
43
будемпользоваться процессами и инструментами, то процесс может
остановиться. Примером подобной ситуации является «итальянская
забастовка», которая описывает процесс примерно такой ситуацией: «я с вами
не согласен, но буду действовать по вашей инструкции и, соответственно,
действуя по вашей инструкции, я зайду в тупик и работа остановится».
2. Работающий продукт важнее исчерпывающей документации. Если
артефакт не несет ценности конкретному заказчику, конкретному клиенту,
конкретному потребителю, то он не нужен.
3. Взаимодействие с заказчиком важнее согласований условий
контракта. Модель согласования контрактов и договорных отношений
примерно такова: создается огромное количество документов, в которых
определены обязанности сторон. Если что-то происходит не так, то
соответственно, ищется по этому документу, кто был виноват и какие
последствия подобной ситуации. В Agile необходимо выстраивать
партнерские отношения с заказчиком и согласование такого огромного
количества документов часто бывает не оправдано, нежели просто
присутствие заказчика на площадке разработчика, и прямой вербальный
доступ к нему для решения определенных проблем.
4. Последняя ценность звучит как: реакция на изменение важнее чем
следование плану. Как бы команда хорошо ни планировала проект, часто чтото
идет не так, тем более, во времена изменчивого рынка. Планируя контракт на
разработку продукта на год вперед, необходимо быть уверенным в том, что
возможны форс-мажоры, и поэтому система работы, отношение к работе
должно быть изначально направлены на то, что будут изменения и команда
разработки должны на них очень быстро реагировать, а не игнорировать их.
Помимо 4-х ценностей в Agile Manifesto стали определены 12
принципов разработки.
44
Принцип № 1. Наивысшим приоритетом для нас является
удовлетворение потребностей заказчика благодаря регулярной и ранней
поставке ценного программного обеспечения. Эти принципы направлены на
разработку программного обеспечения, так как изначально весь Agile вышел
из IT. Этот принцип говорит о том, что при разработке продуктов необходимо
ориентироваться на потребителя. Если возможно показать законченный, но не
до конца, продукт, но этот продукт будет нести определенную ценность, то
есть часть каких-либо функций будет работать, в таком случае заказчик
сможет дать обратную связь. И эта обратная связь может быть ценна, потому
что возникнет лучшее понимание, что же конкретно нужно заказчику. Если это
понимание того, что конкретно нужно заказчику, значит проект сможет быть
реализован успешно и продуктивно.
Принцип № 2 звучит так: изменение требований приветствуется даже
на поздних стадиях разработки. Agile-процессы позволяют использовать
изменения для обеспечения заказчику конкурентного преимущества. С
момента первого заказа, когда заказчик запросил сделать продукт, уже что-то
могло поменяться. Могло поменяться понимание заказчика об этом продукте,
мог поменяться рынок, внешние факторы какие-то и прочее.
Перейдем к следующему принципу. Принцип № 3. Работающий
продукт следует выпускать как можно чаще с периодичностью от пары недель
до пары месяцев. Обычно, можно увидеть следующее: каждый человек делает
какую-то свою часть. Команда пытается собрать из этого одно целое, однако
так – не работает. И при этом тратиться огромное количество ресурсов,
временных, материальных, интеллектуальных, чтобы этот продукт смог
работать. Это описывается термином, который называется «синергия».
Отдельные модули, отдельные части какого-то продукта не соединяются
вместе, не дают того эффекта, когда продукт начинает нести какую-то
отдельную новую ценность.
45
Принцип 4. На протяжении всего проекта разработчики и
представители бизнеса должны ежедневно работать вместе. Это необходимо,
чтобы заказчик мог давать прямую обратную связь о том, движется ли проект
в правильную сторону или нет. Для этого предполагается, что необходимо,
чтобы на одной площадке, где сидят разработчики присутствовали и
представители бизнеса, и они работали плотно и достаточно много времени
работали вместе.
Принцип № 5 звучит так: над проектом должны работать
мотивированные профессионалы. Чтобы работа была сделана, необходимо
создать условия и обеспечить поддержку и полностью доверьтесь команде
разработки. Этот вопрос связан с многочисленными теориями мотивации.
Принцип № 6 звучит так: непосредственное общение является наиболее
практичным и эффективным способом обмена информации как с самой
командой, так и внутри команды. Существуют различные способы
коммуникации, такие как электронная почта, телефон, вербальное общение.
Если выстроить их по шкале скорости. Самая быстрая коммуникация —
вербальная. Это позволяет обмениваться информацией быстро.
Принцип № 7. Работающий продукт — основной показатель прогресса.
Об этом говориться также в ценностях Agile. Основное показатель и критерий
эффективности в Agile – это работающий продукт. Однако, на разработку
продукта может уходить определенное количество времени. И для
отслеживания прогресса существуют принципы итеративной икрементальной
разработки. Основной вывод этого принципа: мера всего – работающий
продукт.
Принцип № 8: разработчики, инвесторы и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно. Agile помогает
наладить устойчивый процесс разработки. Это сложный в переводе на русский
язык принцип. Здесь можно использовать термин, который по-английски