Как правильно составить задание на разработку?

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

Что такое техническое задание (и почему на самом деле вам нужно не оно)

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

На старте проекта команде важно понять бизнес-задачу:

• каким бизнес-целям должен служить разрабатываемый продукт?
• какие задачи продукт должен решить?
• кто и в каких ситуациях будет пользоваться продуктом?
• какие есть ограничения в части реализации?
• какие конкуренты у бизнеса и у продукта?

Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием — техническое задание.

Что есть ТЗ?

Это документ, на основании которого команда разработки реализует проект, и который описывает:

• назначение системы, которую надо разработать;
• перечень функций и алгоритмов, которые должны быть реализованы в рамках проекта;
• требования к интерфейсам;
• требования к интеграциям (включая техническое описание API или любого другого формата обмена данными, который предполагается использовать);
• требования к архитектуре системы;
• бизнес-процессы;
• пользовательские сценарии;
• методологию разработки;
• технологический стек (какие технологии будут использованы и почему);
• и много чего еще.

То есть ТЗ содержит исчерпывающие знания о назначении системы, функциональности и методах реализации и отвечает на вопросы:

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

Очевидно, что разработка такой документации требует, во-первых, специализированных знаний (поэтому ТЗ пишут, как правило, системный аналитик или ведущий разработчик), во-вторых, понимания бизнес-целей и задач.

Вывод: на старте проекта нам нужно не ТЗ, описывающее, как делать систему, а документ, отвечающий на вопрос «Зачем и для кого мы делаем эту систему?»

Как сформулировать бизнес-требования

Документ, описывающий бизнес-цели и бизнес-требования к системе, называется Business Requirements Document, или BRD, или бизнес-и-функциональные требования к системе.

Составить такой документ можно самостоятельно, если следовать определенным алгоритмам.

Рассмотрим на примере: у клиента есть некий бизнес и ощущение (возможно, подкрепленное статистикой), что бизнес начал или продолжает стагнировать.

Бизнес: магазин виниловых пластинок, представленный в Москве несколькими точками оффлайн-продаж.

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

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

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

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

Начинаем документ с пункта «Бизнес-цель». Наши бизнес-цели следующие:

1. Увеличить оборот товара на складе.
2. Собрать данные о целевой аудитории для дальнейшего использования в разработке маркетинговых стратегий.
3. Снизить нагрузку на персонал магазинов за счет автоматизированности функций заказа / оплаты / доставки.
4. Увеличить процент повторных продаж.

Если понятны цели — становятся ясны и задачи проекта:

1. Обеспечить функции предзаказа товаров, оплаты и доставки.
2. Настроить систему сбора статистики по продажам.
3. Настроить систему учета остатков на складах.
4. Обеспечить функции возврата покупателей.

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

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

На выходе должна получиться вот такая матрица:

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

Но обычно интернет-магазины не эффективны, если у них нет интерфейса.

А как же требования к дизайну?

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

Важно понимать, что дизайн — не изобразительное искусство, в отношении которого каждый имеет право на мнение «нравится / не нравится», а интерфейс — не просто какая-то интерактивная картинка, раскрашенная в разные цвета.

Интерфейс (экраны, страницы) — это как раз тот набор элементов (картинки, тексты, кнопки, галочки, интерактивные формы и т.д.), при помощи которого пользователи будут взаимодействовать с вашей системой. И требования к нему должны быть обоснованы функциональным назначением системы и сценариями использования.

Чтобы нарисовать качественный дизайн, нужно понимать, каким целям он будет служить (на эти вопросы отвечает BRD), какой контент будет публиковаться, какие есть технические ограничения по реализации и поддержке.

Требования к интерфейсу

Скажем сразу — ничто так не радует сердце UI/UX-проектировщиков и дизайнеров интерфейсов, как референсы. То есть примеры уже реализованных похожих проектов.

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

Добавить же в BRD ссылку на уже работающий проект — явно проще, чем детально описать каждую страницу, рискуя быть неправильно понятым.

Вывод: команде будет намного проще понять задачу по дизайну, если в ее описании присутствует:

1. Описание пожеланий в сочетании с описанием реальных возможностей заказчика (например: «у нас есть отличные фото продукции в высоком качестве, поэтому хотелось бы использовать это в дизайне»; «у нас красивый логотип и мы хотели бы использовать его цвета и в дизайне сайта»; «у нас много хороших текстов, описывающих преимущества нашего магазина, и было бы хорошо их разместить»).
2. Перечень ограничений (например: «не использовать черный цвет»; «нет качественных фото продукции»).
3. Ссылки на нравящиеся сайты близкой тематики с кратким описанием, почему нравится тот или иной компонент.

Держаться в рамках, соблюдать границы

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

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

Например, мы понимаем, что интернет-магазин будет интегрирован с некой системой товарооборота, откуда интернет-магазин получает данные о товарных остатках и их стоимости (допустим, у нас 1С УТ), следовательно 1С — это важный компонент всей системы, который принимает участие в таких бизнес-процессах, как «Публикация товарного каталога на сайте» и «Оформление товара покупателем».

Рамки проекта — это набор функций системы, которые должны быть реализованы в рамках проекта «Разработка интернет-магазина».

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

Заключение

1. При формировании требований на разработку пишем не техническое задание, а бизнес-и-функциональные требования.
2. По возможности — описываем основные процессы, характерные для вашего бизнеса.
3. При формировании требований к дизайну — оперируем референсами, а не личными эстетическими настройками.
4. Определяем границы системы и проекта, явно обозначаем их команде разработки и не выходим за эти рамки, пытаясь реализовать Систему-В-Широком-Смысле-Слова.

Практика показывает, что при соблюдении этих правил работоспособные системы выходят в релиз в должном качестве и в срок.

Татьяна Болдырева, руководитель проектов.

Больше полезных материалов смотрите на Agima.ru.