О разработке технического задания
Зачем нужно ТЗ?
В своей практике я нередко сталкивался с мнением, что техническое задание не нужно, что оно будет только мешать и тормозить процесс разработки, сковывать его. Считаю это крайне неверной позицией. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям (это, как правило, разработчики) выгодно отсутствие ТЗ?
А вот почему:
- Это скрывает отсутствие опыта, слабое представление сути дела, за которое берётся разработчик;
- Это даёт возможность затянуть разработку и увеличить бюджет;
- Это позволит недобросовестному исполнителю безнаказанно урезать объёмы работ, ухудшать характеристики;
- Это позволит исполнителю “левачить” - заниматься другой разработкой в то время, пока заказчик ему платит. Разработчик может выполнять часть работ, якобы нужных для проекта, а потом сдавать их на сторону.
Отсутствие технического задания во взаимоотношениях заказчика и исполнителя - беззаконие. А беззаконие, как вы знаете, рождает хаос, неразбериху, становится причиной жульничества и надувательства. Так что знайте, уважаемые граждане, что тот, кто предлагает работать без оформления отношений, не совсем честен с вами.
Как аргументируют отказ от оформления ТЗ?
Вообще, это забавная тема. Согласитесь, действия ушлых или недалёких персонажей всегда выглядят комично. Отсутствие логики или прямое надувательство, подмена одного другим часто встречаются в жизни, но не сразу распознаются. Возможно, некоторое из того, что я сейчас опишу, вам уже встречалось. Согласитесь, случаи типичны.
Итак, поводов к тому, чтобы отказаться оформлять ТЗ, можно услышать множество:
- Задача такая сложная и такая “творческая”, что её невозможно загнать в рамки ТЗ!
Глупость… Вы знаете, что технические задания составляются даже на произведения искусства? На памятники, рисунки, логотипы, мелодии, даже на мультяшные персонажи. И в этом нет ничего удивительного. Всё поддаётся формализации и описанию. Лишь непрофессиональный человек не сможет описать свою работу или создаваемый продукт.
- Написание ТЗ займёт много времени и ресурсов. Уж лучше взяться потихонечку за работу, а там - определимся!
Отговорка нерадивого человека… Профи потратит на ТЗ от одного до нескольких дней. Где надо - заложит ресурсы на изыскания, а где - чётко определит выполняемое. Только плохо разбирающийся в проблеме человек не сможет заранее всё предугадать.
- ТЗ не нужно, поскольку задача слишком очевидна и проста!
Ловушка, поставленная профессиональным лентяем… Ну если там всё так просто, то опиши, дорогой, эту простоту на 1-2 листах! “Дорогой” сразу же сникнет, поскольку станет очевидно, что выползет множество нюансов, требующих уточнения. И элементарная проблема в ходе детальной проработки сразу станет сложной и серьёзной. Кстати, такой ход используется для того, чтобы потом растянуть сроки, вытянуть больше денег, когда возникнут “непредвиденные трудности”.
Увы, чаще всего встречал подобные “отговорки” среди программистов. За всю свою практику исключение составил всего один человек. Он - крупный специалист в своей области. Без обсуждений взялся за написание ТЗ и составил его лаконично, грамотно, определённо. Человек, почти полтора десятка лет занимающийся программированием, составил безупречное ТЗ на сложнейший программный продукт.
Приведу другой пример, когда один “крупный деятель”, применяя все приведённые выше отговорки, так затянул процесс разработки программного обеспечения, что все окружающие просто диву давались! Отмечу, что проект, начатый более трёх лет тому назад, до сих пор не закончен. И непонятно, на какой стадии находится эта разработка. Удивительное попустительство работодателя в вопросе составления ТЗ и написания планов практически похоронило проект и громадную кучу денег. А тот “крупный деятель” занимается попутным самообразованием за счёт работодателя и откровенным бездельем.
Кто должен писать техническое задание?
Ответ на этот вопрос однозначен - разработчик. Другого не дано. Только он способен грамотно представить цели, сформулировать задачи. Если цели неясны, то происходит итеративный процесс написания ТЗ - разработчик постепенно формирует цель в глазах заказчика, пытается понять его субъективный взгляд на проблему. Это трудный и длительный процесс, но он поможет избежать двусмысленностей и непонимания.
Но из правил есть исключения. Мой личный опыт показал, что есть категории исполнителей, неспособных писать технические задания. Я это отношу к специфике занятий и людей. И хоть ты расшибись, но эти категории граждан вам ТЗ не родят. Не обижайтесь, перечисляю в порядке убывания способности НЕ написать техническое задание:
- Дизайнеры;
- Web-программисты;
- Программисты.
Как довод, приведу ссылку на статью “Жизнь без технического задания” (Олег Бунин, Компьютерра). В статье даже приводятся пути решения задач без оформления ТЗ. Надо сказать, интересный подход, но, как мне кажется, таящий в себе массу выше описанных проблем.
Или вот, жизненный пример - советы и рекомендации по составлению технического задания. Люди, занимающиеся созданием сайтов, предлагают решать заказчику следующие задачи:
1. Постановка задачи: какие задачи должен решать сайт.
2. Определение общего бюджета финансирования: сколько денег Заказчик может или готов заплатить за сайт.
3. Подготовка материалов для сайта.
4. Разработка технического задания на создание сайта.
Далее специалисты приводят последовательность действий, которую должен осуществить заказчик. Вдумайтесь в написанное! В конце рекомендаций специалисты дают примечание:
Профессиональному Разработчику техническое задание, как таковое, не требуется: он и без него знает, как создать сайт.
Но Разработчик будет создавать дизайн сайта, руководствуясь принципом “клиент всегда прав”.
Тем более что деньги платит клиент. Разработчик не несет ответственности за несоответствие сайта эстетическим ожиданиям Заказчика при условии выполнения технического задания на разработку дизайна сайта.
Следовательно, техническое задание требуется, в первую очередь, для самого Заказчика. Именно на основании утвержденного им технического задания он и должен производить приёмку готового сайта.
Не правда ли, гениально?!?! “ТЗ нужно заказчику, а не разработчику” “Разработчик не несёт ответственности…”
Вот более конструктивный подход: Как правильно составить техническое задание? Не очень много, но по делу.
Надеюсь, уважаемые читатели всё поняли. Когда встаёт вопрос о сложной технической разработке, за написание ТЗ берётся исполнитель. Чем “проще тема”, тем труднее исполнителю составить ТЗ. Это нужно понимать. Лично я допускаю, что на некоторые виды работ техническое задание должно писаться заказчиком, иначе последний рискует потерять много денег и не получить того, что хотел.
Что должно содержать техническое задание?
Определённых рекомендаций по тому, что должно содержать ТЗ, нет. Для тех ТЗ, которые пишутся исполнителем, (технические разработки) существует ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.
Нет стандарта, который бы описывал создание ТЗ для других систем (не автоматизированных). Но ряд исследователей всё равно предлагает отталкиваться именно от указанного стандарта при написании технических заданий в других областях человеческой деятельности (в частности, на программные продукты).
Как видно, стандарт этот был принят в стране, которой уже нет, в строе, которого уже не существует, людьми, которые не были знакомы с современными реалиями. Не спорю, стандарт конструктивен и написан достаточно обобщённо, поэтому его вполне можно применить для написания ТЗ (если этого требует госзаказчик).
Но ведь к вам никто не придёт и не оштрафует за то, что в своей организации вы составили ТЗ по собственной, удобной для вас форме! Нужно учитывать специфику своего предприятия, законодательства, рыночных условий. Поэтому постарайтесь подойти к написанию ТЗ как можно более серьёзно, возможно, с привлечением юриста.
Отмечу ряд требований, которые, по моему мнению, должны выполняться в техническом задании:
- Полнота - как можно более полное описание системы, целей и задач;
- Логичность - описания не должны быть противоречивыми
- Правильность - отсутствие ошибок, которые могут вести к двусмысленности или некорректности;
- Связность - структура документа должна быть подчинена одной цели.
Состав разделов разработчик должен выработать сам, с годами и опытом. Но обращу внимание на основные разделы технического задания, которые в той или иной степени должны быть отражены:
- Технические требования и стандарты;
- Структура;
- Функциональное содержание отдельных структурных элементов;
- Состав работ и сроки выполнения;
- Стоимость работ.
Если в техническом задании были описаны указанные моменты, то его можно считать достаточно полным.
Как уже говорилось выше, исключений много. Есть ряд сфер деятельности, в которых к написанию ТЗ нужно подходить по-особому. Кому интересно, советую прочесть статью Техническое задание для дизайнера. Название статьи говорит само за себя.
Проблема технических заданий - интересный пример постановки задачи при составлении ТЗ на сайт.
Что такое «хорошее» ТЗ на сайт? - еще одна статья, помогающая понять, что же это все-таки за зверь -ТЗ.
Составление технического задания сайта - содержание технического задания с комментариями по каждому разделу. Обстоятельно, подробно.
Очень большой список примеров технических заданий на разработку сайтов. Посмотрите, но относитесь к приведённому критически, с осознанием того, что идеального шаблона для вашего конкретного случая не существует и большинство приведенных работ годятся для "ширпотребных" сайтов. Для серьезных проектов стоит все-таки привлекать профессионального аналитика
Статья взята с сайта Beta с небольшими корректировками