«Техническое задание, это не бюрократическая преграда, а единственный легитимный способ остановить хаос и заставить бизнес сформулировать, что он на самом деле делает. Это карта собственных процессов, где красным выделены не хотелки отделов, а реальные узкие места, которые компания либо готова оплатить, либо предпочитает игнорировать. ТЗ, это исследование, где ответ «нам нужен аналог Jira»
считается неверным с самого начала».
Ситуация знакома многим: в компании нарастает хаос в управлении задачами. Кто-то работает через чаты, кто-то ведёт таблицы, прозрачность нулевая. Решение кажется очевидным — внедрить специализированную систему. Запрос «найти и внедрить Planfix или его аналог» превращается в поручение тому, кто «разбирается в компьютерах». Дальше — два пути. Либо создаётся список функций-пожеланий, который рассылается вендорам для сравнения цен. Либо решение покупается «по знакомству» без формальностей. Через несколько месяцев выясняется, что бухгалтерия не может получить нужные выгрузки, а процессы разработчиков не укладываются в предлагаемый workflow. Инструмент становится цифровым архивом нерешённых проблем, а инвестиции не окупаются.
Почему ТЗ, это исследование бизнеса, а не каталог функций
Традиционный подход рассматривает техническое задание как формальность, необходимую для закупки. На самом деле, это ключевой этап, который отделяет импульсивное желание от осознанной необходимости. Старт с анализа рынка («посмотрим, что есть на рынке») — фундаментальная ошибка. Он сразу замыкает мышление на возможностях вендоров, а не на потребностях бизнеса. Правильная последовательность — движение изнутри наружу: от процессов к требованиям, и только затем — к выбору решения.
Первым шагом должна быть декомпозиция абстрактной цели. Не «автоматизировать управление задачами», а детальное описание: как сегодня возникает задача, кто её фиксирует, в каком виде она передаётся, как отслеживается статус, куда попадают итоговые данные. Часто такой анализ показывает, что корень проблемы — в неотлаженной процедуре, а не в отсутствии софта. Автоматизация кривого процесса лишь увековечит его неэффективность.
Структура ТЗ, которая заставляет вникать в суть
Готовые шаблоны из интернета перегружены сотнями малозначимых пунктов о поддержке браузеров или цветовых схемах. Итоговый документ становится неподъёмным и нечитаемым. Эффективное ТЗ фокусируется на сути и состоит из логически связанных разделов.
1. Контекст и измеримые бизнес-цели
Раздел должен исключать размытые формулировки вроде «повысить эффективность коммуникации». Требуются конкретные, измеримые индикаторы, привязанные к бизнес-результатам. Например: «Сократить среднее время от создания заявки клиента до назначения исполнителя с 4 часов до 30 минут» или «Достичь уровня выполнения проектных задач в срок в 90% случаев в течение года». Цели должны коррелировать с известными компании KPI или стать новыми метриками успеха проекта.
2. Карта текущего процесса (as is)
Цель — не просто перечислить используемые инструменты (Excel, чат, почта), а визуализировать потоки данных, роли, точки принятия решений и очевидные разрывы. Наиболее наглядно это представляется в табличной форме, которая сразу выявляет проблемные зоны.
| Этап процесса | Ответственный | Инструмент/Носитель | Выявленные проблемы и риски |
|---|---|---|---|
| Получение входящей заявки | Менеджер по продажам | Корпоративная почта, личные сообщения в чате | Нет единого реестра, высокий риск потери, зависимость от доступности конкретного сотрудника |
| Регистрация и первичная фиксация | Менеджер по продажам | Общий файл Excel на сетевом ресурсе | Конфликты редактирования, отсутствие истории изменений, несанкционированный доступ |
| Постановка задачи исполнителю | Руководитель отдела | Устное поручение или сообщение в общем чате | Нет формального принятия в работу, приоритеты неясны, ответственность размыта |
| Отчёт о выполнении | Исполнитель | Личные заметки, обратное сообщение в чат | Статус неизвестен заказчику задачи, результат не фиксируется для отчётности |
3. Требования к будущему состоянию (to be) и функционалу
На основе анализа формулируются требования к системе. Критически важно разделить их по категориям приоритета, используя методологию MoSCoW:
- Обязательные (Must Have): Без этих функций решение бизнес-задачи невозможно. Пример: «Единый журнал входящих обращений с обязательными атрибутами: источник, контрагент, дата/время, суть, установленный срок реакции». «Назначение задачи конкретному исполнителю с автоматическим уведомлением». Несоответствие любому пункту этой категории — основание для безусловного отказа от вендора.
- Желательные (Should Have): Функции, которые значительно повышают эффективность или удобство, но чьё отсутствие может быть временно компенсировано. Пример: «Встроенные отчёты по загрузке сотрудников», «Визуализация процессов на канбан-доске». Эти пункты являются предметом переговоров о цене и сроках.
- Возможные (Could Have): Функции, имеющие второстепенное значение для основных целей. Их реализация рассматривается при наличии ресурсов. Пример: «Интеграция с корпоративным календарём для автоматического учёта занятости».
- Не входящие в scope (Won’t Have): Чёткое обозначение того, что не будет требоваться в рамках проекта. Это предотвращает «расползание» функционала. Пример: «Система не должна включать модуль расчёта заработной платы».
4. Технические, интеграционные и регуляторные требования
Этот блок привязывает выбор к инфраструктурной и правовой реальности компании. Ключевые вопросы: требуется ли локальное развёртывание (on-premise) из-за политик безопасности или допустимо облачное решение? Какие интеграции с действующими системами (1С, CRM, СЭД) необходимы? Как должна быть устроена модель разграничения прав доступа? Для российских реалий отдельным критическим пунктом идут требования регуляторов. Если система будет обрабатывать персональные данные (что почти неизбежно при учёте задач), необходимо сразу определить: готов ли вендор предоставить документацию для проведения оценки угроз безопасности персональных данных (ОУБПДн)? Поддерживает ли продукт необходимые средства криптографической защиты информации (СКЗИ), сертифицированные ФСБ? Есть ли у решения заключения ФСТЭК или готовность к проведению аттестационных испытаний?
5. Критерии оценки вендоров и процедура приёмки
Этот раздел трансформирует ТЗ из описания в инструмент управления закупкой. Заранее определяются параметры сравнения и их относительная важность. Эффективный метод — оценочная матрица с весами.
| Критерий оценки | Вес (1-10) | Метод проверки |
|---|---|---|
| Полное соответствие обязательным (Must Have) функциональным требованиям | 10 (обязательный минимум) | Практическая демонстрация на тестовом стенде или пилотной группе |
| Общая стоимость владения за 3 года (лицензии, внедрение, техподдержка, доработки) | 9 | Детальный расчёт на основе предоставленного КП |
| Соответствие требованиям по безопасности и регуляторике (152-ФЗ, ФСТЭК) | 8 | Предоставление действующих заключений, сертификатов или дорожной карты аттестации |
| Гибкость и зрелость API для ключевых интеграций | 7 | Проверка документации и выполнение тестового сценария синхронизации |
| Удобство интерфейса для ключевых ролей (менеджеры, исполнители) | 6 | Сбор обратной связи от фокус-группы после пробного использования |
Здесь же фиксируется процедура приёмки: например, успешное завершение пилотной эксплуатации в одном отделе в течение месяца с выполнением не менее 95% предопределённых тестовых сценариев.
Типичные ловушки после отправки ТЗ вендорам
Качественно составленное ТЗ может быть нивелировано на этапе коммуникации с поставщиками. Их задача — представить свой продукт в наиболее выгодном свете, что часто приводит к вольным интерпретациям требований. Фраза «система поддерживает ролевую модель» может означать как три предустановленных профиля, так и полноценный конструктор прав.
Противоядие — требование верифицируемости каждого пункта. Вместо «гибкая система отчётов» должно быть: «Возможность для администратора, не обладающего навыками программирования, конструировать отчёты путём выбора полей из заданного списка, с применением фильтров, группировок и выводом в табличном виде с опцией экспорта в XLSX». На демо-сессии необходимо настаивать на работе с реальным интерфейсом, а не презентацией, и просить решить конкретные кейсы из ТЗ.
Особое внимание — к вопросам регуляторики. Если этот блок был проигнорирован на этапе составления ТЗ, его поднимут юристы или служба безопасности на этапе согласования договора. Вопросы о соответствии 152-ФЗ, необходимости доработок для интеграции с отечественными СКЗИ или проведения аттестационных испытаний ФСТЭК, заданные постфактум, способны заморозить проект на месяцы или увеличить бюджет в несколько раз.
Итог: ТЗ как инструмент проектирования процессов
Неделя, потраченная на глубокий анализ и создание вдумчивого ТЗ,, это не бюрократическая задержка, а страховка от многомесячного провала внедрения и напрасных финансовых затрат. Главная ценность этой работы — даже не итоговый документ, а сформированное внутри команды общее понимание проблемы, целей и будущего процесса. Это знание остаётся в компании независимо от того, какой софт будет выбран сегодня. В конечном счёте, вы проектируете не конфигурацию информационной системы, а новое, более эффективное состояние бизнес-процесса. И этот проект логично сначала создать и согласовать на бумаге, прежде чем воплощать его в жёстких рамках чужого программного продукта.