Управление ИТ-проектами: полное пособие для менеджеров и предпринимателей

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

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

Управление ИТ-проектами

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

Что собой представляет управление ИТ проектами

Типы человеческой деятельности

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

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

Проектная работа разнообразна, уникальна и изменчива. Она сложнее процессной, потому что надо сначала определиться со стратегическим направлением, а при реализации идеи приходится каждый раз решать сложные, а главное — нетипичные задачи. Ее невозможно построить так, чтобы все элементы выполнялись согласно разработанной инструкции, поэтому и ценится она выше процессной. Чтобы в этом убедиться, достаточно сравнить зарплату швеи на трикотажной фабрике с доходами популярного модельера.

Виды ИТ проектов

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

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

Риски, угрожающие ИТ-проектам

Военные говорят, что «любой план битвы хорошо работает до первого выстрела». В проектной деятельности наблюдается примерно то же самое. Можно составить наилучший план работы, однако она никогда не идет назначенным путем. Руководство проектом, особенно длительным — это постоянное балансирование между большим количеством ограничений. Это сфера, в которой лимитируется буквально все: бюджет, исполнители, сроки и т. д. И если бы только ограничивалось, а то еще и меняется на протяжении выполнения, как например, технические требования. Вот несколько наиболее распространенных рисков, которые могут повлиять на успешное выполнение ИТ-проекта:

1. Технические. Задание от заказчика может быть довольно сложным для выполнения. Члены ИТ-команды могут оказаться недостаточно опытными и подготовленными. Существует опасность некорректного выбора инструментов или технологий для достижения цели. Не следует исключать возможность несовместимости различных систем и технических неполадок.
2. Бюджетные. Из проекта ушли спонсоры, партнеры отказались от сотрудничества или просто исчерпан бюджет. Последнее может быть из-за незапланированных перерасходов, нерационального распределения средств, неожиданных расходов, колебания курсов валют, инфляции и по другим причинам. Все это ведет к финансовой стабильности проекта, когда угроза невозможности дальнейшей работы встает в полный рост.
3. По сроку завершения работы. Обычно при реализации ИТ-проекта команда должна уложиться в довольно жесткие сроки. Нередко это бывает трудно из-за возможных различных задержек. Может иметь место зависимость от результатов по другим проектам. Также влияют внешние факторы, независимые от руководителя.
4. Изменение требований. Иногда заказчик изначально выдвигает не очень конкретные требования или в процессе разработки меняет некоторые важные пункты или параметры. Такая неопределенность заставляет пересматривать первоначальные планы, что заканчивается увеличением затрат и времени, необходимого на выполнение нового варианта.
5. Недостаточно ресурсов. Имеется в виду все. Из проекта ушли главные разработчики, а у оставшихся недостаточно квалификации. Возможно, отсутствует необходимое оборудование или программное обеспечение.
6. Ошибки. Они случаются часто, и если их не выявлять сразу, то в работе системы могут возникнуть серьезные проблемы. На их ликвидацию уйдет больше времени, которого и так не хватает.
7. Зависимость от поставщиков и внешних контрагентов. Здесь все понятно, говорят одно, но иногда не выполняют обещанное. И дело не только в том, что время не ждет. Несоответствие номенклатуры может негативно повлиять на качество выполнения проекта.

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

Project management

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

Управление ИТ-проектом дает возможность четко определить цели и задачи, разработать эффективный план действий для их достижения, обеспечить согласованные действия не только сотрудников команды, но и других заинтересованных сторон. А также своевременно реагировать на неожиданные изменения обстоятельств и риски, контролировать ход работы и максимально эффективно использовать ресурсы. При планировании устанавливается не какая-то общая цель, а вполне конкретная величина, ощутимая во времени и пространстве, с определенными физическими параметрами и функциональными характеристиками, вроде: «К вот такому-то времени мы должны создать вот такой-то продукт». И все это непременно с достаточно высоким уровнем качества. Чтобы выполнить задачу, руководитель:

