Как писать полезное ТЗ на ПО по ГОСТ 19.201

Ниже ключевые тезисы с одноименного семинара, который прошел 30.03.2017.

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

Огромное число легенд, заблуждений, ярких находок и обманутых ожиданий связано именно с ТЗ. Хорошее ТЗ помогает всем ролям в команде лучше выполнять свою работу. Перефразируя известное выражение, можно сказать: «хорошее ТЗ — половина успеха проекта, плохое — половина провала».

На прошедшем семинаре мы обсуждали вопросы написания ТЗ с применением стандарта ГОСТ 19.201-79. Что изменилось за, без малого, 40 лет с момента выхода стандартов серии 19, а что до сих пор актуально и полезно.

 

В начале второй половины 20го века мы все еще ждали третью мировую ядерную войну. Надежность и помехоустойчивость проектирования и коммуникации проектных решений с использованием ГОСТовских документов и процессов была огромной. Предполагалось, что проектная и программная документация должна быть легко применима не только в условиях, когда проектное бюро уже разбомбили, а завод-изготовитель еще нет, но и даже через пару-тройку поколений, когда наши потомки должны были выйти из убежищ, пережив ядерную зиму и дождавшись спада радиационного фона на окрестных территориях.

Сейчас это сюжет для компьютерной игры, но в СССР тех времен каждое проектное решение несло отпечаток неявных требований предвоенного времени. И имело, следовательно, соответствующую добавку к стоимости.

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

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

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

Второе, что необходимо понимать, процессы программной инженерии сильно шагнули вперед. Поэтому и состав работ для производства программного средства, изделия или продукта, и виды нефункциональных требований претерпели изменения. В этой части нужно добавлять, не исключая, при этом, требования ГОСТ 19.201, более свежие стандарты. Для НФТ – это ГОСТ Р ИСО/МЭК 25021-2014, ИСО/МЭК 9126-93. Для состава работ и организации жизненного цикла ‑ ГОСТ Р ИСО/МЭК 12207-2010.

Все остальное никак не поменялось и не менее полезно, чем 40 лет назад.

В частности, ТЗ по ГОСТ 19.201

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

Таким образом, ТЗ по ГОСТ 19-201 в зависимости от масштаба разработки является полным планом проекта (включающим требования к предмету поставки), или проектным заданием на пакет работ, или качественным описанием постановки задачи.

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

Необходимо так же отметить, что на сегодняшний день не существует заменяющего ГОСТ 19.201 стандарта ни на техническое задание, ни на требования к программе – ни отечественного, ни переводного.

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

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

Как писать полезное ТЗ на ПО по ГОСТ 19.201: Один комментарий

Комментарии запрещены.