С чего начать составление грамотного технического задания

1. Прежде, чем составлять техническое задание, пользователь должен понять, что именно он хочет получить. 5. Избавиться в техническом задании от расплывчатых описаний, лишних слов, слов-паразитов.


ГОСТ 25123-82. Через некоторое время, можно будет устроить «ярмарку идеальных технических задний». На дизайн, если к нему есть особые требования, составляется отдельное Творческое задание. У каждого свой язык, один ожидает сценарии, второй картинки, третий диаграммы, четвёртый иерархический реестр и т.д.

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

С чего начать составление грамотного технического задания

7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки. 9. Помните, что ваше задание будет служить справочником для вас — в нем всегда можно посмотреть описание информации, вспомнить забытое требование.

Мне будет очень интересно узнать (и увидеть), что по мнению других хабрапользователей значит «идеальное ТЗ». Ссылку на собственный вариант ТЗ можно написать в комментарий. То, что у вас — это не требования к дизайну, а описание прототипа. Вообще, на ТЗ для ПО есть ГОСТы, там все толково, хотя часть разделов и избыточна (требования к упаковке, маркировке или там транспортивке).

Вашему ТЗ — разработчики могут написать блог в котором не будет капчи (в ТЗ нет) даже на регистрацию и не будет ограничения на частоту постинга (в ТЗ нет), что приведет к заспамливанию.

Как составить техническое задание: советы из личного опыта

Потому что в общем случае очень тяжело и дорого доказать полноту требований. Хорошим ТЗ является то, в котором записаны 95% процентов всех требований, которые в принципе нужны для создания правильного результата.

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

В предложении «имя пользователя может состоять из букв и пробела» забыты все прелести юникода (там такие буквы есть…). Инфраструктурная часть вообще не затронута (оно работает на компьютере разработчика, требования ТЗ выполнены — а что у вас нет libfofudya-1.0alpha3 — в тз про дистрибуцию ничего не было сказано). Следует определить цель задания, ключевые особенности желаемого результата, нарисовать (написать, создать таблицу) для себя желаемый выход работы.

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

ТЗ — не только инструмент разрешения конфликтов между заказчиком и исполнителем

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

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

Продукция производственно-технического назначения. А для технического проекта 300 листов не предел. Задание на проект – это документ и лексика в нем должна быть соответствующая. Дата подписания: рекомендуется подписать техническое задание не позднее чем за 10 календарных дней до предполагаемой даты утверждения извещения и (или) документации о закупке.

Похожие материалы: