Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях. Ирина Сергеевна Шишкина
Чтение книги онлайн.
Читать онлайн книгу Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях - Ирина Сергеевна Шишкина страница 25
4 сущности требований
Напомню вам, что в домене требований есть 4 сущности:
Требования – хотелки заказчика и его команды (будущих пользователей продуктов системы).
Допущения – априорные события и условия, в рамках которых или мы реализовываем проект, или пользователи используют систему или продукт. Это то, что остается неизменным до конца проекта или в процессе эксплуатации продукта.
Ограничения – количественные и качественные показатели, которые указывают на рентабельность разработки или производства. Это коридор возможностей с формулировкой «не менее чем», «не более чем» для руководителя проектов, который может принимать те или иные решения в рамках этих ограничений.
Исключения – то, чего не должно быть в проекте или в продукте.
Более бюрократизированные подходы (например, линейный подход) предполагают наличие восьми документов, где есть требования к продукту, к проекту, исключения, ограничения и допущения, связанные с проектом, с продуктом. И все это благополучно подшивается к Приказу или общей проектной документации.
Если мы говорим о гибких подходах, то чаще всего используется:
свод верхнеуровневых требований на первичном этапе, на этапе планирования;
свод ограничений, исключений, допущений;
динамический документ – свод пользовательских историй или протокола изменения требований в процессе выполнения работ. Меняется чаще всего после проведения ревью.
Что важно учитывать при разработке документов, связанных с управлением требований:
1. Обращайте внимание на формулировки и уровни требований: они могут быть верхнеуровневыми, а могут быть конкретными. Не путайте техническое задание с техническим проектом, потому что чем детальнее требования, чем они более техничные (имеют отношение к технологии выполнения работ), тем больше в них от технического проекта, чем от технического задания. Это значит, что они должны быть выверены исполнителем и подтверждены: «Да, так можно выполнить работы и так это делать целесообразно». Чаще всего под требованиями мы подразумеваем именно хотелки – формулировки «я хочу». Чтобы требования были максимально понятны и конкретны, используйте структуру пользовательской истории: «Я как роль… хочу…, чтобы сделать…».
2. Помните о том, что исключения – это определенный запрет на какие-то конкретные функции внутри продукта или на конкретные действия, подходы и инструменты в проекте. Они должны быть чем-то обусловлены – либо вето заказчика, либо законодательством, либо экономическими ограничениями и так далее.
3. Помните о том, что ограничения – это не бюджет и сроки. Например, количество пользователей в системе: СКАЧАТЬ