ТЗ — что это?
Техническое задание (ТЗ)— это документ, содержащий требования к разрабатываемому проекту.В Техническом задании нет места общим словам, двусмысленностями и неточностям. Именно по этому документу Заказчик будет принимать работу, а Исполнитель выполнять.
Для кого ТЗ?
Техническое задание разрабатывается в первую очередь для Исполнителя (технического специалиста).Многие тут ошибаются и стараются ряд моментов не описывать или описывать в такой форме, что будет понятно заказчику, но вызовет трудности у Исполнителя.
Именно техническому специалисту работать с ТЗ и именно для него разрабатывается документ.
Кто должен подготавливать ТЗ?
Я считаю, что Техническое задание должен готовить Исполнитель.Некоторые члены команды со мной не согласны ))) Готов к жарким обсуждениям за чашечкой кофе. Пишите, звоните, телеграфируйте.
Я аргументирую свое мнение:
- Исполнитель имеет технические компетенции, опыт и сможет адекватнее описать требования к проекту
- Во врем разработки ТЗ Исполнитель погружается в предметную область и начинает лучше в ней разбираться. В этом случае минимизируются риски на недопонимание проекта и лишнюю коммуникацию, чтобы разобраться в предмете разработки.
- Исполнитель заинтересован в качественной проработке ТЗ, потому что ему дальше с ним работать.
- По опыту только 1 из 25 Заказчиков предоставил адекватное ТЗ, по которому можно было выполнить работу. Но даже в этом случае мы со своей стороны адаптировали ТЗ под свой формат, в процессе чего выявилось ряд подводных камней, которые потребовали уточнения и корректировок.
- Заказчик может подготовить только «Проект ТЗ», который будет содержать список основных функций и концептуальное описание проекта. Дальше работа технических специалистов.
Содержание ТЗ
Это очень интересный момент. Совершенству нет предела. Необходимо просто запомнить простую фразу:ТЗ должно содержать только ту информацию, которая влияет на реализацию проекта
Больше всего страдают излишками ненужной информации ТЗ от гос. учреждений. С чем это связано я не знаю, но сколько я не видел таких ТЗ, то
- они очень длинные,
- адекватного текста — 10%,
- по такому ТЗ часто непонятно что надо сделать.
- общее описание проекта (название, цель разработки, задачи);
- структура проекта;
- описание каждого из экранов (состав экрана, прототип (эскизный рисунок экрана),логика функционирования);
- пользовательские сценарии (описание алгоритмов действий пользователей в разных ситуациях);
- требование к функционалу административной панели;
- требования к методами API для взаимодействия с серверной частью;
- другие технические требования к проекту (операционная система, поддерживаемые устройства, используемые технологии для реализации частей проекта, описание математических методов (если это требуется) и др.)
Прототипам ДА или НЕТ
Обязательно необходимо делать прототипы.Все на самом деле просто. Заказчику проще согласовать визуально эскиз экрана чем текст.
Основная ошибка — это не оправдать ожидания Заказчика. Когда он читает текст, то создает себе образ. В 90% случаях образы, которые себе представляют Заказчик и Исполнитель не совпадают. Для синхронизации образов необходимы прототипы.
Эпичная история:
Один из наших Заказчиков в процессе согласования прототипов подумал, что это уже готовый дизайн и утверждал их с такой мыслью. Мы ничего не заподозрили. Но когда мы скинули первые наметки по дизайну, то получили ответ «Зачем нам другой дизайн, нам нравится первый вариант». Мы были сначала в замешательстве и выяснили, что первым вариант дизайна являются прототипы. :) Так и утвердили, но конечно немного все-таки переработав.
Важность ТЗ
Нельзя пренебрегать важностью ТЗ. Уделяйте время на ТЗ столько сколько оно того требует. Не начинайте разработку пока не готов документ.Мы набили кучу шишек по этому поводу:
- делали без ТЗ
- делали с ТЗ, но оно не было ещё утверждено
- делали с ТЗ, но оно не было подробным
- делали ТЗ без прототипов
- делали ТЗ с прототипами, но без описания
- и т.д.
Если вы хотите качественный и ожидаемый результат, то делайте ТЗ.