1. Принимает участие в планировании — определении цели, задач и мероприятий, направленных на реализацию проекта.
2. Выбирает лучший метод управления. Подходов к решению вопросов существует немало и далеко не всегда те, что хорошо работали в прошлом, так же хорошо подходят сегодня.
3. Координирует работу на всех этапах.
4. Оптимизирует использование ресурсов. Чем масштабнее проект, тем больших он требует вложений, притом не только финансовых, но и технических и интеллектуальных. Планирование и дальнейшая оптимизация дают возможность уменьшить расходы и, как следствие, снизить стоимость и сократить сроки выполнения.
5. Составляет «План Б» чтобы минимизировать риски. Случаи, когда что-то идет «не так», случаются не так уж и редко. В случае нештатной ситуации лучше, когда есть наготове запасной вариант вместо того, чтобы долго и напряженно думать, как «тушить пожар».
6. Общается с заинтересованными сторонами, в первую очередь с представителями заказчика или им самим. Это крайне необходимо для результативной работы.
7. Измеряет производительность коллектива. Для этого руководитель должен понимать, какой объем работы может выполнить управляемая им команда. Помогает метрика Velocity, показывающая объем успешно выполненной работы в часах. Эта характеристика позволяет более точно планировать задачи.
8. Быстро и эффективно решает проблемы, возникающие в процессе работы. Для этого желательно их вовремя выявлять, то есть нужно не только держать «руку на пульсе», но и иметь достаточный уровень квалификации.
9. Контролирует сроки выполнения, бюджет и содержание работы согласно модели проектного треугольника*. В ней эти элементы тесно связаны между собой. Когда меняется один из них, то следует менять и оба других, иначе треугольник не сойдется.
10. Мотивирует команду на продуктивную работу, прилагает усилия к созданию благоприятной атмосферы, стимулирует сотрудников на достижение результата.

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

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

Кто входит в команду ИТ-проекта

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

1. Стейкхолдеры

Это организации или отдельные лица, решения которых существенно и непосредственно влияют на выполнение проекта. Когда последний является заказным, то в данную группу входят клиент и его юристы, инвесторы, директора (финансовый, коммерческий) и т. д. К примеру, финдиректор имеет право корректировать бюджет, а юрист компании-заказчика — наложить запрет на хранение данных пользователей на иностранном сервере. Также к стейкхолдерам относятся партнеры, подрядчики, поставщики, государственные регулирующие организации и т.д. Некоторые считают (и, наверное, небезосновательно), что в эту категорию входят СМИ.

1.1. Заказчик или инициатор проекта

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

2. Исполнители

Это команда специалистов, которая работает над проектом.

2.1. Project manager

Это руководитель, который работает над проектом от обсуждения требований заказчика и до завершения работы. Он единственный, кто видит проект целиком, потому что находится как бы «над всеми». Он в курсе дел обо всех процессах в команде. Он организовывает работу и оптимизирует отдельные звенья, контролирует качество и сроки выполнения. Фактически — он один из членов команды, но из-за специфики работы его тоже иногда выделяют.

3. Пользователи

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

Если же говорить в узком смысле, то есть только о команде исполнителей вместе с их руководителем, то в нее входят следующие специалисты:

• Проектный менеджер, то есть руководитель. Его функции рассмотрены выше.
• Бизнес-аналитик. Собирает и анализирует требования клиента, формирует техническое задание, помогает согласовывать цели.
• Менеджер по ресурсам. Планирует и распределяет ресурсы команды в рамках бюджета и срока выполнения, начиная с определения состава участников и соответствия их профессиональных навыков требованиям проекта. Контролирует и оптимизирует использование ресурсов.
• Системный администратор. Обеспечивает работу сетей и серверов, налаживает доступы и безопасность, поддерживает инфраструктуру проекта.
• Технический архитектор. Разрабатывает архитектуру проекта, определяет технологии для ее реализации и необходимые инструменты, обеспечивает устойчивость системы и ее масштабирование.
• Разработчики (фронтенд-, бэкэнд-, мобайл-, веб-). На них лежит главная ответственность за разработку идеи и ее реализацию. Они следят за тем, чтобы продукт соответствовал цели и задачам клиента, имел определенные возможности и удовлетворял конкретные потребности. Пишут коды, предлагают самые эффективные технологии и инструменты. В группе разработчиков может быть тимлид, который ею управляет.
• Тестировщик (QA-аналитик). Определяет перечень необходимых тестов и использует их для проверки безопасности, производительности и функциональности продукта. Пишет отчеты, собирает данные тестирования и проверяет, исправили ли разработчики ошибки.

