Продолжение 1, 2, 3, 4, 5

Очень часто техническое задание на автоматизацию документооборота не пишется вовсе. Еще чаще к разработке этого документа подходят чисто формально – лишь бы было. Если речь идет о госорганах, то это «лишь бы было» должно еще соответствовать требованиям законодательства и стандартов. А поскольку нормативных актов и инструкций по разработке технических заданий на создание информационных систем в суверенном Казахстане за 20 лет писать еще не научились, за основу берут еще старые советские стандарты, например, ГОСТ 34.602-89 (называемый ныне СТ 34.015-2002, который, не смотря на новое название, по-прежнему ссылается на общесоюзные классификаторы). И начинают изобретать нечто такое, что смогут показать проверяющим инстанциям при необходимости. В любом случае создаваемый документ практически только пишется, но никогда не читается и не выступает в качестве руководства к действию.

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

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

К сожалению, заказчик очень часто недопонимает этих прописных истин, и не то, что не принимает никакого участия в разработке ТЗ, но даже не требует от внедренца достойной реализации такого документа. В результате внедренец очень часто использует некое «типовое техническое задание», которое подчас просто повторяет описание программного продукта, на базе которого реализуется проект, с изменением времен глаголов с настоящего на будущее (т.е. меняет «система обеспечивает» на «система должна обеспечивать»). Например, вот одно из таких «типовых технических заданий», набросанных когда-то мной «на коленке» за пару часиков, которое, насколько мне известно, с успехом применяется и по сей день. (Я выкладываю этот документ в качестве демонстрации того, как не следует выполнять содержательную часть задания, т.к. она полностью повторяет описание СЭД Documentolog с упомянутым ранее изменением времен глаголов).

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