Что должно быть в техническом задании: чек-лист

Восемь разделов, без которых документ не работает

1. Процессы «как есть». По шагам, с исполнителями. Без этого раздел «как будет» получается описанием идеальной компании.

2. Процессы «как будет». Что меняется и за счёт чего.

3. Роли и права. Кто работает в системе, что каждому доступно и — отдельно — что недоступно.

4. Функции и экраны. Проверяемыми формулировками: не «удобный список», а «список заказов с фильтром по статусу, дате и менеджеру».

5. Интеграции. С чем обмениваемся, в какую сторону, как часто и что происходит при недоступности второй системы.

6. Данные на старте. Что переносим, откуда, в каком объёме и как сверяем.

7. Нагрузка. Сколько человек одновременно, сколько документов в день, какой объём накопится за три года.

8. Смета и этапы. Сколько стоит и в каком порядке делается.

Девятый раздел: чего в проекте не будет

Его почти никогда не пишут, и именно из-за него проекты выходят за смету.

Мобильное приложение, если делается только веб. Интеграция с маркетплейсом, если о ней говорили, но не считали. Перенос истории за прошлые годы. Обучение второй смены. Доработка 1С на стороне заказчика.

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

Критерии приёмки: как формулировать

Плохо: «система работает быстро», «интерфейс понятный», «отчёты корректные».

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

Разница в том, что второе можно проверить и получить однозначный ответ. Первое проверяется мнением, а мнения у сторон разные — особенно в день оплаты.