ИТ-архитектура. Практическое руководство от А до Я. Первое издание - читать онлайн

Общие Положения

Управление проектом рассматривается как метод и набор процедур, основанных на принятых принципах управления, которые используются для планирования, оценки и контроля рабочих заданий, с целью получить желаемый конечный результат в установленные сроки, в рамках выделенных средств и в соответствии с требованиями к проекту. Данный раздел содержит основные принципы управления проектами, которые должны быть приняты во внимание при построении ИТ Архитектуры Предприятия. Любые проекты, в которые вовлечены ИТ (влияют на ИТ или зависят от ИТ), рассматриваются как ИТ проекты. В процессе планирования, разработки и внедрения различных сервисов ИТ архитектуры необходимо руководствоваться принципами «проектного» подхода.

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

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

Признаки проекта:

•Есть конкретная дата начала. Ключевой признак проекта «временная составляющая», т. е. есть начало и конец проекта.

•Есть конкретная дата конца. Дата установить предполагаемый срок окончания проекта, но зафиксировать условие окончания проекта по получению конечного результата или достижения целей проекта.

•Результат проекта уникален. Это второе отличие проекта от процесса или регулярной деятельности. «Уникальный» не означает абсолютно новый для всех, он может быть уникальным для организатора или команды.

•Ресурсы и бюджет – ограничены.

•Специфический порядок выполнения заданий. Он может предполагать временное изменения в иерархии подчинения и управления от установленного в организации.

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

Задача или набор рабочих заданий – представляет из себя набор действий, которые могут быть выполнены одним или несколькими лицами с помощью простого списка, задающего последовательность действий.

Ключевые аспекты Управления Проектами

Тройственная ограниченность или Треугольник проекта – описывает баланс между содержанием (объем работ или scope), стоимостью (cost) и временем (time, schedule) проекта, что влияет на конечный результат – качество (quality). Качество – это четвертый элемент проектного треугольника, который находится в центре, и любое изменение сторон влияет на него.

Как говорится в популярном слогане «Сделаем хорошо, быстро, дешево. Нужное подчеркните».

Вывод данного постулата сводится к одному: невозможно изменить один из факторов (деньги, перечень работ, время или качество) не повлияв по крайней мере на один из других факторов. Как пример:

Чтобы приблизить дату окончания (время) проекта, вы можете потратить больше ресурсов (деньги) или убрать некоторые задачи (область охвата) из проекта.

Чтобы сделать проект в рамках бюджета (деньги), вы можете либо сократить некоторые задачи (область охвата), что повлияет на возможности продукта (качество).

Чтобы добавить в продукт новые возможности (качество), вы можете продлить срок проекта, чтобы выделить время на новые задачи (время), тем самым добавив новые задачи (область охвата) и привлечь новых людей, чтобы работать быстрее (затраты).

Идея всех методик и подходов сводится к фокусированию внимания на одном или нескольких факторах с контролем воздействия на оставшиеся.

Треугольник проекта

Критерии успешности проекта – чтобы проект считался успешным фактические показатели, должны совпадать с запланированными в плане завершения проекта в срок, в рамках установленного бюджета и в соответствии с требованиями, предъявляемыми к конечному результату. Эти требования могут и должны быть сформулированы и включать в себя измеряемые критерии – показатели успеха проекта.

Цель руководителя проекта – достижения критериев успешности проекта.

Основная задача руководителя проекта – соблюдение баланса треугольника проекта.

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

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

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

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

Классификация по приоритету, позволяет определить порядок выполнения проектов:

•Низкий,

•Средний

•Высокий.

Проекты могут быть классифицированы по назначению в контексте взаимодействия с ИТ:

Административные проекты – связанны с изменениями в организации как правило не влияющие на состояние ИТ инфраструктуры, или без привлечения ИТ ресурсов.

Внутренние проекты – происходящие, как правило, внутри одного подразделения организации и характеризуются незначительными изменениями в ИТ инфраструктуре или с незначительным привлечением ИТ ресурсов

