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