Качество требований в IT-проектах

info@vsetut.pro

Стать автором

Вернуться

22.04.2025 12:04:05 | Хабр

Хабы: Блог компании Reksoft, Анализ и проектирование систем

Качество требований в IT-проектах — тема, которая редко обходится без болезненных вопросов и неочевидных ответов. Эта статья — не о критериях идеальных требований (их мы касаться не будем), а о том, как можно выстроить работу команды, чтобы этих критериев достигнуть. В основе статьи реальный кейс: я расскажу о конкретных сложностях, с которыми мы столкнулись на одном из проектов, о причинах этих проблем и методах, которые помогли не только исправить положение, но и применить данный подход на других командах.

Теперь немного о самом проекте. Компания-заказчик впервые работала с внешними вендорами, а мы впервые сотрудничали с этим клиентом. Казалось, что мы хорошо подготовились: собрали сильную команду — опытных аналитиков, разработчиков, тестировщиков. Из явных проблем: у заказчика не было своего аналитика. Вернее, он появился, но пришел практически одновременно с нами и разбирался в проекте даже меньше нашего.

Когда мы начали проект и приступили к работе, неожиданно столкнулись и с проблемами в подготовке качественных артефактов — тех самых User Story, которые нужно было передать разработчикам. На груминге (у нас в команде «Story Refinement») постоянно возникали вопросы: истории одна за другой отправлялись на доработку по разным причинам. Позже, уже на этапе разработки, часть требований вновь возвращалась с замечаниями: требовались дополнительные уточнения.

Мы начали анализировать ситуацию и осознали, что команда теряет очень много времени. Например, на груминг собирались все 9 участников, обсуждали User Story, но в итоге понимали, что она не готова — её нельзя отдать в разработку, а значит, нужно вернуть аналитикам на переработку. Нас это категорически не устраивало: такие циклы требовали огромных затрат времени.

Подробнее

Читайте также