10 заповедей технического задания (с толкованием)

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

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

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

А потому, когда меня в один момент попросили прочитать доклад о техническом задании для сотрудников агентства, я растерялся. А про что читать? Рассказывать незаконченную историю становления технического задания? Разъяснить текущий формат, который к вечеру я захочу подправить?

Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*

Как получить измеримые результаты в фарммаркетинге.

Показываем на примерах →

Спецпроект

Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

1. ТЗ — обязательный документ при создании любого продукта

Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

2. ТЗ описывает продукт, но не проект

ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

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

3. ТЗ не является договором

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

4. ТЗ описывает не только функциональные требования, но и интерфейс

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

5. ТЗ составляет только обладающий соответствующей компетенцией специалист

Звучит просто, а реализуется сложно.

Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

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

7. ТЗ не терпит правок после его утверждения

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

8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

9. ТЗ должно описывать, как минимум, текущую версию продукта

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

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

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

Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.

Источник: cossa.ru