Кроме указанных могут быть и другие специалисты: контент-менеджер, маркетолог и т.д.

Принципы управления ИТ-проектами

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

1. Четкое определение цели. Все члены команды должны хорошо понимать, что должно быть на выходе. Например, они разрабатывают новое веб-приложение, с помощью которого можно будет лучше управлять базой данных. В этом плане важно сформировать единое видение проектных действий согласно выбранного фреймворка. Это станет основой для эффекта синергии действий различных специалистов, когда результат сложения их усилий превышает простую арифметическую сумму, то есть 2 + 2 = 4,5 или даже 5. Как следствие — заметное повышение общей производительности команды.
2. Планирование действий и контроль выполнения. План должен быть детальным, с расписанной последовательностью задач, определением ответственных и сроками сдачи. Процесс реализации следует регулярно контролировать по каждой группе и по каждому этапу разработки, отслеживать прогресс и, при необходимости, корректировать работу. Например, внедрение принципиально новой системы учета прибыли может состоять из этапов разработки, тестирования и запуска программы.
3. Оптимальное распределение ресурсов. В ИТ-проектах имеет особое значение наилучшее использование времени, финансов и усилий специалистов. Например, при создании мобильного приложения может потребоваться взаимодействие не только дизайнеров, разработчиков и тестировщиков, но также менеджеров по ресурсам и по продукту (маркетолога).
4. Управление рисками. Это понятие включает в себя не только идентификацию возможных проблем, но также их анализ и меры, которые будут предупреждать их возникновение или хотя бы существенно уменьшать негативное влияние. Например, при разработке нового ПО могут возникнуть определенные технические проблемы или клиент пожелает внести изменения в первоначальные требования (последнее, правда, предусмотреть совсем не просто). Важно заранее определить возможные риски и выработать стратегию их нивелирования.
5. Командная работа. Заключается в создании постоянных коммуникативных связей между отдельными звеньями коллектива. Например, постоянный обмен информацией между разработчиками, менеджерами, тестировщиками и т.д. и регулярные совещания помогают не только синхронизировать работу всех специалистов, но также быстро и эффективно решать насущные вопросы.
6. Гибкость, адаптивность к изменениям. В ИТ-проектах нередко возникают ситуации, когда рыночная ситуация меняется так, что результат приходится приспосабливать к новым условиям. Или заказчик решает поменять дизайн сайта или функциональность приложения. Команда должна уметь быстро реагировать на подобные новации.
7. Участие заинтересованных сторон. В качестве примера можно привести случай с разработкой нового ПО. Взаимодействие с будущими пользователями дает возможность получить обратную связь и лучше учесть их потребности.

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

Стандарты управления ИТ-проектами

Управление ИТ-проектами желательно осуществлять в соответствии со стандартами. Наиболее распространенными являются:

• РМВОК (Project Management Body Of Knowledge, cборник знаний по управлению проектами). Его издает и обновляет PMI (Project Management Institute, Институт управления проектами). РМВОК является базой для получения сертификата РМР (Project Management Professional) от РМИ, что высоко ценится во всем мире.
• PRINCE2 (PRojects IN Controlled Environments, Проекты в контролируемых средах) версия 2, 1996 г. вып. Сейчас актуальная версия — PRINCE2 6th Edition (2017 год). Это государственная разработка (агентство ССТА, 1989 год), базировавшаяся на PROMPT 1975 г. выпуска, доработанная представителями бизнеса. PRINCE2 представляет собой главный стандарт project management Великобритании, он распространен в США и других странах.

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

