Требования к этапу Анализа и Дизайна важны для решений по автоматизации бизнеса — это проекты внедрения CRM, ERP, документооборота или автоматизации отдельных групп процессов. В этих проектах часто
- Анализируются бизнес процессы as-is и проектируются процессы to-be
- Чем больше масштаб системы тем больше внимания к Enterprise Architecture нужен
- Большое количество специфических ролей пользователей, большое количество заинтересованных лиц
- Проработка большого количества сценариев взаимодействия пользователя с системой
- Часто встречается интеграция с другими внутренними системами
- Необходимо анализировать не только данные, но и контент (файлы, медиа)
Будь готов
При этом бизнес редко готовится основательно к проекту — модели процессов не прописываются, детали бизнес архитектуры никто не продумывает, какими должны быть процессы известно только в эскизах. Все заняты и считают что ИТ-шники с этим справятся — нарисуют пока, будут отдыхать от кодирования. А ИТ-шники, как обычно, наивно полагают что бизнес знает что, хочет. Вот так и смотрят два барана друг на друга в надежде что между ними есть ворота – а ворот то нет. Это была злая шутка 🙂
Что пишем
Чем больше проект и чем больше количество охватываемых бизнес процессов и их сложность тем важнее указать что конкретно вы ожидаете в рамках данного этапа:
- Перечень процессов для которых нужно выполнить анализ as-is / to-be
- Требования к анализу заинтересованных лиц — нужно ли это делать (да нужно) и что конкретно должно быть сделано (профили, мотивация, интересы, потребности)
- Требования к описанию процессов — как детально должно быть текстом описана модель процесса
- Требования к моделированию процессов — скорее всего вы захотите к каждому процессу увидеть схему в BPMN
- Требования к формированию беклога — кто будет отражать требования к автоматизации и в беклоге, что должно быть описано
- Требования к описанию элементов беклога — как конкретно должны быть описаны пользовательские истории
- Требования к описанию критериев приемки — как минимум следует указать что они должны быть описаны и задать уровень их детализации
- Требования к системе управления требованиями — какая ALM система должна быть использована для ведения реестров требований
- Требования к связанности (traceability) требований — очень крутая, но очень дорогая штука в создании и поддержке. Рекомендуют десять раз подумать и отказаться — только если у вас не очень много денег на реализацию правильного подхода к управлению требованиями.
Очевидно не очевидное
Какие выводы мы можем сделать читая детальный перечень требований к тому что должно быть сделано на этапе анализа и проектирования:
- Чем больше работы по бизнес анализу и проектированию надо выполнить тем меньше точность для изначальной оценки объёма работ на основной этап разработки.
- Чем больше процессов и вовлеченных людей тем больше влияние человеческого фактора на сроки – отпуска, болезни, очень-важная-загрузка, сложно собрать всех вместе, нужно время обсудить, длинные цепочки согласования
- Добротный этап анализа тянет на 20-30% бюджет проекта.
- Нужна большая вовлеченность бизнеса. Если вы видите большое количество работы аналитика = не меньше работы потребуется со стороны заказчика. Если не большее — вам нужно не только прочитать эти требования, но и обсудить, продумать замечания и сделать это в больших группах людей