ИТ проекты – проекты, происходящие внутри организации, в значительной степени влияют на состояние ИТ инфраструктуры, имеющие цель изменить ИТ инфраструктуру организации, или с привлечением значительных ИТ ресурсов организации.

Самая первая фаза (этап) проекта, вне зависимости от выбранного метода управления проектом, является начальная стадия или инициализация проекта. На этом этапе принимается решение по старту проекта. В контексте данной книги, инициаторами проекта могут выступать одна из двух сторон организации:

•Бизнес подразделения

•ИТ департамент.

Вводной информацией на данном этапе может служить стратегия организации или бизнес план.

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

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

•Задает направление работ по реализации проекта.

•Определяет конечные результаты в терминах конечных продуктов или услуг.

•Служить в качестве источника информации для разрешения спорных вопросов, касающихся проекта.

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

Определение заинтересованных сторон (Stakeholders) – позволяет определить, кто является непосредственным заказчиком, имеет права принятия окончательного решения и т п. Кроме этого выявляются общие вопросы по организации проекта, такие как организация, состав рабочей группы по направлениям (на уровне руководителей), порядок взаимодействия, принятия решений, механизмы коммуникации и т п.

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

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

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

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

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

Подходы и методы управления проектами

Классическая Методология Управления Проектами «ВОДОПАД» (WATERFLOW)

«ВОДОПАД» (WATERFLOW) – Традиционная, классическая методология управления проектом. Она также носит название «каскадной» или «поточной» модели, вследствие того, что предлагаемая ею последовательность фаз напоминает водопад. Наиболее очевидный способ сделать свой проект более управляемым – это разбить его процессы реализации на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. Данный подход не предполагает возврата к предыдущим этапам по их завершению и принятию, или внесение изменений в требования проекта. Данная методология управления проектами предполагает разбиение проекта на ряд последовательных задач, с четким определением целей и сроков. Члены проекта выполняют задания в установленном порядке, завершая каждое задание перед тем, как преступать к последующему. В «водопадной» модели, в применении к ИТ проектам разработки программного обеспечения, стадии идут в следующем порядке:

•Определение требований

•Проектирование

•Конструирование («реализация» или «кодирование»)

•Интеграция

•Тестирование и отладка («верификация»)

•Инсталляция

•Поддержка

При этом разработчик не может перейти к следующей стадии, не закончив предыдущую. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к программному обеспечению. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка – внесение новой функциональности и устранение ошибок.

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

Слабые стороны классического проектного менеджмента – не толерантность к изменениям. Если в вашем проекте ресурсы и время не являются ключевыми ограничениями, а содержание проекта подвержено изменениям – возможно вам стоит присмотреться к другим системам управления проектами. Кроме этого, в реальных ИТ проектах довольно сложно на начальном этапе сформулировать детальные требования к конечному проекту.

Гибкая Методология Управления Проектами (Agile Project Management Methodology)

AGILE – семейство процессов и методов разработки гибких методов управления и ведения проектов. Сам по себе Agile – скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют – фреймворк (frameworks). Примеры: Scrum, Kanban, Crystal, LeSS, SAFe, Nexus и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам. Гибкие методы предполагают изменения требований к продукту в течении всего времени проекта. Такое проектирование подразумевает совершенно иной подход к управлению проектами. Изначально методология разрабатывалась для проектов, которым требуются высокая гибкость и быстрая реализация. Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз – короткие циклы, называемые «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации. В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

•Владелец продукта – определяет проектные цели, разрабатывает оптимальный график при заданных проектных параметрах, адаптирует процесс выполнения проекта к изменившимся требованиям и устанавливает приоритеты в характеристиках продукта

•Scrum мастер – устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому

•Члены команды – выполняют большинство поставленных задач, осуществляют ежедневный менеджмент, создают отчеты о ходе выполнения проекта, контролируют качество продукта.

Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

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

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

