DashaMail
06 апреля 2016, 10:00
9

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

И взошел директор по проектированию qb.digital Виталий Мазуревич на гору, и были даны ему Скрижали Завета, как делать правильное ТЗ.

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

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

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

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

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

17 курсов по интернет-маркетингу со скидкой до 50%!

Учебный центр Skillbox проводит новогоднюю распродажу: 17 отличных курсов по интернет-маркетингу и менеджменту со скидкой до 50%! В наборе:

  • Интернет-маркетолог от А до Я
  • Управление репутацией бренда
  • Сквозная аналитика
  • Управление digital-проектами
    и многое другое
Большие скидки, возможность рассрочки платежа. Предложение действует только до конца декабря.

Узнать больше >>>

Реклама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Не пропустите!

6 ошибок в работе со сквозной аналитикой
Нужен ли вашему бизнесу SMM? Даем ответы на все вопросы о продвижении в социальных сетях
Клиентские манипуляции и как их нейтрализовать
План обучения младшего дизайнера в IT-Agency
10 непростительных ошибок в контекстной рекламе: чеклист для новичков
«Хантеры рекомендуют на время поиска работы снизить активность в соцсетях», — Алёна Владимирская
Меньше денег и сплошные переговоры: что бывает, если фрилансер открывает агентство
Почему технарю легче стать хорошим копирайтером, чем гуманитарию. Три факта и личный опыт
Маркетинг влияния: 10 сценариев работы с лидерами мнений
Все знают, но никто не делает: 5 правил, которые ускорили работу команды на 13%
Маркетинг в мире, где города превращаются в новые государства
«Доброе время суток, Карл!» — Почему нас вдруг стали бесить новомодные словечки и крылатые выражения

Комментарии:

Все верно. Сделать хорошее ТЗ - это половина работы.
Кирилл, золотые слова!
- 1 +
Mukla Kuklus #
06.04.2016 14:12
Не читал, но одобряю.
- 1 +
Mikhail Vasiliev #
06.04.2016 15:51
"и на базовом уровне понимает процессы верстки и программинга."
не понимаю этого предложения. Очень размытая формулировка.
Должен ли ПМ. который пишет ТЗ разбираться в коде? Знать язык, на котором этот код написан? Что вообще подразумевалось под этим?
Михаил, тут речь идёт о том, что автор ТЗ должен понимать предметную область сайта, атрибуты сущностей и связи между ними, а также формат этих атрибутов. Т.е. нужно понимание архитектуры БД сайта, но именно на уровне сущнойстей. Знать код для этого совсем не обязательно, это уже вотчина разработчика.
Замечательно: внятно и кратко. Шестой пункт хотет хотет хотет, но непонятно, как внедрить =( добавить ещё документ-черновик в начало работы?
Мила, спасибо. Внедрять надо просто, быстро и решительно. Просто в какой-то момент начать разработку по такой схеме и продавать Заказчику именно такой подход. Почитайте статью вот тут - http://www.cossa.ru/152/112680/ - здесь реальны доводы в пользу такого подхода. Что же касается черновика на начало работы, то у нас есть специально разработанная система документации, которая позволяет с самого начала зафиксировать продукт. Подробнее можете тут посмотреть - https://vimeo.com/143387909
Реклама


🤔 Чем живёт digital?
Главное — в рассылке:




Вход на cossa.ru

Уже есть аккаунт?
Выбирай любой вариант входа:
Facebook Vkontakte

Используйте свой аккаунт в социальной сети Facebook или Вконтакте, чтобы пользоваться сайтом

Не забудьте написать email на странице своего профиля для управления рассылкой