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






В.Беляков

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

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

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

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

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

  1. ТЗ – единственный исходный документ во взаимоотношениях Заказчика и Разработчика при разработке и приемке Системы.                  
  2. ТЗ - согласованная Заказчиком и Разработчиком первоначальная и всесторонняя  модель Системы.
  3. ТЗ - критерий правильности построения и функционирования, а значит и приемки Системы.

Пояснить указанные позиции можно таким  образом.
Программно-технические системы самостоятельно не создают материальные объекты,  допускающие использование объективных средств измерений и критериев оценки соответствия требованиям.  Данные системы трансформируют вербальные объекты, оценка которых может быть только субъективной. Для обеспечения результативности процесса разработки таких систем (с позиции Разработчика) требуется, чтобы ТЗ  содержало окончательный вердикт о соответствии результата ожиданиям плательщика. Единственность и первоначальность  ТЗ еще более увеличивает его роль в процессе разработки программно-технических систем. 
ТЗ является не только первоначальной и согласованной Заказчиком и Разработчиком моделью Системы. ТЗ -  это еще и единственная полная модель Системы, поскольку кроме ТЗ более нет критерия оценки различных свойств Системы.
Поскольку только ТЗ включает окончательные  требования к функционированию системы, исключается возможность использования иных, кроме изложенных в ТЗ, критериев приемки. Любые критерии приемки, «выводимые» из ТЗ, требуют сложного доказательства собственной состоятельности, которое зачастую «скромно умалчивается» Разработчиком. Наличие в ТЗ только качественных вербальных критериев правильности функционирования создает огромный риск для Заказчика и существенно упрощает жизнь Разработчику.
В целом, можно сказать так: каково ТЗ, такая будет и Система. Много вопросов к ТЗ или оно совсем непонятно Заказчику – неудобная будет Система в пользовании:  что надо не будет делать, а что не надо – будет,  да и то с ошибками.
Таким образом, роль ТЗ просто невозможно переоценить. Существуют выведенные практикой нормативы: качество ТЗ на 90% определяет успех разработки и на 50% - её трудоемкость.
Основное содержание ТЗ.
Автор считает, что главнейшими разделами ТЗ являются следующие:

  1. цель создания Системы (далее – Цель);
  2. решаемые Системой задачи (далее – Задачи);
  3. выполняемые средствами Системы функции (далее – Функции);
  4. важнейшие потребительские частные требования и ограничения (ВПЧТО). 

