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