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