Техническое задание

Техническое задание - в поисках истины

Было недавно очень много споров вокруг технического задания. Все судили о ТЗ со своей стороны. Я попытался собрать это все в одну лирическую статью.

Что такое техническое задание?

Cогласно Wiki:

Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).

Cогласно Яндекс.Словари определение более широкое (первая часть с Wiki повторяется один в один):

…ТЗ содержит технико-экономическое обоснование разработки, основные технические требования, предъявляемые к сооружению или изделию, и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Есть определения ТЗ, которыми все пользуются. Оспаривать определения глупо и бессмысленно: «Об определениях не спорят, о них договариваются»(с).

В этой статье я хочу отойти от определений и приблизиться к реальности разработки сайтов.

Я склонен считать, что техническое задание — это документ. Важно, что на нем ставятся подписи и печати, а значит, имеет юридическую силу и при необходимости к этому можно и нужно прибегнуть.

«Кому надо техническое задание?» — вопрос достаточно сложный. На абзац Выше я написал, что это документ, а значит, он нужен как заказчику, так и исполнителю. Давайте детальнее.

Зачем техническое задание менеджеру? В нем менеджер проекта излагает все касательно разрабатываемого продукта. Это делается из следующих соображений:

  • понимать вообще что происходит, т.к. техническое задание включает в себя основание и назначение разработки;
  • четкая постановка задачи подчиненным
  • знать когда и какой персонал нужен;
  • контролировать реализацию;
  • контролировать качество;
  • оценка продвижения реализации проекта: сколько % уже сделано, сколько осталось, сколько по времени и т.д.;

Обязательно ТЗ надо разработчикам, т.е. дизайнеру, верстальщику, программисту и т.д. Надо оно им только из одного соображения: перед тем как делать, надо четко понимать, что ты делаешь и, что должно быть в результате. Согласно методологии постановки целей S.M.A.R.T, цель должна быть измерима. А это в основном цифры. Вот в техническом задании эти цифры и прописываются. Т.е. если клиент сказал, что «сайт должен загружаться быстро», то в ТЗ это описывается примерно так: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb».

Остается только один вопрос: надо ли техзадание клиенту? Я считаю, что в большинстве случаев — не надо! Техническое задание отдавать клиенту разумно в том случае, если клиент может разобраться в нем. А если контактным лицом со стороны клиента является «девочка-маркетолог», то некоторые разделы она вообще не сможет понять как таковые. В результате Вы, конечно, подпишите с клиентом такое ТЗ, но это будет субъективный документ. С другой стороны клиенты разные и если не зажимать их в рамки технического задания, то они будут пить кровь очень долго и мучительно. Тут выбор за Вами.

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

В последнее время часто слышу вопросы: «Техническое задание одно на всех, или по одному на каждого?». На практике я писал и одно на всех и по одному на каждого. Это было что-то вроде эксперимента. Изначально у меня был вопрос: «А как разные люди могут создать что-то одно, опираясь на разные цели/задачи?». Оказалось, что могут.

«Одно ТЗ на всех». Я остался сторонником именно этого подхода. В одном документе описывается, как Сайт должен работать, выглядеть и т.д. Каждый разработчик должен полностью ознакомиться с документом, что бы понимать полную картину. Часто бывает, что ошибки командные, а не чьи-то конкретные, потому и необходимо, что бы команда знала всю картину и не допускала подобные ошибки. Как пример: «Размер страницы без графики, загруженной пользователем, должен составлять не более 50Kb» — этот критерий можно отнести как к дизайнеру, так и к верстальщику. Если в результате страница весит 70К, то дизайнер с верстальщиком могут очень долго играть Вами в футбол.

«По одному на каждого». Как показала практика это самый лучший способ управление проектом, когда команды еще нет. Коллектив есть, а команды нет. Директивный метод управления — классика. Для каждого Вы пишете ТЗ, и каждый его делает. Недостаток подхода в том, что у Вас это занимает очень много времени, которое Вы могли бы потратить на что-то более полезное. Так же Вам приходится изучать нюансы работы каждого, а быть дизайнером, верстальщиком, программистом в одном лице — это плохо, и уж явно это не проектный менеджер в веб-студии.

Не зависимо от «одно на всех или по одному на каждого», ребром всегда становится вопрос детализации технического задания. Тут спорить можно очень долго и безнадежно. Потому что детализация технического задания напрямую зависит от квалификации персонала. На примере программиста: если программист знает спецификацию формата CSV-файлов, то можно не углубляться в технологию как его правильно парсить. И наоборот.

Идеальное техническое задание — миф или реальность?

Нельзя линейкой измерить идеальность. Должны быть критерии. Пока критериев нет — это провокационный вопрос.

Техническое задание и другие документы.

Наряду с техническим заданием обычно подписываются и другие документы. Однозначно подписывается договор. Возможно, подписывается календарный план, который согласно ГОСТ 19.201-78 уже, в каком-то виде, есть в ТЗ и описывается в разделах: стадии и этапы разработки, порядок контроля и приемки. Осталось добавить даты и все.

Часто в техзадании описывается концепция проекта и многие другие — НЕНУЖНЫЕ — вещи. Концепция проекта имеет совершенно другое назначение и потому не стоит включать концепцию в техническое задание.

Реальные кейсы роста продаж
и повышения конверсии!

Узнайте как другие увеличивают продажи на 10%, 30%, 50% или даже в 2 раза!

