Введение в управление проектами внедрения ERP-систем

6.3.Приоритизация требований

В главе 2 рассматривались вопросы сбора требований и fit-gap анализа по ним. На фазе анализа пересматриваются изначальные приоритеты по требованиям уже с учетом возможностей ERP-системы и разумной компоновки границ проекта по срокам и бюджету.

Для приоритизации можно воспользоваться методом MoSCoW (легко запомнить и понять). Метод получил свое название от акронима, образованного следующими классификациями приоритета (буква «o» добавлена для созвучности):

  • Must have – обязательно должно быть (жизненно необходимые требования, без чего не будет работать);
  • Should have – следовало бы иметь (обязательные требования, без чего сложно обойтись);
  • Could have – может быть (стоит сделать для удобства работы);
  • Would like – хотелось бы иметь (можно не делать, «бантики»).

Вся эта методика прекрасно иллюстрируется на примере шариковой ручки, состоящей:

  • из стержня – без него никак нельзя что-то написать (must have);
  • корпуса – писать одним стержнем крайне неудобно, нужная вещь (should have);
  • зажима на корпусе, автомата убирания стержня – полезные для удобства работы опции, но без них уже можно пользоваться инструментом для письма (could have);
  • логотипа и фонарика в торце – на функции работы шариковой ручки никак не влияют, просто опции (would like).

Рис. 6.2. Приоритизация MoSCoW на примере шариковой ручки

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

И тут исполнителю тоже нельзя занимать позицию «как скажете, так и сделаем», нужно все время проверять полученный пул задач на реализуемость и сочетаемость между собой. Например, нельзя сделать какое-то требование с приоритетом must have, если оно делается поверх функциональности, помеченной would like и в этот этап вообще не входящей.

В торге и спорах за приоритеты хорошо помогают оценки реализации (время и стоимость) этих требований. Они сразу отрезвляют поток пожеланий и расставляют все точки над «i»: когда что-то по факту не нужное (но очень желаемое – would like) стоит дорого, оно сразу становится некритичным. Как оценивать сроки и бюджет проекта, рассмотрим в следующей главе.

Показать оглавление

Комментариев: 0

Оставить комментарий