Одна из самых частых проблем при автоматизации бизнеса – расхождение ожиданий заказчика c тем, что в итоге получилось. Например, заказчик уверен, что все требования к будущей IT-системе были очевидны, а исполнитель утверждает, что в ходе проекта появились новые условия, не прописанные изначально. В результате обе стороны недовольны. Чтобы избежать конфликтов и разочарования, нужно составить максимально детализированное техническое задание. О том, как составить ТЗ и что в нём должно быть, менеджер проектов компании «НЭП» Юлия Князькина рассказала порталу Biz360.ru.
Юлия Князькина – функциональный архитектор и менеджер проектов компании «НЭП». Бакалавр прикладной информатики, эксперт по аудиту бизнес-процессов, специалист по внедрению IT-систем на платформе 1С. Практический опыт автоматизации предприятий – более девяти лет. Компания «НЭП» специализируется на внедрении комплексных систем управления ERP, ECM, ЭДО, BPM, CRM и ITIL. Является официальным партнёром фирмы «1С» и других вендоров программного обеспечения и оборудования.

Техническое задание – это документ, который описывает что, как и в какие сроки должно быть сделано. Это не просто список пожеланий заказчика, а инструкция для IT-подрядчика, которая минимизирует недопонимание между сторонами.
Для наглядности, рассмотрим пример из жизни. Предположим, вы хотите построить дом и говорите подрядчику: «Мне нужен трёхэтажный дом с верандой». Казалось бы, всё понятно. Но возникает ряд вопросов:
-
Какой высоты будут потолки?
-
Из какого материала собирается веранда?
-
Какие инженерные системы должны быть в доме?
-
Сколько комнат предполагается в доме?
-
И много-много других вопросов…
Без ответов на все эти вопросы результат может сильно отличаться от ваших ожиданий. То же самое происходит в IT: если ТЗ составлено поверхностно и «приблизительно», исполнитель будет додумывать детали за вас, а вы – получать не то, о чём мечтали, и разочаровываться.
Многие заказчики ошибочно полагают, что могут написать ТЗ самостоятельно. Но чтобы составить грамотное задание для реализации проекта автоматизации, внутренних IT-компетенций, как правило, недостаточно.
Тот же пример из жизни с домом. Если вы хотите посчитать, во сколько вам обойдётся строительство дома, с вами сначала поговорит архитектор, потом дизайнер, потом инженер, и только после этого смету отдадут считать сметчику. Сами вы сможете оценить реальные затраты только очень приблизительно.
В проектах автоматизации та же самая история. Написание ТЗ – это работа для профессионалов. Для подготовки этого документа необходимы следующие специалисты:
-
Бизнес-аналитики – помогают выявить реальные потребности бизнеса. Они будут задавать правильные вопросы, чтобы «вытащить» информацию, которую заказчики напридумывали у себя в голове, когда представляли образ будущего результата.
-
Технические специалисты (разработчики уровня middle/senior) – оценивают сложность разработки/внедрения и необходимых интеграций между разными системами.
-
Функциональный архитектор – обеспечивает согласованность функциональных требований с будущей архитектурой системы, а также трансформирует бизнес-потребности заказчика в реализуемые функциональные блоки информационной системы.
-
Рекомендация бизнесу: если у вас нет собственной IT-экспертизы, закажите разработку ТЗ у опытного подрядчика. Зрелые компании даже проводят отдельные тендеры на составление ТЗ, чтобы потом выбрать исполнителя для реализации.
1. Описание проблемы
Включение в ТЗ раздела «Описание проблемы» критически важно по нескольким ключевым причинам:
- Во-первых, оно даёт исполнителю чёткое понимание контекста. При этом лучше давать не краткую формулировку задачи, а именно развёрнутое описание проблемы: не «хотим автоматизировать учёт», а «сейчас учёт ведётся в Excel, из-за этого возникают ошибки, дублирование данных и задержки отчётности на 3 дня». Это позволяет исполнителю точно установить точку старта (Excel), болевые участки (ошибки, дублирование процессов), измеримые потери (время на отчётность) – и предложить решение, которое устраняет корень проблемы, а не просто делает «какую-то автоматизацию».
- Во-вторых, описание проблемы устанавливает фокус именно на бизнес-целях, а не на технологиях. Не нужно писать в ТЗ «хотим внедрить CRM» (это инструмент, а не цель), лучше сформулировать это так: «из-за ручного ввода заявок теряем 30% клиентов – хотим автоматическое распределение заявок и увеличение количества клиентов».
- В-третьих, снижается риск недопонимания. Разработчики мыслят иначе, чем бизнес-пользователи. Конкретное описание проблемы помогает им предложить оптимальное решение (возможно, вместо дорогой CRM хватит доработанного Google Sheets + скриптов).
2. Цели автоматизации и критерии успешного внедрения
Описания целей автоматизации и критериев успешного внедрения определяет, будет ли проект действительно полезным или превратится в дорогую, но бесполезную игрушку. А именно – поможет избежать «подмены целей»: если заказчик хочет ускорения процессов, а подрядчик делает красивый интерфейс, который не решает поставленную задачу. Если в ТЗ чётко прописано «Критерий успеха: время формирования финансового отчёта сокращается с трёх дней до двух часов», то исполнитель не сможет в ответ на вопросы о результате сказать: «Зато у вас теперь графики в реальном времени!»
Хорошо описанные критерии успеха – это также страховка для исполнителя от бесконечных изменений требований к системе. Ведь если критериев нет, можно бесконечно говорить: «Нуууу, это не совсем то, что мы хотели…».
3. Требования к системе
Это ДНК вашей автоматизации. Без них любой IT-проект превращается в лотерею. Для формулирования требований к системе лучше искать референсы. Посмотрите по сторонам: наверняка в информационном пространстве найдётся какой-то результат, который примерно похож на то, что вы хотите, и сообщите об этом исполнителю. Тогда у него будет более точное направление, чтобы выяснить у вас уже конкретику и сформулировать требования.
Какие требования нужно описать в ТЗ:
-
Функциональные требования (что система должна делать). Например, «Формирование автоматических отчётов в формате PDF и Excel».
-
Нефункциональные требования (как система должна работать). Например, «Время отклика интерфейса – не более двух секунд».
-
Интеграции (с чем система должна взаимодействовать). Например, «Интеграция с Telegram для уведомлений клиентов».
-
Безопасность. Например, «Двухфакторная аутентификация для администраторов».
-
Дизайн и юзабилити (если важно). Например, «Поддержка горячих клавиш для часто используемых действий» или «Интуитивный интерфейс для пользователей без технической подготовки».
4. Сроки и бюджет
Разделы ТЗ «Сроки оказания услуг\выполнения работ» и «Бюджет» – это не просто формальности, а ключевые элементы. Они превращают техническое задание из абстрактного описания в рабочий план с чёткими рамками.
Без чётких сроков разработка решения может растянуться на месяцы (или даже годы), потому что заказчик будет бесконечно вносить правки, а исполнитель не чувствовать срочности решения задач. Если сроки не определены, синхронизация между отделами (а мы не забываем, что проект автоматизации может охватывать все процессы компании) становится хаотичной.
Без фиксированного бюджета подрядчик может делать «идеальное» решение, которое бизнесу не по карману, или бесконечно запрашивать дополнительные платежи, не входившие в изначальную оценку. Если бюджет ограничен, исполнитель сначала может предложить внедрить самое важное, а «хотелки» второго плана (например, красивую аналитику) на второй этап (если он предусмотрен).
5. Правила взаимодействия команд в проекте
Автоматизация – это не только про технологии, но и про людей. Если не прописать, кто, кому, что и когда должен передавать, проект рискует утонуть в хаосе. Вот почему раздел «Правила взаимодействия» критически важен. Ответьте в этом разделе на предложенные ниже вопросы, это поможет вам в дальнейшем избежать конфликтов:
-
Кто принимает решения со стороны заказчика?
-
Кто ответственен за проект с обеих сторон?
-
Как происходит коммуникация?
-
Как вносятся изменения в ТЗ?
-
Что делать, если бюджет исчерпан?
-
Каковы правила работы с рисками?
-
«Они эксперты, сами разберутся». Исполнитель не телепат. Если вы максимально честно и открыто не введёте его в суть стоящей перед вами задачи, он не сможет её решить.
-
Скрытие бюджета. Если сказать исполнителю: «Сделайте много и дёшево», результат может оказаться как в сказке «Жадный Вартан», где вместо одной хорошей шапки заказчик получил семь маленьких и бесполезных. Автоматизация требует высокого профессионализма исполнителя и не может стоить дёшево. Примерный бюджет проекта можно уточнить методом мониторинга рынка цен у нескольких исполнителей.
Хорошее ТЗ – это не бюрократия, а инвестиция в успех автоматизации. Потратьте время и ресурсы на его проработку, и ваш проект будет реализован без переплат и конфликтов. И обязательно обращайтесь за подготовкой ТЗ к экспертам – они помогут превратить ваши идеи в чёткий реализуемый план.
Хотите автоматизацию, которая окупится? Начинайте с идеального ТЗ.
Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал и страницу в «ВКонтакте»