В практике бизнес-анализа есть один парадокс: требования могут быть собраны, оформлены, согласованы — и все равно не работать. Проект уходит в реализацию, команда движется по плану, а через некоторое время начинаются изменения, пересогласования, откаты и споры.
На первый взгляд кажется, что проблема в качестве самих требований. Но чаще всего дело не в этом.
Проблема в том, что требования почти никогда не живут в «вакууме».
Они меняются вместе с бизнесом, уточняются по мере появления новой информации, конфликтуют между собой и постепенно теряют актуальность. При этом во многих командах работа с требованиями заканчивается в момент их фиксации.
Дальше начинается «само как-нибудь».
В результате:
- изменения вносятся без оценки влияния
- приоритеты фактически устаревают, но остаются неизменными
- зависимости между требованиями теряются
- команда реализует не то, что действительно важно
Именно здесь появляется разрыв между бизнес-анализом и реальной управляемостью решения.
Если посмотреть на это с другой стороны, становится очевидно: требования — это не документ и не список задач. Это система, которая требует постоянного управления.
И чем сложнее решение, тем быстрее эта система выходит из-под контроля, если за ней не следить.
В BABOK этому посвящен отдельный раздел — управление жизненным циклом требований. Он описывает не столько «как писать требования», сколько как поддерживать их в рабочем состоянии на протяжении всей инициативы.
Это принципиально другой уровень работы аналитика.
Если коротко, речь идет о пяти вещах:
- как понимать, откуда взялось требование и с чем оно связано
- как поддерживать его актуальность
- как правильно расставлять приоритеты
- как управлять изменениями
- и как действительно достигать согласования, а не формального «ок»
Подробно я разобрал этот раздел с практической точки зрения и показал, как это применять в реальной работе у себя на сайте.
Если вы когда-либо сталкивались с тем, что требования «плывут» уже после согласования — скорее всего, причина именно здесь.