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

Техническое задание - закон для разработчика. В процессе разработки - основной документ, которым он должен руководствоваться. Этот документ призван:
описать цель работы. И разработчик, и заказчик должны чётко понимать, к чему они стремятся, за что один платит деньги, а другой - тратит время и напрягает мозги;
описать задачи. Прежде чем начинать работу, необходимо прикинуть, насколько она затянется, сколько потребует ресурсов. Круг задач должен быть посильным разработчику, а заказчик должен представлять, чем разработчик будет заниматься, за что платить;
регламентировать отношения. Один из самых важных моментов! Заказчик и исполнитель регламентируют объёмы, сроки, денежные суммы, порядок приёмки, форматы исходных и выходных данных и ещё множество условий, которые необходимо прописать во избежание конфликтных ситуаций.

По сути, техническое задание - договор между исполнителем и заказчиком. Договор, естественно, должен быть в рамках законодательства, иначе его можно будет признать ничтожным. Стороны, создающие и подписывающие договор (техническое задание) должны полностью осознавать все его пункты и вправе вносить любые свои требования, которые сочтут нужными.

Всё, что я сказал выше - результат моего собственного опыта и накопленных знаний. Я попытался сформулировать своё понимание сути технического задания. То, как я вижу этот документ в реальных современных условиях. Далее попытаюсь прокомментировать сказанное и проанализировать ошибки разработчиков и заказчиков, вызванные непониманием сути Технического задания (ТЗ).

Зачем нужно ТЗ?

В своей практике я нередко сталкивался с мнением, что техническое задание не нужно, что оно будет только мешать и тормозить процесс разработки, сковывать его. Считаю это крайне неверной позицией. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям (это, как правило, разработчики) выгодно отсутствие ТЗ? А вот почему:
Это скрывает отсутствие опыта, слабое представление сути дела, за которое берётся разработчик;
Это даёт возможность затянуть разработку и увеличить бюджет;
Это позволит недобросовестному исполнителю безнаказанно урезать объёмы работ, ухудшать характеристики;
Это позволит исполнителю “левачить” - заниматься другой разработкой в то время, пока заказчик ему платит. Разработчик может выполнять часть работ, якобы нужных для проекта, а потом сдавать их на сторону.

Отсутствие технического задания во взаимоотношениях заказчика и исполнителя - беззаконие. А беззаконие, как вы знаете, рождает хаос, неразбериху, становится причиной жульничества и надувательства. Так что знайте, уважаемые граждане, что тот, кто предлагает работать без оформления отношений, не совсем честен с вами.

Как аргументируют отказ от оформления ТЗ?

Вообще, это забавная тема. Согласитесь, действия ушлых или недалёких персонажей всегда выглядят комично. Отсутствие логики или прямое надувательство, подмена одного другим часто встречаются в жизни, но не сразу распознаются. Возможно, некоторое из того, что я сейчас опишу, вам уже встречалось. Согласитесь, случаи типичны.

Итак, поводов к тому, чтобы отказаться оформлять ТЗ, можно услышать множество:
Задача такая сложная и такая “творческая”, что её невозможно загнать в рамки ТЗ!

Глупость… Вы знаете, что технические задания составляются даже на произведения искусства? На памятники, рисунки, логотипы, мелодии, даже на мультяшные персонажи. И в этом нет ничего удивительного. Всё поддаётся формализации и описанию. Лишь непрофессиональный человек не сможет описать свою работу или создаваемый продукт.
Написание ТЗ займёт много времени и ресурсов. Уж лучше взяться потихонечку за работу, а там - определимся!

Отговорка нерадивого человека… Профи потратит на ТЗ от одного до нескольких дней. Где надо - заложит ресурсы на изыскания, а где - чётко определит выполняемое. Только плохо разбирающийся в проблеме человек не сможет заранее всё предугадать.
ТЗ не нужно, поскольку задача слишком очевидна и проста!

