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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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