Как собрать требования к CRM: интервью, user stories, BRD и ТЗ — практическое руководство с шаблонами

Была у нас история с одним казахстанским застройщиком. Пришли они с простым запросом: «Нам нужна CRM. Чтобы продавать квартиры». Всё, точка. На вопрос «А какие функции нужны?» ответили: «Ну, обычные. Как у всех».

Через три месяца после внедрения выяснилось, что «обычные функции» — это совсем не то, что имел в виду отдел продаж. Менеджеры хотели видеть планировки квартир прямо в карточке сделки. Руководитель ждал автоматическую бронь с таймером. Бухгалтерия — интеграцию с 1С для выставления счетов. Юристы — контроль статусов договоров. А маркетинг — сквозную аналитику с учётом рекламных кампаний.

Ничего этого в первоначальном ТЗ не было. Потому что ТЗ состояло из одной фразы: «Нам нужна CRM».

Этот кейс — не исключение. По нашей статистике, 70% проблем при внедрении CRM связаны с плохо собранными требованиями. Не с технологиями, не с интеграторами, не с бюджетом. С банальным непониманием того, что именно нужно бизнесу.

Эта статья — подробное руководство по сбору требований к CRM. Без воды и абстрактных теорий: конкретные методы, шаблоны, примеры из практики. Будем говорить про интервью с пользователями, user stories, BRD (Business Requirements Document) и финальное ТЗ — всё, что превращает «хотелки» в рабочий документ.

Почему 90% внедрений CRM буксуют на старте

Прежде чем погружаться в методологию, давайте разберёмся, почему тема сбора требований так критична. Казалось бы: есть бизнес, есть CRM-система, есть интегратор — берём и настраиваем. Что может пойти не так?

На практике — почти всё. Вот типичные сценарии провала.

Сценарий 1: «Сделайте как у конкурентов». Компания просит скопировать процессы соседа по рынку. Забывая, что у соседа другая структура отдела продаж, другой продукт, другой цикл сделки. В итоге CRM работает, но неудобно. Люди сопротивляются, система превращается в формальность.

Сценарий 2: «Руководство решило». Топ-менеджмент спускает требования сверху, не спросив тех, кто будет работать в системе каждый день. Менеджеры получают CRM, которая усложняет их работу вместо упрощения. Саботаж, «забытые» данные, параллельный учёт в Excel.

Сценарий 3: «Нам нужно всё». Компания хочет автоматизировать вообще всё и сразу. Получается монстр из 200 полей, которые никто не заполняет. Или бесконечный проект, который никогда не заканчивается.

Сценарий 4: «Давайте начнём, потом разберёмся». Самый опасный. Внедрение идёт без внятных требований, изменения вносятся на лету, бюджет раздувается, сроки срываются, результат никого не устраивает.

Всех этих ситуаций можно избежать, если потратить время на этап сбора требований. Да, это занимает несколько недель. Да, требует вовлечения разных людей. Но эти вложения окупаются десятикратно — в экономии времени, денег и нервов на этапе внедрения.

Шаг первый: определите, кого опрашивать

Главная ошибка — собирать требования только с руководства или только с рядовых сотрудников. Нужны обе стороны. И ещё несколько неочевидных участников.

Представьте CRM как дом. Руководство определяет, сколько этажей, какая планировка, где несущие стены. Но жить в этом доме будут люди, которым важно, где розетки, удобная ли кухня и хватает ли места в шкафах. Если не спросить обоих — получите либо красивый, но непригодный для жизни дворец, либо удобный, но хаотичный сарай.

Кто должен участвовать в сборе требований

Спонсор проекта — тот, кто принимает финальные решения и распоряжается бюджетом. Обычно это CEO, коммерческий директор или владелец бизнеса. От него нужно понять стратегические цели: зачем вообще нужна CRM, какие бизнес-результаты ожидаются, какие метрики должны улучшиться.

Руководители подразделений — начальники отделов продаж, маркетинга, поддержки, сервиса. Они понимают процессы на уровне команды: как организована работа, какие есть проблемы, что нужно контролировать. От них вы получите требования к отчётам, автоматизации, интеграциям между отделами.

