Рассуждения о проблемах технического задания

[alienator]

> Полное отсутствие стандартов разработки, проектирования и документирования.

Стандарты есть: например, ГОСТ 19.201-78, ГОСТ 34.602-89. Там и про содержание, и про оформление.

Незнание и неумение ими пользоваться — вот это проблема.

[Abductio]

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

[alienator]

Что непонятного-то? Всё по полочкам: цели и задачи, терминология (очень важный пункт, кстати), источники финансирования, самое главное — требования (функциональные, к надежности, к тестированию, даже к патентной чистоте), порядок сдачи-приёма.

Все уже придумано до нас. Бери и пользуйся.

> вызывало у разработчиков стойкое непонимание чего от них хотят

Разработчики не умеют читать список требований? :)

[Abductio]

Хорошо, есть ГОСТы, согласен применение их позволит решить ряд проблем. Вот только вся суть в том, что все и сразу использовать ГОСТ не начнут. К сожалению. Доводилось видеть реакцию на предложение — а давайте писать по ГОСТу. Шарахаются люди от него. Почему не понятно.

[alienator]

А вы просто пишите, и не говорите никому, что это по ГОСТу :)

В общем, в чем собственно проблема — непонятно. Постановщики задач не умеют писать хорошие ТЗ? Разработчики не умеют их читать? Гнать в шею и тех, и тех.

Ну или учить.

[Abductio]

Постановщики задач зачастую задачи ставить не умеют… Не то что писать ТЗ.

Гнать и учить понятно все пытаются. Получается от части. Как я и писал цель топика заставить задуматься тех кто пишет ТЗ о том как они это делают.

[Abductio]

Мне тут подумалось по поводу ГОСТов — они очень общего назначения, а значит не содержат требований относительно сайта. Думается мне, что применение ГОСТа не застрахует от отсутствия в документе структуры сайта или чего-нибудь подобного. Чем плохи универсальные инструменты так это тем, что они решают слишком много задач, но зачастую слишком поверхностно.

[alienator]

> применение ГОСТа не застрахует от отсутствия в документе структуры сайта или чего-нибудь подобного

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

* 1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;
* 2) требования к способам и средствам связи для информационного обмена между компонентами системы;

и так далее.

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

Хотите пользы? Предложите только одну часть ТЗ к обсуждению — терминологию. Если она будет выработана в цельном виде здесь, на хабре, и будет применяться массово — уже большое благо. Я могу порыться в закромах и вытащить тот кусок устоявшейся терминологии, который составлял для шаблонного ТЗ ещё в 2001 году — она хорошо работает до сих пор, хотя уже пора подправить.

А делать структуру сайта (кстати, что это такое? должно быть определено в ТЗ) необходимой составной частью ТЗ — ошибка. Пример — визитка в одну страницу, какая у неё структура?

[Abductio]

Я понял вашу точку зрения, есть над чем подумать.

[nerezus]

Не менее 10-20%(в зависимости от задания) времени и финансирования проектов — в ТЗ. Иначе выйдет и дольше, и дороже.

[Wott]

Мутно как-то и не по делу.

ТЗ имеет вполне определенные задачи и исходить надо от них. Стиль документа конечно хорошо, но правильный по смыслу plain text намного лучше хорошо стилизованной воды.

А ТЗ должен, как часть контракта, необходимо и достаточно описывать содержание проекта как для понимания исполнителем задачи, так и для принятия работ заказчиком. В хорошем случае ТЗ составляется из дизайна системы. В плохом дизайн по ТЗ. По ТЗ составляются методика для приемо-сдаточных испытаний, которая тоже должна быть частью контракта :)

При этом в ТЗ не иметь ничего лишнего и неопределенного. Любое определение — повод заказчика требовать с исполнителя работы. «Система должна ...» и далее пара общих фраз легко может увеличить обьем работ в н-цать раз :)

[Abductio]

В хорошем случае ТЗ составляется из дизайна системы

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

ТЗ имеет вполне определенные задачи и исходить надо от них. Стиль документа конечно хорошо, но правильный по смыслу plain text намного лучше хорошо стилизованной воды.

Безусловно лучше, а правильный по смыслу и хорошо структурированный еще лучше. Лучшее конечно враг хорошего.

[lamaz]

Все проблемы из-за неквалифицированных специалистов. ГОСТы есть, в университетах писать ТЗ учат, что ещё надо. Литературу можно почитать, например www.intuit.ru/department/itmngt/analisis/

[soves]

Большинство заказчиков формулирует ТЗ как: «Хотим сайт, как у компании Х, но без 1-2-3-4-5 и с 6-7-8-9». Поэтому если Вы строите сайты, проще один раз написать перечень требований к сайту (в виде анкеты) для заказчика. По итогам обработки анкеты Вы сможете выдавать заказчику проект ТЗ. Это ускорит работу, да и заказчику будет существенно удобнее.

[Abductio]

Обычно это называют бриф на сайт.

[soves]

Бриф это пару страниц, для самого общего понимания что хочет заказчик. Бриф и ТЗ — это как аннотация и книга (вернее инструкция).

[kislorrod]

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

[erp_shnik]

Ну не знаю, как там оно в разработке сайтов, но вот в практике внедрения ERP, госты никуда не годятся на практике. В основном они регламентируют оформление и «общие» требования, т.е. «воду».
Я в своей практике вынужден был изобретать собственный формат ТЗ для ERP-проектов. В той части, которая касается «существа» ТЗ. По титульному листу и общим требованиям-то как раз и нет вопросов к ГОСТУ, тут все отлично. Это, правда, мало кому нужно.

[Abductio]

Я тоже не могу сказать как в общем в разработке сайтов, могу сказать что опыт трех лет, 5 студий сменил. ГОСТы никуда не годятся.
Хотя я не хочу утверждать однозначно, в разработке сайтов очень много низко квалифицированных «специалистов»