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

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

Вообще, в идеале, Техническое Задание - это документ, создаваемый одними специалистами для других специалистов, и отвечающий на вопрос "Что необходимо сделать", то есть описывающий конкретную реализацию конечного продукта в терминах используемых технологий.

Техническое задание относится к этапу проектирования и может охватывать различные аспекты создаваемого продукта или реализуемого проекта; либо может быть несколько технических заданий для одного проекта - для различных аспектов. Например, может быть единое техническое задание на сайт, а может быть несколько документов - отдельно на дизайн, отдельно на программную часть, отдельно на содержание. Это зависит от техпроцесса, в котором протекает проект. Если проектом занимается единая команда разработчиков, то, скорее всего, единый документ - лучший вариант.

Терминология

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

Бриф - само название подразумевает относительную краткость документа. Бриф отвечает на вопросы "Зачем" и "Почему". Пример квинтэссенции брифа: "ООО Фирма плюс хочет разработать сайт, чтобы люди находили её в интернете, потому что там есть её потенциальные клиенты".

Бриф составляется Заказчиком, иногда согласно структуре, заданной Исполнителем. Бриф содержит ответы на вопросы, которые необходимы для постановки задачи. Бывает, после анализа брифа выясняется, что для достижения целей, Заказчику лучше поможет вовсе не то, что он хочет заказать. Тут уже от Исполнителя зависит - расскажет ли он об этом Заказчику, или пойдёт по пути наименьшего сопротивления, это вопрос позиционирования и наличия специфических ресурсов.

Иногда у Заказчика есть более чёткое понимание, что и зачем необходимо, в таком случае разработчик получает более конкретный документ - Постановку задачи, в котором в общих чертах прописано то, что должно быть реализовано в проекте. Например, как один из пунктов может идти "На сайте предусматривается интернет-магазин с оплатой online, доступный только зарегистрированным пользователям; данные о товарах обновляются ежедневно, источник данных - 1С 8.0"

На основании брифа или описания задач, в зависимости от полноты и конкретизации описаний, разработчик может составить более-менее точную смету проекта и оценить сроки.

Стоит отметить, что необходимость в брифе и постановке задач может отпасть при встрече представителей Заказчика с потенциальным разработчиком и двустороннем обсуждении будущего проекта.

Ну и наконец, собственно, Техническое Задание. Полное описание проекта на бумаге. Может содержать схемы, графики, таблицы, но в основе - текст, по пунктам. Примеры типичных пунктов ТЗ:

• "Поля, предлагаемые посетителю для заполнения при регистрации на сайте: ...далее вложенные пункты",
• "Отображаемая в каталоге информация о товаре: ... далее вложенные пункты"
• "Ссылка с логотипа производителя ведёт туда-то, открывается в новом окне без элементов навигации браузера"

Факты

Несколько вещей, которые стоит принять за отправную точку.

1. ТЗ стоит отдельных денег. Во-первых, это работа, а работа должна оплачиваться. Во-вторых, правильное ТЗ - это 90% успеха проекта. Если ТЗ создаётся "бесплатно", значит либо это не ТЗ, а что-то другое, либо стоимость ТЗ "раскидана" по другим пунктам сметы. Встречаются варианты, когда ТЗ чересчур шаблонно, например, состоит из описания пунктов сметы, по абзацу на строку сметы. Поэтому, перед тем как совершать заказ, в котором фигурирует ТЗ, попросите пример ТЗ на пару реальных проектов - так вы заочно сможете оценить, за что платятся деньги и насколько работа им соответствует.
2. В случае, когда весь проект реализуется в той же компании которая разрабатывает ТЗ, авансовый платёж может быть больше стоимости разработки ТЗ. Это может быть обусловлено несколькими факторами, например:
1. во время разработки ТЗ, компания планирует загрузку ресурсов на срок реализации проекта и хочет быть застрахована от простоя ресурсов;
2. само по себе ТЗ является исчерпывающим описанием проекта, соответственно, разработчик ограждает себя от того, что Заказчик после разработки ТЗ обратится в компанию, где хуже с проектированием, но дешевле реализация (вспомним китайские автомобили с итальянским дизайном, правда, там всё наоборот, но смысл ясен).
3. Стоимость ТЗ зависит от объёмов проекта. Ну не может разработка правильного ТЗ быть одинаково затратной для типового сайта-визитки и мегафункционального мультитематического портала. Даже если строятся они на одном "движке". Поэтому правильным подходом считаю процент от сметы проекта.
4. ТЗ не часто уменьшит смету, но вполне возможно её увеличит. Уменьшение возможно при отказе Заказчика от реализации каких-то элементов проекта, увеличение - при выяснении новых и уточнении оговоренных обстоятельств, и время разработки ТЗ - последняя возможность для этого.

Поэтому общение Исполнителя с Заказчиком на этом этапе - наиболее важно для проекта. И даже ТЗ не всегда гарантирует точность сметы. Разработчику сложно предусмотреть возможные проблемы со стороны заказчика - неподготовленность материалов, длительные утверждения. Иногда Заказчик стремится изменить сроки или порядок работ - конечно же, всё это сказывается на стоимости. И чем масштабнее проект, тем больше может быть разница.

