Прочитал статью Станислава Малкина - Для клиентов: при отсутствии технического задания .
В целом все написано правильно, последовательно и четко.
Сделан очевидный вывод – ТЗ быть! (Однозначно! Я это сказал! Жириновский) И, по мнению Станислава, он должен быть в трёх направлениях:
- Техническое задание писал сам заказчик.
- Техническое задание написал разработчик заказанной системы.
- Техническая спецификация написана профессиональным писателем технических спецификаций.
Давайте пока пропустим второй вариант и перейдем сразу к третьему.
Насколько можно судить по статье, Станислав считает этот вариант наиболее приемлемым, особенно для начинающих клиентов.
Однако недостатков я вижу гораздо больше, чем указано в статье (по сути, единственный указанный недостаток — это дополнительные затраты на написание технического задания):
- Качество.
На основании чего заказчик сможет судить, насколько качественно написано техническое задание.Четких критериев оценки нет. Да, существуют всякие ГОСТы для написания технических условий, но они очень быстро устаревают, а для интернет-технологий могут носить лишь рекомендательный характер.
Но ГОСТы не позволяют определить качество написанного технического задания.
- Время.
Чтобы написать качественное техническое задание, технический писатель должен достаточно изучить предметную область.В чем здесь минус, спросите вы - а минус в том, что как бы качественно, а точнее подробно, не было написано техническое задание, конечному разработчику придется потратить на изучение столько же времени.
- Стандарты.
Общих стандартов нет. ГОСТы есть, никто не спорит, но ГОСТы скорее определяют формат документа, а не содержание и форму.Представим ситуацию — заказчик приходит к разработчику с техническим заданием, написанным третьей стороной.
Если разработчик не новичок, у него уже должна быть своя внутренний корпоративный стандарт написание технического задания.
Естественно, принесенное ТЗ не будет ему соответствовать и, скорее всего, разработчик начнет настаивать на том, чтобы не переписывать ТЗ под свой стандарт, под свои привычки.
Наверняка представленное техническое задание будет дополняться и расширяться, чтобы оно было понятно конечному разработчику.
В целом на этом этапе заказчик потеряет время, деньги и нервы.
- Большой брат.
Как должен вести себя заказчик, если, принеся написанное кем-то техническое задание, конечный разработчик говорит: «Кто вам эту фигню написал? Это фигня! Вот как мы это видим.
»?Эффект от такого варианта написания ТЗ может быть противоположным - заказчик не только не сэкономит свои нервы, время и в целом деньги (имея хорошее ТЗ экономит деньги - поверьте мне на слово :)), но и может серьезно ухудшить отношения с разработчиком.
В этом случае, скорее всего, все будут довольны.
Хотя практика показывает, что разработчики исключают третью сторону (технического писателя) и составляют техническое задание самостоятельно, естественно с участием заказчика.
И напоследок несколько ссылок: ХабраХабр ТК: макеты или текст? Техническое задание для веб-разработчика О ГОСТах Как написать техническое задание?! Классический Юрий Шиляев - Что такое хорошая техническая спецификация для веб-сайта? Перекрестный пост из моего блога.
Теги: #техническое задание #техническое задание #документация #Управление проектом #Подготовка технической документации
-
Google Запустил Рекламную Кампанию В Рунете
19 Oct, 24 -
Юмор: Перезагрузка Сервера
19 Oct, 24
