Зачем нужно ТЗ и чего ждать при работе без него?

Есть в психологии «Закон неадекватности взаимного восприятия». Его суть заключается в том, что человек никогда не воспринимает находящийся перед глазами предмет целиком, а видит его только в определенном ракурсе, по-своему.

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

Побороть их поможет исчерпывающее техническое задание (ТЗ). Про него давайте и поговорим.

ТЗ – вещь серьезная и нужная, раз уж даже ГОСТ на него есть

Важность того, что без ТЗ не обойтись, понимали еще в СССР. В 1989 году был разработан ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Документ получился исчерпывающим и полезным. Несмотря на то, что технологии с того времени сделали колоссальный рывок вперед, большинство тезисов этого ГОСТа разработчики, и мы в uncore в том числе, используем по сей день при подготовке ТЗ на приложения, сайты или иные программные продукты. 

Не верите? Попросите примеры ТЗ у нескольких подрядчиков и вы увидите, что они будут схожи по структуре и содержанию и будут перекликаться с ГОСТ 34.602-89. Правильная интерпретация положений стандарта гарантирует вам получение качественного исчерпывающего технического задания.

И это не единственный стандарт, на который можно опираться при разработке ТЗ. Полезную информацию разработчики и заказчики могут почерпнуть из ГОСТ 19.201-78, ISO/IEC/ IEEE 29148-2011, IEEE STD 830-1998.

Так что такое ТЗ, и что оно дает заказчику и подрядчику? 

ТЗ (на разработку web-сайта, интернет-магазина, мобильного приложения и т.д.) — это основной документ, определяющий требования к создаваемому продукту (решению), порядок его создания и критерии оценки (приемки).

Техническое задание необходимо и заказчику, и подрядчику. Почему? Давайте разберемся.

ТЗ сводит к минимуму разногласия между заказчиком и исполнителем

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

Техническое задание дает четкие критерии оценки готового продукта (сайта, сервиса, приложения)

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

Вот несколько примеров плохих и хороших формулировок из ТЗ на разработку сайта:

Т.е. нужно больше цифр и конкретных формулировок.

Зачастую за доработки, которые не определены в ТЗ разработчики берут доплату. Так что, чем оно полнее и детальнее, тем лучше.

Техническое задание поможет точно оценить затраты и возможности

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

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

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

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

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

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

Кто составляет техническое задание и что в нем должно быть

Если подрядчик говорит вам: «Сделайте ТЗ, а я все реализую», бегите от него.

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

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

Что должно быть в техническом задании

Рассмотрим примерное содержание на примере ТЗ на разработку сайта. Мы в uncore включаем в техническое задание следующие моменты:

• Пояснение используемых в документе терминов. Благодаря ему стороны понимают, что говорят друг с другом на одном языке и одинаково трактуют формулировки.
• Информация о компании-заказчике. Хороший подрядчик — тот, который готов вникнуть в бизнес клиента и разобраться с его потребностями, чтобы решить их максимально эффективно.
• Цели создания сайта и целевая аудитория. Понимание того, для чего делается веб-ресурс, влияет на результат. Кому-то важен дизайн и визуальные эффекты, а скорость не имеет большого значения. Кто-то будет использовать веб-ресурс как виртуальную витрину (интернет-магазин) и как основное средство коммуникации с клиентами – специфику всегда важно учитывать.
• Требования к сайту. Большой и важный раздел. Сюда включают все основные требования – технические и функциональные, описание архитектуры, ролей пользователей, сценарии использования, требования к дизайну, контенту. Обязательно должны быть указаны технические моменты (от скорости до используемых технологий и CMS). Не стоит забывать и про требования к хостингу, на котором будет размещаться веб-ресурс.
• Прототипы страниц. Не стоит пытаться описать все текстом. Наглядная информация воспринимается лучше.
• Стадии разработки. Благодаря этому заказчик видит, что и когда будет готово, и может контролировать процесс на разных этапах. А исполнитель, в свою очередь, понимает, что и когда от него ждут.

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

Общую структуру ТЗ, которую мы используем в своих проектах, вы можете посмотреть – здесь.

Вывод

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

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