1. Техническое задание должно составляться специалистами, говорящими на одном языке с разработчиками.

И здесь есть несколько вариантов, у каждого - свои плюсы и минусы.

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

Во-первых, это может быть невыгодно по ряду причин (Время * з/п + текущая нагрузка). Во-вторых, специалисты в разных областях могут говорить на одном языке, но при этом иметь совершенно разные представления о том, что хорошо, что плохо, что правильно, а что нет. Например, дизайнер-полиграфист и веб-дизайнер - настолько же разные профессии, как конструкторы самолетов и автомобилей. Программист 1С и флэшер - точно так же. А язык один. Краеугольный камень в этом случае - это несоответствие представлений составителя с возможностями и представлениями реализаторов.

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

1. внешние специалисты, разрабатывающие ТЗ, либо генеральный подрядчик проекта.

Можно обратиться в компанию-разработчика и заказать только ТЗ. Здесь плюсом играет то, что составитель изначально знает, что проект реализовывать будет не его компания, соответственно, меньше вероятность "раздувания" бюджета. С другой стороны, сама разработка ТЗ скорее всего будет стоить больше, поскольку для компании это отдельный проект. Обратно, плюсом может стать более полная детализация - в противном случае составителю придётся решать вопросы и по ходу реализации проекта.

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

1. специалисты компании-разработчика. Оптимальный вариант для средних проектов, как по бюджету, так и по сложности.

Несколько сторон проекта

Не буду рассматривать упрощённый вариант проектов, когда весь процесс от постановки задачи до запуска в эксплуатацию реализуется внутри компании, а также вариант, когда реализацией занимается несколько команд. Рассмотрим только вариант заказа продукта в одной внешней компании - самый распространённый и, зачастую, удобный вариант.

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

Далее - существет Менеджер проекта со стороны Исполнителя - человек, на котором сходятся все ниточки по проекту, который в любой момент времени обладает наиболее полной информацией о том, в каком состоянии находится каждый из этапов проекта. Этот человек общается и с коллективами разработчиков, и с командой Заказчика.

Если Руководитель проекта со стороны Заказчика при необходимости может меняться от этапа к этапу, то Менеджер проекта со стороны Исполнителя должен оставаться одним и тем же, иначе путаницы не избежать. При этом, конечно же, возможно прямое общение по рабочим вопросам между коллективами Заказчика и Исполнителя - Менеджер проекта должен управлять процессом, а не быть лишним передаточным звеном.

Ну и конечно же, существуют конкретные исполнители - специалисты из команды Исполнителя, которым требуются точные указания, что надо делать.

Таким образом, в общем случае, Техническое Задание необходимо для того, чтобы:

1. Зафиксировать требования Заказчика (ограничиваются вопросы "А мы думали что вот так будет", "А давайте ещё вот это сделаем");
2. Предоставить инструмент контроля реализации проекта для Заказчика и Исполнителя. (Ответы на вопросы "А как там у нас проект двигается", "Что ещё надо по этому проекту сделать");
3. Создать точные указания для команды разработчиков. (уменьшение временных и материальных затрат на менеджмент во время реализации);
4. На этапе проектирования выяснить и утвердить методы решения нестандартных задач и используемые технологии (уменьшение количества промежуточных согласований, разделение аналитических работ и производства).

Другие факторы необходимости ТЗ (а их ещё много можно вывести) так или иначе относятся к вышеперечисленным.

Кажется, ТЗ полезно всем и всегда? Не совсем так. Само по себе оно конечно полезно, но есть варианты, в которых ТЗ больше вредит, чем помогает.

Когда ТЗ не нужно

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

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

Полнота описания

Полнота описания может быть различной, в зависимости от того, реализуется ли проект «с нуля», либо на базе стандартных решений. Например, внедряемая CRM-система может разрабатываться специально под нужды компании, без использования существующих решений, либо базироваться на одном из «конструкторов», вроде 1C, Terrasoft, Bi-Micro.

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

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

Пункты типичного ТЗ на сайт

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

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

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

Информационная архитектура описывает элементы дизайна – информационные и навигационные блоки с точки зрения их содержания (отображения той или иной информации) и взаимного расположения. Здесь как раз очень уместны схемы.

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

Программные модули – пожалуй, самый технически насыщенный и зачастую, самый объёмный раздел. В зависимости от требований и стандартности описываемых модулей, может содержать как краткое описание функционала, так и словесное описание реализации, с точностью до форматов полей в базе данных.

Технические требования к окружению – очень важный раздел, которому при согласовании часто уделяется недостаточно внимания. Описывает необходимые системные требования к «железу» и программному обеспечению, в окружении которого будет работать создаваемый продукт.

Надеюсь, информация этой статьи поможет вам в дальнейшей работе с IT-компаниями, и избавит хотя бы от некоторых сложностей в общении с разработчиками.

Специально для Рекламного Штурмана,
Кондратий Ермолин < equa@conanima.ru >
группа компаний Анима < www.conanima.ru >