Линейные сотрудники — менеджеры по продажам, операторы поддержки, маркетологи. Те, кто будет работать в CRM каждый день. Их боли — самые практичные: «Мне приходится вводить данные дважды», «Я не вижу историю звонков», «Уведомления теряются». Эти детали критичны для adoption системы.

ИТ-специалисты — системные администраторы, разработчики, если есть. Они расскажут про текущий ИТ-ландшафт: какие системы уже используются, какие данные где хранятся, какие интеграции возможны, какие есть ограничения.

Смежные отделы — бухгалтерия, юристы, логистика. Даже если они не будут основными пользователями CRM, у них могут быть требования: выгрузка данных для отчётности, хранение договоров, отслеживание статусов доставки.

Шаг второй: выбираем методы сбора требований

Есть много способов узнать, что людям нужно. Выбор метода зависит от размера компании, сложности процессов и доступного времени. На практике лучше комбинировать несколько подходов.

1. Глубинные интервью (face-to-face)

Самый информативный метод. Вы садитесь с человеком один на один (или по видеосвязи) и разговариваете о его работе. Не о CRM — о работе. Как устроен его день? С какими задачами он сталкивается? Что отнимает больше всего времени? Что раздражает?

Хитрость в том, чтобы не задавать вопросы про систему напрямую. Если спросить: «Какие функции вам нужны в CRM?» — человек растеряется или начнёт фантазировать. Но если спросить: «Расскажите, как вы обрабатываете новый лид?» — вы услышите реальный процесс со всеми костылями и проблемами.

Когда использовать: всегда. Минимум 5-7 интервью для малого бизнеса, 15-20 для среднего.

Продолжительность: 45-60 минут на человека.

2. Наблюдение (shadowing)

Сидите рядом с сотрудником и смотрите, как он работает. Не вмешиваетесь, не задаёте вопросов — просто наблюдаете. Записываете, какие инструменты использует, сколько окон открыто, куда кликает, где тормозит.

Этот метод вскрывает вещи, о которых люди сами не говорят. Например, менеджер может не упомянуть, что держит отдельный блокнот для напоминаний, потому что для него это норма. Но для вас это сигнал: напоминалки в CRM — критичная функция.

Когда использовать: для ключевых ролей — менеджеров продаж, операторов поддержки. Особенно ценно, если процессы сложные или плохо задокументированы.

Продолжительность: 2-4 часа на человека.

3. Воркшопы (групповые сессии)

Собираете группу из 5-8 человек и модерируете обсуждение. Хорошо работает для выявления противоречий между отделами и поиска компромиссов.

Например, на воркшопе маркетинг может сказать: «Нам важно видеть источник лида». А продажи ответят: «А нам это поле не нужно, мы его не заполняем». Тут же можно обсудить, как сделать так, чтобы поле заполнялось автоматически.

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

Продолжительность: 2-3 часа.

4. Анализ документов и систем

Изучаете то, что уже есть: текущую CRM или Excel-таблицы, регламенты, отчёты, скрипты продаж. Это показывает, какие данные реально используются, какие метрики важны, какие процессы уже формализованы.

Когда использовать: параллельно с интервью. Помогает готовить вопросы и проверять, соответствует ли реальность заявлениям.

5. Опросы (анкетирование)

Если нужно охватить много людей — создаёте анкету в Google Forms или Typeform. Полезно для количественных данных: сколько лидов обрабатывает менеджер в день, какие каналы коммуникации использует, сколько времени уходит на отчёты.

Опросы не заменяют интервью, но дополняют. Интервью — это глубина, опросы — это ширина.

Когда использовать: если в компании более 30 потенциальных пользователей CRM.

Шаг третий: проводим интервью правильно

Интервью — это не просто разговор. Это структурированный процесс с подготовкой, сценарием и фиксацией результатов. Вот как это делать эффективно.

Подготовка к интервью

