Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях. Ирина Сергеевна Шишкина

Обращайте внимание на формулировки и уровни требований: они могут быть верхнеуровневыми, а могут быть конкретными. Не путайте техническое задание с техническим проектом, потому что чем детальнее требования, чем они более техничные (имеют отношение к технологии выполнения работ), тем больше в них от технического проекта, чем от технического задания. Это значит, что они должны быть выверены исполнителем и подтверждены: «Да, так можно выполнить работы и так это делать целесообразно». Чаще всего под требованиями мы подразумеваем именно хотелки – формулировки «я хочу». Чтобы требования были максимально понятны и конкретны, используйте структуру пользовательской истории: «Я как роль… хочу…, чтобы сделать…».

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

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

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

      В большинстве подходов – в гибридном, в предиктивном – журнал требований статичный и не меняется до конца проекта. В гибких подходах верхний уровень требований остается неизменным, а вот все, что касается декомпозиции требований или зоны технического проекта, – динамическая история, поскольку в процессе разработки системы мы получаем обратную связь от заказчика, меняется стратегия, меняются внешние условия рынка, и мы можем менять как технологию выполнения работы, так и какой-то вид системы. При этом основной запрос заказчика остается в силе. Если ему нужна система, которая будет обрабатывать входящие платежи, то мы эту систему и будем делать. Другой вопрос – какая логистика данных будет внутри или какого цвета будут формы для заполнения?

      С журналом требований работает вся команда. По большей части, конечно, работают исполнители, и журнал требований – основа для коммуникаций заказчика с командой или руководителя проекта с заказчиком. Не забывайте о том, что журнал требований – это не только основа для завершения проекта, для формирования закрывающих документов,