РМВОК

РМВОК помогает систематизировать знания профессионального менеджера. Это подробная база знаний, в которой описаны инструменты для работы в project management. В 2021 году вышло 7-е издание втрое меньшего объема с измененной структурой документа. Оно не отменяет 6-ю версию. Седьмая версия книги отличается от предыдущих тем, что в ее основу легли не процессы, а принципы. Это кардинально изменило структуру и подход к проектному менеджменту в целом. Седьмая версия PMBOK Guide доступна на многих языках, а с начала 2022 года и на украинском языке. Ссылка на скачивание в пдф.

РМВОК (Project Management Body Of Knowledge)

РМВОК содержит три базовых элемента: процессы, группы процессов и области знаний, притом последние два фактически являются классификациями первого. Процессов всего сорок девять, на их основе выстраивают управление проектом. Групп процессов пять: инициации, планирования, выполнения, мониторинга и контроля, закрытия. Кроме первой, они обычно циклические (PDCA или цикл Деминга). Отраслей знаний десять. Каждая содержит описание «своих» процессов, их входы, выходы и инструменты. Связь между элементами визуализирована в виде таблицы.

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

Минусы — в большом объеме документа (почти 1000 страниц), поэтому начинающим его обычно трудно освоить и применять. И, конечно же, он не может быть заменителем реального опыта. Как уверяют знатоки, освоить управление ИТ-проектами «с нуля» с помощью РМВОК так же невозможно, как выучить иностранный язык с помощью словаря. Это не учебник, а справочник, поэтому желающим стать проджект-менеджерами лучше начинать с базовых курсов или специальных учебных пособий.

PRINCE2

PRINCE2 предлагает управлять проектом на трех уровнях. Заказчик думает, какую он получит выгоду. Исполнитель — какие его ждут вызовы. Покупатель — как этим воспользоваться. Благодаря Проектному комитету эти три точки зрения складываются в единый треугольник, которому подчинен Проектный менеджер. В данной методологии выделяют три «семерки»: 7 компонентов, 7 процессов и 7 принципов.

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

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

Этапы управления ИТ-проектами

Управление ИТ-проектом — это довольно сложная работа, независимо от того, большой он или не очень. С самого начала что-то может пойти «не так» из-за меняющихся требований заказчика и обстоятельств, не зависящих от главного менеджера. Но можно разделить весь жизненный цикл на отдельные этапы. У каждого из них должна быть своя цель и конкретные результаты — так легче направлять усилия коллектива, управлять ресурсами, контролировать работу исполнителей и обеспечивать нужное качество конечного продукта. Главные этапы реализации проекта:

1. Инициация.
2. Планирование.
3. Реализация.
4. Завершение.

На каждом из них задействованы конкретные лица, поставлены определенные задачи и существуют определенные процессы.

1. Инициация

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

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

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

2. Планирование

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

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

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

Простая диаграмма Ганта. Gantt Chart. Источник: Canva

Сложная диаграмма Ганта. Gantt Chart. Источник: Canva

Обычно базовый план не совпадает с фактическим сроком выполнения отдельных задач. Но это не значит, что не надо стараться его придерживаться. Он помогает концентрировать внимание на плановых сроках завершения и показывает, насколько сильно команда отклонилась от проектных дат. А когда возникают объективные препятствия, то план можно скорректировать. После того, как диаграмма Ганта сделана и согласована, проджект-менеджер проводит kick-off meeting (установочную встречу). На нее приглашаются стейкхолдеры и члены команды. Менеджер рассказывает им все по данному проекту, после чего официально начинается работа по его реализации.

3. Выполнение

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

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

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

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

4. Завершение

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

Методы управления ИТ-проектами

Waterfall (Водопад)

Каскадный метод Waterfall — это традиционная схема работы с линейной структурой, очень распространенная в проджект-менеджменте. Она была известна еще тогда, когда о гибких технологиях никто даже не задумывался. Впервые это название появилось в 1970 году в статье Уинстона Уолкера Ройса, который в то время занимал должность директора Lockheed Software Technology Center. Структура позаимствована у диаграммы Ганта. Для ИТ-проектов Водопад применяется не часто. Почему — станет понятно позже.

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

