Четырёхэтапный метод работы с требованиями (Химонин)

Главные идеи#

Этап 1. Концепция продукта#

Этот этап ведёт бизнес-аналитик или менеджер продукта. Результат — документ видения продукта (Product Vision Document) для продукта под заказ или документ маркетинговых требований (Marketing Requirements Document, MRD) для продукта на открытый рынок. В MRD подробнее описаны целевые сегменты и конкуренты.

Порядок работы зависит от типа продукта. Для продукта под заказ: стимулы, затем цели и критерии успеха, затем потребности заказчика, затем обзор конкурентов. Для открытого рынка: стимулы, конкуренты, целевой сегмент, потребности, затем цели.

• Стимулы — то, что запускает работу: спрос на рынке, производственная необходимость, запрос заказчика, технический прогресс, юридические ограничения.
• Цели бывают финансовыми (доля рынка, продажи, возврат инвестиций, экономия) и нефинансовыми (удовлетворённость, производительность, репутация). Вслед за Вигерсом Химонин настаивает, чтобы цели были измеримыми.
• Целевой сегмент: домашние пользователи, малый и средний бизнес, крупные компании, корпорации. Потребности сегментов резко различаются (администрирование, интерфейс, безопасность, масштабируемость, лицензирование, поддержка). Химонин не советует целиться в крупные корпорации, пока вы не поработали с бизнесом поменьше.
• Сценарии описывают все процессы и окружение, в которых будет использоваться продукт, сразу для всех пользователей. Для продукта под заказ их получают из интервью с заказчиком; для открытого рынка — из профилей пользователей и интервью с подходящими людьми. Сценарии и требования внутри них приоритизируют по MoSCoW, и два приоритета сочетаются: например, требование Should внутри сценария Must считается Should.
• Обзор конкурентов: определите лидеров, изучите цену, доставку и демоверсии, перечислите решаемые ими проблемы и предлагаемые возможности и подведите итог по сильнейшим.
• Образ решения: список возможностей продукта, начиная с нефункциональных, потому что они определяют стоимость и сложность всего остального, плюс краткий образ продукта по шаблону позиционирования Джеффри Мура из книги Crossing the Chasm.
• Содержание проекта: по грубой оценке Химонина для каскадных проектов, точность оценок после концепции — лишь около 50%, после сбора и анализа требований — 60–70%, после проектирования — 80–90%. Отсюда его совет закладывать в ранние экспертные оценки двукратный запас.

Этап 2. Сбор требований#

• Составьте профили пользователей. В корпоративных продуктах директор, секретарь и бухгалтер пользуются одной и той же системой совершенно по-разному; проектируйте под реальные профили, а не под воображаемого среднего пользователя.
• Сформируйте инициативную группу, в которой есть хотя бы один представитель каждого профиля.
• Соберите пользовательские истории: использование продукта в конкретной ситуации с измеримым результатом. Химонин даёт им поля, похожие на поля варианта использования (ID, автор, дата, профиль, приоритет, частота, родительское бизнес-требование, предусловие, цель, поток действий), причём поток действий необязателен.
• Прежде чем спрашивать «что?» или «как?», всё время спрашивайте «Зачем?» — так вы зафиксируете потребности, а не готовые решения.

Этап 3. Анализ требований#

Цель — упорядочить требования и убрать дубликаты. Химонин предлагает два пути.

А. На основе вариантов использования (его предпочтительный путь, потому что каждая функция остаётся связанной с пользовательской историей, которой она нужна):

1. Найдите в историях базовые варианты использования.
2. Нарисуйте диаграмму вариантов использования с цветовой маркировкой приоритетов: зелёный — Must, жёлтый — Should, голубой — Could, красный — Won’t.
3. Уберите повторы: расширения ссылаются на базовый вариант использования, а не копируют его.
4. Найдите взаимоисключающие истории. Решите, ошибка ли это автора или две настоящие точки зрения; затем выберите одну или добавьте условия, при которых верны обе.
5. Разбейте варианты использования на неделимые элементы.
6. Превратите диаграмму в нумерованный список.

Б. На основе спецификации требований (для небольшого объёма или для команд, которые не работают с вариантами использования): извлеките из историй уникальные требования и разбейте их на независимые неделимые утверждения.

Группируйте истории в пакеты примерно по 20–30, чтобы в них было удобно ориентироваться и их было удобно редактировать. Затем ещё раз пересмотрите нефункциональные требования: на этапе концепции они были предположениями, а теперь есть реальные истории, на которых их можно проверить. Изменения требований уровня архитектуры должны утвердить все ответственные, потому что они сдвигают бюджет.

Этап 4. Проектирование#

Результат — функциональная спецификация (Functional Specification): требования уровня системы, модель взаимодействия с пользователем, архитектура продукта и технические подробности.

• Моделируйте потоки выполнения диаграммами деятельности, когда важны действия (мастера), конечными автоматами, когда важны состояния, и диаграммами последовательности, когда несколько объектов работают параллельно.
• Делайте макеты графического интерфейса в отдельном инструменте прототипирования, а не в среде разработки. Химонин замечает, что каждое окно меняется по нескольку раз, а чем позже изменение, тем оно дороже.
• Для каждой функции интерфейса командной строки или API опишите синтаксис, назначение, параметры, результат и пример и как можно раньше передайте это в отдел тестирования.
• Описывайте архитектуру диаграммой развёртывания, компонентами, интерфейсами, потоками сложных процессов и структурой базы данных.