Сильные стороны Agile – их гибкость и адаптивность. Он может подстроиться под практически любые условия и процессы организации. Именно это обуславливает его нынешнюю популярность и то, сколько систем для различных областей было создано на его основе. Один из принципов Agile: «Реакция на изменения важнее следования плану». Вотчина Agile – разработка новых, инновационных продуктов с «открытым концом». В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно – нет информации для планирования. Второй сильной стороной подхода является возможность «совершать ошибки» и быстро их исправлять без существенного влияния на статус проекта в целом.

Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу. Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. Кроме этого – плавающая оценка сроков и бюджетов, неопределенность планирования целей и задач, недостаточное документирование и как следствие увеличение вероятности расхождения поставленных задач и фактической реализации, сложность ретроспективного анализа проекта.

Метод SCRUM семейства Гибких Методов Управления Проектами

SCRUM — («схватка») классический метод, с описанием процессов планирования, контроля и анализа на всех этапах ведения проекта, базирующийся на идеях Agile. Методология реализации agile-разработки предполагает использование интерактивного подхода. «Скрам-сессии», или «30-дневные спринты», используются для определения приоритетных задач. Роль менеджера проекта для упрощения передается скрам-мастеру. Для независимого решения конкретных задач формируются небольшие команды. В ходе встреч со скрам-мастером оцениваются достигнутые результаты, после чего определяется приоритетность невыполненных задач. Основная особенность методики:

•Совещания и анализ по определённым отрезкам времени «спринтов» (sprints).

•Небольшая команда

•Ограничение по определенным промежуткам времени (sprint) для выполнения WIPs.

•Определённых «кусок» продукта (Work in Process WIPs)

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов («W» – product backlog). Затем владельцем продукта – представителем заказчика в команде определяются приоритеты этих частей. Самые важные «кусочки» первыми отбираются для выполнения в спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце спринта заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему спринту. Длительность у спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям заказчика, которые имеют свойство изменяться со временем, перед началом каждого спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, лидер команды проекта (Scrum Master) и владелец продукта. И ответственность за этот процесс лежит на всех. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача – следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены. Основная структура процессов Scrum вращается вокруг 5 основных встреч:

•упорядочивания заделов (backlog),

•планирования Спринта,

•ежедневных летучек

•подведения итогов Спринта

•ретроспективы Спринта.