Этапы работы:

1. Требования к проекту и их аналитика. Заказчик передает свое видение того, каким должен быть продукт, выдвигает определенные требования. Команда их анализирует, пишет техническое задание, оценивает возможные риски, составляет план-график выполнения работ. К следующему этапу переходят только после того, как прописаны все требования, подготовлено ТЗ, создан не только план, но и инструкции относительно того, что и когда следует делать.
2. Проектирование (дизайн). Команда готовит прототип и дизайн-макеты. После этого начинают работать разработчики.
3. Разработка. Специалисты согласно требованиям, плану и макетам пишут коды проекта. Все так, как написано и согласовано, четко по ТЗ. Никаких импровизаций.
4. Тестирование. Выполняется после того, когда все сделано. Этот этап считается главным недостатком каскадной модели, потому что когда возникают существенные проблемы, то иногда на их устранение тратится слишком много времени.
5. Внедрение. Выполненный проект сдается заказчику и запускается в работу.
6. Поддержка. В течение определенного времени предоставляется техническая помощь.

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

Каскадный метод Waterfall

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

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

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

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

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

Кроме того, надо вести много документации, и чем позже обнаружена проблема, тем больше для ее исправления тратится ресурсов. По поводу командной работы — с одной стороны, сотрудники смежных групп связаны между собой по результату. Потому что когда у одной «горят» сроки, то это негативно отражается на работе тех, кто по плану движется за ними, и конечный продукт может не успеть к дедлайну. С другой стороны — каждый специалист работает на отдельном участке и занят решением определенной части общей задачи. Общение с коллегами минимальное. Правда, некоторым это нравится.

Для кого подходит Waterfall? Для задач с конкретно определенными требованиями, малым количеством изменений и высокой стоимостью последних. Для масштабных проектов с большим количеством стейкхолдеров. Там будет полезной модель управления, предусматривающая составление максимально детализированного плана и большое количество развернутой документации. Например, в строительстве, в том числе по типовым проектам, или разработке оборудования. То есть, в таких случаях, когда есть конкретная задача, и на выходе следует получить четко определенный и измеряемый результат. Также она неплохо себя зарекомендовала в проектах, предъявляющих очень строгие требования по соблюдению сроков сдачи ТЗ и выполнению бюджетов. В ИТ Waterfall применяют для небольших по масштабам и краткосрочных проектов с ограниченным финансированием.

Чем отличаются между собой методология, метод и методика

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

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

Исходя из сказанного, Waterfall, о котором рассказывалось выше в статье, не будет ошибкой назвать методологией, потому что эта система исповедует определенные принципы. Если бы для нее написали манифест, как это было сделано для Agile, то он выглядел бы примерно так:

• Работать по правилам. Никаких изменений. Постоянная документация работы.
• ТЗ обязательно. Чем подробнее, тем лучше продукт.
• Последовательность работы. Следующий этап — только после завершения предыдущего. Нельзя возвращаться к уже сделанному.
• Никаких итераций, должен быть единый «прямолинейный» процесс разработки.

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

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

Методология Agile

«Agile» переводится как «гибкий», «ловкий». Именно на этих качествах базируется данная система. Она была презентована официально в 2001 году в штате Юта (США). Именно тогда 17 известных мировых разработчиков создали альтернативу Waterfall, жесткие рамки которой были слишком неудобными для меняющихся условий Project management в сфере ИТ. Специалисты поняли, что дальше работать по старым строгим и слишком забюрократизированным технологиям нельзя. И представили новую в виде «Agile Manifesto», о котором речь пойдет чуть позже. Agile быстро стала популярной. По отзывам лидеров проектного рынка, работающих в различных отраслях, от строительства до маркетинга, более 70% из них отдают предпочтение какому-то из ее методов. В сфере ИТ возникновение Agile вообще стало переломным моментом, потому что команды получили возможность быстро адаптироваться не только к меняющимся требованиям заказчиков, но и к стремительному развитию технологий.

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

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

