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

• Все статьи цикла:
• Функциональная архитектура цифровых продуктов, часть 1 (вы здесь)
• Функциональная архитектура цифровых продуктов, часть 2
• Функциональная архитектура цифровых продуктов, часть 3
• Функциональная архитектура цифровых продуктов, часть 4 (coming soon)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И да, это только первый пост цикла о функциональном проектировании.

• Все статьи цикла:
• Функциональная архитектура цифровых продуктов, часть 1 (вы здесь)
• Функциональная архитектура цифровых продуктов, часть 2
• Функциональная архитектура цифровых продуктов, часть 3
• Функциональная архитектура цифровых продуктов, часть 4 (coming soon)