Павел Шерер дописал цикл о функциональной архитектуре: о детальном проектировании и подводных камнях.

— У каждой функции и функционального раздела должно быть уникальное название: конкретное и максимально понятное, чтобы сразу уловить суть, на английском;
— Название функции должно отражать действие. Например: AddUser;
— Функциональные сценарии прорабатываются итеративно: от простых к детализированным, чтобы успевать накопить достаточно данных для глубокой проработки;
— Описать функцию с помощью схем не всегда возможно, иногда поможет только текст;
— Описание должно включать назначение, входные и выходные данные, зависимости (например, confirmPhone нельзя реализовать, пока не заработает sendSMS), пример использования;
— Сюда можно добавить User Stories, Use Cases и всё, что посчитаете нужным;
— Если названия макетов будут соответствовать документации, это упростит жизнь разработчикам. Например, ShoppingCart — корзина, ShoppingCart.empty — её пустое состояние;
— Нужен баланс в уровне проработки. Слишком общая проработка отрывает архитектуру от реальности. Слишком детальная перегружает, усложняет восприятие и развитие;
— Если рано детализировать одну подсистему, не получится учесть нюансы других (которые ещё не проработаны), и работа может отправиться в мусорку;
— Невозможно задизайнить сложную систему, не понимая, как она будет работать. Но нельзя знать всё. Чем раньше вы «обстучите» свои решения об коллег, тем надёжнее они станут;
— Отдельная задача — убедить бизнес не начинать разработку слишком рано, недостаточно проработав проект;
— Будьте готовы в процессе детальных изысканий возвращаться на высокий уровень на существенно его изменять.

#functional_architecture

UX Notes

Павел Шерер дописал цикл о функциональной архитектуре: о детальном проектировании и подводных камнях.

— У каждой функции и функционального раздела должно быть уникальное название: конкретное и максимально понятное, чтобы сразу уловить суть, на английском;
— Название функции должно отражать действие. Например: AddUser;
— Функциональные сценарии прорабатываются итеративно: от простых к детализированным, чтобы успевать накопить достаточно данных для глубокой проработки;
— Описать функцию с помощью схем не всегда возможно, иногда поможет только текст;
— Описание должно включать назначение, входные и выходные данные, зависимости (например, confirmPhone нельзя реализовать, пока не заработает sendSMS), пример использования;
— Сюда можно добавить User Stories, Use Cases и всё, что посчитаете нужным;
— Если названия макетов будут соответствовать документации, это упростит жизнь разработчикам. Например, ShoppingCart — корзина, ShoppingCart.empty — её пустое состояние;
— Нужен баланс в уровне проработки. Слишком общая проработка отрывает архитектуру от реальности. Слишком детальная перегружает, усложняет восприятие и развитие;
— Если рано детализировать одну подсистему, не получится учесть нюансы других (которые ещё не проработаны), и работа может отправиться в мусорку;
— Невозможно задизайнить сложную систему, не понимая, как она будет работать. Но нельзя знать всё. Чем раньше вы «обстучите» свои решения об коллег, тем надёжнее они станут;
— Отдельная задача — убедить бизнес не начинать разработку слишком рано, недостаточно проработав проект;
— Будьте готовы в процессе детальных изысканий возвращаться на высокий уровень на существенно его изменять.

#functional_architecture

Павел Шерер

Функциональная архитектура цифровых продуктов, часть 5 — Павел Шерер

Детальное функциональное проектирование и частые, но не всегда очевидные подводные камни.

hottg.com/uxnotes/1565

5.9K viewsАнтон Григорьев, Feb 22 at 15:25