Техническое задание и легкость бытия

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

Но подождите! У вас что, нет технического задания?!

Тогда давайте сначала о том, что без ТЗ никак. Да, совсем. Ну или нет, вы можете, конечно, написать разработчикам с вопросом: «А вот сколько за сайт как Фейсбук?» (Вот прям так и спрашивают). А они вам: «Вот стоооолько денег в условных единицах». А вы так: «Ну ясн.»

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

Разумеется, каждая из сторон всегда считает себя правой в любой понятной и непонятной ситуации. Но если ТЗ некачественное, то видим следующую картину:

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

• Клиент принимает то, что есть.
• Разработчик доделывает все бесплатно.
• Стороны договариваются и идут на взаимные уступки.

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

Посмотрим, как это сделать с позиции сотрудничества внешнего заказчика и аутсорс-компании.

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

Грамотно составленное ТЗ бережет ваши нервы и дает плюс к карме!

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

Концепция спецификации позволит вам определить ключевые моменты, сократить риски, донести свое видение до исполнителя и разложить проект по полочкам. А значит, вы сэкономите много времени и сил.

Обычно в предварительный план технического задания включают такие тезисы, как:

• Задачи и цели, описание бизнес-идеи
• Назначение проекта
• Роли исполнителей
• Примерная структура программы

А потом все это уточняется и собирается в утвержденном формате. В зависимости от целей проекта и степени формальности, вы можете воспользоваться стандартом IEEE, ГОСТом или своим индивидуальным корпоративным шаблоном.

Структурируем свое техническое задание

Разумеется, каждое ТЗ составляется индивидуально под проект и отдельные детали включаются по соглашению сторон. А мы остановимся на musthave разделах технического задания:

1. Общие положения

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

2. Цели

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

3. Функциональные и специальные требования

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

4. Процесс разработки

В этом пункте можно обозначить примерные временные рамки начала и конца работы над проектом, промежуточные дедлайны, желаемые системы управления задачами для отслеживания прогресса, и, если необходимо, метод разработки (Waterfall или Agile).

5. Изменения

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

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