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