Процесс работы с требованиями и роль проджекта
Всем привет! В прошлый раз поговорили, что такое требования и какими они бывают, разобрали на примере конференции и разработки мобильного приложения. Я говорила, что когда будем разбирать процесс работы с требованиями, то я тоже буду приводить примеры в разных сферах и в разных подходах, чтобы показать, где зона ответственности у менеджера проектов.
Давайте начнем с определения места и времени для процесса работы с требованиями. В жизненном цикле проекта требования формируются на этапах инициации и планирования, а управляются на остальных этапах, независимо от того, как у нас тип проекта и какой метод управлений (гибкий или линейный). Требования определяют цель проекта и то, как проект может достичь этой цели, то есть его результат (результатом может быть продукт, работа, событие и так далее).
Внутри большого процесса управления проектом у нас есть определенные этапы (они завязаны преимущественно на ЖЗП), и внутри есть группы активностей, которые представляют собой наборы связанных задач. Вот мы сейчас и посмотрим на эти задачи с точки зрения менеджера проекта (или его приближенного варианта в зависимости от метода управления) на примере все той же разработки мобильного приложения для онлайн-покупок и организации научной конференции.
Процесс работы с требованиями
Сам по себе процесс работы с требованиями подразумевает следующие активности между заказчиком (тем, кто инициировал проект ради достижения какой-то цели и получения какой-то выгоды) и командой исполнителя (теми, кто непосредственно будет эту цель успешно или неуспешно достигать):
- Выявление требований — обратите внимание, я не говорю «сбор требований», потому что выявить потребности заказчика, отделяя «хочу» от «надо», — это больше, чем просто собрать информацию о том, что хочет получить заказчик. Нередко выявление начинается со сбора (например, с заполнения анкеты или брифа), а продолжается уже детальным обсуждением проблем, болей, предпосылок этих пожеланий. В результате иногда меняется цель проекта, описание желаемого конечного результата, или же проект вовсе отменяют на стадии инициации (потому что выяснили, что проект не нужен на самом деле). Выявление требований — это получение информации о потребностях и ожиданиях заинтересованных сторон (заказчика, его клиентов, пользователей, спонсоров) в отношении конечного результата проекта.
- Формулирование требований (выражение требований) — на этом этапе выявленные требования формулируются и выражаются с помощью конкретных инструментов (текстовых или визуальных), чтобы по ним можно было бы приступить к планированию работ по реализации этих требований. Требования могут быть выражены в виде пользовательских сценариев, прототипов, пользовательских историй, диаграмм и схем (потоки данных, архитектура приложения), чертежей и дизайн-макетов. Здесь уже оформление требований напрямую зависит от типа, цели и контекста проекта.
- Приоритизация требований — определение важности и срочности различных требований. Это помогает сфокусироваться на наиболее критичных аспектах проекта и эффективно распределить ресурсы для достижения цели. В зависимости от типа управления (гибкого или линейного, итеративного или спирального), приоритизация помогает также определить порядок выполнения работ (то есть является основой для планирования) и сформировать ожидания от реализации (весь результат целиком, MVP и доработки по приоритетам, план на несколько инкрементов вперед).
- Анализ требований — процесс оценки требований на предмет их полноты, целостности и осуществимости. Это позволяет выявить возможные риски и проблемы на ранних этапах проекта. Тип управления очень влияет, поскольку если, например, в каскадной модели я не могу двинуться к следующему этапу проекта без того чтобы весь объем требований проанализировать и поправить, а в скрам я могу, например, анализировать требования на предмет полноты и достаточности на 1-2-3 спринта вперед, весь массив мне не нужен.
- Управление требованиями — это процесс отслеживания и контроля изменений требований на протяжении всего жизненного цикла проекта. Это обеспечивает согласованность и актуальность требований на всех этапах проекта. Здесь тоже влияние оказывает выбранная модель управления, так, в водопаде я смотрю только на результат каждого этапа и сверяю на соответствие требованиям, отдельно фиксирую запросы на изменения и отклонения, тогда как в гибком подходе могу вносить изменения в приоритеты, описание, и регулярно провожу анализ требований.
Роль и зона ответственности менеджера проектов при работе с требованиями в разных управленческих подходах
Теперь давайте посмотрим на тех же примерах, что были в первой части статей про требования, только добавим фреймворк управления проектом для контекста и определения роли менеджера:
- Разработка мобильного приложения для интернет-магазина на Android по Scrum
- Организация научной конференции с очным участием и онлайн-регистрацией по Waterfall
Роль менеджера проектов в разработке мобильного приложения для интернет-магазина на Android по Scrum
И первое, с чего мы начнем, это с того что в Scrum нет менеджера проектов, есть владелец продукта и скрам-мастер, к РМ ближе всего роль именно скрам-мастера, как фасилитатора рабочих церемоний и процессов. РМ в качестве скрам-мастера присматриваем за состоянием артефактов (бэклог, инкремент), но не управляет ими. Владелец продукта в основном отвечает за полноту собранных и формализованных требований, их представленность и приоритеты в бэклоге и т.д., а также за качество артефактов.
Поэтому в данном проекте к обязанностям РМ будет ближе всего:
- При выявлении требований — организация и фасилитация встреч с ключевыми заинтересованными сторонами (владельцы бизнеса, пользователи, команда разработки). Само проведение опросов, интервью, касдевов, исследований — на владельце продукта.
- На этапах формулировании, приоритизации, анализа и управлении требований — фасилитация встреч во время планирования и оценки задач, ревью спринта и ретроспективы спринта по всем вопросам, которые касаются полноты оформления бэклога, понятности (чтобы все написанне задачи были понятны команде и отвечали целям спринта, целям проекта).
Непосредственно создание пользовательских историй (user stories) и задач (tasks), документирование требований в беклоге с четкими и понятными описаниями на этапе формулирования — на владельце продукта.
Расстановка приоритетов, в том числе выбор метода расстановки приоритетов и обновление приоритетов при измененных условиях — на владельце продукта (РМ может повлиять, высказав аргументированное мнение, но решает РО).
Обсуждение с командой вопросов полноты, целостности и осуществимости требований, выраженных в задачах, — на владельце продукта. РМ может при наличии экспертизы дать свое оценочное суждение, но не он исполнитель задачи. Расстановка definition of done в задачах — тоже на владельце, он согласовывает их с командой.
Ведение и поддержание актуальности беклога продукта на протяжении всего жизненного цикла проекта — на владельце продукта. РМ может отслеживать и документировать изменения требований и их влияния на проект, если для этого есть процедуры в команде или практика добавлена в организацию процессов.
Но! Если бы данный проект реализовывался по другому управленческому подходу, то обязанности РМ делил бы с командой аналитики и / или представителями технической команды. Есть РМ с навыками бизнес-анализа, и они могут самостоятельно выявить требования и сформулировать их, но задачи по управлению передадут аналитику, например, или же до конца проекта самостоятельно ведут документацию.
Роль менеджера проектов при организация научной конференции с очным участием и онлайн-регистрацией по Waterfall
Давайте я выскажу тут непопулярную мысль: в водопаде роль менеджера проектов объемнее и ответственнее, потому что включает в себя реальное управление всем проектным треугольником: и бюджетом, и сроками, и скоупом, и качеством (помним, оно внутри треугольника и если тот ломается, то качество испаряется).
Поэтому основу для работы с требованиями в таком проекте давал бы РМ, и потом точечно выдавал бы задачи (например, разобрался, как и что он хочет, сделал схематичное отображение лендинга с посылами и поставил задачу маркетологу собрать ТЗ на лендинг, не забыв и метрики, и анкеты, и прочее).
В чем роль менеджера проектов, когда происходит:
- выявление требований — проведение начальных встреч с основными заинтересованными сторонами (организаторы, спонсоры, участники), сбор требований через опросы и интервью с потенциальными участниками и докладчиками (например, что по времени докладов, что может понадобиться в процессе), анализ аналогичных мероприятий для определения лучших практик и требований.
- формулирование требований — cоздание детального плана мероприятия с четким описанием всех требований и целей конференции, документирование всех собранных требований в форме технического задания, согласование ТЗ со всеми заинтересованными сторонами и получение их утверждения.
- приоритизация требований — определение ключевых требований, влияющих на успех мероприятия, и установление их приоритетов, обеспечение фокусировки на наиболее критичных задачах для своевременного выполнения проекта.
- анализ требований — проведение детального анализа всех требований на предмет их осуществимости и соответствия целям конференции (вдруг на площадке нет и не было такого экрана, какой хотели спонсоры, и надо заказывать отдельно, а техническое обеспечение — часть требований). Еще РМ может проверить требования через показ спонсорам прототипов систем регистрации и оплаты, это тоже способ проанализировать полноту и осуществимость.
- управление требованиями — мониторинг выполнения требований (отчеты и проверки), организация контрольных точек (milestones) для оценки прогресса и соответствия требованиям (вехи и визуализацию дают, и точки контроля понятные для команды), процесс управления изменениями тоже на РМ (и как требования менялись, и как реализация менялась).
Как видите, функционал менеджера проектов при работе с требованиями зависит от типа проекта и выбранного подхода к управлению. В обоих случаях, что я привела в качестве примера, менеджер проектов играет ключевую роль в обеспечении успешной реализации требований и достижения целей проекта, но как я всегда говорю, не забывайте про контекст и цель проекта: они определяют, с какими требованиями как и кому придется работать.
На этом мой обзор требований закончен, пишите, что еще хотите прочитать, или что на ваш взгляд я описала неверно (я буду спорить, но если вы правы — вы правы). А! И залетайте на мой менеджерский огонек: