Было недавно очень много споров вокруг технического задания. Все судили о ТЗ со своей стороны. Я попытался собрать это все в одну лирическую статью.
Что такое техническое задание?
Cогласно Wiki:
Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
Cогласно Яндекс.Словари определение более широкое (первая часть с Wiki повторяется один в один):
…ТЗ содержит технико-экономическое обоснование разработки, основные технические требования, предъявляемые к сооружению или изделию, и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Есть определения ТЗ, которыми все пользуются. Оспаривать определения глупо и бессмысленно: «Об определениях не спорят, о них договариваются»(с).
В этой статье я хочу отойти от определений и приблизиться к реальности разработки сайтов.
Я склонен считать, что техническое задание – это документ. Важно, что на нем ставятся подписи и печати, а значит, имеет юридическую силу и при необходимости к этому можно и нужно прибегнуть.
«Кому надо техническое задание?» – вопрос достаточно сложный. На абзац Выше я написал, что это документ, а значит, он нужен как заказчику, так и исполнителю. Давайте детальнее.
Зачем техническое задание менеджеру? В нем менеджер проекта излагает все касательно разрабатываемого продукта. Это делается из следующих соображений:
- понимать вообще что происходит, т.к. техническое задание включает в себя основание и назначение разработки;
- четкая постановка задачи подчиненным
- знать когда и какой персонал нужен;
- контролировать реализацию;
- контролировать качество;
- оценка продвижения реализации проекта: сколько % уже сделано, сколько осталось, сколько по времени и т.д.;
Обязательно ТЗ надо разработчикам, т.е. дизайнеру, верстальщику, программисту и т.д. Надо оно им только из одного соображения: перед тем как делать, надо четко понимать, что ты делаешь и, что должно быть в результате. Согласно методологии постановки целей S.M.A.R.T, цель должна быть измерима. А это в основном цифры. Вот в техническом задании эти цифры и прописываются. Т.е. если клиент сказал, что «сайт должен загружаться быстро», то в ТЗ это описывается примерно так: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb».
Остается только один вопрос: надо ли техзадание клиенту? Я считаю, что в большинстве случаев – не надо! Техническое задание отдавать клиенту разумно в том случае, если клиент может разобраться в нем. А если контактным лицом со стороны клиента является «девочка-маркетолог», то некоторые разделы она вообще не сможет понять как таковые. В результате Вы, конечно, подпишите с клиентом такое ТЗ, но это будет субъективный документ. С другой стороны клиенты разные и если не зажимать их в рамки технического задания, то они будут пить кровь очень долго и мучительно. Тут выбор за Вами.
Что должно быть в техническом задании?
В последнее время часто слышу вопросы: «Техническое задание одно на всех, или по одному на каждого?». На практике я писал и одно на всех и по одному на каждого. Это было что-то вроде эксперимента. Изначально у меня был вопрос: «А как разные люди могут создать что-то одно, опираясь на разные цели/задачи?». Оказалось, что могут.
«Одно ТЗ на всех». Я остался сторонником именно этого подхода. В одном документе описывается, как Сайт должен работать, выглядеть и т.д. Каждый разработчик должен полностью ознакомиться с документом, что бы понимать полную картину. Часто бывает, что ошибки командные, а не чьи-то конкретные, потому и необходимо, что бы команда знала всю картину и не допускала подобные ошибки. Как пример: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb» – этот критерий можно отнести как к дизайнеру, так и к верстальщику. Если в результате страница весит 70К, то дизайнер с верстальщиком могут очень долго играть Вами в футбол.
«По одному на каждого». Как показала практика это самый лучший способ управление проектом, когда команды еще нет. Коллектив есть, а команды нет. Директивный метод управления – классика. Для каждого Вы пишете ТЗ, и каждый его делает. Недостаток подхода в том, что у Вас это занимает очень много времени, которое Вы могли бы потратить на что-то более полезное. Так же Вам приходится изучать нюансы работы каждого, а быть дизайнером, верстальщиком, программистом в одном лице – это плохо, и уж явно это не проектный менеджер в веб-студии.
Не зависимо от «одно на всех или по одному на каждого», ребром всегда становится вопрос детализации технического задания. Тут спорить можно очень долго и безнадежно. Потому что детализация технического задания напрямую зависит от квалификации персонала. На примере программиста: если программист знает спецификацию формата CSV-файлов, то можно не углубляться в технологию как его правильно парсить. И наоборот.
Идеальное техническое задание – миф или реальность?
Нельзя линейкой измерить идеальность. Должны быть критерии. Пока критериев нет – это провокационный вопрос.
Техническое задание и другие документы.
Наряду с техническим заданием обычно подписываются и другие документы. Однозначно подписывается договор. Возможно, подписывается календарный план, который согласно ГОСТ 19.201-78 уже, в каком-то виде, есть в ТЗ и описывается в разделах: стадии и этапы разработки, порядок контроля и приемки. Осталось добавить даты и все.
Часто в техзадании описывается концепция проекта и многие другие – НЕНУЖНЫЕ – вещи. Концепция проекта имеет совершенно другое назначение и потому не стоит включать концепцию в техническое задание. О том, что такое концепция и чем она отличается от ТЗ можно узнать из замечательного топика на Хабре.
В последнее время начал усиленно интересоваться проектной документацией. Всякого рода технические задания, постановки задачи, календарные планы, расчеты бюджета и т.д.