Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

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

5 <ul><li>каким бизнес-целям должен служить разрабатываемый продукт?</li>

6 <li>какие задачи продукт должен решить?</li>

7 <li>кто и в каких ситуациях будет пользоваться продуктом?</li>

8 <li>какие есть ограничения в части реализации?</li>

9 <li>какие конкуренты у бизнеса и у продукта?</li>

10 </ul>Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием - техническое задание.

11 <h2>Что есть ТЗ?</h2>

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

13 <ul><li>назначение системы, которую надо разработать;</li>

14 <li>перечень функций и алгоритмов, которые должны быть реализованы в рамках проекта;</li>

15 <li>требования к интерфейсам;</li>

16 <li>требования к интеграциям (включая техническое описание API или любого другого формата обмена данными, который предполагается использовать);</li>

17 <li>требования к архитектуре системы;</li>

18 <li>бизнес-процессы;</li>

19 <li>пользовательские сценарии;</li>

20 <li>методологию разработки;</li>

21 <li>технологический стек (какие технологии будут использованы и почему);</li>

22 <li>и много чего еще.</li>

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

24 <ol><li>Какие компоненты включает система и как они будут взаимодействовать?</li>

25 <li>Какие функции и алгоритмы нужно разработать, как именно и при помощи какого стека технологий?</li>

26 <li>Как должен вести себя интерфейс.</li>

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

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

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

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

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

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

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

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

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

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

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

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

39 <ol><li>Увеличить оборот товара на складе.</li>

40 <li>Собрать данные о целевой аудитории для дальнейшего использования в разработке маркетинговых стратегий.</li>

41 <li>Снизить нагрузку на персонал магазинов за счет автоматизированности функций заказа / оплаты / доставки.</li>

42 <li>Увеличить процент повторных продаж.</li>

43 </ol>Если понятны цели - становятся ясны и задачи проекта:

44 <ol><li>Обеспечить функции предзаказа товаров, оплаты и доставки.</li>

45 <li>Настроить систему сбора статистики по продажам.</li>

46 <li>Настроить систему учета остатков на складах.</li>

47 <li>Обеспечить функции возврата покупателей.</li>

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

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

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

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

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

53 <h2>А как же требования к дизайну?</h2>

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

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

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

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

58 <h2>Требования к интерфейсу</h2>

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

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

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

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

63 <ol><li>Описание пожеланий в сочетании с описанием реальных возможностей заказчика (например: "у нас есть отличные фото продукции в высоком качестве, поэтому хотелось бы использовать это в дизайне"; "у нас красивый логотип и мы хотели бы использовать его цвета и в дизайне сайта"; "у нас много хороших текстов, описывающих преимущества нашего магазина, и было бы хорошо их разместить").</li>

64 <li>Перечень ограничений (например: "не использовать черный цвет"; "нет качественных фото продукции").</li>

65 <li>Ссылки на нравящиеся сайты близкой тематики с кратким описанием, почему нравится тот или иной компонент.</li>

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

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

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

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

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

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

72 <h2>Заключение</h2>

73 <ol><li>При формировании требований на разработку пишем не техническое задание, а бизнес-и-функциональные требования.</li>

74 <li>По возможности - описываем основные процессы, характерные для вашего бизнеса.</li>

75 <li>При формировании требований к дизайну - оперируем референсами, а не личными эстетическими настройками.</li>

76 <li>Определяем границы системы и проекта, явно обозначаем их команде разработки и не выходим за эти рамки, пытаясь реализовать Систему-В-Широком-Смысле-Слова.</li>

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

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

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