Качество требований в IT-проектах — тема, которая редко обходится без болезненных вопросов и неочевидных ответов. Эта статья — не о критериях идеальных требований (их мы касаться не будем), а о том, как можно выстроить работу команды, чтобы этих критериев достигнуть. В основе статьи реальный кейс: я расскажу о конкретных сложностях, с которыми мы столкнулись на одном из проектов, о причинах этих проблем и методах, которые помогли не только исправить положение, но и применить данный подход на других командах.
Теперь немного о самом проекте. Компания-заказчик впервые работала с внешними вендорами, а мы впервые сотрудничали с этим клиентом. Казалось, что мы хорошо подготовились: собрали сильную команду — опытных аналитиков, разработчиков, тестировщиков. Из явных проблем: у заказчика не было своего аналитика. Вернее, он появился, но пришел практически одновременно с нами и разбирался в проекте даже меньше нашего.
Когда мы начали проект и приступили к работе, неожиданно столкнулись и с проблемами в подготовке качественных артефактов — тех самых User Story, которые нужно было передать разработчикам. На груминге (у нас в команде «Story Refinement») постоянно возникали вопросы: истории одна за другой отправлялись на доработку по разным причинам. Позже, уже на этапе разработки, часть требований вновь возвращалась с замечаниями: требовались дополнительные уточнения.
Мы начали анализировать ситуацию и осознали, что команда теряет очень много времени. Например, на груминг собирались все 9 участников, обсуждали User Story, но в итоге понимали, что она не готова — её нельзя отдать в разработку, а значит, нужно вернуть аналитикам на переработку. Нас это категорически не устраивало: такие циклы требовали огромных затрат времени.
Мы начали анализировать причины проблем.
Как я уже говорил, команду мы собрали опытную. И из-за этого возникла дополнительная сложность: до этого проекта её участники никогда не работали вместе. Каждый — сеньор с опытом в десятках проектов, и каждый уверен в своей правоте и привык работать по своим стандартам. Это привело к проблемам: никто не хотел подстраиваться под других, каждый настаивал на своём подходе.
Еще одна проблема — новая для нас доменная область. Я, например, имея за плечами 15 лет в финтехе, ранее фокусировался на работе с юридическими лицами в банкинге, а не с физическими. Остальные члены команды также пришли из других областей: ритейла, страхования и прочего. То есть у нас были пробелы в понимании предметной области.
В команде, кроме меня, было два аналитика, но я, выступал в роли архитектора и частично курировал аналитику, поэтому не всегда успевал выстраивать процессы. И существующие процессы оказались для аналитиков неудобными.
Так же была проблема, что нет четких критериев готовности User Story к передаче в разработку. Казалось бы, мелочь, но в сеньорной команде это стало проблемой: каждый участник по-своему понимал, что такое готовая история. Разработчики ожидали один формат, тестировщики — другой, а аналитики — третий.
Кроме того, не было четкого процесса управления требованиями. Стало понятно, что процесс управления качеством требований невозможно отделить от процесса управления самими требованиями — они взаимосвязаны. И мы решили выстроить циклический процесс управления качеством требований.
Мы начали с шаблонов — казалось бы, это аксиома. На техинтервью все отвечают: «Да, используем шаблоны». И у нас они тоже были. Когда проект стартовал, я принес туда шаблоны с предыдущих проектов, и большого значения мы этому не придали. Заказчик вообще не выдвигал требований к формату: «Делайте как удобно». Собственных шаблонов у него не было. Но скоро стало понятно, что наши шаблоны не подходят. Они не устраивали команду, разработчиков, тестировщиков, деливери.
Главный вывод, который мы сделали: шаблоны, которые не адаптированы под нужды всех участников, сильно снижают качество требований. Правильный шаблон — первый шаг к успеху. Когда в нём четко прописаны User Story, Use Case, API, Endpoint, практически невозможно упустить ничего важного.
Мы взяли существующий шаблон и обсудили его с разработчиками и тестировщиками: «Вам не нравится наш вариант? Предложите, каким он должен быть». Постепенно, за несколько итераций, совместно разработали новый формат, протестировали его, выявили слабые места и доработали. Разработчики требовали больше технических деталей, тестировщики хотели видеть всё в одном месте, а не переходить по ссылкам. Но после серии согласований нашли компромисс.
И мы закрепили принцип: шаблон — не догма, а инструмент, который должен устраивать всех. Согласовали с заказчиком возможность изменений, но с условием: от уже утвержденных шаблонов отклонения недопустимы. Это стало ключевым правилом. Даже мелкие нарушения (чуть отступить, описать иначе) мы жестко блокировали — артефакты, не соответствующие шаблонам, не передавались в работу.
Мы изменили workflow работы с требованиями аналитиков — это вызвало наибольшее сопротивление в команде. Изначально аналитики, как это принято во многих командах, работали в одном спринте с командой разработки по Scrum. Но в наших условиях это оказалось неудобно. Мы столкнулись с недостатком актуальной документации по текущей системе. Хотя манифест Agile гласит: «работающий продукт важнее документации», в нашем случае отсутствие актуальной информации о функционале находящемся в продакшене стало критическим. В итоге мы решили отказаться от Scrum для аналитиков и перешли на Kanban, чтобы отделить этап анализа от разработки, и начали поддерживать актуальную документацию по текущей системе в проде.
Мы перевели команду аналитиков на отдельную Kanban -доску. Это добавило гибкости, но увеличило трудоемкость. Процесс выглядел так:
- Задача на аналитику создавалась на Kanban -доске.
- Аналитик работал с ней, после чего задача отправлялась на ревью (об этом ниже).
- После ревью формировалась документация с описанием изменений (например, кусок функционала).
- Задача переходила в статус «Story Refinement», а затем — в статус «Done».
Результатом аналитической задачи становилась одна или несколько задач на Scrum-доске разработчиков. Аналитик создавал их вручную, что добавляло работы, но позволяло разделить процессы. Задачи разработки жили на Scrum-доске, линковались с аналитическими задачами и документацией в Confluence. Причем в Confluence на доработку создавалась отдельная страница «Сhange request». Когда задача на разработку была выполнена, создавалась новая задача на аналитику (на актуализацию общей документации на систему). Аналитик обновлял общую документацию системы, приводя ее в актуальное состояние. Важно отметить, что мы относились к этому не как к техническому долгу, а как к обязательному этапу. И эти задачи довольно быстро выполнялись с указанием ссылки на обновленную документацию.
Работы стало больше — это факт. Пришлось заводить дополнительные задачи, но взамен мы получили свободу. Раньше задачи аналитиков часто замораживались, мы их откладывали из-за того, что некоторые смежные системы не были готовы (у нас было около 15 интеграций). Новый подход позволил уйти от жестких двухнедельных спринтов и брать в работу только то, что действительно актуально и важно.
Кстати, был и дополнительный позитивный эффект — прозрачность для заказчика. Видя две доски (аналитики и разработки и два различных бэклога), он четко понимал, какие задачи находятся на этапе анализа, что уже в разработке, когда и что будет готово. И, кстати, даже отдельно отметил, что такой формат упростил ему контроль за прогрессом.
Теперь о ревью документов. Казалось бы, процесс стандартный и всем знакомый, напрямую влияющий на качество требований (в отличие от шаблонов, чья роль в достижении качества требований не всегда очевидна).
У нас ревью формально существовало, но было необязательным. Мы неоднократно пытались его оживить, меняли подходы, но результат оставался нестабильным. Были мысли типа: раз команда состоит из сеньорных аналитиков, зачем тратить время на проверки? В спешке задачи часто закрывали без ревью, а иногда оно проводилось без привлечения разработчиков, и они впервые видели требования только на Story Refinement, когда аналитик презентовал готовую User Story. Такая ситуация нас категорически не устраивала.
Первое, что мы сделали, это жестко зафиксировали обязательность ревью. Без него документ не мог двигаться дальше. Ревью проводили аналитики, но с одним важным изменением: мы добавили ежедневные 30-минутные встречи с лидом разработки. Заранее, еще на этапе проектирования, с ним обсуждалось, что мы хотим реализовать. Лид, будучи сеньором, также комментировал и вопросы тестирования (тестировщики были перегружены, и привлечь их было сложно). На ревью мы все же старались не придираться. Главное, что мы проверяли — полноту решения, проработку негативных и пограничных сценариев. Ну а если вопросов не было, встречу с лидом разработки просто отменяли.
А еще нам не удалось внедрить внешнее ревью. Мы пытались: по аналогии с командой разработки, где сначала идет внутренняя проверка, а затем внешняя, хотели добавить второй этап. Но аналитик со стороны заказчика, присоединившийся к проекту одновременно с нами, не был погружен в систему. Его ревью сводилось к формальным правкам: «тут запятая», «тут переформулируйте». Это не улучшало качество требований и тормозило процесс — без его одобрения мы не могли двигаться дальше.
Мы обратились к заказчику: объяснили проблему, привели факты о трудозатратах. Он попросил своего аналитика активнее включаться в процесс, но это не сработало. После повторного диалога заказчик согласился: «Качество требований после вашего внутреннего ревью меня устраивает. Отказываемся от внешнего этапа». Ревью осталось обязательным, но только внутренним.
Я считаю, что согласование требований с заказчиком (внешнее ревью) должно проводиться, и наш случай — это скорее исключение из правил, а не как не правило. Но у нас было так, и, конечно, это требовало больше внимания аналитиков на этапе выявления требований (но тут у нас проблем не возникало, сеньерность команды тут как раз дало отличный результат).
Следующий наш шаг — внедрение Definition of Ready (DOR) как чек-листа для передачи требований на обсуждение и оценку командой. Раньше этого не было, и каждый аналитик по-своему определял, когда требование готово.
И очень важный плюс в гибкости самого DOR, у нас это самый «живой» инструмент. Мы постоянно меняем его: добавляем или исключаем пункты, как только видим, что процесс стабилизировался. Сейчас он обновляется буквально каждый спринт — после обсуждения итогов спринта с командой.
В DOR мы так же включили бюрократические процедуры. Например, для передачи User Story в разработку требовались «спузы» — специальные учетные записи к сторонним системам, чтобы разработчики могли начать работу, а тестировщики — проверить функционал. В финтехе получение таких доступов со стороны заказчика занимает длительное время. Поэтому мы добавили в чек-лист пункт: «аналитик заранее запускает процессы получения доступов». Галочка ставилась только если доступы уже получены или их запрос как минимум инициирован.
Этот момент не связан с качеством требований, но напрямую влияет на процесс разработки, поэтому в DOR вошли не только критерии качества, но и бюрократические этапы. Мы сделали обязательными пункты вроде «ревью проведено» или «все доступы запрошены». Так DOR превратился в инструмент, который гарантирует, что требование не просто хорошо написано, но и готово к передаче в работу без задержек.
Результат. Не всё было так уж просто: сеньорные разработчики, аналитики и тестировщики сопротивлялись изменениям. Объединить команду, внедрить процессы управления качеством требований — всё это требовало усилий. Не все воспринимали нововведения с энтузиазмом.
Но сейчас процесс налажен. Мы работаем с заказчиком уже два с половиной года, к проекту подключились три новые команды. Возвраты требований стали минимальными, документация по системе всегда поддерживается актуальной. А если возникают проблемы, техподдержка быстро находит ответы в документации.
Конечно, объем работ вырос, поддержка актуальности требует времени, а процессы — жесткого контроля. Но главное: управление качеством стало циклическим процессом. Мы выявляем проблему, ищем причину, внедряем решение — и так по кругу. Шаблоны, ревью, DOR постоянно адаптируем по обратной связи. Такой подход работает. Мы используем его еще в нескольких командах и планируем развивать дальше.
Подводя итог, могу сказать, что внедрение процессов управления качеством требований — это не разовая акция, а циклическая работа, требующая гибкости и дисциплины. Ну а наш опыт показал: даже в сеньорной команде с устоявшимися привычками можно добиться значимых изменений, если правильно расставить приоритеты.