А где, собственно, ТЗ?

Техническое задание (ТЗ) — основа для выполнения конкретных работ. В нём фиксируем, что нужно сделать, какие есть требования, ограничения и какой результат хотим получить. Хорошее ТЗ экономит время на коммуникациях, избавляет от многочисленных пересказов, подтверждений и путаницы в показаниях. Позволяет заранее обнаружить проблемы, разделить зоны ответственности, оценить объём работ и упростить сдачу-приёмку.

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

И в спорной ситуации письменные договорённости тоже пригодятся. Правда, юридическая сила ТЗ зависит от того, как оно согласовано и связано с договором. Само наличие документа ещё ничего не гарантирует.

Проджект должен писать ТЗ сам?

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

Если задача простая и отдельный аналитик для неё не нужен, менеджер вполне может составить ТЗ самостоятельно. А если задача сложная, организовать его подготовку вместе с командой и проследить, чтобы документ был согласован. И да, иногда всё-таки придётся писать это чёртово ТЗ самим.

Что должно быть в техническом задании

Что? Какие работы выполняем, какие элементы и функции должны появиться.
Где? Где располагаются элементы и в какой части продукта происходят изменения.
Когда? Какие сроки и последовательность работ согласованы, если они относятся к заданию.
Как? Как должен работать функционал, какие есть правила, ограничения и зависимости.
Откуда и куда? Откуда берём данные, куда передаём, что переносим и с чем интегрируем.
Зачем? Какую задачу решаем и какого результата ожидаем.
Какие особенности? Права доступа, ошибки, проверки, исключения и нестандартные сценарии.
Что получим? Как выглядит результат и по каким признакам поймём, что задача выполнена.
Как покажем? Что и в каком виде будем демонстрировать клиенту при сдаче.

Для некоторых объектов придётся отдельно описать добавление, отображение, редактирование и удаление данных. Для других — модерацию, валидацию, автообновление или архивацию. Не нужно механически добавлять весь этот набор в каждую задачу. Описываем только то, что действительно относится к функционалу.

А давайте без ТЗ?

Не давайте.

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

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

Как поставить задачу понятно

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

Допустим, клиенту понадобился баннер для новой акции. Посмотрим, как может выглядеть постановка задачи.

НЕТ

Привет! Я ща с дейлика вернулся, че там у тебя?

Привет, клиенту срочно нужен баннер для новой акции. Текст типа «Сидите дома с нами» (может, сами что поинтереснее придумаешь), в зелёненьких тонах каких-нибудь. Главное, чтоб тема домашняя была какая-нибудь. До семи сделаешь? Надо три варианта.

Задача в таск-трекере

Нужен баннер 468 × 60 px для акции (ссылка). Баннер будет сквозным на весь сайт. Текст: «Сидите дома с нами».
Цвета: обязательно присутствие фирменного #00B800. Шрифт: как у основных заголовков на сайте, можно использовать жирное начертание.
Идея: тематика удалённой работы, что-то среднее между офисом и домом, но с уютом. Фото людей не использовать, сосредоточиться на обстановке вокруг.
Референсы: ссылка 1, ссылка 2, ссылка 3. Дополнительно нужно согласовать: количество вариантов, формат итоговых файлов и срок выполнения. Срок до 19:00.

+ Сообщение дизайнеру

Привет! Я ща с дейлика вернулся, че там у тебя?

Привет! Есть довольно горящая задача, уже стоит на тебя, по срокам ориентируемся примерно на полдня. Требования с клиентом уже обсудили, задача в трекере. Посмотри, реально ли уложиться. Если есть вопросы или сомнения, давай обсудим.

Во втором примере у исполнителя уже есть конкретика. Но даже здесь не нужно делать вид, будто задача готова к работе на сто процентов. Сроки и объём вариантов сначала нужно проверить с дизайнером.

Что видно сразу в плохом ТЗ

