Заказчику не нужно описывать базы данных, API и кнопки интерфейса. Для хорошего старта важнее показать, как компания работает сегодня, какие роли участвуют и где процесс дает сбой.
Не начинайте ТЗ со списка экранов
Типичная попытка подготовиться к разработке внутреннего портала выглядит так: «Нужна главная, проекты, сотрудники, финансы, документы и отчеты». Это полезный список направлений, но по нему невозможно понять, как должна работать система.
Два бизнеса могут одинаково назвать раздел «Проекты», но внутри иметь совершенно разную логику. В одном проект начинается после подписания договора и закрывается актом. В другом он включает предварительную смету, бронирование ресурсов, подрядчиков, несколько дат проведения и фактическую маржу.
Поэтому заказчику полезнее описывать не интерфейс, а движение работы.
Возьмите один реальный проект
Не пытайтесь сразу формализовать всю компанию. Выберите недавний типичный проект и восстановите его путь по фактам.
Запишите:
- Откуда появилась заявка.
- Какие данные получили на старте.
- Кто принял решение продолжать работу.
- Где считалась стоимость.
- Какие документы создавались.
- Кто и что согласовывал.
- Какие задачи возникли после подтверждения.
- Как фиксировались расходы и оплаты.
- По какому признаку проект считался завершенным.
Рядом укажите инструменты: Excel, почта, CRM, Telegram, 1С, облачный диск. Получится намного более полезная основа, чем описание будущих кнопок.
Опишите роли, а не должности
Система должна понимать, что пользователю разрешено видеть и делать. Для этого недостаточно штатного расписания.
Например, «менеджер» в одной компании создает смету и согласует подрядчика, а в другой только ведет коммуникацию с клиентом. Финансист может видеть все проекты, но не редактировать их содержание. Руководитель подразделения — только свою команду.
Для каждой роли ответьте на три вопроса:
- какие данные человек должен видеть;
- какие действия может выполнять;
- что требует дополнительного согласования.
Это поможет спроектировать права доступа раньше, чем они станут проблемой безопасности.
Приложите реальные файлы
Если процесс сейчас работает в таблице, пришлите таблицу. Если используется шаблон договора, смета или форма отчета — их тоже лучше показать. Даже неудобный текущий документ содержит важную информацию: поля, формулы, справочники, исключения.
Не нужно предварительно приводить файлы в порядок специально для разработчика. Наоборот, исходный вид помогает увидеть, где сотрудники вынуждены использовать цвет ячейки, комментарии или дополнительные вкладки вместо нормальной структуры данных.
На формах BUREAU X можно приложить PDF, DOCX, XLSX или текстовый файл прямо к заявке.
Обязательно расскажите про исключения
Идеальный сценарий обычно понятен: создали проект, выполнили, закрыли. Сложность находится в ситуациях «иногда».
Например:
- клиент меняет объем после согласования;
- проект отменяется после предоплаты;
- один ресурс участвует в двух проектах в разные часы одного дня;
- подрядчик прислал документы после закрытия проекта;
- оплату разбивают на несколько частей;
- один сотрудник временно заменяет другого.
Если эти случаи не обсудить, система будет хорошо выглядеть на тестовых данных и мешать в реальной работе.
Разделите обязательное и желательное
Почти в каждом обсуждении появляются функции, которые «было бы хорошо иметь». Их нельзя смешивать с тем, без чего первый рабочий процесс не запускается.
Мы используем простой принцип: первый релиз должен позволять пройти ключевой процесс полностью, пусть без дополнительного комфорта. Например, создать проект, собрать смету, назначить ответственных, прикрепить документы и увидеть финансовый результат.
Расширенная аналитика, дополнительные представления, автоматизация редких исключений и интеграции можно добавлять после проверки основы.
Такой подход снижает стоимость первой ошибки. Если на реальной работе выяснится, что статусная модель выбрана неудачно, ее дешевле поменять до подключения десяти дополнительных модулей.
Не описывайте техническую архитектуру за разработчика
Заказчик может знать, что ему нужен обмен с 1С или вход сотрудников по корпоративной учетной записи. Но выбирать таблицы базы данных, фреймворк или способ хранения сессий — задача технической команды.
В хорошем техническом задании бизнес формулирует ограничения: где размещаются данные, сколько пользователей, какие требования к доступности, какие системы нужно связать, какие данные особенно чувствительны.
А разработчик превращает эти ограничения в архитектуру и объясняет последствия выбора.
Минимальный набор материалов перед первой встречей
Если собрать короткий пакет, достаточно пяти вещей:
- пример одного проекта или заказа;
- список ролей;
- основные файлы и шаблоны;
- перечень сервисов, которые используются сейчас;
- пять самых болезненных проблем процесса.
Если этого нет, не откладывайте разговор. Нужный контекст можно собрать совместно. Наш Конструктор как раз рассчитан на ситуацию, когда технического задания еще нет.
Для понимания результата можно посмотреть кейс внутреннего портала EVENT86, где в одну систему связаны проекты, сметы, финансы, документы и ресурсы.