«Сделайте нам CRM» без описания процессов заканчивается одинаково: подрядчик настраивает типовое, заказчик видит не то, что представлял, и начинается разговор о том, кто кому должен. Техническое задание нужно, чтобы этот разговор случился на бумаге и до начала работ.
Когда задание окупается, а когда хватает брифа
Проект на несколько недель с одной воронкой и без обмена данными в подробном задании не нуждается: его написание займёт столько же, сколько сама настройка. Там достаточно брифа и перечня работ в договоре.
Задание начинает окупаться, когда совпадает хотя бы одно:
- в проекте больше одного отдела, и права у них разные;
- есть обмен с 1С или другой учётной системой;
- переносите данные из существующей CRM или из таблиц;
- внедрение идёт этапами, и между ними в проекте меняются люди;
- принимать работу будет не тот, кто её заказывал.
Последнее встречается чаще всего: договаривался собственник, принимает руководитель отдела продаж, и представления о заказанном у них разные.
Что внутри
Цели и чем меряем результат
Формулировки вроде «повысить эффективность продаж» в приёмке бесполезны. Работают наблюдаемые вещи: заявки со всех каналов попадают в CRM без ручного ввода; руководитель видит воронку без выгрузки в таблицу; счёт выставляется из карточки сделки. Из таких строк потом собираются критерии приёмки — проверить их можно, не споря о толковании.
Границы работ
Раздел, который экономит больше всего нервов, — что в работу не входит. Телефонию подключаем, номера и минуты оплачивает заказчик. Структуру карточек делаем, заполнение историческими данными — отдельная строка. Обучение — два занятия для группы, дальше по часам поддержки. Без этого раздела любая просьба «ещё вот это по мелочи» превращается в обсуждение добросовестности.
Процессы, а не экраны
Описывать нужно движение работы: откуда приходит обращение, кто его берёт, через какие стадии проходит, что происходит на каждой, когда сделка считается успешной и когда проигранной. Обязательные поля на переходах, автоматические задачи, сроки реакции, что делает система, если срок прошёл.
Описывать интерфейс — «кнопка справа сверху» — занятие бесполезное: вендор меняет его сам, и задание устаревает раньше, чем доходит до приёмки.
Роли и права
Кто видит чужие сделки, кто меняет сумму, кто удаляет, кто выгружает список, кто смотрит отчёты по отделу. Пока права не описаны, все работают администраторами, а вопрос возникает в тот день, когда уволившийся менеджер забирает базу с собой.
Интеграции
По каждой нужны четыре вещи: что передаём, в какую сторону, по какому событию и с какой частотой. Плюс пятое, о котором забывают: что считается ошибкой обмена и кто о ней узнаёт.
Для 1С отдельно записывают конфигурацию и её версию, кто отвечает за доработки на стороне 1С и в каком окне можно останавливать обмен. Половина сложностей в таких проектах приходится на границу ответственности между подрядчиком по CRM и подрядчиком по 1С.
Перенос данных
Что переносим, откуда, в каком объёме и чего не переносим совсем. Отдельно — что делать с дублями и с записями без ответственного.
Правило, которое экономит недели: переносить то, с чем будут работать. Выгрузка всей истории за восемь лет в новую систему чаще всего означает, что в ней будет восемь лет мусора, который никто не станет разбирать.
Обучение и приёмка
Сколько занятий, для кого, в каком виде остаётся материал. Приёмка описывается сценариями: провести сделку от заявки до оплаты, выставить счёт, получить отчёт за период, проверить, что заявка с сайта создала лид с источником. Сценарий либо проходит, либо нет — обсуждать нечего.
Для коробки — окружение
Коробочная версия добавляет раздел про сервер: ресурсы, версия PHP и базы, кто обслуживает машину, как и куда делаются резервные копии, кто и когда ставит обновления. Разница между облаком и коробкой как раз в том, что в коробке эти обязанности чьи-то конкретные.
Формулировки, из-за которых спорят на приёмке
| Как написано | Что проверять на приёмке |
|---|---|
| Настроить CRM под процессы компании | Воронка «Продажи» со стадиями из приложения 1, обязательные поля на переходах, автозадача менеджеру при переходе на «Переговоры» |
| Интеграция с 1С | Из 1С в CRM — номенклатура и остатки раз в час; из CRM в 1С — заказ при переходе на «Оплата»; ошибки обмена приходят ответственному письмом |
| Перенести данные | Контакты и компании с полями из приложения 2, сделки за последние два года, дубли сводятся по телефону |
| Обучить сотрудников | Два занятия по два часа для отдела продаж и руководителей, запись и инструкция остаются у заказчика |
| Доработать под нас | Перечень доработок с описанием поведения, остальное — по часам после запуска |
Чем задание отличается от брифа и сметы
Бриф — это вопросы заказчику до начала: чем занимается компания, кто работает в системе, что болит. На нём строят предложение.
Техническое задание — описание того, как система должна работать после внедрения. Оно одно для обеих сторон и служит основанием для приёмки.
Смета — стоимость и сроки по этапам. Она следует из задания, а не наоборот: сначала понятен объём, потом цена. Если цену называют до разговора о процессах, названа стоимость типовой настройки, а не вашего проекта.
У нас первый этап внедрения — предпроектное исследование: разбираем, как компания работает сейчас, и на выходе даём состав работ, срок и стоимость до начала настройки. Прикинуть порядок цифр заранее можно калькулятором на той же странице. Когда задание нужно само по себе — например, чтобы разослать его нескольким подрядчикам и сравнить предложения, — мы делаем его отдельной работой.
Содержание: что перечислить в разделах
- Кто заказчик, чем занимается, сколько человек будет работать в системе.
- Как процессы устроены сейчас и что в них не устраивает.
- Цели внедрения и критерии приёмки.
- Границы: что входит в работы и что не входит.
- Структура системы: воронки, карточки, поля, справочники.
- Автоматизация: роботы, триггеры, согласования, уведомления.
- Права и роли по отделам.
- Интеграции: список, направления, события, обработка ошибок.
- Перенос данных: источники, объём, правила обработки дублей.
- Обучение: формат, участники, материалы.
- Окружение и обслуживание — для коробочной версии.
- Этапы, сроки, порядок приёмки каждого этапа.
- Порядок изменений: как вносятся правки и как они влияют на сроки и стоимость.
Последний пункт пропускают чаще остальных, а работает он чаще остальных: внедрение почти всегда уточняется по ходу, и заранее описанный порядок изменений превращает это из конфликта в процедуру.
Как принимать работу
Приёмка по заданию — это прогон сценариев из раздела приёмки на реальных данных, а не демонстрация экранов. Для коробочной версии к этому добавляется техническая часть: открыть в административном разделе «Проверку системы» и посмотреть чек-лист сдачи проекта. Там видно то, о чём в отчётах не пишут: правили ли файлы ядра напрямую, делается ли резервное копирование, включён ли проактивный фильтр.
И ещё одна вещь, которую стоит получить вместе с системой, — доступы и описание того, что настроено. Без них следующий подрядчик начнёт с разбора чужих решений, и это будет оплачено отдельно.
Статья была полезна?
Частые вопросы
Можно ли внедрять Битрикс24 без технического задания?
Для небольшого проекта — да: одна воронка, несколько сотрудников, без обмена с учётной системой. Там хватает брифа и списка работ в договоре. Как только появляются второй отдел, интеграция или перенос данных, устные договорённости начинают расходиться с памятью сторон.
Кто должен писать ТЗ — заказчик или подрядчик?
Заказчик знает процессы, подрядчик знает возможности платформы. Рабочий вариант — предпроектное исследование: подрядчик разбирает, как компания работает сейчас, и пишет задание, а заказчик проверяет и подписывает. Задание, написанное заказчиком в одиночку, обычно описывает то, как он представляет систему, а не то, что ему нужно.
Что делать, если в процессе выяснилось, что нужно иначе?
Менять задание письменно: допсоглашение или хотя бы письмо с описанием изменений, сроков и стоимости. Внедрение почти всегда уточняется по ходу — плохо не изменение, а изменение на словах, о котором через месяц помнят по-разному.
Нужно ли отдельное ТЗ для коробочной версии?
Нужен дополнительный раздел про окружение: сервер и его ресурсы, версия PHP и базы, кто обслуживает машину, как делаются резервные копии, кто ставит обновления. В облаке это забота вендора, в коробке — чья-то конкретная, и это стоит записать до запуска.
Сколько времени занимает подготовка задания?
Для проекта среднего размера — от нескольких дней до пары недель, в основном это интервью с руководителями отделов. Срок зависит не от объёма текста, а от того, как быстро компания отвечает на вопросы о собственных процессах.