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

С чего начать подготовку к проектной работе? 

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

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

Второй шаг – определите критерии успеха (например, удовлетворенность клиента, сроки и бюджет).

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

Метрики помогают проектному менеджеру увидеть реальное положение дел, своевременно выявить проблемы и принимать обоснованные решения. Некоторые из важных метрик для IT-проектов:

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

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

Какую методологию по управлению проектом лучше использовать?

Грамотно разделить проект на этапы, спланировать задачи и отслеживать их исполнение помогают разные методологии управления. Например, если проект включает множество этапов, которые зависят друг от друга и предполагают строгие временные рамки, Waterfall будет эффективнее, чем Scrum, который требует гибкости, регулярных проверок и изменений по необходимости.

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

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

Проектам со строгими дедлайнами также может пригодиться Critical Path Method (Метод критического пути). Он помогает определить самые важные задачи для соблюдения сроков проекта. В зависимости от них будут выстраиваться четкий график выполнения работ.

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

• Стабильность требований: Если требования четко определены, Waterfall или CPM могут подойти. Для более гибких требований лучше использовать Agile или Scrum.
• Сроки и бюджет: CPM или Lean могут быть полезны для проектов с ограниченными ресурсами и строгими сроками.
• Тип команды: Agile, Scrum и Kanban отлично подходят для креативных и межфункциональных команд, в то время как Waterfall требует более линейной структуры работы
  

Как проектному менеджеру организовать работу с командой с помощью Scrum?

На примере гибкой методологии давайте рассмотрим, как можно управлять проектами, разбивая работу на короткие этапы (спринты). Основные компоненты Scrum:

• Роли:
  • Scrum-мастер – организатор процесса, который следит за тем, чтобы команда придерживалась методологии.
  • Product Owner – владелец продукта, ответственный за приоритет задач и связь с заказчиком.
• События:
  • Ежедневные стендапы – короткие встречи, на которых команда обсуждает, что было сделано вчера, что планируется сегодня и какие препятствия возникли.
  • Ретроспективы – встречи по завершению спринта для анализа и корректировки работы.
• Артефакты:
  • Бэклог – список задач, отсортированных по приоритету, которые необходимо выполнить.
  • Доска задач – визуализация задач на текущий спринт.

Разберем, как работает Scrum, на примере компании, разрабатывающей веб-платформу для электронной коммерции. Такой проект требует гибкости, частой адаптации к запросам клиента и тесного взаимодействия команды. 

Исходные условия

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

Организация работы по Scrum

Этап 1. Формирование Scrum-команды и назначение ролей

• Scrum-мастер: управляет процессом, помогает команде устранять препятствия, проводит встречи и следит за соблюдением принципов Scrum. В нашем примере он также будет работать с клиентом, чтобы уточнять цели и устранять недопонимание.
• Product Owner: отвечает за составление и приоритизацию задач в бэклоге, получает обратную связь от клиента, чтобы правильно определить приоритеты и вносить изменения в бэклог по мере необходимости.
• Команда разработчиков: включает frontend- и backend-разработчиков, дизайнера и специалиста по тестированию, которые работают совместно над задачами в рамках спринта.

Этап 2. Подготовка к спринту и работа с бэклогом

Проект начинается с создания бэклога, в который Product Owner вносит основные требования клиента. Сначала бэклог содержит глобальные задачи, такие как:

1.  Создание личного кабинета покупателя, 
2. Интеграция платежной системы,
3. Реализация функционала корзины,
4. Настройка аналитики для персонализации».

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

Этап 3. Планирование спринтов

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

Этап 4. Ежедневные стендапы

Во время каждого спринта команда проводит ежедневные стендапы — короткие встречи, на которых каждый участник отвечает на три вопроса:

• Что я сделал вчера?
• Что планирую сделать сегодня?
• Какие трудности у меня возникли?

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

Этап 5. Завершение спринта и демонстрация результатов

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

Этап 6. Ретроспектива

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

Шаг 7. Повторение цикла и адаптация к изменениям

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

Преимущества подхода на основе Scrum в этом проекте

1. Гибкость: Команда может быстро реагировать на новые требования клиента. Например, если клиент пожелает изменить оформление страницы каталога, Product Owner может включить эти задачи в следующий спринт, не нарушая ход текущего.
2. Высокая вовлеченность клиента: Заказчик видит результаты каждого спринта, может давать обратную связь и вносить корректировки в бэклог, чтобы конечный продукт максимально соответствовал ожиданиям.
3. Повышение прозрачности и управления временем: Ежедневные стендапы и ретроспективы позволяют команде оперативно решать возникающие проблемы и контролировать, насколько выполняются задачи спринта.
4. Обучение на каждом этапе: Регулярные ретроспективы помогают команде анализировать свою работу, совершенствовать процесс и выявлять, что можно улучшить в следующем спринте.

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

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

Заглавное изображение: Unsplash