Механизм фиксации требований к продукту проекта нужен для получения ответа на вопрос: как должен выглядеть в деталях продукт проекта? Какие у него должны быть характеристики? Что заинтересованные стороны хотят от проекта? Механизм обязательно отрабатывается на этапе подготовки, но может быть запущен и несколько раз в ходе проекта — при появлении новых заинтересованных сторон, новых результатов или каких-то других изменений. Подробнее об этом — из книги Павла Алферова «Проектное управление: как правильно делать правильные вещи».
Базовая схема
Типовые шаги механизма следующие.
1. Провести предварительное выявление требований заинтересованных сторон. Чего они хотят от проекта? Важно спрашивать не только заказчика. Его, конечно, обязательно нужно спрашивать. Но не только его — всех, кто имеет значительное влияние на проект.
2. Определить список обязательных результатов (продуктов проекта) — что будем принимать на выходе.
3. Сформировать требования под каждый из результатов.
4. Провести анализ требований — что подходит, что не подходит, какие есть противоречия и приоритеты.
5. Согласовать требования с ключевыми заинтересованными сторонами.
6. Официально утвердить документ, фиксирующий требования.
Это базовая схема. Чем выше сложность и количество требований, чем больше участников — тем сложнее будет механизм. В крупных компаниях над фиксацией требований работают бизнес-аналитик или целая команда консультантов и аналитиков. Если таковых нет, то чаще всего работой с требованиями занимается руководитель проекта.
Естественно, не все требования имеют равный вес. Сверьтесь со своей картой заинтересованных сторон. Опрашивать имеет смысл тех, кто не только заинтересован в проекте, но и хоть как-то может на него повлиять. Мнение тех, у кого есть какой-то интерес, но нет влияния, не особо важно. Если у вас нет лишних сил и времени, к ним можно не ходить, их требования в список не попадут.
Очень важно «снять показания» со всех ключевых заинтересованных сторон. Нам важно следующее.
• А что конкретно им нужно?
• Как в их понимании выглядит продукт проекта?
• Что для них считается хорошим продуктом, а что плохим?
• Что в нем должно быть, а чего они в нем видеть точно не хотят?
Есть много способов выявить требования: очное или дистанционное интервью, заполнение опросных листов, мозговой штурм, совещание и так далее. И все эти методы подразумевают коммуникацию, взаимодействие, обмен информацией и общение.
У разных каналов коммуникаций разная эффективность. Самое неэффективное — общение через бумагу (официальные документы, служебные записки и так далее). Этот канал хорош для того, чтобы зафиксировать уже принятые решения, но не для достижения взаимопонимания.
Метод К.В.Ж.Д.
После того как мы собрали требования, важно убедиться, что требования разных заинтересованных сторон не противоречат друг другу, провести их анализ.
А если противоречат? На этом этапе у нас еще есть время устранить проблему.
В разрешении противоречий нам может сильно помочь правильная приоритизация требования. Есть простой проверенный метод приоритизации — MoSCoW: это деление всех требований на четыре типа. По-русски — «метод К.В.Ж.Д.» (не путать с Китайско-Восточной железной дорогой).
• Критичные (must) — то, что необходимо сделать в любом случае. Без выполнения этих требований продукт не решит проблему.
• Важные (should) — не самые критичные требования, но они тоже должны быть выполнены. Однако только после реализации must.
• Желательные (could) — требования, которые можно выполнить, если останется время и будут ресурсы.
• Дополнительные (would) — эти требования хотелось бы выполнить, но их можно проигнорировать или перенести на следующие этапы без особого вреда для продукта.
Важно правильно приоритизировать требования в самом начале. Можно каждому из них приписать одну из букв — К, В, Ж или Д. Тогда при реализации проекта будет проще организовывать работу и управлять изменениями.
Имейте в виду: требования обязательно будут меняться. Такова жизнь. Надо заранее подумать и понять, как вы будете проводить изменения. Если не предусмотреть варианты, согласование изменений будет таким же трудоемким, как утверждение исходного документа.
Купить книгу: МИФ / WB / Ozon / Читай-город
