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