Эта статья входит в цикл статей о разработке требований к программному обеспечению. Если вы сразу попали на данную статью, но не читали предыдущих, то вам необходимо в первую очередь начать с первой статьи. В каждой статье есть ссылка на следующую, поэтому в результате прочтения вы вернетесь сюда. Если же все предыдущие прочитали, то поехали.
В прошлой статье мы определили бизнес проблемы, а на их основе поставили бизнес цели. Все это вектор стремления, а теперь нужно перейти от туманной абстракции к более четкой. Нам необходимо установить, а какие будут конечные результаты после того, как каждая цель будет достигнута.
Критерии успеха
Конечные результаты - это по своей сути выбор метрики, по которой будет оцениваться достижение поставленных бизнес целей по завершению проекта. Эти метрики называются критерии успеха.
Критерии успеха оформляются в виде схемы, чтобы было видно от какой бизнес проблемы вытекает какая бизнес цель и каким в итоге должен быть результат. Я обычно различные схемы рисую в Miro, поэтому если у не знаете, где удобно нарисовать схему, то данный сервис будет для вас идеальным.
Но прежде чем приступать к созданию схемы, необходимо помнить важный момент, мы должны держать в курсе всех читателей документа о том, что за информация ему предоставляется. Поэтому даём краткое пояснение.
Если вы наблюдательны, то заметили, что даётся ссылка на рисунок и используется сквозная нумерация. Обязательно нумеруйте рисунки и давайте на них ссылки. Читатель не должен догадываться откуда вытекает контекст того или иного рисунка, схемы и т.д. Успех в понимании с заказчиком достигается путем организации четкой структуры документа и точности. Ссылки и нумерации рисунков относятся к структуре.
Как же рисовать? Все просто. Исходя из результатов предыдущей статьи, вначале была проблема, а для её решения поставили цель. Но проблема было большой, поэтому её разбили на составляющие, а каждой такой составляющей поставили свою цель. Вот такую последовательность необходимо точно отразить. Вот пример общей проблемы, из которой вытекает общая цель.
Как видите из общей бизнес-цели выходит три ветки. Как думаете, что там будет находиться? Верно, частные бизнес-проблемы.
Как мы и говорили, из каждой частной бизнес-проблемы должна выходить частная бизнес-цель.
Вот мы и подошли к тому, ради чего раздел критерии успеха появился в структуре этого документа. Теперь необходимо показать для каждой цели, какой будет результат.
В результате все читатели документа смогут увидеть полную картину того, из чего все начиналось (проблемы) и чем все должно завершиться (результат).
В итоге делаем небольшое заключение для читателя, так сказать выжимку из схемы. Чтобы было понятно.
Положение о концепции проекта
Вот мы подошли к самому главному, это описание концепции проекта. Здесь мы расписываем полный путь того, как должна происходить работа с системой (в нашем случае с ботом).
Именно здесь вы пишите своё первое виденье того, как все должно работать и оставляете ТДУ комментарии, с уточнением того, правильно ли вы поняли или устраивает ли заказчика такой подход. Конечно, этот раздел должен читать не только заказчики, а в первую очередь конечные пользователи, т.к. им предстоит работать в результате с программой, а заказчик (обычно руководитель или владелец бизнеса) чаще всего не сталкивается с проблемами, о которых знают конечные пользователи. Имейте это в виду.
При описании концепции начинайте движение описания последовательно.
Обязательно вставляйте скрины, таблицы, схемы и в данном случае лучше всего подойдет показывать прототипы (нарисованные или схематичные), чтобы заказчик мог точно понимать, о чем вы говорите и как это будет выглядеть. Таким образом можно выявить ряд проблем на раннем этапе.
Обязательно затрагивайте все тонкие места проекта, где может потребоваться дополнительная работа пользователя.
Не стесняйтесь обращать внимание на детали в описании последовательности действий. И оставляйте на них комментарии с пометкой ТДУ, чтобы выяснить - точно ли заказчик это хотел бы увидеть в конечной версии.
После того как описали концепции, переходите к разделу бизнес-риски.
Бизнес-риски
В данном разделе важно указать все риски, которые могут затронуть организацию, если что-то произойдет не так. Наш проект не такой масштабный, поэтому и рисков не так много.
Много или мало, это не важно при разработке требований. Наша задача все фиксировать и информировать об этом заказчика. Если он с чем-то несогласен или хочет что-то поменять, он должен быть своевременно проинформирован. Поэтому данный раздел вы должны заполнять после проведенной аналитики над разделом положение о концепции проекта.
Думайте, анализируйте, экспериментируйте, проводите исследования, но в данном разделе вы должны зафиксировать абсолютно все бизнес-риски, которые могут возникнуть.
Вывод:
Раздел Бизнес требования мы завершили, теперь на пути создания документа о концепции и границах второй раздел, который будет описывать границы проекта и называться он будет Рамки и ограничения.
Не забудь подписаться, чтобы ничего не пропустить. Ставь лайк и напиши добрый комментарий.
