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

197
#Менеджмент 10 июля 2019
  • Татьяна Болдырева

    Руководитель проектов

Допустим, у вас есть свой бизнес и вы успешно дошли до фазы «Нам нужен сайт» или даже «Нам нужно автоматизировать важный бизнес-процесс». Вы даже нашли ребят, которые с удовольствием готовы реализовать любые смелые затеи, но есть один нюанс: команда разработки просит сформулировать задание на проект (обычно это называется «Дайте-нам-ТЗ»). И с этого момента 99% заказчиков начинают делать и писать совсем не то, что просит подрядчик.

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

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

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

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

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

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

Что есть ТЗ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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


  • Татьяна Болдырева

    Руководитель проектов

Блог

0 / 0
+7 495 981-01-85 + Стать клиентом
Работа у нас