Я долго думала, как же начать разговор о технических заданиях (которые дальше я буду обозначать общепринятой аббревиатурой «ТЗ»). Дело в том, что мне доводилось видеть разнообразные ТЗ. ТЗ с высоким уровнем абстракции, смысл которых можно свести к: «пользователи должны быть счастливы». ТЗ, которые содержат много-много страниц описания, переливания из пустого в порожнее, и никакой конкретики. ТЗ, которые написаны сказочно-канцелярским языком. В том смысле, что ни в сказке сказать (язык cломаешь), ни пером описать (перо тоже cломаешь), и только принтер выдержит все. Глядя на это многообразие творческого полета мысли возникает вопрос – а что мы понимаем под ТЗ? Что такое ТЗ? 

Беглое изучение открытых источников приводит нас к ГОСТам. Например, ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»  содержит определение достаточно короткое:

«ТЗ на АС (автоматизированную систему) является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

А ГОСТ 25123-82 «Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления» содержит такое определение:

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

И плывут, плывут перед внутренним взором разнообразные ВыПерДосы и прочие наследия минувшей эпохи. Нужны ли они? Пожалуй, что нет. А как обстоит дело с разумными альтернативами? Англоязычные источники не оперируют понятием «техническое задание». Нет дословного перевода, но есть сходные по смыслу понятия. Наиболее используемыми, в обиходе, являются Product requirements document и Statement of Work.

Кстати, при изучении источников подумалось, что англоязычные источники оперируют понятием «требование», что является редуцированным «требование заинтересованной стороны». В таком подходе участвует клиент. В интерпретации русскоязычных источников кроме того, что ТЗ должно быть и при его наличии всем станет лучше и веселее, мало конкретики, кому будет лучше и веселее? Конструкторскому бюро? Исполнителю? Разработчику? Несмотря на формально упоминаемого «заказчика», не совсем понятно, кто именно может выступать в этой роли. Хотя, кажется, я отвлеклась…

И все-таки - что такое техническое задание?

Техническое задание – это документ, который описывает, каким должен быть продукт, чтобы удовлетворить заказчика. ТЗ выполняет несколько функций:

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

Все это может быть объединено под одной вывеской:

ТЗ – это документ, который описывает, как система должна работать в соответствии с идеальными представлениями заказчика.

На вопрос «что?» ответ получен. Идем дальше.

А зачем? Зачем нужно техническое задание?

Поставим себя на место заказчика. Человека осенила идея! В один непрекрасный день у него рука не влезла в банку с огурцами. Не получилось у него достать огурчики. И человек придумал щипцы, назвал их «Достань огурчики», и пошел искать того, кто сможет их сделать. Ему друг подсказал, что воооон там сидят классные ребята, которые могут сделать что угодно, иди к ним. Человек пришел и говорит: «Ребята, а сделайте мне «Достань огурчики». Что ему ответят?

Полученные ответы по смыслу будут примерно такими:

1 «Слушай, идея – супер! Я сам сталкивался с такой проблемой, но не придумал. Делаем! Сколько будет стоить – разберемся, пока делать будем!».

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

3 «Достань огурчики! А как вы думаете достать огурчики? С помощью щипцов, да… А из чего должны быть щипцы? Из металла? Смотрите, металлические щипцы, они же могут окислятся… Да, лучше будет из нержавеющей стали. А какого размера они должны быть?...».

Что произойдет в варианте 1? Скорее всего, человек заплатит и что-то получит. Почти наверняка не то, что он хотел.

Что произойдет в варианте 2? Скорее всего, человек испугается и пойдет искать кого-то другого. И наткнется на вариант 1 или 3.

Что произойдет в варианте 3? Человек получит то, что он хотел, но при этом ему зададут тучу вопросов. Для чего? Для того чтобы сформировать совместное представление о «Достань огурчики» у всех участников: и у обычного человека, которого осенила идея, и у проектировщиков-разработчиков, и у непосредственных исполнителей. Именно для этого и нужно ТЗ.