Как заставить клиента читать ТЗ? Нарисовать его!

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

Техническое задание на 170 страниц никто не прочитает

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

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

Визуализация: 170 страниц в 4 картинках

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

Кто такие сущности и где они обитают

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

Изображение 1

Чтобы разобраться в сущностях, возьмите глубинное интервью у заказчика. Под словом «глубинный» мы подразумеваем, что оно:

• подготовлено и структурировано заранее;
• содержит открытые вопросы;
• выявляет основные боли, потребности и желания клиента.

Схема сущностей помогает «выяснить отношения» между участниками и элементами сайта. Клиент может выдавать разрозненные ответы о том, как он видит работу ресурса, как пользователь взаимодействует с различными функциями продукта, какие опции и на каких этапах ему доступны. Вы всё это слушаете, визуализируете, приходите к клиенту и говорите: «так»? И после ответа «да» двигаетесь к следующему этапу работы.

IT-кастинг: какую роль выбрать

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

Мы предлагаем визуализировать схему ролей как пирамиду: в нижней части расположите обычных гостей сайта, а дальше разместите пользователей по ступенькам в зависимости от уровня их доступа и «полномочий».

Изображение 2

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

Что такое действия и как их делать

Чтобы создать схему действий, нужно ответить на вопрос: как роли взаимодействуют с сущностями? Спросите клиента: «что будет делать пользователь на вашем сайте?». Собирается ли гость что-то купить, нужно ли ему заполнять форму для регистрации, какие разделы ему необходимы? В итоге у вас должна получиться классическая блок-схема, где важнее даже не то, что вы напишете в самом прямоугольнике как конечный результат, а описание самого пути.

Изображение 3

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

Майндмэп для проекта: как отрисовать структуру сайта

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

Изображение 4

Здесь уже не нужно прописывать конкретные действия пользователей, которые приводят их к определённым точкам. Это верхнеуровневый макет, где должна быть глобально видна взаимосвязь элементов внутри ресурса. Когда будете составлять структуру, держите под рукой текстовую версию технического задания: все детали и комментарии не уместятся на одном изображении.

Прототипы: как собрать всё воедино

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

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

Изображение 5

Проектную документацию на один лист посмотрят все

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

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

2. Поэтапное согласование каждого визуала минимизирует риск глобальных правок, когда проект уже будет запущен в работу.

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

Источник фото на тизере: