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

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

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

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

Так проектировщики перекладывают свои обязанности (а с ними и риски) на разработчиков, которые вынуждены принимать решения и искать ответы на вопросы вроде «Что будет, если соцсеть не вернула имейл пользователя?»

ФА призвана снизить риски, стабилизировать разработку, заранее найти ответы на значительную часть вопросов, не заставлять обычных программистов принимать общие архитектурные или тонкие юиксовые решения.

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

#functional_architecture

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

— Этапы создания ФА: высокоуровневый (скелет продукта) и детальный (мясо);
— Это разделение условно: где-то приходится возвращаться к переосмыслению общих решений, где-то нельзя продолжить без более глубокого погружения в область;
— Кажется, что набросать общую структуру проекта проще, чем детально расписать каждую функцию. Загружать в голову функциональность большого продукта и анализировать её — сложно. В начале работы важно сохранить высокий уровень абстракции, чтобы не уйти в детали и не ошибиться с основными решениями;
— Простейшие функции складываются в крупные, которые входят в функциональные разделы, которые тоже могут быть вложенными. Раздел «Логин и регистрация» → подраздел «Аутентификация» → функция «Валидация формы» → функция «Проверка на обязательное поле»;
— На 1-м этапе обычно описываем только функциональные разделы и ключевые функции;
— Функций всегда лютая тьма. Проще всего выявлять их через функциональные сценарии продукта (часто строятся на основе User Flow или аналогов);
— Сперва создаём базовые сценарии, затем углубляем их по мере появления детальной информации о продукте;
— Выносим отдельно функциональность, встречающуюся в нескольких разделах. Например, просмотр списка новостей (карточки новостей, их обновление и подгрузка новых) на главной и на странице «Новости».

#functional_architecture

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

— Если не выделять общие функции продукта, есть риск получить копипаст одной и той же функциональности (в лучшем случае) или несколько разных реализаций интерфейса и логики. Это усложняет поддержку и дальнейшее развитие продукта;
— Общие функции не всегда лежат на поверхности, часто их выявление становится отдельной задачей;
— Как это делать: в небольших проектах можно просто спрашивать себя, не используется ли эта конкретная функция где-то ещё;
— Можно составить матрицу функциональных свойств объектов — список всех сущностей и возможных действий с ними, основанный на информационной архитектуре;
— Примеры общих функций: показ системных сообщений, отправка запроса по API, обработка ответа по API, валидация полей форм, показ сообщений форм, отправка данных формы и обработка ответа (может использовать функции API), проверка наличия сети, обновление экрана, отправка данных для аналитики;
— Функции могут зависеть друг от друга. При иерархической зависимости уровень диктует порядок проектирования и реализации. Например, подтверждение номера телефона нельзя реализовать без а) обработки запроса на сервере и б) отправки смс;
— Если отправка смс используется только здесь (не является общей), разработать её можно вместе с функцией подтверждения номера телефона;
— Функция обработки запроса на сервере — общая. При этом она зависит от функций «валидация данных» и «очистка параметров», значит, спроектировать и реализовать надо сначала их;
— Есть линейная (параллельная) взаимосвязь. Например: регистрация через имейл и регистрация через соцсети;
— Также функции бывают клиентские и серверные — в зависимости от того, где они выполняются.

#functional_architecture

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

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

#functional_architecture #process