1. Главная задача, которая стоит перед командой — удовлетворить клиента. Для этого последний должен своевременно и в полном объеме получать качественное ПО, а также его обновления.
2. Изменения во время разработки продукта — это к лучшему. Благодаря гибким процессам клиент с большей вероятностью получит продукт с существенными конкурентными преимуществами.
3. Готовое к употреблению ПО должно поступать к заказчику чем чаще — тем лучше, ориентировочно в диапазоне 2-16 недель.
4. На протяжении всего процесса руководители и специалисты работают вместе.
5. Для успеха проекта важно обеспечить персоналу необходимые условия и весомую мотивацию. Люди должны чувствовать, что руководство поддерживает их и доверяет им.
6. Лучший способ обмена информацией внутри команды — личное общение.
7. Команда работает на результат, это основное мерило работы. Главный критерий — работающее ПО, а не человеко-часы или другие показатели.
8. В основе работы лежат гибкие процессы. Работая в таком формате, можно выдерживать нужный темп не только на короткой «дистанции», но и при разработке масштабных проектов.
9. Готовый продукт должен быть технически совершенным, с качественным дизайном.
10. Следует сводить к минимальной «лишнюю» работу. Чрезмерное усложнение проекта и процессов не приветствуется.
11. Так же вредна заорганизованность, попытки жесткого руководства на всех уровнях. Идеал Agile — самоорганизованная команда, то есть такая, где нет ярко выраженного лидера. Но каждый из участников при необходимости может в любой момент проявить лидерские способности и организовать работу в интересах команды. Только в таких условиях рождаются лучшие продукты.
12. Команда должна время от времени оценивать свою работу и корректировать поведение.

На основе вышеперечисленных принципов сформированы четыре ценности Agile:

• Люди и то, как они взаимодействуют между собой важнее, чем процессы и инструменты.
• Работающее ПО на выходе важнее, чем детальная документация.
• Сотрудничество с заказчиком важнее, чем техническое задание.
• Готовность к изменениям важнее, чем утвержденный план работы.

Методологии Agile присуща работа короткими итерациями (спринтами) по 2-3 недели. Внутри каждой обычно существует стандартный кластер задач: анализ, проектирование, собственно работа и тестирование. На выходе каждого спринта должен быть работающий продукт, пусть даже без некоторых функций. Сроки берут с запасом, аналитикой и планированием не увлекаются, потому что потом все равно это придется делать снова. После каждой итерации команда анализирует результаты и корректирует приоритеты.

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

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

Scrum

Среди отечественных ИТ-специалистов Scrum является наиболее распространенным методом управления проектами. Он довольно простой и высокопроизводительный, рассчитан на относительно небольшие коллективы из 7-9 участников. Подразумевает командную работу, в которой наряду с разработчиками принимают активное участие и заказчики.

Работа начинается с того, что владелец продукта формирует перечень требований (бэклог), представляющий собой общий список работ. Масштабная задача делится на небольшие задачи, для выполнения которых даются короткие (1-4 недели) временные фазы — спринты. Работы берут из бэклога. Спринты желательно планировать так, чтобы на выходе каждого показать какой-то измеримый результат, то есть часть конечного продукта. После выполнения спринта проводят обзор и ретроспективу. Когда есть необходимость, пересматривают задачи и формируют мини-бэклог для следующего спринта.

Scrum-доска часто выглядит как Kanban, но имеет четкую структуру спринтов

Ежедневно команда проводит небольшие скрам-митинги или стендапы или синки, во время которых каждый участник рассказывает, что сделано, что запланировано и какие возникают проблемы. Не отклоняться от поставленной цели помогают, кроме стендапов, также работа с бэклогом, пересмотр приоритетов и планирование. За всем следит scrum-мастер, который еще и помогает разработчикам взаимодействовать между собой. Особенностью Scrum является наличие квартального планирования и отчетность. Этот метод хорошо работает в условиях неопределенности, он дает возможность с самого начала пообещать бизнесу определенные результаты работы в четко определенные сроки.

