Анализ требований: как всё учесть в IT-проекте
Анализ требований на старте спасает проект за фиксированную стоимость от споров, когда посередине выясняется, что модуль интеграции не учли. Я собираю требования из 7 источников: текущее решение и процессы, бриф на разработку, интервью со стейкхолдерами, конкуренты, CJM и JTBD, опыт похожих ecommerce-проектов.
Делаете вы проект за фиксированную стоимость. А в середине проекта узнается, что модуль интеграции(или любую другую функцию) не учли. Клиент говорит, что сами виноваты, что не спросили «вы же профессионалы». Вы как настоящие разработчики утверждаете, что работаете по техническому заданию и не больше. И дальше долгие споры, где едва ли может быть win-win.
И клиент не виноват, он все не может учесть. И вы не виноваты, так как оценивали ровно то, что просили.
Сбор требований к проекту: 7 источников
Встает вопрос, как на старте все учесть, чтобы такого не было? Провести агрегацию требований к проекту.
1. Текущее решение. Даже, если планируете разработку CRM, а CRM не было. Как-то же они решали эту проблему раньше.
2. Текущие процессы компании. Контентщики что-то заполняют. Менеджеры что-то обрабатывают. Бухглатера что-то проводят. У всего этого есть процесс, которые формирует требования.
3. Бриф с несколькими десятками вопросом. Некоторым клиетнам помогает сформулировать мысли лучше, чем при интервью.
4. Интервью со всеми стейкхолдерами.
5. Анализ конкурентов.
6. Целевые сегменты клиентов. Посмотреть их CJM, JTBD, US и другие избитые аббревиатуры. Проще говоря, что пользователи этим продуктом будут делать.
Опыт схожих проектов в анализе требований
7. Опыт схожих проектов. Тут и пригодится ваша экспертность. У почти всех ecommerce-проектов, например, одни и те же интеграции, алгоритмы расчета доставок, сценарии оформления заказа. Кстати, для ecommerce у нас есть чек-лист с набором вопросов. Пишите +, отправлю.
И после десятка часов работы у вас появится спецификация и вилочная оценка проекта.
Какие бывают требования к IT-продукту
Требования делятся на несколько уровней, и путаница между ними — частая причина споров, потому что бизнес-требования отвечают на вопрос «зачем», пользовательские — «что человек будет делать», а функциональные — «что должна делать система». Отдельно стоят нефункциональные: скорость, нагрузка, безопасность, доступность. Путаница обходится дорого.
Модуль интеграции, о котором забыли в середине проекта, обычно теряется на стыке уровней: бизнес знает, что данные должны попадать в 1С, но в списке функций этого нет, потому что никто не спросил.
Чек-лист вопросов для ecommerce-проектов закрывает самые частые пробелы вроде интеграций, доставки, оплаты и сценариев оформления заказа, но не заменяет разговор с людьми, которые работают с системой каждый день.
| Уровень | Вопрос | Пример |
|---|---|---|
| Бизнес-требования | Зачем проект | Сократить время обработки заказа вдвое |
| Пользовательские | Что делает пользователь | Менеджер видит все заказы клиента в одном окне |
| Функциональные | Что делает система | Заказ выгружается в 1С при смене статуса |
| Нефункциональные | Как система работает | Страница каталога открывается быстрее 2 секунд |
Сбор требований: техники и инструменты
Семь источников из поста дополняют друг друга: интервью дают глубину, бриф — широту, а анализ текущих процессов — правду о том, как всё работает на самом деле, а не как описано в регламенте. Нужны все три.
- Интервью со стейкхолдерами: по одному, а не всей группой, иначе мнения подстраиваются под руководителя.
- Наблюдение: посидеть рядом с менеджером, который обрабатывает заказы, и посмотреть, что он делает вручную.
- Анализ документов: регламенты, выгрузки, отчёты, которые сейчас собираются в Excel.
- Бриф: несколько десятков вопросов, на которые клиент отвечает письменно.
- Прототип: кликабельный макет в Figma быстро показывает, что забыли.
Как вести интервью со стейкхолдерами
Хорошее интервью — это вопросы о прошлом и настоящем, а не о желаниях. «Расскажите, как вы обработали последний сложный заказ» даёт больше, чем «какие функции вам нужны».
После каждого интервью я записываю требования своими словами и отправляю на подтверждение. Расхождения находятся сразу, а не через месяц разработки.
Вопрос «что будет, если это не сделать» помогает отделить реальную потребность от пожелания.
Приоритизация: что делать в первую очередь
Собранных требований почти всегда больше, чем бюджета. Без приоритетов оценка становится неподъёмной, а проект — бесконечным. Выбирать всё равно придётся.
Для приоритизации удобен метод MoSCoW: каждое требование помечается как Must (без этого не запускаемся), Should (важно, но можно позже), Could (хорошо бы) или Won't (не в этот раз). Обсуждение по этой схеме быстро показывает, где на самом деле MVP.
Ошибки при анализе требований к проекту
- Собирать требования только у руководителя и не говорить с теми, кто будет работать в системе.
- Записывать решения вместо задач: «нужна кнопка выгрузки» вместо «бухгалтер тратит час на перенос данных».
- Пропускать нефункциональные требования до этапа нагрузочного тестирования.
- Не фиксировать, что в проект не входит. Список исключений защищает от споров не хуже списка функций.
- Не возвращаться к требованиям после первых недель разработки.
Спецификация и вилочная оценка
Результат анализа — спецификация: документ, где описаны функции, интеграции, роли пользователей и ограничения. По нему команда оценивает работы, а клиент проверяет, всё ли учтено. Это база для оценки.
Вилочная оценка честнее точной цифры. Минимум показывает стоимость, если всё пойдёт по плану, а максимум — если подтвердятся риски, и клиенту проще принять решение, когда он видит диапазон и знает, от чего зависит итог.
На фиксированную цену я бы соглашался только после такой работы. Фикс без анализа требований — ставка, в которой проигрывают обе стороны.
Сам анализ занимает десятки часов, и это тоже работа, за которую стоит платить. Многие подрядчики делают его отдельным этапом с фиксированной ценой: клиент получает спецификацию и оценку и может пойти с ними к любому исполнителю.
Вопросы и ответы
Как собрать требования к IT-проекту?
Изучить текущее решение и процессы компании, дать бриф с несколькими десятками вопросов, провести интервью со стейкхолдерами, проанализировать конкурентов и сегменты клиентов, опереться на опыт схожих проектов.
Что получается после анализа требований?
После десятка часов работы получается спецификация и вилочная оценка проекта.