Основные правила подготовки качественного технического задания

Автор статьи: Андрей Басос

Набор правил — рекомендаций квалифицированному аналитику

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

Прежде всего, надо понять, чем именно является техническое задание. Итак, техническое задание — это документ, содержащий требования Заказчика к автоматизированной системе (далее — АС). Вот так вот просто и незатейливо. Казалось бы — приходи, спрашивай у Заказчика, что ему надо, и записывай. А потом передавай это разработчику. Но не все так просто.

Ведь требования — это продукт синтеза, а не анализа. Заказчик может вам в общих чертах рассказать, что он хотел бы получить и в каком виде. Но его повествование совсем не обязательно сложится в логичную и непротиворечивую картину, пригодную для передачи в разработку. Зачастую Заказчик не в состоянии выдать Вам требования, если Вы правильно не выстроите с ним работу. И чем серьезнее, объёмнее будет набор его требований к АС, тем дороже вам обойдется любая ваша оплошность на стадии подготовки технического задания.

Аналитику следует придерживаться ряда правил, если он не хочет в итоге обмануть ожидания Заказчика:

Правило №1

Начните с правильного определения объекта автоматизации. Объект автоматизации — это тот самый вид деятельности в организации Заказчика, эффективность управления которым необходимо повысить посредством внедрения АС. Подтверждением того факта, что вы сумели правильно выявить объект автоматизации, является его связное и подробное описание. Например: «Управление закупочной деятельностью». Принимайте требования к АС только если вы точно сумели определить объект автоматизации, в рамках которого эти требования будут реализовываться.

Правило №2

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

Правило №3

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

Правило №4

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

Правило №5

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

Правило №6

Формулируйте все требования на понятном Заказчику языке. Не допускайте чересчур сложной и допускающей двусмысленные толкования терминологии. Техническое задание должно легко и с интересом читаться представителями приемочной комиссии.

Правило №7

Уделяйте максимум времени согласованию с Заказчиком приемочных испытаний. Мало описать объект автоматизации, зафиксировать проблемы и критерии эффективности АС, расписать требований пользователей. Вам надо четко договориться с приемочной комиссией Заказчика о сценарии сдачи АС. И здесь дело даже не в том, что потом Вам будет проще сдать АС (хотя и не без этого). Важно другое — когда Заказчик вместе с Вами будет придумывать приемочные испытания (контрольные примеры, процедуры тестирования) — он еще раз будет вынужден осмыслить те проблемы, которые он хочет решить и продумать свои требования. А это позволит еще раз проработать все техническое задание и устранить ранее допущенные недочеты в формулировках.

Правило №8

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

Следование вышеизложенным правилам позволит Вам успешно выявить требования и согласовать качественное техническое задание вне зависимости от того, какими шаблонами и технологиями Вы будете пользоваться.

К списку статей