Что такое ТЗ и зачем оно нужно

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

Проводя аналогию, это подобно проекту дома, по которому в дальнейшем идет его строительство.

Цель техзадания – конкретизировать, что и каким образом должно работать.

Более того, техническое задание является «общим знаменателем» в сравнении предложений у различных студий определяя объем работ. Только имея на руках готовое ТЗ, можно обращаться к различным подрядчикам для оценки стоимости проекта.

Что бывает без ТЗ?

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

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

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

Без ТЗ и результат ХЗ

Без ТЗ и результат ХЗ
Народная мудрость

Кто должен готовить техническое задание?

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

  1. Он компетентен в своей деятельности. Во всяком случае, так должно быть. Он способен предусмотреть многие ошибки и нюансы, исходя из своей квалификации, в отличии от клиента, который, зачастую, заказывает первый сайт в жизни.
  2. У него могут быть собственные наработки. С технической точки зрения, большинство сайтов имеют больше сходств, чем различий. Использование готовых наработок способно сократить сроки разработки, снизить бюджет и сфокусировать больше внимание на тех особенностях, которые делают сайт уникальным.
  3. Разработчик способен выразить мысль наиболее корректно и точно. Помимо ясного видения задачи, ее нужно отразить письменно таким образом, чтобы это не вызывало разночтений. Уметь сформулировать мысль ясно и четко – для многих клиентов оказывается крайне сложной задачей.

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

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

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

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

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

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

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

Абстракции, неопределенности и обобщенных пожеланий.

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

Как должно быть написано техническое задание?

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

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

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

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

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

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

Что делать с тем, чего нет в ТЗ?

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

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

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

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

Как оценить качество техзадания?

Дайте его прочитать паре Ваших сотрудников и спросите, все ли им понятно, остались ли вопросы, а потом – как это будет работать?

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

Для типовых сайтов, могут подойти друзья и родственники.

Юридическая значимость технического задания

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

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

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

Резюме

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

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

Понравился пост - поделись с друзьями:

Другие публикации из категории
Что важно знать, заказывая сайт, чтобы сэкономить время, деньги и нервы
Хватит читать –
время действовать!
8 918 067 72 93
Краснодарский край