За день до встречи отправьте участнику короткое письмо: кто вы, зачем встреча, сколько займёт, какие темы хотите обсудить. Это снимает напряжение и даёт человеку время подумать.

Подготовьте список вопросов, но не планируйте читать его как анкету. Вопросы — это ориентир, а не сценарий. Главное — слушать и задавать уточняющие вопросы по ходу разговора.

Структура интервью

Вступление (5 минут). Представляетесь, объясняете цель: «Мы собираем требования к новой CRM. Ваш опыт поможет сделать систему удобной для всех. Это займёт около часа, нет правильных или неправильных ответов».

Контекст работы (10 минут). Узнаёте общую картину: «Расскажите о своей роли», «Как устроен типичный рабочий день», «С кем вы чаще всего взаимодействуете».

Текущие процессы (20 минут). Углубляетесь в детали: «Откуда к вам приходят лиды?», «Как вы ведёте историю общения с клиентом?», «Какие отчёты вы делаете?». Просите показать конкретные примеры.

Проблемы и боли (15 минут). Выявляете, что мешает: «Что отнимает больше всего времени?», «Какие задачи вызывают раздражение?», «Если бы вы могли изменить одну вещь в работе — что бы это было?».

Желаемое состояние (10 минут). Мечтаем вместе: «Как бы выглядел идеальный день?», «Какую информацию хотелось бы видеть сразу?», «Что должна уметь система, чтобы вы сказали: вот это удобно».

Завершение (5 минут). Спрашиваете, есть ли что-то ещё. Благодарите за время. Уточняете, можно ли вернуться с дополнительными вопросами.

Шаг четвёртый: оформляем требования в user stories

После интервью у вас куча записей, заметок, цитат. Теперь это нужно превратить в структурированный формат. User stories (пользовательские истории) — один из лучших способов это сделать.

User story — это короткое описание функции с точки зрения пользователя. Формат простой:

Почему этот формат работает? Потому что он фокусируется на том, зачем нужна функция, а не только на том, что это. Это помогает принимать решения: если ценность неясна — может, функция и не нужна?

Примеры user stories для CRM

Посмотрим, как превратить собранную информацию в user stories.

Исходные данные из интервью: менеджер сказал: «Я трачу кучу времени на поиск номера телефона клиента. Звонит человек, называет имя, а я лезу в Excel, ищу по фамилии, иногда ошибаюсь в написании...»

User story:

Ещё пример. Руководитель отдела продаж: «Мне нужно каждый понедельник собирать отчёт: кто сколько звонков сделал, сколько встреч провёл, какие сделки закрыл. Трачу на это полдня».

User story:

Детализация user stories: критерии приёмки

Сама по себе user story — это верхнеуровневое требование. Чтобы передать её разработчикам или интеграторам, нужны критерии приёмки (acceptance criteria). Они описывают, как проверить, что функция реализована правильно.

Пример:

Подробнее про методологию agile и работу с user stories мы писали в статье Change management при внедрении CRM: как добиться принятия системой командой.

Шаг пятый: собираем BRD (Business Requirements Document)

BRD — это главный документ, который описывает, что нужно бизнесу от новой системы. Он не про технические детали реализации, а про бизнес-цели, ограничения и ожидания. Это контракт между заказчиком и исполнителем: «Вот чего мы хотим достичь».

Если user stories — это кирпичики, то BRD — это архитектурный план дома. Он показывает общую картину и контекст.

Структура BRD для CRM-проекта

1. Резюме проекта. Краткое описание: зачем внедряем CRM, какие проблемы решаем, что получим в результате. Одна-две страницы, которые можно показать любому человеку для понимания сути.

2. Бизнес-цели и метрики успеха. Конкретные, измеримые цели. Не «улучшить продажи», а «увеличить конверсию из лида в сделку с 15% до 25% за 6 месяцев». Не «упростить работу менеджеров», а «сократить время на оформление заказа с 20 до 5 минут».

