Comments 19
> Полное отсутствие стандартов разработки, проектирования и документирования.
Стандарты есть: например, ГОСТ 19.201-78, ГОСТ 34.602-89. Там и про содержание, и про оформление.
Незнание и неумение ими пользоваться — вот это проблема.
Стандарты есть: например, ГОСТ 19.201-78, ГОСТ 34.602-89. Там и про содержание, и про оформление.
Незнание и неумение ими пользоваться — вот это проблема.
Сколько не рассматривал ГОСТы, не мог понять как бы их использовать для разработки. А случаи когда задания приходили от гос. структур и соответствовали ГОСТу это вызывало у разработчиков стойкое непонимание чего от них хотят.
Что непонятного-то? Всё по полочкам: цели и задачи, терминология (очень важный пункт, кстати), источники финансирования, самое главное — требования (функциональные, к надежности, к тестированию, даже к патентной чистоте), порядок сдачи-приёма.
Все уже придумано до нас. Бери и пользуйся.
> вызывало у разработчиков стойкое непонимание чего от них хотят
Разработчики не умеют читать список требований? :)
Все уже придумано до нас. Бери и пользуйся.
> вызывало у разработчиков стойкое непонимание чего от них хотят
Разработчики не умеют читать список требований? :)
Хорошо, есть ГОСТы, согласен применение их позволит решить ряд проблем. Вот только вся суть в том, что все и сразу использовать ГОСТ не начнут. К сожалению. Доводилось видеть реакцию на предложение — а давайте писать по ГОСТу. Шарахаются люди от него. Почему не понятно.
Мне тут подумалось по поводу ГОСТов — они очень общего назначения, а значит не содержат требований относительно сайта. Думается мне, что применение ГОСТа не застрахует от отсутствия в документе структуры сайта или чего-нибудь подобного. Чем плохи универсальные инструменты так это тем, что они решают слишком много задач, но зачастую слишком поверхностно.
> применение ГОСТа не застрахует от отсутствия в документе структуры сайта или чего-нибудь подобного
и так далее.
Применение ГОСТа — застрахует. Сайт есть программное обеспечение (если добавить регламент работы персонала — читай, админов и модераторов, то можно назвать уже и автоматизированной системой), и этим ничем не отличается от сотен других видов программного обеспечения. И вполне подлежит описанию по стандартам.
Хотите пользы? Предложите только одну часть ТЗ к обсуждению — терминологию. Если она будет выработана в цельном виде здесь, на хабре, и будет применяться массово — уже большое благо. Я могу порыться в закромах и вытащить тот кусок устоявшейся терминологии, который составлял для шаблонного ТЗ ещё в 2001 году — она хорошо работает до сих пор, хотя уже пора подправить.
А делать структуру сайта (кстати, что это такое? должно быть определено в ТЗ) необходимой составной частью ТЗ — ошибка. Пример — визитка в одну страницу, какая у неё структура?
2.6.1.1. В требованиях к структуре и функционированию системы приводят:
* 1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;
* 2) требования к способам и средствам связи для информационного обмена между компонентами системы;
и так далее.
Применение ГОСТа — застрахует. Сайт есть программное обеспечение (если добавить регламент работы персонала — читай, админов и модераторов, то можно назвать уже и автоматизированной системой), и этим ничем не отличается от сотен других видов программного обеспечения. И вполне подлежит описанию по стандартам.
Хотите пользы? Предложите только одну часть ТЗ к обсуждению — терминологию. Если она будет выработана в цельном виде здесь, на хабре, и будет применяться массово — уже большое благо. Я могу порыться в закромах и вытащить тот кусок устоявшейся терминологии, который составлял для шаблонного ТЗ ещё в 2001 году — она хорошо работает до сих пор, хотя уже пора подправить.
А делать структуру сайта (кстати, что это такое? должно быть определено в ТЗ) необходимой составной частью ТЗ — ошибка. Пример — визитка в одну страницу, какая у неё структура?
Не менее 10-20%(в зависимости от задания) времени и финансирования проектов — в ТЗ. Иначе выйдет и дольше, и дороже.
Мутно как-то и не по делу.
ТЗ имеет вполне определенные задачи и исходить надо от них. Стиль документа конечно хорошо, но правильный по смыслу plain text намного лучше хорошо стилизованной воды.
А ТЗ должен, как часть контракта, необходимо и достаточно описывать содержание проекта как для понимания исполнителем задачи, так и для принятия работ заказчиком. В хорошем случае ТЗ составляется из дизайна системы. В плохом дизайн по ТЗ. По ТЗ составляются методика для приемо-сдаточных испытаний, которая тоже должна быть частью контракта :)
При этом в ТЗ не иметь ничего лишнего и неопределенного. Любое определение — повод заказчика требовать с исполнителя работы. «Система должна ...» и далее пара общих фраз легко может увеличить обьем работ в н-цать раз :)
ТЗ имеет вполне определенные задачи и исходить надо от них. Стиль документа конечно хорошо, но правильный по смыслу plain text намного лучше хорошо стилизованной воды.
А ТЗ должен, как часть контракта, необходимо и достаточно описывать содержание проекта как для понимания исполнителем задачи, так и для принятия работ заказчиком. В хорошем случае ТЗ составляется из дизайна системы. В плохом дизайн по ТЗ. По ТЗ составляются методика для приемо-сдаточных испытаний, которая тоже должна быть частью контракта :)
При этом в ТЗ не иметь ничего лишнего и неопределенного. Любое определение — повод заказчика требовать с исполнителя работы. «Система должна ...» и далее пара общих фраз легко может увеличить обьем работ в н-цать раз :)
В хорошем случае ТЗ составляется из дизайна системы
Интересно, дизайн становится основополагающим в проекте. Опыт таких разработок у меня печален.
ТЗ имеет вполне определенные задачи и исходить надо от них. Стиль документа конечно хорошо, но правильный по смыслу plain text намного лучше хорошо стилизованной воды.
Безусловно лучше, а правильный по смыслу и хорошо структурированный еще лучше. Лучшее конечно враг хорошего.
Все проблемы из-за неквалифицированных специалистов. ГОСТы есть, в университетах писать ТЗ учат, что ещё надо. Литературу можно почитать, например www.intuit.ru/department/itmngt/analisis/
Большинство заказчиков формулирует ТЗ как: «Хотим сайт, как у компании Х, но без 1-2-3-4-5 и с 6-7-8-9». Поэтому если Вы строите сайты, проще один раз написать перечень требований к сайту (в виде анкеты) для заказчика. По итогам обработки анкеты Вы сможете выдавать заказчику проект ТЗ. Это ускорит работу, да и заказчику будет существенно удобнее.
ТЗ, в котором полностью прописаны все мелочи по созданию будущего проекта от целей до дизайна и функционала, всех пунктов меню и полей форм для заполнения будущими пользователя — это во первых хорошая проработка проекта, еще до стадии прототипирования, а во вторых такое ТЗ подписанное заказчиком может уберечь Вас от доработок не прописанных в ТЗ.
Ну не знаю, как там оно в разработке сайтов, но вот в практике внедрения ERP, госты никуда не годятся на практике. В основном они регламентируют оформление и «общие» требования, т.е. «воду».
Я в своей практике вынужден был изобретать собственный формат ТЗ для ERP-проектов. В той части, которая касается «существа» ТЗ. По титульному листу и общим требованиям-то как раз и нет вопросов к ГОСТУ, тут все отлично. Это, правда, мало кому нужно.
Я в своей практике вынужден был изобретать собственный формат ТЗ для ERP-проектов. В той части, которая касается «существа» ТЗ. По титульному листу и общим требованиям-то как раз и нет вопросов к ГОСТУ, тут все отлично. Это, правда, мало кому нужно.
Sign up to leave a comment.
Рассуждения о проблемах технического задания