Кому же нужно, это самое, ТЗ?

Заказчики → Кому же нужно, это самое, ТЗ?

Глобально я сталкивался с тремя видами ТЗ:

1. ТЗ ради бюрократической возни – для того чтобы был подписан договор;
2. ТЗ прикрывающее жопу разработчику;
3. Техдока помогающая успешно реализовать проект;

Да да…  именно так, технического задания  прикрывающего «что бы то ни было» у Заказчика в веб-разработках не существует в природе.

Что бы ни написал в техдоке сам Заказчик, это неизменно будет реализовано только на уровне понимания и внутренних стандартов того разработчика, кто занимается проектом.

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

Вот например такой кейс – http://it-burg.com/text/article/17_martak_bareru_lorri_protiv_ample/

1. ТЗ ради бюрократической возни – для того чтобы был подписан договор.

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

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

Т.е. по сути, Заказчик должен знать технологии и процесс разработки на уровне внутренних стандартов любого крупного авторитетного грамотного разработчика, чтобы документально чуть более защищено для себя сконструировать техдоку. Но даже при таких знаниях визуальная часть – незащищена.

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

Лично я – ни разу. 

Максимум что я видел про типографику в ТЗ – использовать такие-то шрифты… Это то же самое что сказать  – для того чтобы создать  BMW 7 серии пользуйтесь такой-то маркой сталепроката… Как будто марка стали определяет как этот самый BMW будет выглядеть и ездить.

Все, что касается внутренних норм разработки разработчика – это свой устав в своем «монастыре». И у адекватных девелоперов  этот самый «монастырский устав» лежит в портфолио, как наглядный результат каждодневного применения этих самых норм.

2. ТЗ прикрывающее жопу разработчику.

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

Стандартное приложение к договору на создание веб-проекта измеряющее «среднюю температуру по больнице».

Такое ТЗ как и ТЗ первого типа на руку плохому разработчику. На любую претензию по качеству реализации он может смело сказать – «всё согласно ТЗ».

3. Техдока помогающая успешно реализовать проект.

ТЗ в его классическом понимании это бюрократический архаизм никак не регламентирующий деятельность нормального разработчика при работе над проектом.

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

Заставить dev-команду перетащить на бумагу все что она использует в своей каждодневной работе – сравни написанию учебного пособия «Как создавать грамотные веб-проекты». И при этом в головах, все равно, останется бОльшая часть материала.

Описывать в техдоке попсовые очевидности про модули новостей, фотогалереи и прочее – потеря времени.

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

Такая дока пишется всегда совместно заказчиком и разработчиком в средах позволяющих одновременную работу с документами, и нередко – в режиме onflow.  Такая техдока может эволюционировать версиями,  так же как и сам проект.

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

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

nadeyev

Вернуться к списку постов