Можно по-разному подходить к процессу разработки сервисов и приложений. Идеальной методологии не существует, многое зависит от особенностей команды и самого проекта. Тем не менее, некоторые практики показывают себя хорошо, и в ходе различных проектов могут распространяться на все работы, обеспечивая более предсказуемый результат. Это не означает, что для конкретного проекта и команды не будет существовать более эффективного пути организации работы, но согласитесь — лучше иметь постоянно работающий хороший инструмент, чем под каждый проект пытаться найти самый лучший.
Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».
Предпосылки
В проектной работе, к которой мы в свое время привыкли, этап проектирования начинался с передачи Технического задания (ТЗ). В практике встречались ТЗ разной степени проработанности. Нередко заказчик сам готовил ТЗ и часто это были документы низкого качества, которые требовали доработок.
Также, мы могли начинать проектирование интерфейсов системы, основываясь на поверхностном описании процессов и бизнес-требованиях, и в таких случаях ТЗ писалось после проектирования. Есть практики, когда клиент разделяет Техническое задание и Техническое решение, или когда BRD становится входной точкой для проектирования.
Можно вспомнить еще другие частные частные варианты входа в процесс проектирования интерфейсов.
Как вы видите, вариантов было много. Некоторые из них были более привычными, и можно было бы считать их хорошей практикой, которой нужно все время следовать, но…
В основе нашего «но», которое побуждает менять практику лежит понимание того, что Time to market стал важным фокусом проектной работы. И вместе с этим, проект — это всегда люди, которые вовлечены со всех сторон. Так возникло убеждение, что нам надо учитывать необходимость поддержания клиентов во включенном в проект состоянии и для этого следует обеспечить контролируемую нагрузку и регулярность активностей.
Проще говоря, нужно аккуратно использовать ресурс бизнес-заказчика (product owner, клиента) — не перегружая его, но и не позволяя чересчур расслабляться. Ведь ничто так не загружает людей, как работа над большим ТЗ. Даже его вычитывание делает людей, которые специально к этому не готовились, глубоко несчастными. А те, кто готовились, выглядят уставшими.
И вот, мы определили два фактора. С одной стороны, все заинтересованы быстрее начать проект и увидеть хоть какой-то первый результат. С другой стороны, никто не хочет участвовать в написании полноценного ТЗ.
Оба фактора часто верны и для бизнес-заказчика, и для команды разработчиков.
Мы считаем, что начинать проектирование без формализованных материалов возможно — но это, в итоге, станет долгой дорогой. На таком пути прототипы могут быть инструментом выявления потребностей и согласования решений, но все затянется. Соответственно, если нас интересует сокращение времени проекта, то надо выбрать подход с документацией, но ее объем можно сократить и подготовку документов разнести во времени.
Таким образом у нас сформировался процесс, в котором первым документом после сбора требований и формирования бэглога, становится Задание на проектирование.
Какие задачи решает Задание на проектирование
Документ подготавливается для того, чтобы организовать работу по проектированию с пониманием области проекта, учетом основных сценариев и исключений.
В идеальном варианте, мы должны иметь возможность отдать документ внешнему исполнителю, который не погружен в проект, который после прочтения скажет что-то вроде: «Да, в принципе понятно, можно начинать. Только есть пара вопросов.»
Кто основные пользователи Задания на проектирование
Задание подготавливается для команды проектирования и бизнес-заказчика. Выгода команды проектирования понятна и в основном заключается в том, что при наличии задания нет необходимости дополнительно исследовать предметную область и погружаться в понимание особенностей работы системы. При этом виден объем работ, которые можно заранее оценить и спланировать. А бизнес-заказчик получает возможность формализовать свои требования через небольшой документ, провалидировать их, ранжировать в зависимости от своих бизнес-задач.
Конечно, документом могут пользоваться и другие участники проекта, кто заинтересован в получении ранней информации о функциональных возможностях интерфейса.
Содержание Задания на проектирование
В нашей практике Задание на проектирование стало частным случаем большого Технического задания и наследуют в себя часть его разделов только с меньшей детализацией.
Типовой состав включает:
Титульный лист с выходными данными.
Историю изменений документа, если мы ввели в практику ее вести.
Список терминов и сокращений, используемых в документе.
Цели и задачи проекта в общем виде.
Описание ролей/пользователей.
Список основных сценариев с возможными исключениями.
Описание предметной области, которые касаются интерфейсов системы.
1. Титульный лист
Хорошее оформление документа еще никому не мешало, и здесь это правило тоже работает, а Титульный лист — это начало хорошего оформления. При большом желании, им можно пренебречь, но чаще всего отсутствие нормального Титула объясняется исключительно ленью.
Вот чтобы уменьшить количество такой лени, я добавил этот пункт.
Что может содержать:
Название проекта.
Дата документа.
Версия документа.
Автор.
2. История изменений
Хранить в документе Историю изменений — это хорошая практика, которая поможет обеспечить управляемость документом и возможность «найти концы», если до этого дойдет.
С одной стороны, дату и версию документа можно хранить на уровне титульного листа, но, если у нас начинается версионность, то хочется видеть различия в версиях. Можно не детально, но хотя бы так, чтобы понимать основные изменения. Ведь при долгом обсуждении документа, такие изменения обязательно будут. Ну а если все обсуждения проходят легко, то и История изменений будет короткой.
Что может содержать:
Дата.
Номер версии документа, в которую внесены изменения.
Описание изменений, краткое.
Автор, который внес изменение в документ.
3. Список терминов и сокращений
Вместе с Титульным листом, Историей изменений — это еще один пункт для хорошего оформления документа.
Нам нередко приходится использовать профессиональные сокращения, например, “ТЗ”, а в бизнесе сокращения встречаются еще чаще.
Как только пользователи не называют свои системы, подсистемы, подразделения и т.д!
В итоге, всякое сокращение, понятное вовлеченным участникам проекта, будет новым словом для нового человека. Или, что еще хуже, он поймет сокращение или термин неправильно, опираясь на свой прошлый опыт, который будет неприменим к текущей ситуации (законы Мерфи еще никто не отменял ).
Поэтому, добавление в документ списка сокращений — хорошая практика, которая поможет сократить время на объяснения и уменьшит вероятность неправильного понимания важных вещей.
4. Цели и задачи проекта
Общее описание того, что мы делаем, зачем и какой результат ожидаем получить.
Основная цель данного раздела — погрузить исполнителя в контекст проекта достаточно глубоко, чтобы он ясно понял — о чем все это.
Для этого раздела нужно найти баланс, чтобы не было лишней информации. Можно ориентироваться по объему: если Цели и задачи занимают больше одной страницы, скорее всего стоит поубавить воды.
5. Пользовательские сценарии
Основные пользовательские сценарии (и исключения/альтернативные сценарии к ним) описанные в простом формате.
Название сценария (можно в формате User Story).
Предусловия (опционально).
Триггер (опционально).
Основные шаги выполнения сценария.
Можно делать сценарии в формате User Story, без детализации. Но следует помнить правила для описания таких сценариев. Как минимум, сценарии должны быть короткими, и обязательно нужно описывать, как позитивные, так и негативные варианты поведения системы.
Предпочтительно делать короткие сценарии, без ветвлений. Если мы имеем дело со сложным составным интерфейсом, то лучше создать отдельные сценарии для фич, чем формировать мега-сценарий. В ситуации, когда мы совсем не понимаем, что может происходить в рамках интерфейса, и времени на аналитику нет, мы можем задавать очень обобщенный сценарий (например, покупка товара в Интернет-магазине), но при этом помнить, что этот сценарий в дальнейшем, уже в процессе проектирования, должен быть декомпозирован на более простые составляющие.
В рамках сценария нужно избегать описания интерфейса и конкретных интерфейсных решений, потому что это снижает свободу возможных решений и, скорее всего, усложнит поиск хорошего решения. Если у аналитика есть идея, как может быть реализован тот или иной сценарий в интерфейсе, лучше эту идею изложить в виде комментария к сценарию, чтобы идея воспринималась, как предложение возможного решения, а не как требование к исполнению.
Ниже я привел несколько примеров того, какими могут быть сценарии. В конечном счете, формат можно выбрать и другой. Главное, чтобы сценарии функционально покрывали весь проект (или хотя бы нужно стремиться к этому).
6. Описание предметной области
Совокупность данных, которые нужны для проектирования интерфейса.
Можно использовать ссылки на источники таких данных. Например, когда мы переносим контент с существующего проекта, то можно указать ссылки на текущие страницы, с которых будет переноситься контент. Но такая практика хороша, когда данные очевидны, например, когда мы копируем блоки текста с одной версии системы в другую. Попытка же сослаться на форму с динамическими данными и скрытой логикой, скорее всего, приведет к тому, что мы не сможем ее корректно проектировать.
Данные чаще всего описываются в табличном формате. Вместе с общим описанием данных полезно прилагать примеры данных, а в некоторых случаях — примеры крайних значений, которые может принимать то или иное поле. Например, если у нас есть поле «Название компании», то важно понимать какой длины оно может быть, «ООО Ромашка» или «Московский ордена Трудового красного знамени инженерно-технический институт тяжелого машиностроения МИТИТМ» потребуют разных интерфейсных решений.
Примеры 4, 5 и 6 даны, с одной стороны — как возможные форматы таблицы данных, с другой стороны — как пример того, что формат описания может быть различным.
7. Справочники и прочие материалы
Можно включить в документ дополнительные материалы, которые помогут спроектировать интерфейсы. Чаще всего это материалы, связанные с фиксированными данными и контентом.
Например, можно включать справочники, которые нам нужны для формирования форм, чтобы в интерфейсе показывать реальные данные, когда пользователь выбирает значение в выпадающем списке. В зависимости от длины такого списка удобными будут различные интерфейсные решения.
Справочники выносятся в отдельный раздел, чтобы не увеличивать раздел с описанием предметной области.
Можно не включать в документ сам справочник, а давать ссылку на него.
В заключение
Задание на проектирование подготавливается, чтобы повысить качество работы над проектом на стадии проектирования.
За счет более глубокого погружения в технические аспекты реализации, появляется возможность сразу, на стадии проектирования, учесть редкие пользовательские кейсы, которые стали бы очевидны и без задания на проектирования на более поздних стадиях. При этом, за счет ограниченного объема и фокусировки, только на аспектах касающихся интерфейсов, удается сократить время, требуемое для подготовки Задания на проектирование, если сравнивать со временем, требуемым на подготовку полноценного Технического задания.
