Есть такая проблема: инженеры делают программное обеспечение, пишут код, тратят много сил и времени, а в финале бизнес недоволен результатом. Обе стороны демотивированы. Разбор полетов обычно сводится к обсуждению качества требований и точности формулировок. Для команды разработчиков вывод – надо быть более внимательными к качеству требований, которые берутся в разработку.
Если рассмотреть этот вопрос с практической стороны, то инжинирингу желательно запланировать несколько контрольных точек в расписании проекта для валидации требований, причем на разных этапах жизненного цикла продукта.
Цель этого упражнения для команды разработчиков – выявить проблемы в требованиях до того, как ресурсы будут выделены для их реализации.
Мне доводилось часто наблюдать, как маленькие проекты, и даже компании, разрастались до больших сложных продуктов, когда провалидировать все необходимые требования в неформальной форме уже просто невозможно. Из моего опыта хорошо работают такие виды контролей качества требований как ревью, прототипирование и приемочные тесты. Рассмотрим каждый из них более детально.
Ревью требований
На мой взгляд, наиболее распространенным контролем является проверка и анализ требований. Собираешь группу (2+ человек) заинтересованных ребят и проверяете фичу на непротиворечивость, однозначность, понятность и полноту. Иногда даже короткое обсуждение дает уже хороший результат. Для этого команде задается фокус на поиск нестыковок, ошибочных предположений, отсутствия ясности и отклонений от стандартов (best practices). Для удобства работы можно подготовить рекомендации или чек-листы на что надо обратить внимание. Ревью требований может быть на любом этапе, но обязательна точка контроля перед стартом разработки. И если у вас система, которая состоит из нескольких модулей, то не стесняйтесь подключать экспертов по затрагиваемым модулям. Это могут быть продакт менеджеры, бизнес аналитики, разработчики, QA. Ревью требований – простой и очень эффективный способ избежать очевидных ошибок и ложных прогнозов.
Прототипирование
Прототипирование – очень классный контроль того, что ожидает бизнес в результате. Правда, и более трудозатратный. Поэтому, если ревью должно быть всегда, то прототип только в случаях больших или сложных фич. Порой вам надо будет аргументировать, зачем нужен прототип, ведь это время и деньги.
Прототипы позволяют сэкономить и предотвратить потери ресурсов на исправление ошибок или переделывание функционала, вызванных плохой продуманностью требований.
Даже простой прототип уже обязывает продумать customer flow и необходимые экраны, что позволяет определить очевидные проблемы и нестыковки на этапе проектирования. Согласитесь, что это гораздо дешевле, чем сделать готовый продукт и проверять на пользователях. Прототипирование позволяет получить быструю обратную связь. Например, динамическое поведение пользовательского интерфейса гораздо доступнее через кликабельный прототип, чем через текстовое описание или набор дизайнов в
InVision. Кстати, частота изменений требований после создания прототипа гораздо ниже, так как подготовка прототипа требует большей степени проработки, чем простое текстовое описание.
Разработка приемочных тестов
Одна из форм контроля качества требований – это добавление к ним критериев приемки. Просто добавьте строку в свой проектный план: “Разработка сценариев приемочного тестирования (приемочных тестов)”. Да, иногда обсуждение критериев приемки может быть дольше, чем само требование. Но, это полезное упражнение, в этом заинтересованы все стороны. Это еще один шаг к пониманию того, как конечные пользователи используют систему.
Все вышеперечисленные контроли – это отправка к практике управления рисками и снижению затрат. Управление рисками является одной из ключевых обязанностей менеджера проекта. Обеспечение того, чтобы разработка начиналась с провалидированных требований, является ключом к снижению риска, а значит делает проекты более успешными с точки зрения денежных и временных затрат.
Останні коментарі