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) стоит дорого, оно сразу становится некритичным. Как оценивать сроки и бюджет проекта, рассмотрим в следующей главе.