Нечёткие цели и задачи.
Мало деталей в технической информации.
Размытые или неустановленные сроки.
Требования не согласованы между сторонами.
Не определены ответственные лица и порядок согласования.
Нет критериев оценки результата.
Отсутствуют ссылки на необходимую документацию сторонних сервисов.
Не проверены условия использования сторонних сервисов, лицензии и другие ограничения.
Не указано, что входит в работу, а что считается дополнительной доработкой.

Как работать с требованиями

Выявление. Определяем требования, выясняем потребности и ищем проблемы, которые должна решить задача.

Анализ. Разбираем требования, выделяем главное, обнаруживаем противоречия и недостающую информацию.

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

Документирование. Описываем согласованные требования и фиксируем то, что осталось открытым. После уточнений обновляем документ, чтобы команда не работала по устаревшей версии.

Объём, структура и границы работ

Чем сложнее проект, тем объёмнее может быть техническое задание. Бывают ТЗ и на 250–300 страниц. Но количество страниц само по себе не показатель качества. Для небольшой задачи иногда достаточно 1–3 строк, если в них действительно есть вся необходимая информация.

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

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

Избегаем абстрактных требований. Например, «должна быть удобная навигация». Для одного удобно, для другого неудобно. А выполнен ли такой пункт, непонятно именно из-за нечёткости формулировки. Лучше описать конкретное поведение: пользователь должен иметь возможность перейти из карточки товара в категорию, вернуться к результатам поиска или открыть корзину не более чем за определённое число действий, если такой критерий действительно согласован.

Обозначаем границы работ. Функционал, который не описан и не согласован, не должен автоматически превращаться в бесплатную доработку. При этом формулировку «всё остальное на усмотрение исполнителя» лучше не использовать как универсальную страховку. Условия изменения объёма работ и дополнительных согласований нужно закреплять в договорённостях сторон.

ТЗ для дизайнера

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

Минимум для разработки дизайна сайта:

Заполненный бриф, особенно если речь о редизайне.
Согласованные требования к дизайну.
Примеры и референсы.
Фирменные цвета, логотипы и другие материалы клиента.
Шрифты и информация о правах на их использование.
Согласованные прототипы страниц, если они предусмотрены процессом.

При подготовке прототипов лучше отказаться от рыбы вида «Lorem ipsum dolor sit amet» или «Тексттекстексттекст, а здесь будет прайс». Желательно использовать реальные материалы клиента или хотя бы тексты, близкие по смыслу и объёму к будущим. Так проще понять назначение каждого блока и оценить, насколько корректно он спроектирован. И дизайнеру, и менеджеру, и самому клиенту.

При получении материалов от клиента важно понимать элементарные требования к форматам. Например, JPG не лучший исходник для иконки, а логотип 100 × 100 px вряд ли подойдёт для большого баннера. Если нужен масштабируемый логотип, запрашиваем вектор.

Если дизайнер работает в Figma, заранее уточняем, какие исходники ему подойдут. Не нужно автоматически отправлять PSD и ожидать, что он откроется как обычный редактируемый файл. И до уверенного озвучивания клиенту каких-либо сроков обязательно советуемся с дизайнером, чтобы определить хотя бы вилку времени на задачу.

ТЗ для разработчика

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

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

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

ТЗ для SEO-специалиста

Если от клиента поступает задача для SEO-специалиста, фиксируем все требования в рабочей системе: что именно нужно сделать, на каких страницах, с какой целью и какой результат ожидается. Если это первая задача на подготовку текстов, можно попросить примеры с других сайтов. Необязательно даже из той же тематики. Главное, выяснить, что клиенту нравится, какие есть пожелания по содержанию, структуре и подаче.

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

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

Что в итоге

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

Главное, чтобы после прочтения ТЗ никто не сидел с вопросом «А что, собственно, делать-то?». И чтобы через месяц не выяснилось, что клиент представлял одно, менеджер согласовал другое, а команда вообще сделала третье.

Об авторе статьи

Аня Каргина

Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.

К началу статьи