3. Стейкхолдеры и пользователи. Кто заинтересован в проекте, кто будет использовать систему, какие у каждой группы потребности и ожидания. Таблица с ролями, количеством пользователей, основными сценариями использования.

4. Описание текущего состояния (AS-IS). Как работают процессы сейчас: какие инструменты используются, как устроена воронка продаж, какие есть проблемы и узкие места. Диаграммы процессов, если есть.

5. Описание целевого состояния (TO-BE). Как должны работать процессы после внедрения CRM. Какие изменения ожидаются, какие процессы автоматизируются, какие появляются новые возможности.

6. Функциональные требования. Здесь живут ваши user stories, сгруппированные по модулям или бизнес-областям: управление лидами, сделки, клиентская база, отчёты, интеграции и так далее.

7. Нефункциональные требования. Производительность (сколько пользователей, сколько данных), безопасность (роли, права доступа, шифрование), доступность (SLA, бэкапы), масштабируемость.

8. Интеграции. Какие внешние системы нужно подключить: 1С, телефония, мессенджеры, email, сайт, маркетплейсы. Для каждой — что интегрируем и зачем.

9. Ограничения и допущения. Бюджет, сроки, технические ограничения, зависимости от других проектов. Всё, что может повлиять на решения.

10. Риски. Что может пойти не так и как с этим справляться. Сопротивление сотрудников, нехватка данных для миграции, изменение бизнес-приоритетов.

Шаг шестой: готовим техническое задание (ТЗ)

BRD — это про бизнес. ТЗ — это про реализацию. Если BRD отвечает на вопрос «Что нужно?», то ТЗ — «Как это будет работать?».

ТЗ — более технический документ. Он адресован тем, кто будет настраивать или разрабатывать CRM: интеграторам, разработчикам, системным администраторам. Здесь уже можно и нужно говорить про конкретные решения.

Чем ТЗ отличается от BRD

Что включить в ТЗ на CRM

Структура данных. Какие сущности будут в системе: контакты, компании, сделки, задачи. Какие поля у каждой сущности. Какие связи между сущностями. Если есть кастомные объекты — описываем их.

Воронки и статусы. Какие воронки продаж или бизнес-процессы. Какие статусы на каждом этапе. Какие переходы разрешены, какие — нет. Какие действия триггерятся при смене статуса.

Автоматизации. Какие события должны запускать автоматические действия. Например: «при создании лида с источником "сайт" — назначить ответственного по round-robin и создать задачу "Позвонить в течение 15 минут"».

Интеграции. Технические детали: API или выгрузка файлов, формат данных, частота синхронизации, обработка ошибок. Для каждой интеграции — схема потока данных.

Роли и права. Какие роли пользователей будут в системе. Что видит и может делать каждая роль. Матрица доступа: сущность × действие × роль.

Отчёты и дашборды. Какие отчёты нужны, какие метрики показывать. Для каждого отчёта: источник данных, фильтры, группировки, визуализация.

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

Подробнее про миграцию данных — в статье Миграция данных в CRM: дедупликация, валидация, контроль качества.

Шаг седьмой: приоритизируем требования

Вы собрали 150 user stories. Реализовать все сразу невозможно — ни по времени, ни по бюджету. Нужна приоритизация: что делаем в первую очередь, что откладываем, что отбрасываем.

Здесь помогает метод MoSCoW:

• Must have — обязательно. Без этого система не имеет смысла. Например, базовая работа со сделками.
• Should have — важно. Система будет работать без этого, но плохо. Например, интеграция с телефонией.
• Could have — желательно. Если будет — хорошо, если нет — переживём. Например, геймификация для менеджеров.
• Won't have (this time) — не сейчас. Отложим на следующие фазы. Например, мобильное приложение.

Приоритизацию лучше делать вместе с бизнес-заказчиком. Вы показываете полный список требований, объясняете трудоёмкость каждого, а заказчик решает, что критично. Это снимает конфликты потом: «Мы же договаривались, что это Could have».

Ещё один полезный инструмент — матрица ценность/усилия. Для каждой фичи оцениваете: сколько пользы она принесёт (ценность) и сколько сил потребует на реализацию (усилия). Получаете четыре квадранта:

