Когда вам нужно запустить сайт, вы используете готовый движок (CMS-систему). При запуске своего бизнеса тоже можно ускориться, для этого есть франшизы и план управления требованиями.
Когда речь заходит о крупных и нестандартных проектах, программисты используют фреймворки, это своего рода конструкторы с уже готовыми функциями, которые остаётся адаптировать под задачи, поставленные клиентом.
Как ни странно, в крупном бизнесе тоже так можно, для этого есть комплексные своды знаний по запуску проектов, которые остаётся адаптировать под свои требования, например, как PMBoK.
Какая связь между программистами и бизнесом? Удивительно, но и те, и другие могут использовать один и тот же фреймворк для описания масштабного проекта – это упомянутый выше PMBoK.
Что такое PMBoK?
PMBoK (от англ. Project Management Body of Knowledge, рус. «Свод знаний по управлению проектами») – это международный всеобъемлющий документ, описывающий все возможные нюансы запуска проекта любой сложности.
Выпускается и поддерживается руководство PMBoK некоммерческим институтом PMI (Project Management Institute). Официальное печатное и электронное издание доступно сразу на нескольких языках, включая русский.
Текущая актуальная версия – седьмая.
Несмотря на то, что свод знаний часто напрямую ассоциируют со стандартом управления проектами, разработанным ANSI, это не совсем верно. Отраслевой стандарт ANSI согласуется с PMBoK только в части управления проектами. В самом своде гораздо больше информации – более 600 страниц на английском и чуть менее 600 в русском варианте перевода.
Главное, что нужно понять, PMBoK – это не стандарт, это лишь свод правил. Всеобъемлющий, подробный, очень детальный и понятный, но просто документ, которым можно руководствоваться, а можно и не руководствоваться.
Тем не менее многие крупные компании, в том числе российские, используют PMBoK для планирования системы управления. Это быстро, это просто, в конце концов – выгодно.
Многие готовые бизнес-решения, разработанные на основе PMBoK, рассчитаны на применение в Agile-командах.
Сам по себе свод PMBoK – это не методология.
Что такое план управления требованиями
План управления требованиями (англ. Requirements Management Plan или сокращённо RMP) – это часть руководства PMBoK, относится к группе процессов планирования.
План управления требованиями идёт вторым разделом плана управления проектом.
Здесь отражаются общие подходы:
- кто и как создаёт требования к проекту;
- каким образом утверждаются и согласовываются требования;
- как они сопоставляются с жизненным циклом проекта;
- как корректируются по мере роста и становления проекта;
- как анализируются и документируются.
Зачем нужно так много всего предусматривать?
Стадия планирования вообще самая ответственная для любого проекта. Если на этом этапе будут допущены критические ошибки, это может иметь фатальные последствия.
Примерно таким набором участников может формироваться проект (все, кто на него влияет).
Из-за разного виденья и понимания ситуации каждым из участников могут формироваться разные требования. Это может вылиться в ситуацию, показанную на картинке ниже.
Чтобы такого не происходило, логично назначить ответственных сотрудников, распределить их роли при планировании, собрать все возможные требования, проанализировать, категоризировать, распределить по важности (приоритетам), протестировать возможность реализации, разработать спецификации, документы и прочее.
Какие виды требований могут быть в плане
В первую очередь, это функциональные требования, например, бизнес-функции или требования конечных пользователей, если речь о конкретном продукте для потребителей.
Во вторую очередь, это могут быть нефункциональные требования: например, пожелания к качеству, эргономике, эффективности, а также ограничения по применению (соответствие отраслевым стандартам и правилам, имеющийся бюджет, выделенные на реализацию сроки и не только.).
Бизнес-требования формулируются заказчиками, но важно понимать, что за реализацией обычно стоят более технически подкованные в своей сфере специалисты. Поэтому отношения между заказчиком и исполнителем логично формализировать, а личные встречи или опрос/анкетирование проводить в присутствии обеих сторон для своевременного обнаружения недопонимания.
Что касается баланса таких требований, на ум приходит интересная аналогия. Результат может быть быстрым, качественным, недорогим, но выбрать можно не более двух вариантов.
Как собираются требования
Для сбора требований от заинтересованных лиц чаще всего применяются брифы, опросы, система анкетирования. Но в отдельных типах проектов могут использоваться более сложные методики: мозговой штурм, семинары, фокус-группы, система прототипирования, ассоциативные карты и др.
При сборе информации важно правильно определить круг участников и выставить их важность (приоритеты). Система ранжирования может быть и у самих требований.
Перед окончательным утверждением требования логично оптимизировать: найти и убрать повторяющиеся, убрать те, которые невозможно выполнить и прочее.
На выходе процедуры сбора должны появиться:
- документация по требованиям;
- матрица отслеживания требований.
К требованиям нельзя относить:
- конкретные детали архитектуры;
- вообще детали реализации;
- проектную информацию (относительно процесса и команды разработки);
- сведения о тестировании и планировании.
Важное замечание: заказчик – это не всегда пользователь продукта. Это нужно учитывать и понимать.
Если вы жаждете подробностей, всегда можно обратиться к оригиналу – то есть к PMBoK. Первоисточник распространяется платно, найти его можно в магазинах книг или на официальном сайте проекта PMI.
Как план управления требованиями в проекте сочетается с Projecto?
Легко. Мы разработали универсальную систему управления проектами. Projecto совместима практически со всеми методологиями.
Чтобы убедиться в этом лично, достаточно ознакомиться с демоверсией сервиса.
Это совершенно бесплатно!