Павел Шерер написал 4-ю статью цикла о функциональной архитектуре.

— V-модель разработки делает акцент на тестировании, что позволяет выпускать стабильные продукты за оптимальное время;
— Но она не гарантирует качество, так как всегда кто-то формирует видение (дизайнер с макетами, аналитик с требованиями), а остальные от них отталкиваются. При этом первые плохо понимают технические ограничения, а вторые потребности пользователей;
— В разработку уходят требования, а значит, «строители» принимают решения за «архитекторов»;
— На старте проекта много белых пятен и хаоса, но их закрашивание хаос не уменьшает, так как специалисты почти всегда уходят в детали и принимают решения без понимания общей картины. В моменте кажется, что ситуация под контролем, но потом часть наработок оказывается в корзине;
— Работа над функциональной архитектурой подразумевает этап высокоуровневого проектирования, продумывание базиса, на который потом можно положить детальное описание функций;
— Нет шаблонов ФА, которые могут переходить из проекта в проект, так как архитектура должна подстраиваться под продуктовые реалии. Но могут быть методологические форматы отдельных артефактов;
— Если нет супердизайнера или плотной связки дизайнера с аналитиком, решающих всё в реальном времени, создать консистентную проектную документацию поможет «перекрёстное опыление»;
— Это синхронизация дизайна и аналитики при создании каждого функционального слоя: 1) концепция, 2) функциональная модель, 3) сценарии, 4) информационная архитектура, 5) сведение функций с экранами и состояниями;
— Например, на этапе концепции дизайнеры прорабатывают базовую ролевую модель, потребности и особенности пользователей. Аналитики вместе с технарями и бизнесом решают, как закрыть интересы всех заинтересованных сторон.

Канал Павла. #functional_architecture #process

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

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

#functional_architecture