Техническое задание

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

Распространенность технических заданий обусловлена «философской» природой этого документа. Техническое задание – это формальное описание того, что нужно Заказчику и что, соответственно, он ожидает получить от Исполнителя.

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

Не погружаясь в детали разработки ТЗ, хочется акцентировать внимание на том, в каких случаях в создании ТЗ может быть полезен ИТ-консультант. Классических сценариев всего два: 1). ТЗ пишет Заказчик и 2). ТЗ пишет Исполнитель.

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

Вариант «ТЗ пишет Исполнитель» идеален в случае комбинации следующих условий: а). Заказчик, руководствуясь какими-либо соображениями или обстоятельствами, принял решение о выборе конкретного Исполнителя до начала работ по созданию решения и б). Заказчик на 100% доверяет и делегирует Исполнителю решение всех вопросов относительно архитектуры решения, выбора программно-аппаратных платформ и др.

В реальных ситуациях и тот и другой вариант «в чистом виде» встречаются достаточно редко и в большинстве случаев ТЗ – это совместное творчество Исполнителя и Заказчика. На первый взгляд удивительно, но участие в разработке ТЗ третьей стороны – Консультанта во многих случаях может позволить добиться лучшего результата меньшими ресурсами. Причем, Консультант может «играть» как за Заказчика, так и за Исполнителя.

Например, выступая на стороне Заказчика, Консультант может быть полезен, если:

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

Выступая на стороне Исполнителя, Консультант может быть полезен, например, в следующих случаях:

Отсутствие или нехватка ресурсов для разработки ТЗ требуемой квалификации.
Необходимость абстрагироваться при составлении ТЗ от используемых Исполнителем методик, технологий, платформ и сконцентрироваться на потребностях Заказчика.

Примеры технических заданий из моих работ:

Фрагмент (структура и содержание одного из подпунктов) технического задания на создание ИС