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