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

Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».

Предпосылки

В проектной работе, к которой мы в свое время привыкли, этап проектирования начинался с передачи Технического задания (ТЗ). В практике встречались ТЗ разной степени проработанности. Нередко заказчик сам готовил ТЗ и часто это были документы низкого качества, которые требовали доработок.

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

Можно вспомнить еще другие частные частные варианты входа в процесс проектирования интерфейсов.

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

В основе нашего «но», которое побуждает менять практику лежит понимание того, что Time to market стал важным фокусом проектной работы. И вместе с этим, проект — это всегда люди, которые вовлечены со всех сторон. Так возникло убеждение, что нам надо учитывать необходимость поддержания клиентов во включенном в проект состоянии и для этого следует обеспечить контролируемую нагрузку и регулярность активностей.

Проще говоря, нужно аккуратно использовать ресурс бизнес-заказчика (product owner, клиента) — не перегружая его, но и не позволяя чересчур расслабляться. Ведь ничто так не загружает людей, как работа над большим ТЗ. Даже его вычитывание делает людей, которые специально к этому не готовились, глубоко несчастными. А те, кто готовились, выглядят уставшими.

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

Оба фактора часто верны и для бизнес-заказчика, и для команды разработчиков.

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

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

Общая схема процесса разработки в котором используется Задание на проектирование
Общая схема процесса разработки в котором используется Задание на проектирование

Какие задачи решает Задание на проектирование

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

В идеальном варианте, мы должны иметь возможность отдать документ внешнему исполнителю, который не погружен в проект, который после прочтения скажет что-то вроде: «Да, в принципе понятно, можно начинать. Только есть пара вопросов.»

Кто основные пользователи Задания на проектирование

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

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

Содержание Задания на проектирование

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

Типовой состав включает:

  1. Титульный лист с выходными данными.

  2. Историю изменений документа, если мы ввели в практику ее вести.

  3. Список терминов и сокращений, используемых в документе.

  4. Цели и задачи проекта в общем виде.

  5. Описание ролей/пользователей.

  6. Список основных сценариев с возможными исключениями.

  7. Описание предметной области, которые касаются интерфейсов системы.

1. Титульный лист

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

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

Что может содержать:

  • Название проекта.

  • Дата документа.

  • Версия документа.

  • Автор.

2. История изменений

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

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

Что может содержать:

  • Дата.

  • Номер версии документа, в которую внесены изменения.

  • Описание изменений, краткое.

  • Автор, который внес изменение в документ.

3. Список терминов и сокращений

Вместе с Титульным листом, Историей изменений — это еще один пункт для хорошего оформления документа.

Нам нередко приходится использовать профессиональные сокращения, например, “ТЗ”, а в бизнесе сокращения встречаются еще чаще.

Как только пользователи не называют свои системы, подсистемы, подразделения и т.д!

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

Поэтому, добавление в документ списка сокращений — хорошая практика, которая поможет сократить время на объяснения и уменьшит вероятность неправильного понимания важных вещей.

4. Цели и задачи проекта

Общее описание того, что мы делаем, зачем и какой результат ожидаем получить.

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

Для этого раздела нужно найти баланс, чтобы не было лишней информации. Можно ориентироваться по объему: если Цели и задачи занимают больше одной страницы, скорее всего стоит поубавить воды.

5. Пользовательские сценарии

Основные пользовательские сценарии (и исключения/альтернативные сценарии к ним) описанные в простом формате.

  • Название сценария (можно в формате User Story).

  • Предусловия (опционально).

  • Триггер (опционально).

  • Основные шаги выполнения сценария.

Можно делать сценарии в формате User Story, без детализации. Но следует помнить правила для описания таких сценариев. Как минимум, сценарии должны быть короткими, и обязательно нужно описывать, как позитивные, так и негативные варианты поведения системы.

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

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

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

Пример 1: Сценарий с детальным описанием
Пример 1: Сценарий с детальным описанием
Пример 2: Сценарий без детализации
Пример 2: Сценарий без детализации
Пример 3: Вариант описания сценариев через User Story
Пример 3: Вариант описания сценариев через User Story

6. Описание предметной области

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

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

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

Пример 4: Таблица описания данных
Пример 4: Таблица описания данных
Пример 5: Таблица описания данных
Пример 5: Таблица описания данных
Пример 6: Таблица описания данных
Пример 6: Таблица описания данных

Примеры 4, 5 и 6 даны, с одной стороны — как возможные форматы таблицы данных, с другой стороны — как пример того, что формат описания может быть различным.

7. Справочники и прочие материалы

Можно включить в документ дополнительные материалы, которые помогут спроектировать интерфейсы. Чаще всего это материалы, связанные с фиксированными данными и контентом.

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

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

Можно не включать в документ сам справочник, а давать ссылку на него.

В заключение

Задание на проектирование подготавливается, чтобы повысить качество работы над проектом на стадии проектирования.

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

Комментарии (0)