Все указанные разделы ТЗ в той или иной форме содержаться в упомянутых выше нормативных документах, поэтому далее ссылка на эти документы приводиться не будет.
Указанные понятия в силу их широкой употребительности целесообразно наделить следующим смыслом.
Цель – коммерческий изъян (далее – Изъян) финансово-хозяйственного механизма Заказчика, который устраняется фактом успешного внедрения Системы. Ввиду неформальности данной статьи строгое определение понятия «Изъян» приводиться не будет.
Задача – упорядоченная и целенаправленная деятельность нескольких или всех составных частей Системы по достижению отдельного финансово-хозяйственного эффекта, обеспечивающего частичное достижение поставленной Цели.
Функция – конкретная зависимость выходных реакций элемента Системы в ответ на подаваемые на его вход допустимые воздействия.
Помимо  Цели, Задач и Функций в ТЗ необходимо ввести требования по используемому составу технических средств, квалификации привлекаемого персонала, а также явно ощущаемые Заказчиком экономические, технические и организационные ограничения. Все такие требования и ограничения, остро ощущаемые Заказчиком, и составляют ВПЧТО. Все остальные разделы ТЗ, присутствующие в реальных ТЗ, оформленных в соответствии с указанными выше нормативными документами, не имеют никакого отношения к соответствующему этапу, т.к. по сути являются уже результатом первоначального проектирования Системы.
В подтверждение справедливости приведенного подхода, покажем, как происходит или объективно должно происходить «зачатие» Системы. Данный интимный  акт таков.
Чаще всего  Изъян ощущается руководством компании, которое указывает своим подчиненным на необходимость его устранения. Подчиненные, топ-менеджеры компании, находят пути устранения Изъяна. Это и есть Задачи. В том случае, когда предлагаемые пути устранения Изъяна носят чисто информационный характер и возникает необходимость в создании Системы. 
Сама потребность в Системе определяет Цель, которая должна быть сформулирована Заказчиком тем или иным способом. Формулирование Задач также относится к обязанности Заказчика, поскольку как раз Задачи и появляются первыми в жизненном цикле Системы.
Автор просто удивляется, как неразумно поступают иногда руководители – Заказчики, отказывающиеся формулировать Задачи. Ведь это сделать проще простого! Надо вызвать топ-менеджера компании, которому было поручено устранить Изъян, и который указал на то, что Система нужна. И просто записать его ответ на вопрос: как надо устранить Изъян. Он делал это не раз, даже можно найти его докладную записку на этот счет. Там есть все Задачи!
Теперь о Функциях. Они - детище Разработчика. Но должны быть усвоены Заказчиком очень хорошо, поскольку полномасштабная приемка Системы возможна только по испытаниям Функций. Интересно то, что синтез Функций – это уже проектирование. И представление их в ТЗ является «подарком» Разработчика. Не будем развивать эту тему, она отражает консенсус интересов.  Здесь можно согласиться с «забеганием вперед» Разработчика.
Но «вбить» Цель, Задачи и Функции в ТЗ – не самоцель. Надо принять в эксплуатацию Систему, наделенную этими свойствами. Поэтому по результату приемки Заказчик должен ясно представлять, каким образом можно решить Задачи с использованием реализованных в Системе Функций и каким образом решение Задач приведет к достижению Цели. Поэтому, если приемка Системы происходит только на основании функциональных испытаний, это грозит Заказчику остаться с «дырявым корытом». Понимание следования условий выполнения Задач из реализации Функций и достижения Цели из выполнения Задач – это коммерческая обязанность Заказчика. Ее выполнение не может быть доверено Разработчику по указанной выше причине расхождения моментов целедостижения Сторонами разработки. И здесь опять надо вызывать топ-менеджера – прародителя Системы. Но что делать с этим прародителем - отдельная большая тема.
Поскольку надежда на скорое изменение устоявшейся практики создания ТЗ – большая иллюзия, придется еще долго мириться и приспосабливаться к негативным факторам процесса разработки программных систем. Сделать это наиболее рационально поможет анализ противоречий, который приводится ниже.
Частные проблемы и риски ТЗ  
На этапе ТЗ выявляются следующие явные частные проблемы Заказчика:

  1. неполное понимание ТЗ, отсутствие уверенности, что будущая Система - это то, что надо;
  2. отсутствие полного и понятного критерия приемки будущей Системы;        
  3. преобладание в ТЗ несущественных конструктивных и функциональных деталей, упрощающих Разработчику  сдачу Системы, но мешающих Заказчику понять её;
  4. излишняя сложность ТЗ;
  5. неполнота описания Системы;
  6. отсутствие полной согласованности специалистов Разработчика по всем вопросам, отраженным в ТЗ;
  7. значительное количество замечаний по оформлению;
  8. разный уровень описания составных частей будущей Системы – свидетельство различной готовности разработчика к созданию различных составных частей Системы.

Конкретный Заказчик конкретной системы может ощущать не все указанные неудобства. Часто Руководитель Заказчика доверяется своему топ-менеджеру, который согласно кивает в ответ на «продавливающий» доклад Разработчика с отчетом об очередном этапе разработки. Однако, такое согласие будет дорого стоить Заказчику, если в ТЗ отсутствует Цель, Задачи и ВПЧТО в дружественной последнему формулировке. Часто достаточно долго существует ошибочное мнение об успешности принятой Системы. Этому виной текучка и искусственное переключение внимания Руководства на другие проблемы фирмы со стороны топ-менеджмента, ответственного за использование Системы. 
Обозначенные частные проблемы ТЗ создают следующие риски Заказчика:

  1. риск недостижения Цели;
  2. риск невыполнения одной или нескольких Задач;
  3. риск неудобства Системы (противоречивости, избыточности  Функций);
  4. риск переплаты (неполноты функций Системы);

