Управление разработкой цифрового продукта начинается не с кода, а с требований. Ошибки на этом этапе часто обходятся дороже самой реализации.
Если задача сформулирована недостаточно подробно, заказчик и команда могут по-разному понимать ожидаемый результат. В итоге с технической точки зрения работа оказывается выполнена, а с точки зрения бизнеса — нет.
В статье разбираем, как подготовить ТЗ для разработчика, и показываем пример технического задания на разработку корпоративной системы. Его структуру можно использовать как основу для своего проекта.
Что такое техническое задание
Техническое задание — это документ, который фиксирует, что нужно сделать, зачем и как проверить результат. Оно помогает избежать разночтений между бизнесом и командой, точнее оценить сроки и бюджет, а также сделать результат разработки более предсказуемым.
Исправить требования на этапе составления ТЗ обычно занимает несколько минут или часов обсуждения.
Но если проблема обнаруживается в процессе разработки, приходится переделывать и тестировать код, заново согласовывать результат. Это влияет на сроки, стоимость и качество проекта, а в отдельных случаях может привести к накоплению технического долга. В крупных проектах стоимость таких изменений может многократно превышать затраты на первоначальную проработку требований.
Поэтому инвестиции в подготовку ТЗ окупаются не только сокращением сроков, но и снижением расходов на доработки.
Сегодня компании всё чаще используют ИИ для подготовки ТЗ. Но передавать сгенерированный документ в разработку без проверки нельзя: компания может согласовать требования, которые сама не разобрала, и получить слишком сложный и дорогой проект. Поэтому разработка ТЗ должна начинаться с тщательной проверки и выбора объёма, который компания готова реализовать и использовать.
Из чего состоит правильно поставленная задача
Для небольшой доработки может быть достаточно карточки с описанием изменения и критериями приёмки. Для корпоративной системы потребуется раскрыть отдельные функции и связи между ними.
Ниже приведён образец технического задания на разработку программного обеспечения на примере доработки внутреннего портала. Это структура с примерами заполнения: конкретные параметры необходимо согласовать для своего проекта.
Шаблон ТЗ на разработку: структура и пример заполнения
Предположим, сотрудники компании уже создают заявки на закупку во внутреннем портале. Но согласование проходит по электронной почте: решения теряются в переписке, а инициаторам приходится уточнять статус у коллег.
Компания хочет перенести согласование в портал. На этом примере рассмотрим, какие сведения должны появиться в документе.
1. Текущее состояние системы
Если система уже существует, сначала фиксируют, как она работает сейчас. Это позволяет определить необходимые изменения и учесть их влияние на действующие функции.
В разделе описывают:
- Рабочий процесс. Кто участвует в нём и какие действия выполняет.
- Существующие функции. Что уже реализовано и какие части продукта затронет доработка.
- Данные и интеграции. Где хранится информация и с какими программами настроен обмен.
- Техническое устройство. Какие технологии используются, где размещена система и доступен ли исходный код.
- Проблемы и ограничения. Что мешает работе и какие условия необходимо учитывать.
В нашем примере нужно изучить существующую форму заявки и её передачу в учётную программу. Затем определить, как добавить согласование, сохранив действующие заявки и историю работы.
Если актуальной документации нет, сначала потребуется обследовать систему. Его результаты станут основой для требований к доработке.
2. Цели и границы проекта
Опишите, что компания хочет изменить и какой результат ожидает получить. Затем определите, какие возможности входят в проект.
В нашем примере: сотрудники должны подавать и согласовывать заявки внутри портала. Инициатор должен видеть текущий статус, а ответственный руководитель — получать заявки на рассмотрение.
Здесь же фиксируют, что не входит в разработку. Например, складской учёт остаётся в действующей программе, а автоматический выбор поставщиков откладывается.
Если есть обязательная дата запуска или ограничение бюджета, их также нужно указать. Бизнес-цель и результат разработки при этом оценивают отдельно.
3. Пользователи и права доступа
Перечислите роли и опишите доступные каждой из них действия (простой формулировки «предусмотреть разные права» недостаточно).
Например:
- Сотрудник создаёт заявку и отслеживает её рассмотрение.
- Руководитель согласовывает заявки своего подразделения или возвращает их на уточнение.
- Специалист по закупкам получает согласованные заявки для дальнейшей работы.
- Администратор управляет настройками маршрутов согласования.
4. Функциональные требования
Опишите, что должна делать система. Требования удобно группировать по функциям или разделам продукта.
Например, для создания заявки нужно определить:
- Какие поля заполняет сотрудник и какие из них обязательны.
- Можно ли сохранить черновик и продолжить заполнение позже.
- При каких условиях заявка отправляется на согласование.
- Можно ли изменить или отозвать отправленную заявку.
Требования должны объяснять поведение продукта. Вместо «добавить уведомления» нужно указать, кто получает сообщение, при каком событии и через какой канал.
Пример требования: после отправки заявки руководитель подразделения получает уведомление в портале со ссылкой на её рассмотрение.
5. Правила работы и пользовательские сценарии
Функции нужно связать в последовательный процесс. Для этого описывают путь пользователя от начала задачи до результата и правила перехода между этапами.
В нашем примере: сотрудник заполняет заявку и отправляет её руководителю. После согласования она поступает специалисту по закупкам. Если сумма превышает установленный порог, требуется дополнительное решение финансового директора.
Отдельно разбирают отклонения от основного сценария:
- Руководитель возвращает заявку на уточнение.
- Инициатор отзывает заявку до завершения согласования.
- Ответственный сотрудник временно отсутствует.
- Участник пытается изменить уже согласованные сведения.
Для каждой ситуации нужно определить дальнейшее поведение системы. Например, при возврате на уточнение заявка должна снова стать доступной инициатору для редактирования, а комментарий руководителя — сохраниться.
6. Данные и интеграции
Укажите, какую информацию использует система и как она взаимодействует с другими программами.
В нашем примере: сведения о сотрудниках и подразделениях поступают из кадровой системы, а согласованная заявка передаётся в учётную программу.
Для каждого обмена фиксируют:
- Состав передаваемых данных.
- Направление и условия передачи.
- Соответствие полей и справочников в разных программах.
- Поведение при ошибке или временной недоступности другой системы.
- Порядок повторной передачи, исключающий создание дубликатов.
Если возможности подключаемой программы пока неизвестны, их необходимо исследовать. Иначе оценка интеграции будет строиться на предположениях.
7. Требования к интерфейсу и работе системы
Определите, какие экраны нужны пользователям и как на них будет представлена информация. Макеты и схемы переходов можно оформить приложениями к ТЗ.
Также зафиксируйте условия работы продукта:
- Совместимость. Поддерживаемые устройства и браузеры.
- Производительность. Допустимое время выполнения операций при согласованной нагрузке.
- Защита информации. Правила доступа к данным и регистрации значимых действий.
- Надёжность. Требования к резервному копированию и восстановлению после сбоев.
Требование должно задавать допустимое время открытия и условия, при которых его измеряют.
8. Внедрение и передаваемые материалы
Определите, что потребуется для запуска системы и что компания получит по завершении работ.
Для существующего портала важно согласовать порядок обновления. Например, потребуется ли остановка работы и как сохранить созданные ранее заявки.
В ТЗ также фиксируют:
- Где будет размещена система и кто предоставляет инфраструктуру.
- Какие данные нужно перенести или подготовить.
- Какие инструкции потребуются пользователям и администраторам.
- В каком составе передаются исходный код и техническая документация.
- Кто отвечает за запуск и проверку системы после установки.
Это позволяет заранее учесть работу, которая не видна на макетах, но необходима для использования продукта.
9. Критерии и порядок приёмки
Критерии приёмки определяют, когда работа считается выполненной. Они должны быть связаны с требованиями и допускать однозначную проверку.
Например, при проверке согласования заявки нужно убедиться, что:
- Заявка поступает руководителю нужного подразделения.
- После возврата на уточнение сотрудник может исправить сведения и отправить её повторно.
- Решения участников сохраняются в истории.
- Согласованная заявка передаётся в учётную программу без дублирования.
- Пользователь без необходимых прав не может изменить решение руководителя.
Кроме критериев, определяют порядок приёмки: кто проверяет результат и как фиксируются замечания.
Приведённый пример технического задания на разработку показывает уровень детализации документа. Для реального проекта потребуется заполнить конкретные значения и приложить необходимые материалы. Нерешённые вопросы нужно зафиксировать вместе с ответственными за их уточнение.
Как из ТЗ появляются задачи для разработки
После согласования требований команда разбивает работу на отдельные задачи. Это называют декомпозицией.
При этом важно сохранить связь каждой задачи с исходным требованием. Такая связь называется трассируемостью требований.
На практике пунктам ТЗ присваивают номера, а в задачах разработки указывают ссылки на них. С требованиями связывают и проверки. Это позволяет увидеть, какие возможности уже реализованы и какие ещё не проверены.
Если требование изменится, команда сможет найти связанные задачи и определить, что потребуется пересмотреть.
ТЗ для разработчика и подробный список задач можно вести отдельно. Например, согласованные требования хранить в проектной документации, а работу по их реализации — в системе управления проектами. Главное, чтобы связь между ними сохранялась.
Чек-лист готовности задачи к разработке
Перед передачей ТЗ полезно пройтись по чек-листу:
- Понятна ли бизнес-проблема, которую решает доработка?
- Определен ли ожидаемый результат для бизнеса?
- Описан ли пользовательский сценарий?
- Зафиксированы ли ограничения по срокам, бюджету и технологиям?
- Есть ли критерии приемки?
- Приложены ли необходимые макеты, схемы или примеры?
- Согласованы ли требования со всеми заинтересованными сторонами?
Если по всем пункты соблюдены, задачу можно отдавать в разработку.
Типичные ошибки при постановке задач
Самая распространенная ошибка — отсутствие бизнес-цели. Команда понимает, что нужно сделать, но не понимает, какой результат ожидает заказчик. Чтобы этого избежать, перед постановкой задачи зафиксируйте проблему, которую должен решить новый функционал, и ожидаемый бизнес-результат.
Не менее часто встречаются слишком общие формулировки. Например, улучшить интерфейс или ускорить систему. Такие требования практически невозможно объективно проверить после завершения работ. Используйте конкретные требования и измеримые критерии, по которым можно оценить результат.
И последнее — не фиксировать изменения в документации. Нередко правки обсуждаются устно или в мессенджерах, поэтому спустя время участникам проекта сложно восстановить историю принятых решений. Все изменения лучше сразу вносить в задачу или проектную документацию, чтобы избежать недопонимания и споров.
Вывод
Хорошо выстроенное управление разработкой начинается с понятных требований. Документ должен объяснять, какой продукт нужен компании и как будет проверяться его работа.
Используйте шаблон ТЗ на разработку как основу, но заполняйте его с учётом своих процессов. Объёмный документ не заменит обсуждения спорных правил, а подробное описание далёких планов не поможет запустить первую версию.
В Aiston мы помогаем компаниям прорабатывать требования, проектировать решения и запускать цифровые продукты с учётом бизнес-целей. В рамках этой работы определяем границы проекта и согласовываем требования, чтобы команда могла оценить объём разработки до её начала.
Если вам нужна помощь с разработкой ТЗ или доработкой существующей системы, обсудите задачу с нами.