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

Нажав кнопку "Принять и продолжить", вы соглашаетесь с Политики конфиденциальности

Принять и продолжить

Сообщить об ошибке

Отменить

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

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

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

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

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

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

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

Что есть ТЗ?

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Сэкономьте время на изучении Serpstat

Хотите получить персональную демонстрацию сервиса, тестовый период или эффективные кейсы использования Serpstat?

Оставьте заявку и мы свяжемся с вами ;)

Оцените статью по 5-бальной шкале

5 из 5 на основе 9 оценок
Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Поделитесь статьей с вашими друзьями

Войти Регистрация

Вы исчерпали лимит запросов.

Или email
Забыли пароль?
Или email
Back To Login

Не волнуйтесь! Напишите свой электронный адрес и мы пришлем вам новый пароль.

Вы уверены?

Awesome!

To complete your registration you need to enter your phone number

Назад

Мы отправили код подтверждения на ваш номер телефона

Your phone Resend code Осталось запросов

Что-то пошло не так.

Свяжитесь с нашей службой поддержки
Или подтвердите регистрацию с помощью Телеграм бота Перейдите по этой ссылке
Выберите один из проектов

Знакомство с сервисом

Ознакомьтесь с основными возможностями Serpstat удобным способом!

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

Имя

Email

Телефон

Будем рады вашему комментарию
Увеличить лимиты

Улучшить тариф

Экспорт недоступен для вашего тарифного плана. Вам необходимо улучшить свой тариф до Lite или выше, чтобы получить доступ к инструменту Подробнее

Зарегистрироваться

Спасибо, мы с вами свяжемся в ближайшее время

Пригласить
Просмотр Редактирование

E-mail
Сообщение
необязательно
E-mail
Сообщение
необязательно

У вас закончились лимиты

Вы достигли лимита на количество созданных проектов и больше не можете создавать новые проекты. Увеличьте лимиты или удалите существующие проекты.

Я хочу больше лимитов