Частые ошибки при сборе требований

Напоследок — антипаттерны. Вещи, которые мы видели десятки раз и которые всегда ведут к проблемам.

Ошибка 1: «Мы уже всё знаем»

Руководство считает, что понимает потребности сотрудников без интервью. «Зачем спрашивать менеджеров, я и так знаю, что им нужно». В итоге — CRM, которая удобна директору, но непригодна для ежедневной работы.

Как избежать: интервью обязательны. Минимум 5 разговоров с линейными сотрудниками.

Ошибка 2: Требования-решения

Вместо описания проблемы описывается готовое решение. «Нам нужна кнопка Х в правом верхнем углу». А зачем кнопка? Какую задачу решает? Может, есть способ лучше?

Как избежать: всегда спрашивать «зачем». Если человек называет конкретную функцию — уточнять, какую проблему она решает.

Ошибка 3: «Хотим всё»

Список из 300 требований без приоритетов. Нереалистичные ожидания, бесконечный проект, разочарование.

Как избежать: приоритизация с MoSCoW. Для первой версии — только Must have.

Ошибка 4: Игнорирование нефункциональных требований

Все фокусируются на фичах, забывая про производительность, безопасность, масштабируемость. Потом выясняется, что CRM тормозит на 50 пользователях или данные доступны всем.

Как избежать: отдельный раздел в BRD для нефункциональных требований. Вопросы про нагрузку и безопасность — на каждом интервью с ИТ.

Ошибка 5: Нет версионирования

Требования живут в разных файлах, разных версиях, у разных людей. Никто не знает, какая версия актуальна. Путаница, конфликты, доработки по устаревшим требованиям.

Как избежать: единый источник требований (Confluence, Notion, Google Docs с контролем версий). Один ответственный за документ.

Практические советы напоследок

Несколько вещей, которые мы вынесли из десятков проектов по сбору требований в Казахстане и СНГ.

Записывайте всё. Не надейтесь на память. Аудио- или видеозапись интервью (с разрешения) + заметки. После каждого интервью — 15 минут на структурирование записей, пока свежо в голове.

Используйте визуализацию. Диаграммы процессов, wireframes, прототипы — люди лучше понимают картинку, чем текст. Нарисовали схему воронки — покажите заказчику, пусть подтвердит, что понял правильно.

Подтверждайте понимание. После каждого блока информации — резюмируйте: «Правильно ли я понял, что...?». Это спасает от недопониманий.

Планируйте итерации. Первый раунд сбора требований — не последний. После прототипа будет второй раунд уточнений. После пилота — третий. Это нормально.

Учитывайте культуру компании. В Казахстане есть специфика: иерархичность, важность личных отношений, иногда — нежелание открыто критиковать начальство. Создавайте доверительную атмосферу, гарантируйте анонимность обратной связи, если нужно.

Документируйте отказы. Если что-то отклонили — записывайте почему. «Функция Х — отложена на фазу 2, потому что низкий приоритет и большие усилия». Это защитит от вопросов «А почему этого нет?» через полгода.

Итог: требования — это инвестиция в успех проекта

Многие воспринимают сбор требований как бюрократию — скучные встречи, бесконечные документы. На самом деле это фундамент всего проекта. Когда требования собраны грамотно, вы экономите месяцы работы и миллионы тенге. Когда кое-как — получаете бесконечную переделку того, что уже, казалось бы, готово.

Что делать прямо сейчас:

1. Определите список ключевых стейкхолдеров — кто должен участвовать в сборе требований
2. Запланируйте интервью — минимум по 45 минут на человека
3. Подготовьте вопросы, адаптированные под каждую роль
4. После интервью — оформите user stories с критериями приёмки
5. Соберите всё в BRD и проведите приоритизацию с заказчиком
6. Детализируйте Must have требования в ТЗ

И помните: лучше потратить две недели на сбор требований, чем два месяца на переделки. Успешных проектов начинаются с правильных вопросов.