ТЗ — одна из самых сложных вещей в отношениях заказчика и технической команды. Это извечная проблема: клиенты не умеют его писать, а исполнители — без него работать.
Почему так происходит? Давайте сначала разберемся, что такое ТЗ. По сути, это технический документ, который описывает все требования к продукту. Проблема в том, что разработчик и заказчик чаще всего говорят на разных языках, поэтому для одного из них ТЗ другого выглядит как текст на китайском. Клиент мыслит категориями бизнеса, ему нужен продающий сайт. Для исполнителей понятие «продающий сайт» бесполезно: им требуется четкая инструкция, какие элементы должен включать в себя продукт, чтобы быть продающим. Так, при ремонте квартиры вы подробно рассказываете рабочим, какая кладка плитки должна быть в ванной, сколько розеток в гостиной, какой высоты натяжные потолки и какого бренда оконные пакеты. Если же вы придете с запросом сделать вам стильный ремонт — скорее всего, в финале выяснится, что представление о стиле у вас и у строительной бригады не совпадают.
С техническим заданием для сайта или приложения все намного сложнее: например, может оказаться, что функционал сервиса технически нереализуем в том виде, в котором хочет его видеть клиент — поэтому продукт надо строить по-другому. Или что задача, которая кажется заказчику маленькой и несложной, на самом деле большая и трудоемкая. А значит, что работа займет больше времени, чем предполагалось, и сроки проекта будут сорваны.
Как написать ТЗ
На самом деле нет универсального способа составить техническое задание. Например, мы используем интерактивный метод, когда сначала делаются прототипы с комментариями, а затем на их основе пишется само ТЗ. Это удобно для наглядности и ведения диалога с клиентом. Расскажем о том, как выглядит этот процесс:
Структура технического задания:
-
Описание проекта и компании: задачи, которые призван решить продукт, ценности и пожелания заказчика, фирменный стиль, УТП и аудитория бизнеса — все то, что помогает команде разработки быть в одном контексте с клиентом и сделать первые прототипы.
-
Прототипы: первые визуальные наброски будущего сервиса, благодаря которым можно визуально продемонстрировать его структуру.
-
Технологический стек: язык программирования, фреймворк, требования к хостингу и так далее.
-
Предполагаемая структура сервиса. К примеру, в ТЗ на разработку приложения для изучения английского клиент хочет видеть последовательность блоков с теорией и практикой, словарь, личный кабинет с настройками и главную страницу, где можно выбрать нужный урок. Такая структура может быть сделана в формате описания или схемы.
-
Функциональные требования к каждой странице или экрану: описание того, что должно происходить на экране. Если вернуться к приложению для английского, на экране с практическим заданием будет вопрос и три варианта ответа. После выбора одного из них будет подсвечиваться правильный вариант, а затем экран автоматически переключится на следующий вопрос.
-
Пользовательские сценарии: что происходит, например, при платной подписке и бесплатной. Или какими способами пользователь может получить информацию о том или ином языковом правиле через приложение.
-
Контент: изображения, тексты, видео, аудиофайлы для тренировки произношения и прочее.
-
Финальные прототипы. После создания техзадания и согласования с заказчиком мы корректируем наши прототипы и обсуждаем их с заказчиком.
Кто должен заниматься разработкой ТЗ
Если заказчику нужен простой информационный сайт с обратной формой связи, техническое задание на него он вполне может написать самостоятельно. Но для комплексного продукта со сложным функционалом всегда лучше составлять ТЗ совместно с разработчиками. Так получится «смэтчить» бизнес-запросы с техническими требованиями.
И кстати, проект, который заказчик считает простым, может таить в себе много подводных камней. Поэтому перед созданием техзадания всегда лучше посоветоваться с технической командой. Например, с нами;)