Компания Ratio составила три шаблона технических заданий: для дизайнеров, программистов и веб-разработчиков полного цикла. Можно скачать и заполнить их — исполнитель точно поймёт, какой сайт вам нужен.
ТЗ в строгом значении слова — это документ, закрепляющий критерии, по которым будет приниматься работа. Но на практике под техзаданием часто понимается целый комплект документов: концепция проекта («что это такое?»), спецификация («каким проект должен быть?»), описание разделов и модулей будущего сайта.
Мы понимаем под ТЗ подробную формулировку задачи, которую заказчик составляет вместе с подрядчиком. В шаблонах от Ratio учтена вся информация, которая требуется нам для начала работы. Можете разбить документ на части и согласовывать их отдельно — так или иначе, к началу проекта информация по списку будет готова.
Если сайт или приложение действительно необходимы, то не жалейте времени на подробное ТЗ — оно закрепляет принятые решения и позволяет обойтись без повторных обсуждений. Техзадание гарантирует, что вы и исполнитель мыслите в одном направлении: на бумаге ваши требования к проекту что-то значат, их не получится забыть или проигнорировать.
Кроме того, ТЗ — это возможность проверить проект на слабые места. Составив техзадание, вы увидите скрытые ошибки и устраните их до того, как они превратятся в проблему.
Техзадание начинается с одного предложения — например, «нужно добавить функцию X на готовый сайт интернет-магазина». В дальнейшем это предложение раскрывается подробнее.
Структура ТЗ на веб-разработку:
Описание проекта: концепция, гипотезы, целевая аудитория, критерии успеха.
Исходные данные: чеклист контента, полное описание разделов проекта с примерами
Задание на дизайн: механика работы блоков и дизайн-прототип со ссылками на psd-исходники
Задание на разработку: структура разделов проекта, их описание, а также технические требования и ссылки на готовый дизайн
Описание разделов составляйте развёрнуто: не просто «раздел Работа у нас», а структура страницы, контент, нужна ли форма обратной связи и какие поля должны в ней быть.
Сроки и штрафы в ТЗ лучше не упоминать, они закрепляются в более значимых документах — договоре и дополнительных соглашениях. Правки тоже прописываются отдельно, в листе возражений к приёмке.
Разбираться в чужих мыслях трудно, можно запутаться и что-то пропустить. Постарайтесь облегчить жизнь подрядчикам — это поможет им сделать работу быстрее.
На что обратить внимание:
Составляйте списки (вместо сплошного текста)
Оформляйте заголовки через стили H1, H2 и так далее (для автоматического оглавления в Google Документах)
Выделяйте ключевые фразы (для чтения по диагонали)
Нумеруйте страницы, пункты и подпункты (чтобы во время обсуждения легко понимать друг друга)
Пользуйтесь внутренними ссылками
Из-за внутренних ссылок документ приходится листать туда-сюда, но они необходимы — ТЗ редко получается с первого раза, обычно туда вносят правки. Если повторять одну и ту же информацию несколько раз, корректировать ТЗ будет неудобно: в одном месте поправили, а ещё два забыли.
Техзадание на комплексную разработку — это ТЗ дизайнера и программиста в одном флаконе. К этому документу часто обращается менеджер, ведь ему нужно видеть полную картину, чтобы направлять команду.
Конечно, универсальной формы для техзадания не существует. Мы просто делимся нашими наработками, поэтому используйте шаблон как основу, но не бойтесь изменять или дополнять его.
Хорошим ТЗ я считаю документ, который не вызывает вопросов ни у заказчика, ни у конечного исполнителя. Разночтений быть не должно, поэтому в начале нужно встретиться или созвониться, возможно, даже несколько раз. В результате вы составите подробное описание проекта, на основе которого можно сделать техзадание.
Обычно над документом трудится целая команда. В крупных проектах можно разделить ТЗ на функциональную и техническую части, но лучше отправляйте их единым файлом — так проект будет восприниматься цельно.
Если вам нужен только дизайн, то воспользуйтесь этим шаблоном. Но учтите, что для начала работы понадобится контент: тексты, фотографии, логотипы и иллюстрации.
Если есть задача, но нет контента, всё пойдет плохо, ведь моя работа зависит от качества исходящей информации.
Мне удобно, когда ТЗ оформлено в виде списка страниц. Чтобы чётко и понятно, без лишних слов был расписан ключевой смысл сайта, его экранов и разделов. Написать такое ТЗ может не каждый клиент, часто приходится самостоятельно придумывать структуру и закладывать в неё смыслы. Но есть люди, которые уже видят конечный результат — именно у таких клиентов получаются хорошие ТЗ. Мне остаётся только воплотить их задумки в жизнь.
Если вам нужны только услуги программиста, значит у вас есть готовый дизайн — без него приступать к разработке нет смысла. В техзадании обязательно укажите ссылки на правильно подготовленные макеты под все поддерживаемые устройства.
Идеальное ТЗ для программиста должно быть однозначным и полным, чтобы разработчик выполнил задачу без единого вопроса.
Если нужно подготовить вёрстку/фронтенд, внутри должны быть показаны и описаны все состояния, трансформации и анимации элементов. Не забудьте описать интерфейс бэкенда — спецификацию API или простых запросов.
Чтобы сделать бэкенд, понадобится описание необходимых алгоритмов (основанные на User Stories и бизнес-требованиях), структуры данных (сущности и их характеристики), а также точек интеграции бэкенда с фронтендом и другими системами.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Директор Ratio
Если подрядчик работает по продуктовому подходу, с тестированием гипотез и поиском лучших решений, то на старте подробная техническая спецификация всех функций проекта, скорее всего, не понадобится. После первых прототипов ход разработки почти всегда меняется, поэтому прописывать все мелочи сразу нет смысла.
Но даже при продуктовом подходе вам нужна общая концепция с гипотезами по проекту. В дальнейшем гипотезы будут подтверждаться или опровергаться, это позволит нащупать вектор развития.
Убедитесь, что в заявке вы описали целевую аудиторию и зафиксировали бизнес-показатели, на которые будет ориентироваться продуктовая команда. Дальше по принципу sales first сразу начинаем работу над MVP — первым прототипом, с помощью которого можно быстро проверить спрос и собрать данные для аналитики: как пользователи переходят на сайт, куда нажимают и какие остались впечатления.