ТЗ без сюрпризов: 5 типовых разногласий, которые лучше предусмотреть на берегу

[@bzverev]

После прочтения появилось много вопросов.

1. Если речь про ТЗ, то надо уточнить, на что это ТЗ? На систему, на программу или на работу?

ТЗ на систему - это, скорее всего, ГОСТ 34.602.

Если на программу - то, скорее всего, по ГОСТ 19.201.

Если на работу, то стандартов общепринятых нет.

2. Упомянуты 44-фз и 223-фз. Это госзакупки. Работы по ним ведутся в формате проекта, т.е. есть фиксированный бюджет и фиксированные сроки. А это, извините, водопад, т.е. ГОСТ 34.601 (теперь ГОСТ Р 59793). Тем более, что госзаказчики (а кто ещё по 44-фз и 223-фз работает?) любят ГОСТы. Значит, забываем скрам, спринты, бэклоги и прочее. Да и скрам, как методология, основанная на принципах аджайл, не должна работать ни с ТЗ, ни с документацией (вспоминаем два из четырёх базовых постулата аджайл про документацию vs. продукт и гибкость vs. первоначальные договорённости).

Ну и про термин ЧТЗ. Не в смысле "челябинский тракторный завод", а "частное техническое задание". Это ТЗ на часть системы (открываем ГОСТ 34.602, п. 3.3), а не доп.ТЗ (п.3.5 в том же ГОСТ 34.602). Да, традиция, мы все привыкли, но в оригинале значение акронима было другое.

Ну и главное не сказано. На основе ТЗ (со всеми ЧТЗ и доп ТЗ кумулятивно) должны писаться ПМИ (на основе которой идёт приёмка) и документация (техно-рабочий проект). А как иначе проверить, что исходная постановка реализована вообще и реализована правильно, и готовый продукт удовлетворяет предъявляемым к нему требованиям?

[@Svetlana_Purik]

По п.1. В статье приводится разбор слабых мест в технических заданиях на разработку систем, сервисов и т.д. (см. начало статьи).

По п.2. Суть про детальные требования к НСИ. В частности рассматривается в виде примера каталог товаров, работ и услуг.

Если уходить в техническую суть документов - обозначили верно.

[@bzverev]

Про НСИ надо учитывать два момента. Информационная база, в состав которой входит и НСИ, состоит из внемашинной и внутримашинной. Внемашинная включает в себя классификаторы и кодификаторы, определяемые вне системы. Например, семейство классификаторов (ОКПО, ОКОНХ, ОКВЭД, ОКОПФ, ОКСМ, ОКАТО и т.п.). За их ведение отвечают внешние структуры. Вопрос только в том, кто, как и когда их превращает во внутримашинную форму. Но задача интеграции может стоять отдельно, и она двоякая - организационная и техническая. Да, хорошо, если это изначально прописано в ТЗ.

Но есть и локальные справочники, которые делятся на вне машинные данные и на внутримашинные. Их можно вести либо в самой системе, либо также делать интеграцию с той системой, которая для этого справочника первична. И тут, конечно, тоже хорошо БЫ прописать это в ТЗ. Но чаще бывает, что это делается на этапе проектирования (я сторонник водопада), т.е. на этапе создания ТЗ формулируются только общие требования, а реализация отдаётся на откуп разработчикам - соответственно, результаты отражаются в документации техно-рабочего проекта.

[@bzverev]

Про ТЗ и проект ещё хочу сказать. Дело в том, что ТЗ хорошо там, где есть проект, т.е. чёткая спецификация требований и чёткие сроки. Иначе это процесс (и там работает, кстати, скрам), но ТЗ по нему написать практически невозможно - в лучшем случае бриф, из которого делается бэклог