Kanban

Это также достаточно распространенный метод, еще более гибкий, чем предыдущий. В его основе лежит визуализация процессов на доске с помощью карточек. Каждая задача имеет определенный статус (например: to do — сделать, doing — в работе, done — сделано). Некоторые задачи могут иметь отметку «Высокий приоритет». Команды, работающие онлайн, применяют инструменты Trello, Jira и др. Количество задач, взятых в работу, ограничено, благодаря этому избегают неэффективной многозадачности. Руководитель должен постоянно отслеживать движение карточек по столбикам доски и корректировать работу.

Пример стандартной Kanban-доски

Спринтов нет. Если Scrum — итеративный, то Kanban — непрерывный. Он лучше подходит для команд, у которых много незапланированной работы, такой как постоянные исправления, проблемы с поддержкой, срочные запросы функций и тому подобное. Вместо того, чтобы ждать окончания очередного этапа работы, команда начинает работать над новыми вопросами по мере их появления и в процессе работы меняет приоритеты. С другой стороны, в Kanban трудно составлять квартальные планы, назначать конкретные сроки выполнения, предоставлять четкие результаты и писать отчеты.

Scrumban

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

Lean

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

Кроме указанных выше, есть и другие методологии и методы: eXtreme Programming для динамических проектов, которые должны быть реализованы в сжатые сроки, Six Sigma для контроля качества, Critical Path Method, определяющий критические задачи и другие.

Советы по выбору метода управления ИТ-проектом

Как утверждают сотрудники Half Double Institute, в 2019 году более 53% ИТ-проектов можно было бы завершить в установленные сроки только за счет правильного выбора метода. Вот несколько советов, которыми желательно пользоваться при его определении:

1. Направление деятельности. Следует заметить, что во многих отраслях есть методы, которые уже давно и широко используются. Они доказали свою эффективность, поэтому этот аспект стоит не просто исследовать, а еще и постараться понять, почему выбирают именно их. Потому что в бизнес-нише среди команд-лидеров найдется как положительный опыт, так и отрицательный. Например, для ИТ-проектов 71% американских фирм (данные zippia.com, 2022 год) выбирают один из фреймворков Agile, потому что это лучше всего в ситуации меняющегося рынка. А в промышленности с ее давно сформированными стандартами лучше Waterfall с его тщательным контролем и многочисленной документацией.
2. Приоритеты проекта. Конечно, на выходе каждой разработки должен быть продукт с измеримыми характеристиками. Но желательно выяснить, что более важно: соблюдение бюджета и сдача работы в срок, или отшлифованный функционал? Точный учет задачи клиента и стандартов или эксперименты и инновации? Распределение обязанностей членов команды и четко разграниченная зона ответственности или одинаковое вовлечение в процесс работы всех причастных? Каждая методология имеет определенные ценности и приоритеты, они должны соответствовать требованиям проекта.
3. Сложность и масштабируемость. Не все методы одинаково хорошо подходят для выполнения сложных или простых задач. Кроме того, когда существует вероятность изменения ТЗ в плане его расширения, то желательно определить, применима ли выбранная методология для более крупных проектов.
4. Какие есть ограничения по дедлайну и ресурсам. Бюджет — он будет фиксированный или на выполнение каждого следующего этапа выделяются отдельные средства.
5. Коммуникация со стейкхолдерами. Следует понимать, насколько тесными будут связи с клиентом, подрядчиками, поставщиками. Как быстро они будут реагировать на предложения, отвечать на вопросы, часто ли с ними можно будет общаться.
6. Команда исполнителей. Выбирая метод, нужно учитывать опыт и предпочтения команды проектировщиков, потому что некоторые фреймворки требуют специальных навыков или даже обучения. Следует разобраться, имеет ли команда возможности для эффективного внедрения конкретного метода и соблюдения его принципов. Еще один аспект — размер команды. Одни методологии лучше работают на значительных долговременных проектах с большим количеством исполнителей, тогда как другие — в небольших коллективах.

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