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

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

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

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

Автоматизация завода

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

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

Юзкейс — это блок-схема или последовательность шагов с текстовым описанием. Обычно описывает рабочий процесс в деталях через последовательные шаги.

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

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

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

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

Оно отображает все функции системы и их смысл.

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

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

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

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

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

Арктик

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

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

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

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

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

Это UX прототип для сбора обратной связи от будущих пользователей, а не финальный интерфейс.

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

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

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

Выводы

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

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

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

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

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

2727
7 комментариев

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

4
Ответить

да, жиза. Баланс - это ключевое. Важно на старте хорошо расписать приоритеты, чтобы система решала задачи. И при этом были учтены все важные факторы и функциональность.

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

Ответить

Да, ТЗ на 50 страниц, да ещё и с диаграммами, часто ведут к тому, что заказчик смотрит, аппрувит, а через пару месяцев осознаёт, что что-то недопонял, и надо всё переделать. И желательно, вчера :/

2
Ответить

что-то все равно не понял, чем графическое техзадание отличается от вайрфрйема?)

1
Ответить

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

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

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

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

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

1
Ответить

Достаточно интересно было ознакомиться ,спасибо за информацию

Ответить

Отлично! Очень интересно, спасибо автору!

Ответить