Встреча по упорядочиванию заделов (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него зависит, какую ценность получит Заказчик по итогам спринта.

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

Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.

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

Сильные стороны – был разработан для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям. Кроме того, этот фреймворк подходит для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в которой реализуется проект – постоянные коммуникации между членами командами позволяют недостаток опыта или квалификации одних сотрудников за счёт информации и помощи от коллег. На мой взгляд основное преимущество Scrum в том, что он позволяет «быстро ошибаться». Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.

Слабые стороны – очень требователен к команде проекта. Она должна быть небольшой (5—9 человек) и кросс-функциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например, разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга. Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь само-организовываться.

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

Метод KANBAN семейства Гибких Методов Управления Проектами

KANBAN — также представляет из себя гибкий, итеративно-инкрементальный подход к управлению проектами базирующийся на идеях Agile. Является противоположностью «SCRUM» метода. Основные особенности методики:

•Каждый участник проекта самостоятельно берет на себя ограниченное количество задач, а не по указанию менеджера

•Работа вносится в карточку (Sticker)

•Количество «незавершённой» работы (WIPs) ограничено для каждой стадии

•Новая работа берется только тогда, когда существующая выполнена или «вытянута» (LEAN).

•Больше внимания к управлению изменениями, визуализация узким мест, незавершенной работы и т п

•Ограничения по количеству WIPs и их статусы

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент. Руководство принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи – всё это нормально для работы по Kanban.

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

Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть, как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей. Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile.

Но у Kanban есть четыре столпа, на которых держится вся система:

•Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.

•Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.

•Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.

•Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны – Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких временных рамок, что хорошо подходит для замотивированных и опытных команд. При правильной настройке и управлении, Kanban может принести большую пользу команде проекта. Точный расчёт нагрузки на команду, правильная расстановка ограничений и концентрация на постоянном улучшении – всё это позволяет Kanban серьёзно экономить ресурсы и укладывать в сроки и рамки бюджета. И всё это в сочетании с гибкостью.

Слабые стороны – Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких сроков. Для жёстких сроков проекта лучше подходит классический подход или Scrum.

Гибридная Методология Управления Проектами

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

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

Методология Быстрой Разработки Приложений (Rapid Application Development RAD)

Быстрая разработка приложений (RAD) – это специфическая проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения.

Диаграмма: Сравнение WATERFLOW и RAD подходов

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

•Планирование

•Пользовательское проектирование

•Быстрое конструирование

•Переключение

Основные преимущества применения различных подходов RAD:

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

Инкрементальный подход предполагает разработку услуги «от куска к куску», то есть последовательно. При этом каждый «кусок» может поддерживать одну из бизнес-функций, для которых предназначена услуга в целом. Для бизнеса инкрементальный подход дает возможность использования какой-то значимой части услуги до того, как она будет разработана полностью. Дополнительные преимущества: продукт быстрее поступает на рынок, более широкие возможности для разработки устраивающего пользователей интерфейса, большая адаптивность к изменяющимся требованиям бизнеса и простота развития и изменения функциональности решения. Методология быстрой разработки приложений, с одной стороны, помогает улучшить показатели результативности проекта и повысить качество риск-менеджмента. Но с другой стороны, данная метрология не подходит для масштабных IT проектов, может привести к низкому качеству кода и требует постоянного вовлечение клиента в процесс исполнения всего проекта. RAD является более современным и гибким подходом к проектированию.

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

Методология Экстремального Программирование (Extreme Programming XP)

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

Методология моделирования событий Event Chain Methodology (ECM)

Эта методология управления проектами помогает выявить и спрогнозировать потенциальные риски. Анализ проекта при помощи метода Монте Карло и Диаграммы цепочки событий помогает определить вероятность некоторых рисков и их возможное влияние на проект в целом. Визуализация связей между внешними событиями и работами проекта помогает создать план, максимально приближенный к реальности.

Метод Адаптивные Рамки Проектов APF (Adaptive Project Framework)

Использование адаптивных/регулируемых рамок проектов APF (Adaptive Project Framework) позволяет улучшать проект на каждом этапе, основываясь на полученном опыте от предыдущих результатов. Определив цели проекта и постоянно контролируя работы проекта, менеджер может обеспечить успех максимально возможной стоимости бизнеса и создать бизнес-ценность для потенциального потребителя.

Метод «Реализация Выгоды» (Benefit Realization BF)

Цель метода «Реализация Выгоды» (Benefit Realization BF) – выгода от реализации проекта Успех определяется как достижение желаемой/ожидаемой выгоды. Если клиенты хотят увеличить продажи CRM (система управления взаимоотношениями с клиентами – customer relationship management software), проект не будет выполнен/реализован до того момента, пока продажи не повысятся на 15% – даже если Вы установили и наладили работу CRM вовремя и с соблюдением/в соответствии с бюджетом.

Методология PRISM (проекты со встроенными устойчивыми/жизнеспособными методами)

Сочетание проектного планирования с экологической устойчивостью мер. Хотите пойти в «зеленом» направлении? В таком случае, PRISM точно для Вас! Сокращение расходования энергии и издержек обращения (распределение затрат), все это при одновременном снижении Вашего воздействия на окружающую среду.

ПРОЧИЕ МЕТОДЫ И СПЕЦИФИЧЕСКИЕ ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ

Помимо перечисленных, существуют и другие методологии управления проектами:

•функционально-ориентированная разработка (feature driven development, FDD),

•разработка динамических систем (dynamic systems development, DSDM),

•адаптивная разработка программного обеспечения, Rational Unified Process (RUP),

•Концепции Шесть сигм (six sigma) и Бережливого Производства (LEAN). Управление проектом на основе принципов «контроля качества». Будут детально рассмотрены в следующей главе.

Методология Управления Проектами в Контролируемой Среде (PRINCE2)

Управление проектами на основе методологии «PROJECT MANAGEMENT INSTITUTE PMI»