Допустим, у вас есть свой бизнес и вы успешно дошли до фазы «Нам нужен сайт» или даже «Нам нужно автоматизировать важный бизнес-процесс». Вы даже нашли ребят, которые с удовольствием готовы реализовать любые смелые затеи, но есть один нюанс: команда разработки просит сформулировать задание на проект (обычно это называется «Дайте-нам-ТЗ»). И с этого момента 99% заказчиков начинают делать и писать совсем не то, что просит подрядчик.
В этой статье мы расскажем, как самостоятельно составить действительно полезный документ, который поможет понять задачу, а не наоборот.
Что такое техническое задание (и почему на самом деле вам нужно не оно)
Для начала пора бы разобраться в терминологии: в процессе разработки проекта мы постоянно пишем какие-то документы, у всех них разное назначение и пишутся они для разных участков проекта и разной аудитории.
На старте проекта команде важно понять бизнес-задачу:
- каким бизнес-целям должен служить разрабатываемый продукт?
- какие задачи продукт должен решить?
- кто и в каких ситуациях будет пользоваться продуктом?
- какие есть ограничения в части реализации?
- какие конкуренты у бизнеса и у продукта?
Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием — техническое задание.
Что есть ТЗ?
Это документ, на основании которого команда разработки реализует проект, и который описывает:
- назначение системы, которую надо разработать;
- перечень функций и алгоритмов, которые должны быть реализованы в рамках проекта;
- требования к интерфейсам;
- требования к интеграциям (включая техническое описание API или любого другого формата обмена данными, который предполагается использовать);
- требования к архитектуре системы;
- бизнес-процессы;
- пользовательские сценарии;
- методологию разработки;
- технологический стек (какие технологии будут использованы и почему);
- и много чего еще.
То есть ТЗ содержит исчерпывающие знания о назначении системы, функциональности и методах реализации и отвечает на вопросы:
- Какие компоненты включает система и как они будут взаимодействовать?
- Какие функции и алгоритмы нужно разработать, как именно и при помощи какого стека технологий?
- Как должен вести себя интерфейс
Очевидно, что разработка такой документации требует, во-первых, специализированных знаний (поэтому ТЗ пишут, как правило, системный аналитик или ведущий разработчик), во-вторых, понимания бизнес-целей и задач.
Вывод: на старте проекта нам нужно не ТЗ, описывающее, как делать систему, а документ, отвечающий на вопрос «Зачем и для кого мы делаем эту систему?»
Как сформулировать бизнес-требования
Документ, описывающий бизнес-цели и бизнес-требования к системе, называется Business Requirements Document, или BRD, или бизнес-и-функциональные требования к системе.
Составить такой документ можно самостоятельно, если следовать определенным алгоритмам.
Рассмотрим на примере: у клиента есть некий бизнес и ощущение (возможно, подкрепленное статистикой), что бизнес начал или продолжает стагнировать.
Бизнес: магазин виниловых пластинок, представленный в Москве несколькими точками оффлайн-продаж.
Проблематика с точки зрения владельца бизнеса: коллекционеры винила не имеют возможности регулярно посещать магазин, мониторить новинки и оперативно заказывать интересующие товары, а поскольку бизнес не автоматизирован — все предзаказы делаются только по телефону, что неудобно и бизнесу, и покупателю.
В итоге магазин упускает потенциальную прибыль, увеличивает нагрузку на продавцов и консультантов, имеет скудное представление о портрете своего покупателя и не может коммуницировать с аудиторией в объеме, необходимом для выстраивания дальнейшей маркетинговой стратегии. Плюс на складе постоянно оказываются какие-то неучтенные остатки, что искажает статистику товарооборота.
Решение: разработать интернет-магазин, в котором покупатель сможет посмотреть весь каталог, сделать предзаказ и отследить его исполнение, а продавец — обеспечить своевременное исполнение заказа, получить отчет о состоянии склада, по пути сняв статистику о пользовательских интересах и пользовательском поведении.
Итак, у нас есть понимание бизнес-проблемы и ее решения. Тут важно не начать писать ТЗ, а все же написать Бизнес-требования (невзирая на творческий зуд, стимулирующий к написанию детального задания на разработку).
Начинаем документ с пункта «Бизнес-цель». Наши бизнес-цели следующие:
- Увеличить оборот товара на складе.
- Собрать данные о целевой аудитории для дальнейшего использования в разработке маркетинговых стратегий.
- Снизить нагрузку на персонал магазинов за счет автоматизированности функций заказа / оплаты / доставки.
- Увеличить процент повторных продаж.
Если понятны цели — становятся ясны и задачи проекта:
- Обеспечить функции предзаказа товаров, оплаты и доставки.
- Настроить систему сбора статистики по продажам.
- Настроить систему учета остатков на складах.
- Обеспечить функции возврата покупателей.
Промежуточный результат: сформулирован перечень задач, где каждая задача привязана к определенной (или нескольким) целям.
Теперь уточняем, что должна уметь делать система, чтобы каждая задача в разрезе каждой цели была успешно решена. То есть фиксируем основные функции системы.
На выходе должна получиться вот такая матрица
Теперь команде разработки понятно, зачем заказчику нужен интернет-магазин, какими базовыми функциями он должен обладать и по каким параметрам будет оцениваться успешность проекта.
Но обычно интернет-магазины не эффективны, если у них нет интерфейса.
А как же требования к дизайну?
Формулируя эти требования, многие скатываются в формат «я хочу / мне нравится», проецируя таким образом личное чувство прекрасного на систему, которая в первую очередь должна быть функциональной и удобной.
Важно понимать, что дизайн — не изобразительное искусство, в отношении которого каждый имеет право на мнение «нравится / не нравится», а интерфейс — не просто какая-то интерактивная картинка, раскрашенная в разные цвета.
Интерфейс (экраны, страницы) — это как раз тот набор элементов (картинки, тексты, кнопки, галочки, интерактивные формы и т.д.), при помощи которого пользователи будут взаимодействовать с вашей системой. И требования к нему должны быть обоснованы функциональным назначением системы и сценариями использования.
Чтобы нарисовать качественный дизайн, нужно понимать, каким целям он будет служить (на эти вопросы отвечает BRD), какой контент будет публиковаться, какие есть технические ограничения по реализации и поддержке.
Требования к интерфейсу
Скажем сразу — ничто так не радует сердце UI/UX-проектировщиков и дизайнеров интерфейсов, как референсы. То есть примеры уже реализованных похожих проектов.
Референсы просят не потому, что каждый творец в душе плагиатор и хочет облегчить себе жизнь, а потому, что восприятие у всех разное и трактовать формулировки вида «хочется чего-то травянисто-зеленого и вызывающего ощущение летнего пикника на даче у бабушки» в разрезе конкретной задачи на дизайн — заведомо игра в гадание на гороскопах, потеря смысла задания и времени.
Добавить же в BRD ссылку на уже работающий проект — явно проще, чем детально описать каждую страницу, рискуя быть неправильно понятым.
Вывод: команде будет намного проще понять задачу по дизайну, если в ее описании присутствует:
- Описание пожеланий в сочетании с описанием реальных возможностей заказчика (например: «у нас есть отличные фото продукции в высоком качестве, поэтому хотелось бы использовать это в дизайне»; «у нас красивый логотип и мы хотели бы использовать его цвета и в дизайне сайта»; «у нас много хороших текстов, описывающих преимущества нашего магазина, и было бы хорошо их разместить»).
- Перечень ограничений (например: «не использовать черный цвет»; «нет качественных фото продукции»).
- Ссылки на нравящиеся сайты близкой тематики с кратким описанием, почему нравится тот или иной компонент.
Держаться в рамках, соблюдать границы
Итак, выше мы договорились, каким целям будет служить наша система, каким требованиям будет соответствовать интерфейс. Следующий важный момент — определить границы системы и рамки проекта.
Границы системы — это набор компонентов системы, взаимодействующих друг с другом в рамках выполнения соответствующих бизнес-процессов.
Например, мы понимаем, что интернет-магазин будет интегрирован с некой системой товарооборота, откуда интернет-магазин получает данные о товарных остатках и их стоимости (допустим, у нас 1С УТ), следовательно 1С — это важный компонент всей системы, который принимает участие в таких бизнес-процессах, как «Публикация товарного каталога на сайте» и «Оформление товара покупателем».
Рамки проекта — это набор функций системы, которые должны быть реализованы в рамках проекта «Разработка интернет-магазина».
Если обращаться к примеру с интеграцией 1С — то задачи по интеграции с 1С в рамки проекта укладываются, а вот задачи по возможным доработкам 1С — будут относиться к другому проекту.
Заключение
- При формировании требований на разработку пишем не техническое задание, а бизнес-и-функциональные требования.
- По возможности — описываем основные процессы, характерные для вашего бизнеса.
- При формировании требований к дизайну — оперируем референсами, а не личными эстетическими настройками.
- Определяем границы системы и проекта, явно обозначаем их команде разработки и не выходим за эти рамки, пытаясь реализовать Систему-В-Широком-Смысле-Слова.
Практика показывает, что при соблюдении этих правил работоспособные системы выходят в релиз в должном качестве и в срок.