Определение рисков – важнейший этап решения проблемы ТЗ, поскольку только риски носят экономический смысл и вызывают ответные действия Сторон разработки. Риски могут только постулироваться. Представленный выше взгляд на них  отражает мнение автора, но легко заметить, что данный набор рисков отражает полное событие. Очевидно, что риски есть и у Разработчика, например, риск непринятия Системы. Можно легко увидеть, что все риски Разработчика вызываются рисками Заказчика. При этом не все риски Заказчика определяют риски Разработчика, со многими рисками Заказчик остается один на один. Кроме того, Разработчик чаще всего нейтрализует все свои риски описанным выше «пиратским» способом.
И теперь самое главное – острие противоречия. 
Причины проблем ТЗ
Основной проблемой ТЗ, как было указано выше, является игнорирование уровня компетенции Заказчика.    С одной стороны, при разработке ТЗ уровень компетенции Заказчика в вопросах разработки Системы наглядно проявляется. Опыт автора позволяет свести все возможные компетенции Заказчика в области разработки программно-технических систем к трем уровням:        
высший - имеет место, когда Заказчик управляет процессом разработки и внедрения Системы (детальное обсуждение и корректировка ТЗ, погружение в проект, отслеживание всех стадий, участие в приемке на всех стадиях, разработка методики приемо-сдаточных испытаний);                
средний - имеет место, когда Заказчик контролирует процесс разработки Системы (формальный контроль прохождения стадий, участие в испытаниях и приемка продукта по методикам Разработчика);
низший - Заказчик лишь учитывает все, что делает Разработчик (неполное понимание ТЗ, учет результатов испытаний, формальная приемка Системы).                
Статистики по распределению всех Заказчиков по указанным уровням компетенции в настоящее время не существует.  Косвенные данные позволяют сделать следующее разбиение: низший уровень - 95%, средний - 5%, высший – единицы («советские мамонты»).
С другой стороны, контексты всех  ТЗ можно типизировать по соответствию сторонам разработки. Очевидно, тип контекста всех существующих ТЗ имеет ярко выраженное соответствие Разработчику. Поэтому основную проблему ТЗ, заключающуюся в игнорировании уровня компетенции Заказчика, можно трансформировать в следующую:
проблема ТЗ вызвана несоответствием уровня компетенции Заказчика и типа контекста ТЗ.
Действительно, неужели некомпетентный в программировании Заказчик принципиально не может качественно принять Систему? Он что, не знает, что ему надо? Конечно, может! Но ТЗ в этом случае должно быть изложено, максимум на двух страницах: цель, задачи, состав работающего персонала и технических средств. А критерием приемки при этом будет выступать неформальное согласие Заказчика с результатами работы Системы, поскольку даже правильное выполнение всех функций всех элементов Системы не является для Заказчика окончательным подтверждением согласия с Системой. Система должна решать Задачи и достигать Цель.
Но какой Разработчик сдаст такую Систему? А это уже вопрос уровня компетенции Разработчика.
Вероятно, справедлив следующий закон сохранения компетенций:
при снижении уровня компетенции Заказчика в вопросах разработки программных систем уровень компетенции Разработчика должен соответственно повышаться и обеспечивать возможность сдачи-приемки Системы по неформальным критериям Заказчика.
Действительно, некомпетентный в программировании Заказчик может только обозначить Цель создания Системы и решаемые ею Задачи. Причем, у коммерческого Заказчика целей то всего может быть три (в конечном смысле): увеличение дохода, снижение расхода и интегрированная – увеличение прибыли. А задачи могут быть описаны не на формальном языке проектирования систем, что непосильно Заказчику, а вербально, пусть и максимально подробно.  Функции же должен «нарезать» Разработчик. А это означает  отсутствие в ТЗ ориентированного на Заказчика формального критерия приемки, поскольку такое функциональное соответствие «вход-выход» уже находится в зоне ответственности Разработчика и к Заказчику никакого отношения не имеет  (но как хочется Разработчику «привязать» Заказчика к сочиненным  им функциям!).
Но самым интересным в данном вопросе является то, что любая Система в настоящее время сдается и принимается только по функциям, а не по задачам и целям! И этот парадокс тоже начинается на этапе ТЗ!
Исходя из вышесказанного, более конкретными, данными нам в ощущениях, причинами проблем ТЗ являются сохраняемые практически во всех разработках следующие условия:

  1. невнимание Заказчика к этапу ТЗ – отсутствие в ТЗ его Цели и Задач;
  2. формирование ТЗ практически полностью в контексте Разработчика;
  3. навязывание Разработчиком выгодного себе функционального критерия приемки системы;
  4. представление в ТЗ результатов последующих этапов проектирования. 

Как видим, счет здесь 1:3 в пользу Разработчика. Заказчик имеет только одно очко, и то – негативное, против себя самого. Именно поэтому и предлагается следующий контекстно-целевой подход к решению проблемы ТЗ.
Методом решения проблемы ТЗ предлагается принять совокупность следующих действий:

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

