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

Что такое функциональная архитектура, зачем она нужна и почему рынок привык работать плохо.

4-5 минут на прочтение
Функциональная архитектура цифровых продуктов, часть 1

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

Этот пост (как и весь цикл) написан не только и не столько для инженеров и программистов, сколько для тех, кто проектирует цифровые продукты. Ну и для тех, разумеется, кто платит за это проектирование и последующую разработку.

Определение функциональной архитектуры

Так что же такое Functional Architecture? Если коротко, то:

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

Слишком размыто? Как и всегда, когда кто-то пытается засунуть объёмную методологию в одно короткое определение. Давайте разбираться.

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

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

Перенос рисков

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

Мы привыкли, что разработка — это область проектного процесса с довольно высокой степенью неопределённости. Именно поэтому все агентства и production-компании работают по T&M, с оплатой по часам, а не по результату. Им просто невыгодно брать на себя финансовые риски клиента. Ведь на старте они не могут быть уверены в том, что информации достаточно, а документация по проекту верная и исчерпывающая. Зачастую разработчикам вообще прилетают только функциональные требования, юзкейсы и дизайн-макеты (разумеется, этого мало).

И что происходит в итоге? Правильно, риски перекладываются на клиента. Сорян.

Но это если рассматривать проектный процесс с точки зрения задействованных в нём сторон. А давайте взглянем изнутри. Давайте разделим этот самый процесс на два ключевых направления: продуктовый дизайн (исследования, аналитика — проектирование, в общем) и разработку (кодинг, девопс и тестирование). Тогда получается, что проектировщики попросту перекладывают свои обязанности (а с ними и риски) на разработчиков. Да, всё просто.

Программисты вынуждены принимать решения и искать ответы на те вопросы, которые их вообще не должны касаться. Классика: «а что будет, если соцсеть не вернула e-mail пользователя?». Или: «а пользователю нужно сообщать о вот этой вот ошибке?».

Инженеры и строители начинают работать за архитекторов, если тем не хватает квалификации. Такое, блин, возможно только в IT.

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

Деградация кода

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

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

Скорее всего, программист в этот момент даже не помнит, что обрезка изображений, которую он сейчас пишет для аватара в профиле, используется ещё и при создании новости. А через два месяца, когда дойдёт до новостей, он может не вспомнить про то, что уже писал эту треклятую обрезку. И сделать две: одинаковых внешне, но разных в реализации. Или, что вероятнее, он просто скопипастит первую. Потому что выносить её за пределы профиля — это уже рефакторинг, а таску нужно закрыть сегодня.

А представьте, что над проектом работает два, пять разработчиков? Какова вероятность, что они синхронизируются в мелочах вроде пагинации, «бесконечного» скролла или валидации данных? Что каждый из них не напишет в своей части проекта собственный вариант каждого решения?

А ведь это так просто: выявить все общие функции ещё на этапе проектирования и явно указать на них программистам. Не надеяться на авось, и не отмазываться зоной ответственности. Никто, кроме проектировщика/аналитика/дизайнера, не знает проект настолько хорошо, чтобы это сделать. Разумеется, если нет специального человека.

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

Функциональные требования и описание

Когда я рассказываю о функциональной архитектуре на своих лекциях, то в половине случаев слышу: «а, ну это понятно, у нас на проектах тоже есть функциональные требования». Нет. Функциональные требования и функциональная архитектура — разные вещи. Когда ваш аналитик собирает функциональные требования, он формирует задачи, в редких случаях — предварительное, неструктурированное описание системы. Отдавать сырые требования разработчикам, даже хорошим — так себе идея.

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

И даже если углубиться в это конкретное требование, расписать его максимально подробно (посчитав и вес одного авто, и удельный вес, и даже среднюю скорость проезда), то всё равно получится фигня. И не важно, десять таких «требований» будет или пять сотен. Строителям, как и разработчикам, нужны куда более полные и комплексные инструкции. Структурированные с учётом множества факторов. В противном случае строители просто залью всё армированным бетоном, чтобы уж наверняка.

Функциональная архитектура предполагает предоставление инженерам и программистам целостного и глубокого описания разрабатываемой системы. Понятных и однозначно трактуемых инструкций. FA стабилизирует и ускоряет процесс разработки.

И в следующих статьях мы поговорим об этом.

Немного лирики

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

Павел Шерер, продюсер IT-решений

Канал в Telegram
#документация #технический дизайн
Проектирование регистрации
Предыдущая статья Регистрация и логин на стероидах
Функциональная архитектура
Следующая статья Функциональная архитектура цифровых продуктов, часть 2

Раньше тут были комментарии, но я решил не плодить сущности. Есть что сказать или спросить — велкам в телеграм-канал:

Обсудить в Telegram