Великолепная семерка пунктов техзадания на разработку сайта

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

Задача проекта

У любого сайта есть назначение. С помощью сайта решают те или иные задачи. Проблема в том, что во многих случаях заказчик считает, что цель проекта исполнителям ясна. На деле же о точной цели часто не ведает даже клиент, не говоря уже о подрядчике.
Слишком расплывчатая постановка вопроса и результату способствует аналогичному. Попробуйте попасть в нужную мишень, если по соседству с ней расположены десятки и сотни других, неотличимых от целевой. Задача нуждается в максимальной конкретизации и формализации. Но, как говорил Эйнштейн, «всё должно быть настолько просто, насколько возможно; но не более того».
Важно понимать, что задачи должны быть в формате, подразумевающем возможность измерений. Если стоит цель сделать сайт удобным для пользователя, необходимо прописать способы измерения удобства. Иначе можно говорить о пожеланиях и мечтах, но никак не о конкретике.
Измеряемые задачи позволяют определять эффективность сайта. Неизмеряемые не дают никакой возможности анализировать результат – заказчику и подрядчику остаётся гадать, насколько итог соответствует цели.

Целевая аудитория сайта

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

Описание персонажей

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

Истории персонажей (user story)

Целевая аудитория не существует в вакууме. У каждой группы есть своя история. Ваша задача на этом этапе – описать в техническом задании всевозможные ситуации взаимодействия персонажей с сайтом. Необходимо проследить и предугадать все шаги посетителя – от знакомства с сайтом до стадии принятия решения, характерного для определённой группы.
Путь пользователя к цели называется User eXperience (UX). Именно от опыта взаимодействия пользователя с сайтом зависит конечный результат. Останется посетитель довольным – вы получаете потенциального клиента. В противном случае, усилия оказались напрасными.

Функционал сайта

User story задают функционал площадки, который в ТЗ фиксируется в списочном формате. Далее список используется разработчиками в качестве ориентира для расстановки приоритетов. Это позволяет быстро доводить до ума не абстрактные, а соответствующие ожиданиям пользователей программные функции.
Последовательность важна – сначала персонажи и истории, а затем разработка функционала. Перестановка этапов с ног на голову приведёт к тому, что сайт будет спроектирован без учёта потребностей истинных заказчиков.

Вопросы интерфейса и дизайна

От user story во многом зависит и интерфейс сайта. Чтобы клиенту и прочим командным игрокам было проще представить результат, рекомендуется делать прототипы – статические или динамические. Первые используются при несложном функционале. Если статика позволяет уяснить суть, не нужно усложнять.
В остальных случаях прибегают к динамике. Такие прототипы схематично иллюстрируют расположение и работу основных элементов площадки в целом и отдельных страниц. Это полноценная имитация проектируемого сайта – есть возможность использовать навигацию и взаимодействовать с теми или иными компонентами сайта.
Требования к дизайну можно зафиксировать в формате Moodboard – коллажной доски, изображающей примеры дизайнерских решений будущего сайта. При разработке нужно учитывать, что идеальный дизайн незаметен. Посетитель должен решать задачи, не обращая внимания на визуальное оформление.

Технический потолок сайта

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