Краткое пояснение контекстно-целевого похода к решению проблемы ТЗ таково.
КБЗ ТЗ можно определить как часть (зона) ТЗ, доступ в которую открыт для Разработчика только в режиме чтения. КБЗ ТЗ – сделано Заказчиком, понятно Заказчику и является единственным критерием приемки Системы. Конечно, не все существующие ТЗ имеют в своем составе КБЗ ТЗ. Можно утверждать, что ТЗ, не имеющие КБЗ ТЗ в своем составе,  определяют провальный проект для Заказчика. При этом Разработчик чаще всего живет вольготно. И, как было отмечено выше, существует парадоксальная ситуация: сам Заказчик может и не догадываться, что его Система – это совсем не то, что ему надо! Понятно, что КБЗ ТЗ должно включать  Цель, Задачи, Функции и ВПЧТО.  Причем Цель, соответствующая позиции Заказчика, является самой важной составной частью КБЗ ТЗ.
КБЗ ТЗ включает формулирование исходных целевых посылок разработки исключительно средствами и в интересах Заказчика.  Разработчик принципиально не имеет «права» вмешиваться и указывать, каким способом и в каком виде формулировать КБЗ ТЗ. Только «девственная» чистота (от «грязных» рук Разработчика) формулировок КБЗ ТЗ в конечном итоге выгодна самому Разработчику. При этом КБЗ ТЗ должен включать:

  1. коммерческую конкретную Цель разработки и внедрения Системы;
  2. возлагаемые на Систему конкретные финансово-хозяйственные Задачи Заказчика;
  3. ограничения технического, кадрового состава Системы, некоторые другие конкретные требования Заказчика.

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

  1. анализ (синтез) Цели, как элемента КБЗ ТЗ;
  2. анализ (синтез) Задач, как элемента КБЗ ТЗ;
  3. анализ Функций;
  4. идентификация КБЗ ТЗ;
  5. оценка рисков;
  6. синтез необходимых диагностических ситуаций Цели;
  7. синтез необходимых диагностических ситуаций Задач.

Проведение указанных процедур основывается на значительном опыте участия автора в разработках и приемках программно-технических систем различного назначения и носит неформальный характер. Некоторые ориентиры для понимания существа осуществляемого творческого процесса могут быть сведены к следующему.
Цель и Задачи выявляются по функциям и данным, представленным в ТЗ,  на основе знаний принципов управленческого учета, различных контуров корпоративного управления и полнофункциональной организующей схемы предприятия.
Функции оцениваются на полноту, неизбыточность и непротиворечивость.
КБЗ ТЗ должен оценить и согласовать Заказчик.
Риски оцениваются по степени согласованности Цели, Задач и Функций, а также типу контекста ТЗ и критерию приемки Системы.
Синтез диагностических ситуаций Цели и Задач проводится на основе выявления определяющих условий и достигаемых частных эффектов функционирования Системы.
Возможные действенные форматы представления результата работы Методики следующие.

  1. КБЗ ТЗ.
  2. КБЗ ТЗ и оценка рисков.
  3. КБЗ ТЗ, оценка рисков и диагностические ситуации Цели и Задач.

Первый формат позволяет Заказчику понять реальную потребность в Системе. Очень часто идентифицированные в ТЗ Цель и Задачи помогают  существенно сократить расходы за счет исполнения некоторых участков процесса организационно-техническим способом. Это особенно эффективно в том случае, когда разработка Система свободна от имиджевой предпосылки и в условиях дефицита финансовых средств. При этом и Цель и Задачи могут быть достигнуты, но более бюджетным способом.
Второй формат носит проверяющий Разработчика характер. Он эффективен, когда есть возможность поменять «коня на переправе», когда есть возможность выбора. Совокупность КБЗ ТЗ и оценок рисков позволяет выявить потенциал и предрасположенность Разработчика к созданию Системы в интересах Заказчика.
Третий формат – это полноценный результат экспертизы ТЗ. И эффективность, и экономичность, и надежность Системы – все эти свойства обеспечиваются на самом высоком уровне.

Получение Заказчиком на этапе согласования ТЗ таких результатов как КБЗ ТЗ, оценок рисков и перечня диагностических ситуаций по подтверждению реализации в Системе возможностей достижения Цели и выполнения Задач создает значительную уверенность в успешности создания Системы и ее полезности для Заказчика.

 


 

Valid HTML 4.01 Transitional
Copyright © 2005-2017 Лугин Владимир Григорьевич