Создаём понятное техническое задание: опыт Аспирити

Мы в Аспирити не делаем длинные технические задания. Вместо этого все требования визуализируем через макеты, кликабельные прототипы и графические ТЗ. В статье покажем, как это работает на наших проектах.

Почему мы используем такой метод?
- чтобы клиенту было проще представить себе проект и предоставить качественную обратную связь;
- чтобы уменьшить количество правок на более поздних этапах разработки;
- чтобы найти общий язык с командой клиента и пользователями с начала проекта.

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

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

Чтобы работник завода мог быстрее понять, что мы пытаемся сделать и что получится в итоге, лучше показывать всё на картинках и примерах.

Для этого проекта мы сделали графическое техзадание.

С графическим ТЗ работникам завода становится проще отследить цепочку взаимодействия с интерфейсом, а значит, и понять, все ли функции учли на этапе составления ТЗ.

Этот подход позволил нам избежать крупных правок в будущем.

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

В качестве дополнения оно даёт большую предсказуемость по срокам, помогает дать более точную оценку в начале работы над проектом, а также избежать появления множества правок и доработок в процессе разработки. А ещё на основе графического ТЗ легче отрисовывать итоговый UX и UI.

Мы автоматизировали отдел управления недвижимостью и инвестиционными проектами для крупного частного провайдера финуслуг в Норвегии. В отделе компании работает 30+ человек. У каждого из них был свой список задачников, эксель табличек, заметок, папок и календарей. Из-за такого обилия инструментов, человеку непосвящённому во внутреннюю кухню компании было сложно сделать единую систему, которая бы управляла бизнес-процессами и при этом была удобна для всех. Поэтому до разработки нужно составить такое техническое задание, которое учтёт все подводные камни в юзер стори и текстах, а также опишет корнер-кейсы.

При этом обычному сотруднику Арктика, как и работнику завода, всё равно, что будет написано в техническом задании. Он как пользователь не принимает участия в разработке новой системы, ему вообще удобно работать как раньше. А ещё он не несёт ответственности за провал проекта, не мотивирован искать истину в техническом задании и следить, чтобы учли все важные моменты. Если начать разработку по такому ТЗ, то высока вероятность, что придётся вносить изменения, а процесс затянется.

Чтобы максимально вовлечь таких сотрудников в процесс, вместо кучи листов текста с описанием функциональности, мы отрисовали макеты экранов с комментариями к ним.

Например: здесь вы вбиваете число А, далее применяется формула Б из макроса В и т. д.

На выходе получился кликабельный/интерактивный прототип в Figma, который мы отдали на тестирование будущим пользователям системы. Если сравнивать с графическим техзаданием, то это более проработанная версия, которая на экранах отображает не только функциональность, но и даёт представление о будущем дизайне, так как предполагает проработку UX дизайна.

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

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

При таком подходе пользователю гораздо проще представить себя за работой, и он быстрее воспринимает информацию. Обратная связь получается в формате: «Вот здесь я вношу данные Х, здесь формирую отчёт У. Кажется, этой форме не хватает нужного мне поля. А в этой карточке здорово было бы видеть номер телефона клиента и т. д.». В тексте зачастую сложно заметить такие мелочи.

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

Это чревато затягиванием релизов, перерасходом бюджета и прочими неприятными штуками. Интуитивно понятно, что чтобы не допускать таких просчётов, нужно глубже погружаться в бизнес заказчика, а также более плотно взаимодействовать с будущими пользователями системы. Это помогает выявить все сценарии использования будущей системы и учесть их при разработке. Однако пользователь не всегда мотивирован разбираться в объёмных технических заданиях и наборе юзер сторис от аналитика.

По нашему опыту превращение текста в понятное техническое задание позволяет делать процесс разработки более предсказуемым для всех сторон. Безусловно, визуальное отображение для ТЗ требуется не везде. Мы используем его только на крупных и технически сложных проектах, а также на проектах с узкой специализацией. Оно также может пригодиться для частей проектов с уникальным функционалом.

Такой подход к проектированию создаёт понятные ожидания у пользователей, что помогает при последующем вводе в эксплуатацию. Пользователь уже видел блок-схемы и макеты, а значит, понимает чего ожидать. На том же заводе это критически важно, так как позволяет пользователям быстро разобраться в системе без просадок на производстве.

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