Сбор требований — фундамент, на котором держится весь проект. Неверный сбор требований может стоить проекту много денег и времени. Вот подход, который спасает от бесконечных правок и «я не это имел в виду». Шаг 0: Подготовка и погружение (Самое важное!) Прежде чем задать первый вопрос: 1. Пойми контекст. Что за бизнес? Какая его боль? Не «хотим чат в приложении», а «клиенты теряются на этапе выбора услуги, хотят мгновенной консультации». 2. Найди всех, кто «в теме». Ключевые стейкхолдеры (заинтересованные лица): бизнес-заказчик, будущие пользователи, технические специалисты, поддержка, юристы. У каждого — своя правда. 3. Выучи язык бизнеса. Говори с финансистами о KPI и ROI, с поддержкой — о нагрузке, с пользователем — о простоте. Какие бывают требования? 1. Бизнес-требования (Зачем?) — Цели верхнего уровня. Пример: «Увеличить долю повторных продаж на 15% в следующем квартале». 2. Пользовательские требования (Что?) — Что должны делать пользователи в системе. Пример: «Возможность оформить возврат товара в личном кабинете за 3 клика». 3. Функциональные требования (Как?) — Конкретные функции системы. Пример: «Система должна отправлять email-подтверждение при создании возврата». 4. Нефункциональные требования (Каким образом?) — Свойства системы: скорость, безопасность, надёжность. Пример: «95% страниц кабинета должны загружаться менее чем за 2 секунды при 1000 одновременных пользователей». Часто про них забывают, а потом система «падает». Как собирать? Инструментарий аналитика Нет одного волшебного метода. Использую комбинацию: - Интервью (основа) — Готовь вопросы заранее, но будь готов/а уйти вглубь. Спрашивай «почему?» до тех пор, пока не докопаешься до истинной потребности. - Воркшопы (мозговые штурмы) — Когда нужно собрать разных людей и быстро набросать процессы или идеи. Идеально использовать доску (Miro, Mural и др). - Анализ существующих данных и документов — Что уже есть? Старые системы, отчёты в Excel, письма поддержки, документация — кладезь информации. 📝 Правила фиксации: чтобы поняли все и не было двоякого толкования - Пиши просто и однозначно. Не «Система должна быстро работать», а «Операция поиска клиента по номеру телефона должна выполняться ≤ 1 секунды». - Используй стандартные шаблоны (User Stories, Use Cases, диаграммы процессов BPMN). Это как общий язык для команды. Плохие сигналы (того, что всё пошло не так) - «Это и так очевидно» (ничего не очевидно). - Заказчик говорит только в абстракциях («дружелюбный интерфейс») и не может привести пример. - Требования начинают меняться ежедневно без приоритизации (нужен срочный контроль изменений). - Техническая команда не задаёт уточняющих вопросов (значит, они что-то додумывают сами). Итог: Идеальных требований не бывает Задача аналитика — не записать каждую мелочь под диктовку, а выявить истинные потребности, договориться о приоритетах и зафиксировать договорённости так, чтобы и бизнес, и разработка поняли друг друга. Ваш успех — это не когда вы сдали «в точности как в ТЗ», а когда решили бизнес-задачу и пользователи стали работать эффективнее.