Поэтому в 3red.net мы рассматриваем техническое задание как самостоятельный результат работы. Заказчик должен получить пользу от этого этапа, даже если реализацию продолжит другая команда.
«Нам нужна интеграция» — это начало разговора
За короткой формулировкой могут скрываться совершенно разные задачи.
В одном случае нужно передавать заявки с сайта в CRM. В другом — синхронизировать товары, цены, остатки и заказы между несколькими системами, учитывать изменения и обрабатывать ошибки.
Даже фраза «нужно передавать заказы» оставляет немало вопросов:
- В какой момент начинается передача?
- Какие данные обязательны?
- Что происходит, если принимающий сервис недоступен?
- Как избежать повторного создания одного заказа?
- Где сотрудники увидят ошибку и кто будет её исправлять?
- Как обрабатываются изменения и отмены?
Пока ответов нет, заказчик и разработчик могут обсуждать одну задачу, но представлять разные результаты.
Для интернет-магазина, личного кабинета или автоматизации внутреннего процесса ситуация аналогичная: название проекта ещё не описывает, как он должен работать.
Задача аналитики — обнаружить расхождения до того, как они превратятся в написанный код.
За что платит заказчик
Не за количество страниц и не за документ с формулировкой «система должна быть современной и удобной».
Он оплачивает работу по превращению исходной идеи в согласованную модель будущего решения.
В зависимости от задачи эта работа должна дать ответы на несколько групп вопросов.
Какие сценарии нужно реализовать
Кто будет пользоваться решением? Какие действия должны быть доступны? Что происходит при успешном выполнении операции, а что — при ошибке?
Нам важно описать не только идеальный путь, но и исключения: недоступность сервиса, некорректные данные, повторный запрос, отмену операции.
Как будет работать бизнес
Какие действия выполняются автоматически, а какие остаются у сотрудников? Кто принимает решения? Где меняются данные и кто отвечает за их актуальность?
Разработка должна учитывать процесс целиком, а не только отдельную кнопку или передачу данных.
Как будут взаимодействовать системы
Какие данные передаются между сайтом, CRM, 1С и внешними сервисами? В каком направлении? Какая система является источником конкретных данных?
Недостаточно перечислить названия интеграций. Нужно согласовать правила их работы.
Как будем принимать результат
Что должно работать, чтобы задача считалась выполненной? Какие сценарии проверяем? Что входит в согласованный объём, а что остаётся за его пределами?
Это основа предметного разговора: не «мы ожидали другое», а «вот согласованный сценарий — давайте проверим».
Почему этот этап стоит отдельно
Чтобы ответить на перечисленные вопросы, нашей команде нужно изучить процессы заказчика, разобрать ограничения, обсудить варианты и зафиксировать договорённости.
Эта работа происходит до основной разработки, но от этого не становится бесплатной по своей природе.
Мы выбираем прозрачный подход: отдельно показываем стоимость проработки задачи и отдельно — стоимость реализации.
При этом платная аналитика не означает, что на первом разговоре нельзя обсудить проект или дать предварительный ориентир. Важно не выдавать первоначальное предположение за точную оценку подробно разобранной задачи.
Почему ТЗ не должно привязывать заказчика к нам
Если документ понятен только его автору, заказчику трудно использовать его самостоятельно.
Наш принцип: после оплаченного этапа у бизнеса должен оставаться результат, который можно передать другой команде для изучения и оценки.
Для этого в ТЗ нужны не внутренние сокращения студии, а понятные сценарии, требования, ограничения и зафиксированные решения.
Другой подрядчик может предложить иной способ реализации или задать дополнительные вопросы. ТЗ не обязано исключать любое дальнейшее обсуждение. Но оно должно давать общую точку отсчёта, а не заставлять заново выяснять, что требуется бизнесу.
Мы хотим, чтобы заказчик продолжал работу с нами потому, что ему подходят наша команда и подход, а не потому, что без нас невозможно расшифровать оплаченный документ.
Всем ли нужно подробное ТЗ?
Нет. Для небольшой, понятной доработки бывает достаточно короткой постановки задачи и критериев приёмки. Готовить многостраничный документ ради изменения одной кнопки мы не предлагаем.
Но любая крупная работа требует предварительной проработки: будь то интеграция с внешним сервисом, автоматизация бизнес-процесса, разработка личного кабинета или запуск интернет-магазина.
Важен не тип проекта, а его сложность: сколько систем участвует, какие сценарии нужно учесть, какие есть ограничения и кто отвечает за результат. Чем больше взаимосвязей, тем важнее договориться о них до начала реализации.
Объём ТЗ должен соответствовать задаче:
- для интеграции основной акцент может быть на составе данных, правилах обмена и обработке ошибок;
- для автоматизации — на этапах процесса, ролях сотрудников и исключениях;
- для интернет-магазина — на пользовательских сценариях, каталоге, оформлении заказа и взаимодействии с учётными системами.
При этом ТЗ не гарантирует, что требования никогда не изменятся. Оно фиксирует согласованную отправную точку, относительно которой можно обсуждать изменения, сроки и стоимость.
Для нас смысл отдельного этапа именно в этом: заказчик получает не обещание «во всём разобраться по ходу», а понятное описание того, что мы собираемся создавать и как проверим результат.