100% без спама!

  • to Seoart:
    Примеров концепции, к сожалению, нет.

  • to Seoart:
    Примеров концепции, к сожалению, нет.

  • Хорошо написано про ТЗ.
    А примеры описания концепции web проекта у тебя случайно нет?Кроме тех которые выложены на Хабре.

  • Хорошо написано про ТЗ.
    А примеры описания концепции web проекта у тебя случайно нет?Кроме тех которые выложены на Хабре.

  • Дима

    Спасибо за статью. Черпнул для себя немного.

    Всё, что будет написано ниже — ИМХО!

    Хочу подчеркнуть мысли, которые считаю очень правильными, и скажу почему я так считаю.

    > Я считаю, что клиента в любом случае нужно зажимать в рамки!

    — Согласен!
    Но не потому, что клиент плохой или разработчик – лодырь. А потому, что клиент, как правило, нарисовал себе картинку в голове, но на бумаге описать сложно (не возможно), а разработчику угадать не получается (если конечно он не умеет читать мысли).
    Особо тяжелые случаи – «если контактным лицом со стороны клиента является девочка — маркетолог». Это просто нет слов! Давайте логотип в право, шрифт уже, цвет ярче, кнопку толще, чтоб там мигало, тут булькало…. Хм…. Не смотрится…. Давайте оставим шрифт таким как был раньше, логотип выше, кнопки уже…. А подберите вот туда несколько картинок, просто я не знаю как будет смотреться…. Вы знаете, приехал директор, ему не понравилось, нарисуйте еще несколько разных макетов, не похожие на предыдущие….
    (извините, наболело =))
    ——————————-

    > Зачем техническое задание менеджеру?
    — В виде документа, в котором по пунктам расписано, что за чем нужно делать – не надо. Ведь менеджер – это управленец. Он управляет процессом и сам, лучше заказчика знает, что ему нужно делать (если по по хорошему).
    Если в виде конечного задания, в котором описаны общие пожелания – надо. Просто ради того, что менеджер не обязательно в течении 24-х часов, думает об одном проекте. Просто как напоминалка, о общих пожеланиях клиента.
    ——————————-

    > “Техническое задание одно на всех, или по одному на каждого?”
    — Одно на всех. Даешь задание менеджеру, а он в свою очередь сам своей команде расскажет, что нужно делать.
    ——————————-

    > Идеальное техническое задание — миф или реальность?
    — Миф =)
    ——————————-

    > Техническое задание и другие документы.
    — Договор нужен. Желательно описать в нем функциональность сайта.
    Ну например, сайт должен содержать автоматическую ленту новостей. Или сайт на 2-х языках и т.д.
    ——————————-

    > “Об определениях не спорят, о них договариваются”(с).
    — Если приблизится к реальной разработке сайтов, то это очень четко подмечено! Тем более, что, как по мне, терминология, которой пользуется разработчик, может быть не всегда понятна, рядовому бизнесмену…

  • Дима

    Спасибо за статью. Черпнул для себя немного.

    Всё, что будет написано ниже — ИМХО!

    Хочу подчеркнуть мысли, которые считаю очень правильными, и скажу почему я так считаю.

    > Я считаю, что клиента в любом случае нужно зажимать в рамки!

    — Согласен!
    Но не потому, что клиент плохой или разработчик – лодырь. А потому, что клиент, как правило, нарисовал себе картинку в голове, но на бумаге описать сложно (не возможно), а разработчику угадать не получается (если конечно он не умеет читать мысли).
    Особо тяжелые случаи – «если контактным лицом со стороны клиента является девочка — маркетолог». Это просто нет слов! Давайте логотип в право, шрифт уже, цвет ярче, кнопку толще, чтоб там мигало, тут булькало…. Хм…. Не смотрится…. Давайте оставим шрифт таким как был раньше, логотип выше, кнопки уже…. А подберите вот туда несколько картинок, просто я не знаю как будет смотреться…. Вы знаете, приехал директор, ему не понравилось, нарисуйте еще несколько разных макетов, не похожие на предыдущие….
    (извините, наболело =))
    ——————————-

    > Зачем техническое задание менеджеру?
    — В виде документа, в котором по пунктам расписано, что за чем нужно делать – не надо. Ведь менеджер – это управленец. Он управляет процессом и сам, лучше заказчика знает, что ему нужно делать (если по по хорошему).
    Если в виде конечного задания, в котором описаны общие пожелания – надо. Просто ради того, что менеджер не обязательно в течении 24-х часов, думает об одном проекте. Просто как напоминалка, о общих пожеланиях клиента.
    ——————————-

    > “Техническое задание одно на всех, или по одному на каждого?”
    — Одно на всех. Даешь задание менеджеру, а он в свою очередь сам своей команде расскажет, что нужно делать.
    ——————————-

    > Идеальное техническое задание — миф или реальность?
    — Миф =)
    ——————————-

    > Техническое задание и другие документы.
    — Договор нужен. Желательно описать в нем функциональность сайта.
    Ну например, сайт должен содержать автоматическую ленту новостей. Или сайт на 2-х языках и т.д.
    ——————————-

    > “Об определениях не спорят, о них договариваются”(с).
    — Если приблизится к реальной разработке сайтов, то это очень четко подмечено! Тем более, что, как по мне, терминология, которой пользуется разработчик, может быть не всегда понятна, рядовому бизнесмену…