Ловушка, поставленная профессиональным лентяем… Ну если там всё так просто, то опиши, дорогой, эту простоту на 1-2 листах! “Дорогой” сразу же сникнет, поскольку станет очевидно, что выползет множество нюансов, требующих уточнения. И элементарная проблема в ходе детальной проработки сразу станет сложной и серьёзной. Кстати, такой ход используется для того, чтобы потом растянуть сроки, вытянуть больше денег, когда возникнут “непредвиденные трудности”.

Увы, чаще всего встречал подобные “отговорки” среди программистов. За всю свою практику исключение составил всего один человек. Он - крупный специалист в своей области. Без обсуждений взялся за написание ТЗ и составил его лаконично, грамотно, определённо. Человек, почти полтора десятка лет занимающийся программированием, составил безупречное ТЗ на сложнейший программный продукт.

Приведу другой пример, когда один “крупный деятель”, применяя все приведённые выше отговорки, так затянул процесс разработки программного обеспечения, что все окружающие просто диву давались! Отмечу, что проект, начатый более трёх лет тому назад, до сих пор не закончен. И непонятно, на какой стадии находится эта разработка. Удивительное попустительство работодателя в вопросе составления ТЗ и написания планов практически похоронило проект и громадную кучу денег. А тот “крупный деятель” занимается попутным самообразованием за счёт работодателя и откровенным бездельем.

Кто должен писать техническое задание?

Ответ на этот вопрос однозначен - разработчик. Другого не дано. Только он способен грамотно представить цели, сформулировать задачи. Если цели неясны, то происходит итеративный процесс написания ТЗ - разработчик постепенно формирует цель в глазах заказчика, пытается понять его субъективный взгляд на проблему. Это трудный и длительный процесс, но он поможет избежать двусмысленностей и непонимания.

Но из правил есть исключения. Мой личный опыт показал, что есть категории исполнителей, неспособных писать технические задания. Я это отношу к специфике занятий и людей. И хоть ты расшибись, но эти категории граждан вам ТЗ не родят. Не обижайтесь, перечисляю в порядке убывания способности НЕ написать техническое задание:
Дизайнеры;
Web-программисты;
Программисты.

Это те категории работников, с которыми мне довелось столкнуться. Скорее всего, уважаемые читатели смогут продолжить список или откорректировать его по-своему. Кому захочется это сделать - прошу комментировать статью или высказываться на Форуме Берлоги Инженера.

Как довод, приведу ссылку на статью “Жизнь без технического задания” (Олег Бунин, Компьютерра). В статье даже приводятся пути решения задач без оформления ТЗ. Надо сказать, интересный подход, но, как мне кажется, таящий в себе массу выше описанных проблем.

Или вот, жизненный пример - советы и рекомендации по составлению технического задания. Люди, занимающиеся созданием сайтов, предлагают решать заказчику следующие задачи:

1. Постановка задачи: какие задачи должен решать сайт.
2. Определение общего бюджета финансирования: сколько денег Заказчик может или готов заплатить за сайт.
3. Подготовка материалов для сайта.
4. Разработка технического задания на создание сайта.

Далее специалисты приводят последовательность действий, которую должен осуществить заказчик. Вдумайтесь в написанное! В конце рекомендаций специалисты дают примечание:

Профессиональному Разработчику техническое задание, как таковое, не требуется: он и без него знает, как создать сайт.
Но Разработчик будет создавать дизайн сайта, руководствуясь принципом “клиент всегда прав”.
Тем более что деньги платит клиент. Разработчик не несет ответственности за несоответствие сайта эстетическим ожиданиям Заказчика при условии выполнения технического задания на разработку дизайна сайта.
Следовательно, техническое задание требуется, в первую очередь, для самого Заказчика. Именно на основании утвержденного им технического задания он и должен производить приёмку готового сайта.

Не правда ли, гениально?!?! “ТЗ нужно заказчику, а не разработчику” “Разработчик не несёт ответственности…”

Вот более конструктивный подход: Как правильно составить техническое задание? Не очень много, но по делу.

