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






В.Беляков

Философия ТЗ: как выявить и создать контекст Заказчика?

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

О проблеме ТЗ.
Основной проблемой ТЗ, на самом деле, является игнорирование уровня компетенции Заказчика будущей системы (далее – Системы) по вопросам ее разработки и приемки. Весь юмор состоит в том, что при разработке программных систем нормативными документами не предусматривается наличие института специализированных заказчиков подобно тех, которые действуют в строительстве, при создании военных систем и в других критичных и высокотехнологичных процессах синтеза продукции. В этих областях Заказчик-пользователь директивно «снабжается» Заказчиком-специалистом и последний «защищает» первого от узко профессиональных «нападок» Разработчика. Программная продукция считается высокотехнологичной, но не критичной продукцией, поэтому Заказчик-специалист нормативно отсутствует и Заказчик-пользователь изначально «проигрывает» Разработчику.
«Проигрыш» Заказчика явно начинается с этапа ТЗ. И прежде всего, с декларирования цели. Можно легко доказать, что цель Заказчика – дальше и выше, чем у Разработчика. Вот это доказательство. Обе стороны разработки – коммерческие предприятия, по ГК РФ целью их деятельности является получение прибыли; прибыль Разработчика, связанная с Системой, формируется значительно раньше, чем соответствующая прибыль Заказчика, а именно – по факту оплаты разработки; но у Заказчика с этого момента все только начинается, и еще не известно, будет ли толк от Системы. Доказательство завершено. Исходя из доказанного, в  ТЗ мы практически всегда имеем цель Разработчика: создание Системы. А это и есть «проигрыш» Заказчика – ведь ему надо посредством Системы получить эффект в развитии своего финансово-хозяйственного механизма.  Этот факт – навязывание Заказчику цели Разработчика – и отражает основную проблему ТЗ. Далее ком нарастает: производственные, финансово-экономические и административные задачи Заказчика, решаемые Системой,  заменяются функциями отдельных ее элементов; критерии осознания хозяйственного эффекта подменяются критериями правильности выполнения отдельных функций, которые сами по себе Заказчику не нужны.
Есть еще одна сторона вопроса – устаревшие нормативные документы. Существующая практика указывает на широкое использование двух ГОСТов как основы для разработки ТЗ на создание программных  систем: ГОСТ 19.201-78, и ГОСТ 34.602-89. Все они имеют рекомендательный  характер, создавались в нерыночной обстановке и отражают уже давно прошедшие условия развития программной продукции  и сравнительных уровней компетенции заказчиков и разработчиков. Замечу,  что во времена создания этих ГОСТов, т.е. на начальных этапах развития новой формы продукции - программной,  указанные уровни были практически одинаковыми, а потому никакого «проигрыша» Заказчика не было. Скорее даже был диктат Заказчика. 
Предлагаемая методика контекстно-целевой  экспертизы ТЗ (далее – Методика) позволяет Заказчику-пользователю в «единоборстве» с Разработчиком «сравнять счет» на этапе рассмотрения ТЗ и создать существенный запас прочности  на дальнейшие этапы разработки и приемки Системы.
О философии ТЗ.
В статье рассмотрены следующие вопросы:           

  1. роль ТЗ (субъект);
  2. основное содержание ТЗ: цель, задачи, функции, важнейшие потребительские частные требования и ограничения (объект);                                   
  3. частные проблемы и риски ТЗ, причинность  проблем ТЗ (противоречие); 
  4. метод решения проблем ТЗ, основное содержание Методики (развитие).

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

  1. ТЗ – единственный исходный документ во взаимоотношениях Заказчика и Разраб