В далеком 99-ом году, когда у меня появился первый самостоятельный заказ на разработку веб-системы (3-ий курс) мне необходима была опора, которая позволила бы достойно выглядеть перед заказчиком без риска уйти в переработки за свой счет. Мой отец – крутой специалист в области проектирования АСУТП, всегда говорил мне – пиши ТЗ. Они, как в то время, так и сейчас, использовали ГОСТ 34, в котором есть подробная структура требований к автоматизированной системе любого класса.
Чем веб-сайт не автоматизированная система? Она самая… Поэтому книжечка с этим стандартом, которая была у меня в шаговой доступности, была присвоена «на время» и отлично помогла мне выполнить первый проект. Тогда, надо сказать, я слабо разбиралась во всех тонкостях 34-ого ГОСТа и поэтому для меня, как для начинающего специалиста, он просто стал отличным вопросником-чеклистом при работе с заказчиком. Хотя не все разделы этого стандарта (34.602) я и понимала, это, тем не менее помогло мне выглядеть по оценкам моего заказчика «видно, что профессионально». Помню особенно заставил задуматься даже не раздел с требованиями, а раздел «Этапы …». Возможно с этого началась моя карьера как руководителя проекта :-)
Даже если не брать в рассмотрение весь 34-ый комплекс, как это замечательно делает А.Н. Тимофеев, (чей опыт измеряется сотнями ТЗ), один 34.602 уже может здорово помочь, т.к. содержит требования к тому, что вы должны получить по результатам предварительного общения с заказчиком и предварительного проектирования – то, под чем можно было бы подписаться.
Чуть позже, работая преподавателем в рамках курса «Структурно-логическое проектирование веб-узлов» (второе высшее), я составила рыбу вопросов, скрещивая которую с разделами 34.602 можно было генерировать много правильных стартовых вопросов для общения с заказчиком.
Конечно, сегодня я вижу и неполноту, и серьезные ошибки в этой, составленной мной в студенческие годы схеме. Например, в ней красочно отображен «типовой глюк» начинающих аналитиков – считать, что ТЗ содержит только функциональные требования.
Однако 34-ый ГОСТ по-прежнему под рукой, хотя, благодаря и опыту, и многолетним обсуждениям практики проектирования в нашем коллективе, взгляд на него уже более полный и, я бы сказала, гораздо более осознанный – как на отличный, рабочий инструмент, позволяющий сэкономить силы.
Сегодня изменилась и среда, в которой я выполняю проектирование, мое современное ТЗ на CMS сегодня выглядит «чуть чуть по круче», но могу подтвердить, что все написанное в 34-ой серии правда и хорошо работает.
По этой теме далее могу рекомендовать:
• предварительно — статью «Два подхода к разработки ТЗ»;
• конечно, сам ГОСТ 34;
• вебинар А.Н. Тимофеева «Основы разработки ТЗ по ГОСТ 34». Отзывы.
Автор: PMLE