Надеюсь, уважаемые читатели всё поняли. Когда встаёт вопрос о сложной технической разработке, за написание ТЗ берётся исполнитель. Чем “проще тема”, тем труднее исполнителю составить ТЗ. Это нужно понимать. Лично я допускаю, что на некоторые виды работ техническое задание должно писаться заказчиком, иначе последний рискует потерять много денег и не получить того, что хотел.

Что должно содержать техническое задание?

Определённых рекомендаций по тому, что должно содержать ТЗ, нет. Для тех ТЗ, которые пишутся исполнителем, (технические разработки) существует ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.

Нет стандарта, который бы описывал создание ТЗ для других систем (не автоматизированных). Но ряд исследователей всё равно предлагает отталкиваться именно от указанного стандарта при написании технических заданий в других областях человеческой деятельности (в частности, на программные продукты).

Как видно, стандарт этот был принят в стране, которой уже нет, в строе, которого уже не существует, людьми, которые не были знакомы с современными реалиями. Не спорю, стандарт конструктивен и написан достаточно обобщённо, поэтому его вполне можно применить для написания ТЗ (если этого требует госзаказчик).

Но ведь к вам никто не придёт и не оштрафует за то, что в своей организации вы составили ТЗ по собственной, удобной для вас форме! Нужно учитывать специфику своего предприятия, законодательства, рыночных условий. Поэтому постарайтесь подойти к написанию ТЗ как можно более серьёзно, возможно, с привлечением юриста.

Отмечу ряд требований, которые, по моему мнению, должны выполняться в техническом задании:
Полнота - как можно более полное описание системы, целей и задач;
Логичность - описания не должны быть противоречивыми
Правильность - отсутствие ошибок, которые могут вести к двусмысленности или некорректности;
Связность - структура документа должна быть подчинена одной цели.

Такое ощущение, что я этот текст где-то видел.

Вот тут : ссылка

Непонятно для чего было все это?

По опыту, удобно составить некий опросник-анкету, который клиент заполнит и подпишет.
80% проектов можно вписать в стандартизированный опросник, те проекты, которые "нестандартные" обычно оказываются либо проблемные либо убыточные.
(клиент зачастую платит меньше чем нужно потратить на разработку чего то нового и неизвестного раньше)
Поэтому разумный выход - написать опросник, в который вписать пункты, которые легко выполнить, а если проект не влазит в стандартный опросник, то от него лучше просто отказаться.

А по-моему, отказываться надо как раз от стандартных

Со статьей не согласен категорически.

1. В подавляющем большинстве случаев в отсутствии ТЗ виноват не исполнитель, а сам заказчик. Именно заказчику или некогда или лень тратить время на это, или же ему жаль денег на оплату ТЗ, чтобы его сделали другие.

2. Написать хорошее ТЗ (и утвердить все его нюансы с заказчиком) на средний проект объемом 300-500 человеко-часов занимает вовсе не 1-2 дня, а минимум неделю, обычно более. Также возможно потребуется провести некоторые ресечи, которые могут отнять значительное время. Никакой профессионал не будет это делать бесплатно. В среднем, ТЗ стоит от 400 USD и выше, а многим заказчикам жаль этих денег, вот и стартуют проект без ТЗ, лишь с кратким описанием задачи.

3. Автор статьи считает, что работать без ТЗ - преступление. Это не так. Написать ТЗ не всегда возможно. Например, на саппортные работы по сайту, исправление списка дефектов из багтреккера, и т.д. Как в этом случае быть? Да и часто бывает, когда заказчик сам не знает всего что нужно будет сделать. Поэтому существует ряд признанных методологий, которые позволяют работать без ТЗ, например - AGILE.

В общем, вывод, статья - очень однобокий примитивный взгляд на проблему.

Правильно, за ТЗ нужно платить. Это по сути проект будущего сайта. Кто вам сделает проект дома бесплатно? вот и за проект сайта нужно платить.