ТЗ на разработку внутреннего ПО: что подготовить заказчику

Опишите текущий процесс и причину изменений

Фраза «нужна автоматизация» оставляет слишком много вопросов. Возьмите одну повторяющуюся операцию: обработку заявки, согласование документа, выдачу оборудования или подготовку отчёта. Запишите, с какого события она начинается, кто участвует и чем заканчивается. Укажите, где сейчас хранятся данные и как сотрудники передают работу друг другу.

Затем назовите затруднение. Например, менеджер повторно вводит сведения из письма в таблицу, а руководитель узнаёт о задержке только после звонка клиента. Это условный пример, а не результат нашего клиентского проекта. Он показывает, какую проблему должен решать инструмент: сохранить обращение, назначить ответственного и показать актуальный статус.

Если исходные показатели неизвестны, так и отметьте. Несколько наблюдений за обычной рабочей неделей полезнее придуманного процента экономии. По ним можно выбрать, что измерять после запуска: время операции, число ручных переносов данных или долю обращений без назначенного исполнителя.

Разделите пользователей, роли и действия

Перечислите участников процесса и задачи каждого. У роли должно быть понятное назначение: оператор регистрирует обращение, исполнитель обновляет ход работы, руководитель видит очередь своей команды. Отдельно определите, кто управляет настройками и доступами. Название должности само по себе не объясняет, какие сведения человек может просматривать или менять.

Для каждой роли выберите основные действия и ограничения. Может ли исполнитель видеть чужие заявки? Кто возвращает закрытую задачу в работу? Нужен ли временный заместитель? Что происходит с задачами сотрудника, который больше не работает в компании? Эти вопросы влияют и на интерфейс, и на устройство доступа.

Краткая формула сценария: «Я как [роль] хочу [действие], чтобы [результат]». Рядом стоит записать условие проверки. Такой подход помогает связать функции с потребностями пользователей, а не собирать перечень пожеланий без приоритета.

Зафиксируйте данные и внешние системы

Составьте небольшой реестр объектов: заявка, клиент, сотрудник, документ, оборудование. У каждого объекта перечислите обязательные поля, допустимые значения и источник информации. Если один справочник уже ведётся в учётной системе, уточните, кто отвечает за его актуальность и нужно ли разрешать изменение из нового приложения.

Для интеграции недостаточно слов «подключить CRM». Нужны направление обмена, событие запуска, состав полей и ожидаемое поведение при ошибке. Укажите, какие системы доступны, есть ли документация API и кто сможет предоставить тестовый доступ. Секреты и пароли в ТЗ не включайте: согласуйте отдельный способ передачи.

Если нужно перенести старые записи, опишите их объём и качество. Отметьте дубли, незаполненные поля и неизвестные форматы. Перенос архива и разработка новой функции — разные задачи; полезно оценивать их отдельно. Для примеров используйте обезличенные данные с сохранённой структурой.

Определите границы первой версии

Выберите один законченный маршрут, который команда сможет пройти от начала до результата. Для условной системы обращений это регистрация, назначение, выполнение и закрытие заявки. Если убрать один из обязательных шагов, красивый интерфейс ещё не станет рабочим инструментом.

Разделите требования на три группы: необходимые для выбранного маршрута, полезные после запуска и пока не входящие в проект. Для каждой обязательной функции объясните её связь с задачей. Отчёт или уведомление имеет смысл включать сразу, если без него нельзя контролировать процесс; иначе его можно обсудить в следующем этапе.

Зафиксируйте исключения. Например, первая версия работает с одной организацией и не включает расчёт зарплаты, мобильное приложение или перенос всего бумажного архива. Это даёт основу для оценки. Появившиеся позднее задачи нужно обсуждать вместе с их влиянием на этапы, а не незаметно добавлять в текущую работу.

Опишите условия работы и ограничения

Сообщите, где будет использоваться приложение: в офисе, удалённо, на компьютере, планшете или общем терминале. Уточните обычную и пиковую нагрузку, требования к размещению, зависимость от интернета и важные периоды работы. Если точных значений нет, обозначьте вопрос для совместной проверки.

Не пишите просто «система должна быть быстрой». Выберите ключевую операцию и условия, при которых проверяется её выполнение. Численные цели согласуйте после оценки нагрузки и инфраструктуры. Для интерфейса полезно назвать поддерживаемые устройства и браузеры, а для данных — доступные роли и требования к истории изменений.

Отдельно обсудите резервное копирование, восстановление и эксплуатацию. Кто отслеживает ошибки, кто отвечает на обращения сотрудников, где ведётся список изменений? Не все ответы обязан дать заказчик заранее. Важно сделать неопределённость видимой, чтобы она вошла в обследование и план проекта.

Превратите пожелание в проверяемое требование

Удобное требование можно проверить на определённых входных данных. В руководстве NASA по требованиям также подчёркивается проверяемость формулировок. Для обычного бизнес-проекта этот принцип помогает заранее договориться, что считать готовой функцией, без переноса сложного отраслевого стандарта целиком.

Проверяйте не только успешный путь. Запишите, что происходит при недоступности внешней системы, пустом обязательном поле или повторном действии пользователя. Если результат должен сохраняться после обновления страницы, это тоже нужно проверить. Несколько ясных условий полезнее оценки «в целом удобно».

Договоритесь о результатах этапов и передаче

Определите, что команда показывает на каждом этапе: описание процесса, прототип, работающий сценарий или интеграцию. Назначьте человека со стороны заказчика, который собирает замечания и согласует решения. Если обратная связь приходит от нескольких участников, нужен общий порядок разбора противоречий.

В составе передачи перечислите исходный код, доступы, инструкции по запуску, описание настроек и порядок сопровождения. Уточните, что входит в текущую работу, а что оценивается отдельно. Проверка функции, обучение сотрудников и обслуживание после запуска требуют разных действий и не возникают автоматически из слова «разработка».

Полезно вести таблицу открытых вопросов: вопрос, ответственный, когда нужен ответ и на что он влияет. Нерешённая интеграция может помешать оценке, а оттенок второстепенного элемента — нет. Такое разделение помогает двигаться по проекту без видимости, что все детали уже известны.

Шаблон ТЗ для первого обсуждения

Заполните разделы ниже короткими ответами. Если сведений нет, оставьте пометку «нужно уточнить». В шаблоне есть место для одного подробного сценария: его обычно проще обсудить, чем длинный перечень функций без контекста.

1. Проблема и выбранный рабочий процесс.
2. Участники, роли и ограничения доступа.
3. Основной маршрут и исключения.
4. Объекты данных, обязательные поля и источники.
5. Интеграции, перенос информации и тестовые примеры.
6. Функции первой версии и отложенные задачи.
7. Условия эксплуатации и открытые вопросы.
8. Критерии приёмки, этапы и состав передачи.

Что делать, если требований пока мало

Можно ли начать без готового ТЗ? Да. Для первого обсуждения полезны описание процесса, примеры документов и список затруднений. Обследование и подготовку требований можно выделить в самостоятельный этап, прежде чем оценивать всю разработку.

Нужно ли заранее выбирать технологию? Сообщите об ограничениях вашей инфраструктуры и компетенциях команды. Конкретный стек стоит обсуждать после сценариев, данных и условий эксплуатации, если в компании нет обязательного технологического стандарта.

Кто согласует изменения? Назначьте владельца решения со стороны бизнеса. Разработчик поясняет последствия технических вариантов, а владелец процесса подтверждает приоритет и ожидаемый результат. Зафиксируйте согласованную версию документа и сохраняйте историю существенных изменений.

Проверьте документ перед оценкой

Пройдите по ТЗ вместе с сотрудником, который выполняет описанную работу. Попросите показать реальный путь задачи и сравните его с текстом. Часто здесь обнаруживаются неочевидные согласования, дополнительные таблицы и действия при нестандартных случаях.

• Каждая обязательная функция решает названную задачу.
• Понятно, кто получает доступ к данным и меняет их.
• Для внешних систем обозначены возможности и неизвестные условия.
• Первый рабочий маршрут можно проверить от начала до конца.
• У каждого спорного требования есть ожидаемый наблюдаемый результат.
• Открытые вопросы отделены от уже согласованных решений.

Такое ТЗ можно использовать как основу разговора о разработке внутреннего программного обеспечения. После обследования оно будет уточняться. Смысл документа — помочь участникам одинаково понимать задачу и оценивать результат на согласованных условиях.