Если эта первая статья, с которой вы знакомитесь с информационной архитектурой, примите мои соболезнования: вам может быть непонятно. Рекомендую идти в начало цикла.

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

Паттерны моделирования свойств

Как мы уже знаем, все свойства можно поделить на несколько типов: базовые, ссылочные, составные, вычисляемые, технические и ограничительные. И если с базовыми всё плюс-минус понятно, то что делать с остальными — отнюдь не всегда ясно.

Да и с базовыми, если честно, порой могут возникнуть проблемы. Например, у нас есть свойство «Цвет». Оно простое: ни на кого не ссылается, это не таксономия — это, скорее, словарь, сквозное свойство. Как с ним быть? Или с полем «Описание» — оно тоже простое, но активно участвует в индексации и поиске, об этом тоже нужно подумать.

Давайте разбираться.

Нормализованные словари

Их ещё называют «справочниками», а разработчики — ENUM, перечислением. Мы их уже касались вскользь. Поля такого типа могут принимать только значения из конкретного, определённого перечня.

Правила:

• Значения — всегда конечные и контролируемые, добавление новых происходит только по процессу ревью.
• Поддерживают алиасы/синонимы для поиска, но в БД хранится нормализованное значение (ключ).
• Если значения словаря локализуются (переводятся на другие языки), то внутренний ключ остаётся неизменным.

Пример:

У товара есть поле brand, которое ссылается на запись из справочника брендов. В справочнике брендов есть конечный перечень записей обо всех брендах, представленных в системе.

Риски:

• Избыточная детализация (когда в словаре много синонимов или значений) может привести к «шуму» в фасетах. Например, когда в словаре «Цвет» появляются сотни почти одинаковых значений: алый, бордо, вишнёвый, винный и тп.
• Из-за отсутствия владельца, ответственного за словарь, повышается риск появления дублей и рассинхронизации.
• Использование ENUM в БД для часто меняющихся списков почти всегда усложняет разработку и деплой.

Ссылочные поля

Поля, указывающие на другие сущности через внешние ключи. Главное их отличие от нормализованных словарей в том, что ссылочные поля связывают сущности между собой и с другими объектами (например, с терминами таксономий). Тогда как значения ENUM из предыдущего примера не являются отдельными объектами, они просто строчка в фиксированном списке.

Ссылочные поля — это «мостики» между сущностями: товар связан с категорией, тегами, продавцом, заказами. Благодаря им карточка не живёт в вакууме, а встраивается в общую систему.

Правила:

• Для «один‑ко‑многим» 1:N (категория → товары) у товара хранится ссылка на свою категорию.
• Для «многие‑ко‑многим» M:N (товар ↔ тег) связи хранятся отдельно.
• Важно продумать, что происходит при удалениях: кого переносим, кого архивируем, а где просто убираем связь.

Пример:

У товара есть одна «Категория», но множество «Тегов».

Если удалить тег — товар останется. Если удалить категорию — нужно заранее решить, куда товар переедет.

Риски:

• Непродуманные правила удаления ведут к потере данных или поломке логики. Я видел случаи, когда при удалении рубрики в CMS, из базы данных удалялись десятки статьей и сотни комментариев.
• Когда связи между сущностями организованы неэффективно, системе приходится делать много лишних запросов, фильтровать данные или пересчитывать агрегаты на лету. Это замедляет скорость работы продукта.
• Если связи построены небрежно, при массовых обновлениях могут случиться зависания или сбои. Например, любое изменение категории или продавца может вызвать ошибки в отображении связанных с ними карточках.

Вычисляемые поля

Это свойства, которые не вводятся вручную, а считаются системой на основе других данных: средний рейтинг, количество просмотров, популярность, конверсия. Они помогают понять, насколько «живой» или успешный объект, не требуя ручного обновления.

Вычисляться такие поля могут «на лету», либо храниться в БД или кэше.

Правила:

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

Пример:

Риски:

• «Расползание» цифр: в карточке одно, в отчёте другое. На момент написания статьи такое можно увидеть на Хабре, там два разных счётчика просмотров: один доступный всем, другой — только авторам.
• Неочевидные формулы, спрятанные в глубинах кода. Показатели меняются, команда не понимает причин.
• Слишком частые пересчёты. Система вычисляет показатели слишком часто, нагружая серверы без нужды. Или наоборот — слишком редкие обновления, из‑за которых пользователи видят устаревшие данные.

Диапазоны и интервальные фасеты

Кто-то считает интервальные фасеты лишь подмножеством вычисляемых полей, но я решил выделить их отдельно. Они чаще всего встречаются и имеют несколько специфичных свойств.

Фильтры по числам и датам помогают пользователю быстрее находить подходящие товары. Мы редко ищем вещь за точно 2 570 рублей — обычно хотим что-то «в районе двух‑трёх тысяч». Поэтому интерфейс должен позволять задавать диапазон значений: цену «от-до», вес или рейтинг. Пользователь мыслит не конкретными числами, а удобными «вилками» — например, «до 1000 рублей» или «от 4 звёзд и выше».

Правила:

• В системе хранится точное значение, а пользователю показываются готовые «умные» интервалы (например, на основе реального распределения цен). Если меняем цену, то принадлежность к интервальным полям изменяется автоматически.
• Правила границ (включительно/исключительно) и округления задаются явно. Чтобы не было непонятно, входит «1000» в «до 1000» или в «1000-5 000».
• Должны быть продуманы правила обработки пустых/нулевых значений. Например, «цена не указана» — это отдельная группа, она не попадает в интервалы.

Пример:

Риски:

• Для денег и размеров нужно быть аккуратными с единицами и валютами. Если смешать сумму и валюту, это может плохо кончиться: фильтр по цене может стать бесполезен.
• Непродуманные интервалы дают пустые результаты и раздражают пользователей.

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

Составные и полуструктурированные поля

Когда у сущности много разнородных характеристик (например, у товара есть изображения, материалы, дополнительные свойства) — удобнее собрать их в «пакеты». То есть не разбивать свойство на десятки отдельных полей, а объединить в один структурированный набор. Это помогает избежать перегруженности данных и сделать архитектуру более гибкой.

Во второй статье цикла я писал о сильной и слабой типизации. Так вот составные поля — отличных пример признака слабой типизации.

Правила:

• Те свойства, которые часто используются для фильтрации, сравнения или сортировки (ширина, вес, цена), лучше выделить в отдельные простые поля. Остальное можно хранить в составе набора.
• Важно сразу договориться о едином формате (например, JSON или таблица), чтобы не получилось сотни уникальных схем в разных объектах.
• Также стоит помнить об ограничении глубины вложенности — чем проще структура, тем меньше ошибок при обновлениях.

Пример:

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

Таким образом, мы не делаем отдельные поля для тех свойств, которые используются только вместе.

Риски:

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

Поисковые поля

Это поля, которые напрямую влияют на то, как пользователи находят нужный элемент через поиск. Именно они определяют качество и релевантность результатов. Обычно сюда входят: название, краткое описание, артикул и так далее.

Правила:

• Поиск должен «думать как человек»: учитывать разные формы слов («купить» и «покупка»), синонимы («ноутбук» и «laptop») и популярные опечатки. Именно поисковые поля должны лучше всего индексироваться.
• Полезно задавать разный «вес» полям — название важнее описания, а описание важнее технических характеристик.
• Важно поддерживать актуальный словарь синонимов и опечаток: он должен пополняться на основе статистики реальных поисковых запросов.

Пример:

Риски:

• Сложные запросы без ограничений по размеру выдачи запросто могут «положить» поиск, перегрузив систему.
• Если переусердствовать с синонимами, поиск начинает показывать нерелевантные результаты, будет слишком много «шума».
• Несвоевременно обновляемый словарь приводит к тому, что люди начнут искать новые термины, которых в базе нет — и, не получив результатов, посчитают, что товара нет вовсе.

Технические поля

Это служебные поля, которые фиксируют то, что пользователям знать не обязательно. Например: когда и кем запись создана/изменена, какой у неё статус, флаги индексации. Такие данные помогают поддерживать порядок, находить ошибки и понимать, как объект живёт во времени. Без них часто невозможно разобраться, кто и что сделал, особенно если с системой работает большая команда.

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

Правила:

• Типовые значения указываются в едином формате: например, время — только в UTC+0. Это позволяет потом не путаться при реализации и анализе.
• Важно заранее договориться о понятных статусах сущностей и допустимых переходах между ними, фиксировать автора, источник и причину изменений.
• Желательно хранить историю правок хотя бы ключевых сущностей, чтобы при спорных ситуациях можно было восстановить ход событий.

Пример:

Риски:

• «Прыгающие» даты из‑за разных часовых поясов, непонятные или дублирующие статусы, невозможность определить автора изменений.
• Потеря истории при импорте или миграции: если данные перезаписать без сохранения временных меток, аналитика и отчёты станут недостоверными.

Ограничительные поля

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

Правила:

• Разделяйте «бизнес‑ограничения» (что показываем и кому) и «технические» (что разрешает система). Должно быть прозрачно, почему сущность или операция скрыта или недоступна.
• Желательно сопровождать такие поля пояснениями — что именно ограничивает доступ и где отображается уведомление пользователю.
• Все ограничения должны иметь понятные статусы (например, «активно», «ожидает проверки», «временно снято с продажи») и быть управляемыми, а не жёстко зашитыми в код.

Пример:

Риски:

• Скрытые ограничения ломают пользовательский опыт. Если это не предусмотрено специально, всегда сообщайте об ограничениях тем, кого они касаются.
• Разные правила на фронте и бэкенде почти всегда приводят к несоответствиям. Лучше делать основную логику на сервере, а клиенту (браузеру или приложению) доверять только визуальное отображение.
• При массовых изменениях может возникнуть путаница. Например, когда правила блокировок не синхронизированы между странами или каналами продаж.

Собственно, фиксация

Теперь, когда с паттернами стало немного понятнее, давайте попробуем всё это зафиксировать.

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

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

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

Основная информация

Опишите, как поле называется в системе (код), какой у него тип данных (текст, число, дата и тп), обязательно ли оно для заполнения, приведите примеры. Добавьте пояснение, зачем это поле нужно, какую задачу решает.

Пример основной информации о сущности «Товар»:

Обратите внимание на тип данных: в различных системах типы данных могут обозначаться по-разному, при работе с IA желательно придерживаться какого-то единого, понятного всем, формата. Конкретно здесь:

• int — простое целое число;
• text — текст без явных ограничений в типе данных (не varchar, например);
• float — число с плавающей точкой (3.23);
• ref — ссылка на другую сущность, reference;
• enum — его вы уже знаете, нормализованный словарь.

Источник и валидация

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

Индексация и поиск

Как используется в поиске, фильтрах и аналитике. Опишите, участвует ли поле в поиске или фасетах, влияет ли оно на фильтрацию, сортировку и аналитику. Укажите, какие сценарии зависят от него (поиск по названию, сортировка по цене, фильтр по цвету). Добавьте, нужна ли регулярная переиндексация и как часто.

Владение и контекст

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

Жизненный цикл и обновление

Как часто меняется поле. Разделите поля по типу обновления: редактируемые пользователем, автоматически пересчитываемые системой, импортируемые из внешних источников. Укажите частоту проверки актуальности и правила пересмотра.

Нормализация и перевод значений

Как поддерживается единообразие. Опишите, как поле очищается и приводится к общему формату: регистр, язык, синонимы, стандарты записи. Если данные многоязычные — уточните правила перевода. Добавьте примеры типичных ошибок и корректного вида.

Таблица свойств (Entity Attribute Matrix)

В итоге для каждой сущности у вас появится единая таблица, где перечислены все поля с их типом, источником, обязательностью, правилами и владельцем. Она должна стать единым источником правды для всей проектной команды: от дизайнеров с аналитиками до разработчиков с архитекторами. Такая таблица поможет поддерживать актуальность архитектуры данных и синхронизировать работу API, интерфейсов и аналитики.

Обязательно ведите версионирование: когда и кем изменялась таблица, что именно было изменено. Это позволит, при необходимости, провести трассировку изменений (например, при расхождении информационной архитектуры с программной реализацией).

Ну и напоследок, как и обещал, полная таблица свойств из этой статьи:

Не переключайтесь, в цикле будет ещё как минимум две статьи.

Запись Информационная архитектура: сущности (практика, vol.2) первой появилась на Павел Шерер.

Небольшое вступление

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

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

Подготовка: контекст и границы

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

Цель продукта

Начните с формулировки основной пользовательской ценности и трёх–пяти задач, ради которых продукт вообще существует. Например: «заказать доставку еды за 3 клика», «найти нужную деталь по артикулу», «сравнить тарифы по параметрам».

В сложных продуктах может быть сильно больше 3-5 ключевых задач. В этом случае рекомендую декомпозировать его на логические или функциональные компоненты — и в каждом из них уже выводить свои цели и задачи.

Для каждой задачи задайте измеримые KPI: «среднее время до результата (time‑to‑task)», «конверсия в целевое действие», «доля успешных сценариев» и подобные.

Границы домена

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

Источник истины

Определите, где хранятся все артефакты ИА: таблицы сущностей, словари терминов, фасеты, схемы связей и тд. Лучше всего, если это будет ваша внутренняя вики, типа Confluence. Для диаграмм и визуальных схем можете использовать draw.io (благо, он встраивается почти куда угодно) или FigJam.

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

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

Согласование терминологии

Создайте единый глоссарий терминов, где каждое понятие имеет согласованное определение. Например: в интерфейсе, в аналитике и в БД термин «пользователь» должен значить одно и то же, а не три разных понятия: аккаунт, клиент и автор. Я встречал системы, где одна и та же информационная сущность в одном месте называлась «пользователь», в другом «клиент», а в третьем «посетитель». Не надо так.

Хорошо организованный глоссарий устраняет двусмысленности и предотвращает непонимание между аналитиками, дизайнерами и разработчиками.

Декомпозиция: перечень сущностей

После того как определены контекст и границы продукта, наступает этап декомпозиции — разбиения системы на отдельные сущности. На этом шаге мы превращаем абстрактные понятия («контент», «пользователи», «данные») в конкретные элементы модели, с которыми можно работать, описывать их свойства и связи.

Цель здесь простая: увидеть полную картину того, из чего состоит продукт и как эти части взаимодействуют между собой.

Определение типов

Пройдитесь по всем сценариям вашего продукта и выпишите устойчивые типы информации: «товар», «категория», «метка/тег», «пользователь», «заказ», «корзина», «страница» и тп. Добавьте сюда вспомогательные и производные сущности, которые не видны пользователю напрямую, но обеспечивают работу системы — например, «транзакция», «сессия», «ревизия».

Скорее всего, на этом этапе вы упустите какие-то объекты, ничего страшного. Как я уже говорил, работа над IA — не всегда строго последовательный процесс. Вернётесь, как найдёте ошибку.

Описание сущности

Для каждой сущности кратко опишите:

• роль (что делает эта сущность, зачем она нужна);
• жизненный цикл (от создания до удаления или архивации);
• точки появления в интерфейсе (можно прям названия экранов);
• обязательные операции (создать/редактировать/найти/связать).

Тут важно не уходить в дебри и не погружаться в детальное проектирование. Вот вам пара простых примеров:

Проверка на дубликаты

Проверьте, нет ли дублирующих или пересекающихся сущностей: если у вас есть и «автор», и «пользователь», возможно, это одно и то же с разными контекстами. Тогда их лучше объединить в одну сущность и добавить поле «роль» или «тип».

Закрепление ответственных

Для сложных систем составьте матрицу принадлежности: кто владелец данных по каждой сущности (продукт, контент, аналитика), где они хранятся и как обновляются. Опять же, не уходите в детали, здесь важно оставаться на высоком уровне абстракции.

Вот простенький пример такой матрицы для e-com:

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

Выработка метрик

Дополнительно укажите метрики для каждой сущности — показатели того, что она используется и актуальна. Вот несколько примеров:

Эти показатели помогут оценивать зрелость и здоровье информационной архитектуры, выявлять запущенные участки и планировать развитие модели данных.

Классификация: таксономии, уровни и операции

После того как сущности выделены и описаны, важно понять, как они группируются и взаимодействуют в структуре продукта. Этот этап превращает «список объектов» в осмысленную систему: мы определяем, какие сущности являются базовыми разделами, какие служат фильтрами или связками, и как пользователь перемещается между ними.

Классификация помогает превратить набор данных в удобную навигацию, а архитектуру — в понятную карту продукта.

Типы таксономий

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

Пример, по традиции, из e-com:

Уровни сущностей

Назначьте уровень сущности — высокий, средний или низкий:

• Высокие уровни — это корневые разделы и хабы, которые формируют скелет навигации и точку входа в систему.
• Средние уровни — это страницы‑коллекции, объединяющие однотипные объекты.
• Низкие уровни — карточки конкретных объектов, где реализуются операции и принимаются решения.

Пример распределения сущностей по уровням:

Такое разделение помогает проектировать маршрут от главной страницы к объекту и обратно, управлять глубиной дерева и оптимизировать путь пользователя.

Группы, фасеты и фильтры

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

Пример разницы между статьёй и товаром:

Приоритеты и наследование

Добавьте описание приоритетов и наследования таксономий: что отображается в интерфейсе, что используется для аналитики и SEO, а что служит внутренней классификацией.

Например:

Обязательно фиксируйте ещё и правила наследования: категория → подкатегория → объект. В интерфейсе это проявляется как автоматическое применение фильтров при переходе на нижний уровень.

Управление обновлениями

Зафиксируйте методы актуализации таксономий: кто отвечает за создание новых терминов, их перевод, синхронизацию и архивирование. Опишите процессы ревизии, чтобы не допустить появления дубликатов или устаревших меток.

Например, контент‑отдел добавляет новые категории раз в квартал, SEO‑отдел проводит сверку алиасов, а аналитика проверяет наличие связанных данных.

Для крупных продуктов полезно ввести аудит изменений с фиксированием автора, даты пересмотра и краткого описания причины (например, «слияние категорий», «переименование фасета»).

Выявление связей: кардинальности и контексты

В теоретической части цикла мы говорили о кардинальностях, хранении, сценариях и индексах. Теперь давайте взглянем на то, как к этом прийти.

Кардинальности

Определение кардинальности было в прошлой статье, подробно на термине останавливаться не стану. Добавлю только, что для каждой связи крайне желательно описать:

• с чем осуществляется связь,
• тип связи,
• глубину вложенности и
• пример (при необходимости).

Вот как это может выглядеть для сущности «товар»:

Такая таблица может стать отличным началом для дальнейшей проработки связей.

Контекстные связи

Речь о связях вроде «похожие», «часто вместе», «варианты», «альтернативы» и так далее. Они используются в карточках, рекомендациях и аналитике пользовательских сценариев. Например, в e-commerce это может быть «с этим товаром часто покупают», а в медиа — «похожие статьи» или «продолжение серии».

Важно разделять логические связи (на уровне ИА) и вычисляемые (на уровне аналитики и рекомендательных алгоритмов).

Вот тот же пример, но с добавленными контекстными связями. Здесь и дальше я буду удалять лишние столбцы для читаемости, но в реальной таблице их лучше бы оставлять (или делать перекрёстные таблицы):

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

Ключевые и вариативные связи

Выделите два типа связей:

• ключевые (частые) связи — они должны быть быстрыми, индексируемыми, проверяемыми на целостность;
• вариативные — их можно хранить гибко, например, в JSON или агрегированных таблицах.

Вот тот же пример:

Направление и зависимости связей

Направления связей и зависимость объектов часто определяет их поведение. Заказ зависит от пользователя, а не наоборот. Комментарий зависит от поста, а не пост от комментария. Такие зависимости влияют на каскадное удаление и миграции, это очень важная часть ИА и дальнейшего проектирования баз данных.

Вот как это может выглядеть:

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

Итог

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

Запись Информационная архитектура: сущности (практика, vol.1) первой появилась на Павел Шерер.

Вокабуляр

Для начала давайте вспомним некоторые определения, которые помогут вам ориентироваться в этой статье:

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

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

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

Термин таксономии — конкретная единица этой классификации (например, категория «Кроссовки» в таксономии «Обувь»).

Фасет — нормализованный атрибут, используемый для фильтрации и уточнения поиска (бренд, цвет, размер и тп).

Что такое «сущность» и чем она не является

Сущность всегда:

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

Из-за того, что терминология, как обычно, размыта, сущности легко можно спутать с чем-то, что ими не является, например:

• со страницей/экраном (это представление сущности в одном из контекстов);
• с UI‑компонентом (это способ отображения свойства или связи);
• с таблицей БД (это реализация хранения, одна сущность может жить в нескольких таблицах и наоборот);
• с бизнес‑процессом (это поведение вокруг данных: процесс «оформить заказ» использует сущности «корзина», «заказ», «платёж»).

Небольшая оговорка: иногда название сущности совпадает с названием представления, это абсолютно нормально. В контент‑ориентированных продуктах (CMS, документация, лендинги) тип «Страница» может быть полноценной контент‑сущностью с собственными свойствами (название, ярлык, текст, автор и тп) и жизненным циклом. Тезис «страница — не сущность» касается только путаницы между сущностью домена и экраном интерфейса (UI‑представлением).

Сложно? На самом деле нет. Вот вам простой тест. Объект — это сущность, если содержит хотя бы 3 из следующих признаков:

• имеет собственные свойства;
• имеет связи с другими объектами;
• повторяется во множестве экземпляров;
• нужен в отчётности/поиске;
• имеет собственные правила валидации/жизненный цикл.

Свойства сущности

Как мы уже выяснили, у сущностей есть свойства. Это, пожалуй, самое важное, что отличает их от остальных объектов цифрового продукта. Давайте поговорим об этом чуть подробнее.

Типы свойств

Свойства могут быть нескольких типов:

• Базовые: идентификатор, название, описания и прочие. Это простые поля, которые содержат типовую информацию. Базовые свойства не ссылаются на другие объекты и, как правило, представлены в виде простых типов данных (строка, число, дата и тп).
• Ссылочные: внешние ключи на другие сущности (например, «идентификатор пользователя» в сущности «заказ»), а также термины таксономий (категория, метка, группа). Ссылочные свойства нужны для того, чтобы гарантированно связать сущности между собой и с терминами таксономий.
• Составные: свойства, которые включают в себя сразу несколько значений, объединённых одной логикой. Составные свойства могут быть однородными и неоднородными:
  • однородные списки (например, изображения: {url, alt},...);
  • неоднородные комплекты (например, габариты: {weight, width, height, depth}).
• Вычисляемые: свойства, для фиксации (сохранения, отображения и тп) которых нужно сначала произвести какие-то операции. Например, это могут быть: цена со скидкой, количество на складе, агрегированный рейтинг.
• Технические: SKU/артикул, временные отметки, статусы модерации/публикации, флаги индексации. Технические свойства редко используются в визуальном представлении (например, в карточке товара из десятка технических свойств будет выводиться только артикул).
• Ограничительные: права доступа (ACL), владельцы, видимость. Их очень легко спутать с техническими, так как они тоже используются больше в логике, чем в представлении. Если сомневаетесь, задайте себе вопрос: «это свойство влияет на возможности пользователей?» — если да, то перед вами именно ограничительное свойство.

И снова небольшое уточнение, чтобы избежать путаницы: типы свойств сущностей — не то же самое, что типы данных, которые эти свойства содержат. Например, если у нашей сущности «товар» есть свойство title (название), то тип свойства здесь — базовый, тогда как тип данных — строка. Подробнее о типах данных я писал здесь.

Пример описания свойств

Минимальный набор информации, которую желательно фиксировать при описании каждого свойства сущности:

1. название — короткое имя свойства, одно-два слова;
2. код — как это свойство будет называться в коде и базе данных;
3. тип данных — строка, число, массив, объект, ссылка и тп;
4. обязательность — обязано ли свойство быть заполненным, если отметка «да», то значение свойства не может быть пустым;
5. пример — короткий пример заполнения свойства (если пример слишком длинный, он может быть обрезан);
6. описание/комментарий — если требуется вносить какую-то дополнительную информацию.

При желании, этот перечень можно дополнить дополнительными параметрами:

1. источник — откуда берётся значение свойства (логика, подсистемы, интеграции и тп);
2. валидации — базовое правило проверки значения свойства;
3. индексация/поиск — участвует ли свойство в поиске и индексации, если да, то как;
4. политика i18n — для локализуемых свойств: какие переводятся, какие нет;
5. политикой заполнения — кто и когда обязан заполнить.

Вот пример того, как могут фиксироваться свойства сущности «товар» (табличка получилась внушительная, скрольте влево):

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

Примеры по доменам

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

Чтобы показать, насколько всё может отличаться от продукта к продукту, вот вам несколько примеров сущностей со свойствами из разных доменов:

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

Связи между сущностями

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

Кардинальности

Кардинальность — это характеристика связи между двумя сущностями (таблицами, объектами, классами и т.д.), показывающая, сколько экземпляров одной сущности может быть связано с экземпляром другой. Проще говоря, это способ ответить на вопрос: «Сколько А может быть связано с одним B?» и наоборот.

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

Подробнее про кардинальности я писал в цикле про дизайн данных, здесь пройдёмся коротко:

• Один-ко-одному, 1:1 — связь, когда каждой записи одной сущности соответствует не более одной записи другой (аккаунт ↔ профиль). Используется для разделения личных и технических данных или выделения редко используемых атрибутов.
• Один-ко-многим, 1:N — наиболее частая связь: один объект верхнего уровня связан с множеством подчинённых (категория → товары; организация → проекты). Применяется для иерархий, коллекций и агрегатов.
• Многие-ко-многим, M:N — объект может быть связан с несколькими другими (товар ↔ теги; пост ↔ автор). Реализуется через промежуточные таблицы/сущности, содержащие идентификаторы обеих сторон и метаданные связи.

Хранение и производительность

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

Это ещё не дизайн баз данных, но первый шаг к нему.

Ключевые, частые связи

Реализуются как явными внешними ключами (Foreign Key, FK — ссылка из одной таблицы БД на запись другой таблицы), так и отдельными таблицами. Индексируются для быстрого поиска и каскадных операций (например, при удалении пользователя каскадом удаляются его профиль, способы оплаты и тп). Ключевые связи хорошо подходят для данных, которые часто запрашиваются и требуют согласованности.

Например, ключевой связью является связь пользователя и его профиля (1:1) или заказа и товара (1:N).

Вариативные, редкие связи

Удобнее хранить в агрегированных структурах (JSON, массивы, ключ-значение) или связующих таблицах без строгих FK. Такой подход облегчает эволюцию схемы и интеграции с внешними источниками.

Пример вариативной связи: товар и теги (M:N через JSON или связующую таблицу) или пост и связанные материалы (список ссылок в массиве).

Комбинированный подход

Сочетает строго типизированные связи для критичных сценариев (например, FK для заказов и пользователей) и гибкие структуры для второстепенных (например, свойства товара в JSON). Это компромисс между скоростью, расширяемостью и затратами на сопровождение.

Пример комбинированного подхода: заказ и пользователь (жёсткий FK) + история изменений в JSON, товар и его характеристики (основные поля + гибкое поле параметров).

Поисковые сценарии и индексы

Вот вы открыли свой любимый маркетплейс. Вбили в поле поиска нужный товар, отфильтровали по бренду и отсортировали результат по цене. Поздравляю, вы только что покрыли практически все поисковые сценарии.

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

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

Индексировать можно разные типы полей:

Фасетные поля

Категория, бренд, размер, цвет, материал и прочее. Хранятся в нормализованных словарях или связаны с терминами таксономий, индексируются отдельно. Это даёт возможность строить фильтры и считать количество элементов в каждой группе (это ещё называется «фасетные агрегации»). Чтобы ускорить отклик системы, важно хранить предвычисленные частоты — но это уже совсем мрак, оставим его архитекторам БД.

Поисковые поля

Используют полнотекстовые индексы и префиксные деревья для автодополнения и предложений. Помните, как вы вбиваете что-то в строку поиска, а вам показывают подсказки? Вот это оно. Здесь же добавляются морфологический анализ, поддержка синонимов, транслитерации и нечёткий поиск (fuzzy search).

Сортировочные поля

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

Сложно? Подождите, это ещё не всё

Существует тьма технических приёмов, нацеленных на оптимизацию индексирования: применение комбинированных индексов по частым связкам category_id + price, денормализация популярных связей product → category_name, кэширование фасетных частот для снижения нагрузки и прочее. Но это вам так, если захочется погрузиться.

Таксономии и «сквозные» свойства

Правильная таксономия обеспечивает единый язык между пользователями, системой и бизнесом. Таксономии бывают нескольких типов, и каждая решает свою задачу:

Иерархическая таксономия

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

Такая модель хорошо подходит для каталогов товаров, корпоративных порталов и CMS, где пользователи ожидают логичную последовательность разделов и вложенных подразделов.

Преимущество: высокая предсказуемость навигации и простота в управлении.

Недостаток: ограниченная гибкость и риск «похоронить» информацию слишком глубоко.

Плоская таксономия

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

Чаще всего плоские таксономии используется в медиа, блогах и SaaS‑платформах для тегирования и сквозных переходов между материалами.

Преимущество: простота расширения и гибкость.

Недостаток: если не контролировать список терминов, со временем возможна потеря структурности и даже полная поломка логики (например, когда у вас есть 2 разных метки «UX» и «ux»).

Фасетная таксономия

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

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

Преимущество: высокая управляемость фильтрацией и быстрый поиск.

Недостаток: сложность проектирования и ухудшение управляемости при росте числа комбинаций.

Сквозные свойства

Например: материал, бренд, разрешение экрана. Сквозные свойства выполняют роль фасетов и служат мостом между таксономиями и данными:

• живут в единых словарях, которые поддерживаются централизованно;
• используются как фасеты и правила мерчендайзинга/рекомендаций;
• имеют политику синонимов, нормализации значений и правила локализации;
• могут быть жёстко типизированы (enum — о них чуть ниже) или гибкими (текстовые значения, появляющиеся из данных);

Однако у сквозных свойств есть и обратная сторона. Давайте разберём на примере свойства товара «материал».

«Материал» — фасет только при наличии нормализованного словаря (ограниченный справочник материалов). Если материал хранится как произвольный текст (например, «металлический с пластиковыми вставками»), он не является фасетом и остаётся обычным полем: участвует в полнотекстовом поиске, но не в фасетной фильтрации.

Противоречивые классификации

Иногда классифицировать сущности оказывается сложно. Хороший пример такой противоречивой классификации — вопрос «где разместить арбуз»? Это ягода (что правильнее с точки зрения ботаники), тыквина (что ещё более правильно) или фрукт (ведь именно там его ищут пользователи)?

Когда один и тот же объект может относиться сразу к нескольким категориям, архитектору важно не выбрать «правильный» ответ, а установить управляемую логику принятия решений. Задача таксономии — не отражать условную «истину», а обеспечивать предсказуемость и согласованность между системами.

И для этого существует несколько правил:

1. Вводим приоритеты классификаций (биология < повседневные ожидания < бизнес‑цели каталога). Эти приоритеты задают уровень, на котором принимается решение — например, витрина каталога ориентируется на пользовательскую логику, а не на научную.
2. Формируем правила визуализации и информационные связи: как объект отображается в меню, поиске, фильтрах и фасетах, чтобы не было дублирования или рассинхронизации. В карточке сущности могут быть указаны обе принадлежности, но навигация использует только основную.
3. Фиксируем конфликты и владельцев решения: кто принимает решение, когда пересматривается структура, где фиксируются комментарии и примечания.
4. Документируем принципы разрешения конфликтов и исключения, чтобы разные подсистемы (поиск, рекомендации, SEO) пользовались единым источником правды.

Пример визуализации базы данных

По итогу работы над информационной архитектурой обычно создаются спецификации API и дизайн БД. Про API здесь говорить пока рано, а вот про БД уже пора.

Ловите пример того, как может выглядеть простенькая база данных в виде ER-диаграммы:

Здесь учитывается почти всё:

• По типу соединения можно понять тип связей. Например, от users.id к orders.user_id соединение начинается одной линией, а заканчивается несколькими, разветвлением — это связь однин-ко-многим (1:N).
• Иконка «ключика» возле названия поля обозначает первичный ключ (primary key), который уникально идентифицирует каждую запись. А иконка «заметки» говорит о том, что у поля есть дефолтное значение.
• Если возле названия есть иконка «ссылки», то это внешний ключ (foreign key), и от него почти всегда будет связь 1:N к источнику. Например, от того же orders.user_id к users.id.
• Две буквы «NN» в конце каждой строки — это «NOT NULL», поле не может быть пустым. Та самая обязательность из таблички, помните?
• Буква «Е» в orders.status означает «ENUM» — набор именованных констант. Значение этого поля может быть заполнено только значениями из определённого словаря. В нашем случае статус заказа может быть только pending, paid, shipped, delivered или canceled.
• Ну а всякие varchar, int, decimal, datetime и другие — всего лишь типы данных, которые хранятся в этом поле.

Так нафига вообще тогда информационная архитектура, если можно сразу пилить ER-диаграммы и не париться? Да потому что они описывают только один слой IA — слой реализации хранения данных (в самом начале статьи мы об этом говорили). Огромный пласт информации, накопленной грамотным подходом к IA, здесь не учитывается. Примеры, политики заполнения и мультиязычности, правила валидации, источники данных и куча всего остального.

Так что не ER-диаграммами едиными.

Что дальше

А дальше мы поговорим о практической работе с сущностями: как их искать, формализовать и поддерживать, немного поговорим о частых ошибках и анти-паттернах. Отдельно я расскажу о том, как из сущностей и их связей формировать навигацию и поиск. Ну и бонусом, в следующих статьях будет несколько шаблонов, чек-листов и даже мини‑RFC для решения по сущностям.

Подписывайтесь на канал, там будут все новости.

Запись Информационная архитектура: сущности (теория) первой появилась на Павел Шерер.

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

Детальное функциональное проектирование

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

Именование функций

У каждой функции и каждого функционального раздела должно быть своё уникальное название. Названия должны быть максимально понятными и самодостаточными. Используйте английский язык — это обеспечит единое понимание в команде (особенно если она международная) и немного упростит работу программистов.

Удачное название функции упрощает её поддержку и снижает риск двусмысленности.

Неудачные названия часто бывают слишком абстрактными или краткими, что затрудняет чтение и может привести к ошибкам при оценке и реализации. Следуйте нескольким простым правилам:

• Глаголы: название функции, как правило, должно отражать действие. Например, из названия AddUser сразу понятно, что происходит добавление пользователя.
• Минимум аббревиатур: если аббревиатура не общеизвестна, лучше её избежать. Если же совсем никак, заведите в проектной документации словарь.
• Ясность: человек должен понимать суть функции, даже если читает её название впервые.

Функциональные сценарии

Функциональные сценарии прорабатываются итеративно: от самых простых к детализированным. К этому времени накапливается достаточное количество данных для их глубокой проработки.

Пример высокоуровневого сценария для UserRegistration:

1. Пользователь открывает страницу регистрации.
2. Вводит свои данные.
3. Нажимает кнопку «Зарегистрироваться».
4. Валидация: система проверяет данные.
   • Если всё корректно, создаётся аккаунт, и на почту отправляется письмо для подтверждения.
   • Если данные некорректны, отображается ошибка.
5. Подтверждение: пользователь переходит по ссылке в письме, чтобы подтвердить регистрацию.
6. Если почта не подтверждена в течение 24 часов, аккаунт удаляется, пользователю показывается сообщение об ошибке.

Теперь рассмотрим, как можно детализировать отдельный фрагмент такого сценария: например, ConfirmEmail:

• Мы проработаем обмен данными и их сохранение.
• Для каждой проверки будет выделена отдельная функция.

Обратите внимание, что над некоторыми клиентскими функциями указаны названия и состояния экранов (например, ConfirmEmail.check) — мы к этому ещё вернёмся.

Описание функций

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

Описание функции должно быть лаконичным и понятным для всех участников команды: от разработчиков до уборщиков и бизнес-специалистов. Что обычно включает в себя описание функции:

• Назначение: зачем нужна функция и что она делает.
• Входные и выходные данные: какие данные функция принимает и что возвращает (если применимо).
• Зависимости: с чем функция взаимодействует, без чего не будет работать (например, функциональный раздел confirmPhone не получится реализовать до того, как будет готов sendSMS).
• Пример использования: когда и как функция применяется.

Пример упрощённого описания функции AddToCart:

• Назначение: добавить товар в корзину для оформления заказа.
• Входные данные: идентификатор sku и количество count товаров, идентификатор пользователя guid.
• Выходные данные: обновлённое состояние корзины, массив cardState.
• Зависимости: InventoryService (для проверки наличия товара).
• Пример использования: пользователь добавляет товар в корзину, система проверяет наличие и обновляет состояние корзины.

Здесь можно добавить User Stories, Use Cases и вообще всё, что вы посчитаете нужным. Главное, чтобы описание было трактуемым однозначно.

Итеративная работа над сценариями позволяет их улучшать по мере получения новой информации и обратной связи от связанных специалистов или пользователей.

Названия и состояния экранов

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

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

Названия экранов

Название экрана должно ясно объяснять его назначение. Если у вас в Figma экраны будут именованы так же, как в проектной документации, это упростит работу фронтендеров и сделает эту документацию более консистентной.

Состояния экранов

Каждый экран может находиться в различных состояниях, которые важно предусмотреть заранее. Пример состояний для экрана ShoppingCart:

Помните, в сценарии над некоторыми клиентскими функциями указывались названия и состояния экранов? А теперь представьте, что это — ссылки на конкретные фреймы в Figma. Разработчикам не нужно больше играть в «найди 10 различий», они видят взаимосвязь функций и экранов напрямую.

Подводные камни

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

Ниже я перечислил самые частные ошибки и недоработки, которые допускал сам или видел у других.

Недостаточная проработка

Иногда хочется приступить к разработке пораньше. Это желание понятно, я много раз слышал обвинения в «вотерфольности» моего подхода. И именно «аджайлами» люди частенько прикрывают нежелание или неумение нормально проектировать. Ну что ж, дело хозяйское.

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

Пример:

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

Уровень абстракции

Я часто об этом говорю (например, здесь), и повторю снова.

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

Пример:

В одном из недавних проектов аналитик проявил чудеса самостоятельности и (пока никто не видел) расписал в деталях одну из подсистем. Но его работа не учитывала огромное количество нюансов других компонентов, которые к тому времени ещё не были спроектированы. Итог: вся работа в мусорку.

Технические знания

Казалось бы, странно требовать от дизайнеров каких-либо знаний в технических областях. Но нет, не странно.

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

Пример:

При проработке внутренней части корпоративного блога, дизайнеры и аналитики не продумали возможность взаимной блокировки редактора (это когда ты не можешь править текст, который правит кто-то другой). Разработчики тоже не додумались. В итоге какое-то время, пока не внедрили веб-сокеты, контент-менеджеры перезатирали изменения друг друга.

Консультации с экспертами

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

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

Пример:

Делали мобильное приложение. Одной из метрик эффективности продуктового дизайна была конверсия. Однако для пользователей из разных каналов необходимо было создать уникальный опыт. Пришёл с YouTube — один сценарий, с Telegram — другой. Дизайнеры тупо добавили на начальный экран вопрос «откуда вы пришли». Хотя достаточно было сходить к маркетологам или разрабам, чтобы они рассказали про такое чудо инженерной мысли, как диплинки.

Донесение ценности до бизнеса

Самый больной «камень». Хотя он и не подводный вовсе, а очень даже надводный. Знали бы вы, сколько раз мне приходилось доказывать клиентам, что начинать разработку ещё слишком рано. Или что влитые в проектирование деньги сохранят бюджет проекта в дальнейшем.

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

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

Антипример:

Я смог донести до клиента важность проектирования и исследований. Сам ездил со специалистами, прикидываясь стажёром. Выкопали вообще все бизнес-процессы до самых корней. С момента начала проектирования до первой строчки кода прошло 9 месяцев. Зато релиз вышел почти через год после начала разработки. Итог: от первой встречи с клиентом до релиза — один год и 11 месяцев. Ключевой конкурент потратил на это почти 5 лет с командой, в 3 раза больше нашей.

Лень и возврат к общей картине

Как я уже говорил, продумать всё невозможно. Да, вы были хороши и ваша высокоуровневая архитектура прекраснее, чем «Битва кентавров» Микеланджело. Но будьте готовы, что в процессе детальных изысканий вам придётся возвращаться на высокий уровень. И не просто возвращаться, а кое-где существенно его изменять.

Увлечение деталями иногда мешает вернуться к общей концепции. Это ведёт к потере видения конечной цели и необходимости исправлений.

Пример:

Я проектировал одного из своих питомцев. Вроде, предусмотрел всё, всю свою маркерную доску испещрил сценариями, был готов приступать к разработке. Осталось совсем немного: добить механики копирования пункта в собственный вишлист. А это повлекло за собой пересмотр механик регистрации (потому что теперь это нужно было делать не с отдельной страницы) и механик создания вишлиста (по той же причине). Пришлось возвращаться на высокоуровневое проектирование и изменять структуру API. Хорошо, код писать не начал, переписывал бы.

Итог

Если вы дочитали эту статью до конца, значит, у вас достаточно мотивации, чтобы начать (или продолжить) делать правильно. Если же вы просто проскроллили вниз — мои соболезнования (и ноль процентов осуждения). Всё, что я мог сделать, чтобы стабилизировать процесс проектирования и разработки, я в этом цикле сделал.

Дальше дело за вами.

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

Поэтому в этой статье мы поговорим о том, как убедить бизнес в необходимости проработки ФА и как выстроить пуленепробиваемый (ну почти) процесс её создания.

Погнали.

Зачем бизнесу функциональная архитектура

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

Укрепление стандартов

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

V-модель делает отдельный акцент на тестировании, это позволяет выпускать стабильные продукты с оптимальным Time to Market. Однако стабильность вовсе не означает качество. В погоне за соблюдением стандартов мы часто нарушаем баланс в проектировании.

Давайте будем честны, в V-модели (как и в большинстве других) всегда есть «главные» направления, которые задают тон всему проектированию. Как правило, такими «главными» становятся либо аналитики, либо дизайнеры. То есть обычно варианта два:

• дизайнеры рисуют макеты по функциональным требованиям;
• аналитики пишут требования, исходя из макетов.

Ясное дело, я сейчас упростил. Не только «макеты» и не только «требования». Порой просто «лидирующие», а не всегда прям «главные». Не всегда лишь аналитики и дизайнеры, иногда ещё какие-нибудь инженеры (привет, психбольница Купера). Но суть, полагаю, ясна: кто-то всегда отталкивается от видения другой стороны.

И в этом кроется дьявол. Аналитики (простите, друзья) нифига не шарят в юиксе. Дизайнеры (сорри, гайз) почти ничего не знают о технологических особенностях продукта. Юзерфлоу произрастает из функциональных требований и превращается в монстра Франкенштейна, а требования к продукту запросто игнорируют фундаментальные потребности пользователей.

Кроме того, само понятие «функциональных требований» вызывает лично у меня крайне неоднозначные эмоции. В первой статье цикла я упоминал, что функциональные «требования» и «описание» — отнюдь не одно и то же. Так вот V-модель подразумевает, что в разработку передаются именно «требования». А это значит, что «строители» начинают принимать решения за «инженеров» и даже «архитекторов». Потому что архитектурный максимум, на который способна классическая V-модель, это архитектура «системы».

Готовые модели и фреймворки часто игнорируют внутреннюю гармонию продукта. Почти всегда есть некоторый перекос в сторону дизайна, аналитики или инженерии. Причём не важно, Agile это, Incremental Model, RAD или Iterative Model.

Думаю, вывод здесь очевиден: для бизнеса такой перекос означает снижение качества продукта. Что в конечном счёте увеличивает стоимость его улучшения и развития.

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

Снижение продуктовой энтропии

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

Другими словами, мы проектируем продукты по кускам, максимально углубляясь в ту часть, которой сейчас занимаемся. Продумываем экран каталога? Надо сразу понять, что и как отображать на каждой карточке товара. Проектируем чат? Давайте тут же решим, будет ли возможность преобразовывать текст в эмодзи. И не важно, что потом принятые нами решения станут барьерами, ограничениями продукта — потому что создавались без оглядки на общую картину. Ведь общей картины-то на тот момент и не было.

Приведу пример. На заре моего аналитического опыта был у меня проект по цифровому депонированию объектов интеллектуальной собственности. Такое электронное подтверждение авторства. Основой сервиса была форма загрузки контента, и я, по неопытности, сделал именно на ней основной акцент. Мы с аналитиками и дизайнерами вылизали эту форму до блеска. Она была идеальной, но абсолютно не учитывала категории пользователей. Как потом оказалось, жизненный цикл юридических и физических лиц в продукте отличается очень и очень сильно. Нам пришлось серьёзно переработать форму депонирования и её логику, так как с юридической точки зрения заполняемые поля значительно отличались. Мы потратили время и ресурсы на проработку того, что потом поменялось более чем на 70%. Более того, разработчики к тому времени уже сформировали определённый фундамент, и им тоже пришлось многое переделывать.

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

И нет, это не waterfall. Проектирование может и должно осуществляться итерационно.

Снижение издержек

Как обычно происходит передача требований в разработку? Берутся макеты, UX-спецификация (если вы крутые), какие-нибудь функциональные и нефункциональные требования, всякие User Stories, Use Cases, User Flows — и отправляются разработчикам. Которые анализируют все эти (зачастую разрозненные) артефакты и решают, как именно должна работать система. Иногда в процесс встраиваются системные аналитики, которые немного упрощают процесс анализа — но даже они не проектируют функции продукта. Максимум, прорабатывают интеграционные механики и глобальную (не функциональную) архитектуру.

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

Круто, если на проекте есть выделенный архитектор. Но даже он обычно проектирует не функциональную модель, а облачную или программную. Сильный техлид уменьшит количество проблемных участков кода, но даже он не способен постоянно помнить о всех функциях системы. Закон Миллера вполне конкретно определяет количество элементов, которые может удержать в кратковременной памяти обычный человек: максимум 9. Даже если наш архитектор/техлид гений и может в два раза больше — это не сравнимо с количеством функций даже самой простой цифровой системы.

Разумеется, всё это приводит к усложнению поддержки и развития продукта. Дорабатывать его становится сложно, внедрение каждой новой фичи стоит всё больше и больше денег.

Функциональная архитектура — не серебряная пуля. Она не решит всех проблем. Но она, как минимум, снимет часть издержек за счёт изначальной стабилизации проектирования и разработки.

Проектное взаимодействие

Окей, с этим понятно. Но ведь бизнес — это не только про сокращение издержек и энтропии. Это ещё и про отлаженные и эффективные процессы. В том числе, про процессы проектирования, аналитики и продуктового дизайна в целом. Как же внедрить проработку функциональной архитектуры? Кто за неё отвечает и как она ложится на остальные проектные артефакты, вроде той же CJM или User Stories?

Давайте разбираться.

Шаблонизация

И начать я хочу с тезиса, который может вас немного разочаровать. Любые шаблоны в ФА — безусловное зло. Да, могут быть какие-то методологические форматы отдельных артефактов. Да, унификация документации важна (особенно, если над ней трудятся несколько человек одновременно). Но глобальных шаблонов, кочующих из проекта в проект, быть не должно.

Почему так? Потому что любая архитектура должна подстраиваться под продуктовые и проектные реалии. Но никак не наоборот. Когда вы начинаете выстраивать архитектуру (причём не только функциональную) с помощью жёстких шаблонов и «устоявшихся» паттернов, вы накладываете на продукт серьёзные ограничения. Причём ограничения, зачастую абсолютно ничем, кроме вашего опыта, не оправданные.

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

Авторы функциональной архитектуры

Кто читал вторую статью, тот наверняка помнит функциональные сценарии. Это такая стероидная смесь из BPMN и sequence diagram:

Если внимательно присмотреться к ФС, то можно увидеть, что они, в числе прочего, описывают и пользовательский путь. А значит, включают в себя значительную часть UX. Но при этом здесь есть и серверная логика, и какие-то технологические особенности системы.

Типичный аналитик вряд ли способен качественно проработать навигацию и опыт пользователя. Даже хороший продуктовый дизайнер может не знать нюансы аутентификации через IdP. Но если ни дизайнер, ни аналитик не могут самостоятельно проработать функциональную архитектуру, то кто же должен ею заниматься? Вариантов несколько.

Иногда находится супердизайнер. Достаточно подкованный, чтобы решать базовые технические вопросы и достаточно опытный, чтобы отделить свои знания от незнаний — и сходить за последними к архитекторам и разработчикам.

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

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

Перекрёстное опыление

То, о чём я хочу рассказать, мой хороший друг Олег Будко назвал «перекрёстным опылением». Именно оно позволяет не допускать перекоса в сторону дизайна, аналитики или инженерии, а также создавать действительно консистентную проектную документацию.

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

Давайте чуть подробнее пройдёмся по каждой вехе (за исключением IA, она вне рамок этой статьи).

Концепция

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

Здесь дизайнеры прорабатывают базовую ролевую модель, потребности и особенности будущих пользователей системы. Аналитики вместе с ними, а также с бизнесом и технарями решают, каким образом продукт закрывает интересы всех заинтересованных сторон. В итоге у нас формируются ключевые механики, функциональные границы и (иногда) ролевая матрица создаваемой системы. Это объёмный этап, чуть подробнее я описывал его в небольшом цикле про концепцию.

Функциональная модель

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

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

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

Однако в реальности модель может изменяться и актуализироваться — особенно если проект действительно большой

Дизайнеры пилят (или допиливают) CJM, опираясь на функциональную модель. Аналитики изучают CJM и мапят её со своей моделью. Если в модели отсутствует какой-то функциональный раздел, который подразумевается в CJM (например, онбординг), то это очень быстро выявляется.

После того, как первая версия модели готова, мы можем приступить к итерациям высокоуровневого проектирования. Например, начинаем прорабатывать логин и регистрацию.

Функциональные сценарии и описание

Аналитики расшивают функциональную модель на более мелкие разделы, внутри которых уже описывают функциональные сценарии и описание функций. Разумеется, подглядывая в доки дизайн-команды. Дизайнеры смотрят на эти сценарии и сравнивают их со своими user/screen flow, user stories и тп. Конкретный набор артефактов со стороны дизайна не важен, у каждого проекта/команды свой набор. Важна регулярная синхронизация.

На выходе мы получаем проработанную итерацию ФА, консистентную и согласованную.

Экраны, состояния и функции

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

Обратите внимание, что над всеми системными функциями в верхней, клиентской, области есть названия и состояние экранов. Над функцией «Переход к состоянию успешной регистрации» есть надпись «Nav.Authn, ValidationSuccess». Так вот «Nav.Authn» — это название экрана, а «ValidationSuccess» — его состояние.

Такая нотация позволяет:

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

А теперь представьте, что текст «Nav.Authn, ValidationSuccess» может быть ссылкой, ведущей на конкретный фрейм в фигме (тот же draw.io позволяет это делать). И разработчику даже не нужно соотносить функции и экраны, за него это уже сделано! Он просто пишет код — то есть делает то, в чём реально хорош. Мы не заставляем его глубоко анализировать проектную документацию. У него есть функциональные сценарии и описание функций. Они слинкованы с конкретными макетами. Вся логика системы понятна и прозрачна.

Итог

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

Здесь же главный посыл простой: ФА способна стабилизировать практически любую модель разработки ПО, и (при грамотном подходе) сделает это легко, изящно и с выгодой для бизнеса.

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

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

Общие функции

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

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

Выявление

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

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

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

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

Пример

В любом случае, говорить об общих функциях абстрактно смысла не имеет. Нужна конкретика. Посему вот вам короткий пример таких разделов и функций, частенько встречающихся в мобильных и веб-приложениях:

• Показ системных сообщений. Общая функция вывода системных сообщений в интерфейс: негативных, информационных или позитивных. Может принимать параметры (статус, текст и приоритет).
• API. Объёмный функциональный раздел, отвечающий за обмен данными между клиентом (сайтом, мобильным приложением, голосовым помощником etc.) и сервером.
  • Отправка запроса. Функция отправки запроса на сервер. Всегда включает в себя параметры (как минимум адрес и, собственно, передаваемые данные). Может совмещаться с авторизационными действиями: очень часто тело запроса содержит в себе данные, а заголовки запроса — авторизационную информацию (подробнее об этом в дизайне данных).
  • Обработка ответа. Вызывает другие функции, в зависимости от ответа сервера (у разработчиков это называется callback-функции). Например, может использовать функцию «Показ системных сообщений».
• Формы. Общий функциональный раздел для работы с формами.
  • Валидация полей форм. Общая функция проверки на корректность заполнения полей форм, включает в себя дочерние функции:
    • проверка на обязательное поле,
    • проверка корректности email,
    • проверка корректности номера телефона,
    • проверка корректности даты и/или времени,
    • проверка корректности чисел,
    • проверка по регулярному выражению (сама регулярка передаётся параметром).
  • Показ сообщений форм. Показ сообщений о событиях форм (сообщение отправлено, поле «email» заполнено неверно и тп). Может использовать другую общую функцию «Показ системных сообщений».
  • Данные форм. Общая функция обмена данными форм с сервером.
    • Отправка данных формы. Общая функция на клиенте (браузер, мобильное приложение), отвечающая за передачу данных формы на сервер. Может использовать функцию «API → отправка запроса».
    • Обработка ответа. В зависимости от ответа сервера, выполняет те или иные действия (показ сообщения об ошибке, перенаправление на другой экран и тп). Может использовать функцию «API → обработка ответа».
• Наличие сети. Проверка наличия доступа к Интернету при загрузке экранов и отправке форм. Может включать в себя дочерние функции (например, для блокировки интерфейса мобильного приложения или отложенной отправки данных форм, когда появится интернет).
• Обновление экрана. Обновление содержимого экрана мобильного приложения (например, по свайпу вниз). Всегда инициирует выполнение других функций.
• Аналитика. Общая функция отправки данных в аналитику.
  • Переход. Отправка в аналитику перехода между экранами. Во многих SDK эта функция реализуется «из коробки».
  • Событие. Отправка в аналитику отдельного события (например, добавления товара в корзину или шэринга поста в соцсети).

Разница подходов

Внимательный читатель заметит, что общие функции в этой и предыдущей статьях формируются по несколько разным принципам. Например, в прошлой статье нет общей функции форм, всё сведено просто к данным. Зато там есть функция «очередь сообщений», а здесь её нет — очередь сообщений формируется автоматически на основе параметра «приоритет».

Это сделано не случайно, а в качестве иллюстрации к основному посылу всего цикла:

Вы сами решаете, какими будут структура и состав вашей функциональной архитектуры. Любая шаблонизация ставит под угрозу стабильность и результат проектирования. Руководствуйтесь здравым смыслом, не стесняйтесь консультироваться у специалистов.

Вообще, возобладание шаблонов над разумом — бич современного проектирования. Думайте, сравнивайте подходы. Выстраивайте собственный рабочий флоу под специфику каждого проекта.

Зависимые функции

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

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

Так и в функциональной архитектуре. Функции имеют разный уровень и зависят друг от друга. Есть базовые, фундаментальные, на которых строится вся система. Есть более высокоуровневые, которые обеспечивают взаимодействие остальных.

Вот вам простой пример. Ваши разработчики не смогут написать функцию подтверждения номера телефона, пока не будут спроектированы и реализованы более фундаментальные функции обработки запроса на сервере и отправки SMS.

Иерархическая зависимость

Вот смотрите. Допустим, функция отправки SMS используется нами лишь в одном месте: когда пользователь подтверждает номер телефона. Мы совершенно уверены, что больше никто и нигде не будет отправлять SMS в нашем проекте. Это значит, что отправка SMS — не общая функция, и приступить к её разработке можно будет, когда мы доберёмся до, собственно, подтверждения номера.

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

Линейная зависимость

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

Но есть и другой вид — линейная, или параллельная взаимосвязь. Хороший пример: регистрация. Допустим, в вашем проекте можно зарегистрироваться с помощью email и через сервисы/соцсети. Классическая ситуация. Однако поразмыслив, вы решаете в первом релизе ограничиться какой-то одной, например, через email. Вы её проектируете, даёте задание разработчикам. Разработчики разрабатывают. Вы довольны. Но довольными вы будете ровно до тех пор, пока не придёт время реализовывать вторую часть, регистрацию через внешние сервисы.

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

Конечно, это всё решаемо. Поля в БД можно добавить, регистрацию переписать. Только зачем, если можно с самого начала сделать правильно? Спроектировать сразу обе, передать разработчикам и сказать, что пока нужно делать только одну?

Линейная зависимость функций самая неочевидная. Вы даже не представляете, сколько велосипедов и костылей таится в тех продуктах, которыми мы пользуемся каждый день. Костылей, появившихся из-за того, что кто-то просто поленился подумать.

Серверные и клиентские функции

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

Снова приведу пример. Вот есть у вас общая функция валидации с переданным параметром «email». Что она должна уметь делать? Проверять корректность введённых или переданных данных — и всё, вроде. Но нет.

Клиент

На клиенте (например, в браузере) она должна проверять корректность введённых данных и:

• Если данные не валидны:
  • визуально изменять поле (изменять цвет текста и границ на красный);
  • выводить сообщение «некорректный email» рядом с полем;
  • запрещать отправку формы.
• Если данные валидны:
  • скрывать сообщение и возвращать визуальное состояние поля (если ранее оно было заполнено неверно);
  • передавать управление функции отправки данных на сервер.

Сервер

В то же время, на сервере должна быть своя валидация, потому что клиентскую легко обойти (и выполнить, например, SQL-инъекцию). Поэтому серверная валидация также должна проверять корректность полученных данных:

• Если данные некорректны:
  • возвращать на клиент ошибку с текстом «некорректный email» и признаком поля, рядом с которым нужно показать сообщение;
  • прерывать выполнение.
• Если данные корректны, возвращать управление функции обработки данных форм (например, регистрации), где уже происходит очистка данных и их запись в БД.

И это — только банальная валидация. Представьте, насколько сложно на таком уровне грамотно спроектировать даже привычную нам функцию регистрации?

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

Итог

Функциональное проектирование — это не просто перечисление функций будущего продукта. Это громадная работа по их анализу, выявлению взаимосвязей и потенциальных дубликатов. В следующей части я немного расскажу о том, как связывать функциональное проектирование, аналитику и UI/UX, а также о парочке неочевидных решений.

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

В этой статье я хочу рассказать о том, как «продолжение» User Story может не только улучшить UX продуктов, но и решить кое-какие фундаментальные проблемы их разработки.

Цифровые продукты редко запускаются гладко. Правки к сценариям, функциональности и макетам зачастую возникают прямо в процессе реализации. Никто никогда не в курсе, куда несётся поезд продуктовой разработки — а обратное чувство, чаще всего, обманчиво.

Персоны и User Story — это такая прикольная штуковина для того, чтобы погрузить всех участников в проектный процесс, выявить и подсветить истинные задачи пользователей. Однако сами по себе персоны практически не влияют на процесс создания продуктов, лишь на их функциональность. Чего нельзя сказать о следующем этапе развития пользовательских историй — о User Story Mapping.

Об этом подходе написано уже немало, в том числе и на русском языке. Но большинство таких статей (на мой субъективный взгляд) либо весьма поверхностны, либо имеют серьёзный перекос в сторону именно UX, практически игнорируя аспект управления и развития продукта. Однако я искренне благодарен авторам таких статей, ибо понахватал оттуда приличное количество тезисов и умозаключений.

Проблемы

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

Требования к продукту плохо структурированы по отношению друг к другу

Нет иерархии и последовательности требований. Не всегда понятно, какая задача какую блокирует и от какой зависит. Чаще всего зависимость задачи проставляется исключительно командой разработчиков или тимлидом — но они не владеют общим видением продукта, руководствуясь только своими представлениями о локальном участке архитектуры. То есть они не видят всю связь, весь flow бизнеса и пользователя целиком. Не тот уровень абстракции.

Это, разумеется, влияет на глобальную архитектуру, на качество кода и самого продукта, на динамику разработки. Что, в свою очередь, приводит к многократному увеличению стоимости поддержки и развития.

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

Требования к продукту не приоритизированы с точки зрения ценности для пользователей

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

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

Последствия в этом случае весьма печальны, вплоть до полной невостребованности продукта аудиторией.

Отсутствует единое понимание стратегии разработки, последовательности и состава релизов

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

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

Кто-то мне скажет, что это не всегда возможно. Часто исследования идут бок о бок с разработкой. Те же гибкие методологии, в конце концов. Однако даже здесь нужно опираться на определённый фундамент, базис. Ну и кроме того, гибкие методологии имеют весьма ограниченный ореол применения.

Функциональные границы проекта очерчены слишком высокоуровнево или даже вовсе отсутствуют

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

Случалось ли у вас, что клиент/начальник/инвестор начинал каждую неделю приносить новые функции в проект? И обычный вначале лендинг в итоге превращался в космолёт-монстр, с админкой, функцией телепортации и собственным мобильным приложением?

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

User Story Mapping

Как я уже сказал, все эти проблемы (и не только) решают карты историй. Вот вам хорошее определение USM:

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

Крис Симс (в переводе Ольги Жолудовой и Рината Шайхутдинова)

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

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

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

Шаг 1. Выявляем активности

Сначала нужно собрать список основных активностей пользователей. В нашем примере игры их пять:

1. Регистрация и логин;
2. Работа над аватаром;
3. Работа над убежищем;
4. Участие в сражении;
5. Работа с баллами лояльности.

Это — ключевые, главные «категории» действий пользователя в игре. Они включают в себя всю остальную деятельность. Если использовать терминологию функциональной архитектуры, то здесь мы создаём глобальные функциональные разделы.

Шаг 2. Разворачиваем активности в задачи

Теперь мы раскладываем их (активности) на задачи. Например, активность «Регистрация и логин» превращается в три задачи:

1. Регистрация и логин через соцсети;
2. Регистрация и логин через e-mail;
3. Восстановление доступа.

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

Шаг 3. Задачи детализируем до конкретных историй

И, наконец, истории (жёлтые карточки) — они расположены в порядке приоритета — сверху критичные, внизу наименее важные. Приоритет обычно выстраивается, исходя из нескольких условий:

• ценность для пользователей;
• ценность для бизнеса;
• сложность реализации.

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

В случае нашего примера, задача «Регистрация и логин через e-mail» разложилась на 2 истории:

1. Регистрация с помощью e-mail;
2. Логин через e-mail;

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

В результате этапа мы понимаем, какая задача из каких историй состоит и к какой она относится активности. Мы понимаем, какие истории нужно сделать в первую очередь. Мы можем планировать спринты и релизы.

Шаг 4. Делаем из приоритетов схему релизов

Напомню, что истории — это всего лишь функции будущей системы. Понимая это, мы просто переносим те истории, которые не критичны или требуют на этом этапе слишком много ресурсов, в следующий релиз. Точно так же можно выделить MVP.

Например, нам проще сделать логин и регистрацию через соцсети — и регистрацию через e-mail мы отодвигаем на второй релиз. Пользователям не так важна покупка амуниции — и она тоже вылетает из MVP.

Дополнительно: цветовая индикация и структура

Принято разделять USM на две структурных части:

1. Верхняя часть, с активностями и задачами, называется «backbone» (хребет), но я предпочитаю слово «скелет».
2. Нижняя часть, истории, называется «тело».

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

Итог

С помощью User Story Mapping можно не только планировать новые продукты, но и улучшать уже существующие — например, приоритизировать бэклог.

USM позволяет на очень простом визуальном языке донести до всех участников команды не только функциональный состав продукта, но и порядок проектирования и реализации. Если вы хотите выполнить глубокое функциональное проектирование будущего продукта, то User Story Mapping — отличное начало для этого.

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

Запись User Story Mapping и функциональная архитектура первой появилась на Павел Шерер.

О чём статья

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

Типизация

В языках программирования есть понятия «сильной» и «слабой», «статической» и «динамической» типизаций. Если несколько упростить, то «типизация» диктует, как именно заполняются переменные в коде: можно ли одну и ту же переменную в разные периоды времени наполнить то текстом, то числом, то датой и тд.

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

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

Пример проекта

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

Информационная структура

В проекте есть несколько информационных сущностей, у каждой есть некоторые свойства. Все сущности связаны между собой: какие-то напрямую, какие-то опосредованно.

Если попробовать изобразить иерархию сущностей графически, то получится что-то вроде этого:

1. Инфоблок — самая низкоуровневая сущность, «молекула» информационной архитектуры, содержащая произвольную информацию (например, текст, цитату, изображение и тп). Из инфоблоков, собственно, и строится почти вся контентная часть продукта.
2. Год — статическая среднеуровневая сущность, которая объединяет инфоблоки в разрезе определённых лет. Они единые для всех композиторов, но конкретные годы у конкретных композиторов могут не совпадать.
3. Период — уникальная для каждого композитора среднеуровневая сущность, проходящая через все слои и объединяющая годы в определённый этап жизни композитора.
4. Слой — статическая информационная сущность, объединяющая разные периоды в некий тематический срез творчества композитора. Слоёв ограниченное количество, они обязательны и одинаковы для всех композиторов.
5. Композитор — высокоуровневая, главная сущность проекта.

Если рассматривать эту модель как плоскую, то получается, что внутри одного композитора находится произвольное количество инфоблоков, которые объединяются в годы, которые объединяются в периоды, которые объединяются в слои.

У каждой сущности есть свои свойства. Мы не будем детально перечислять и описывать все такие свойства, так как это выходит за рамки темы статьи. Но мы помним, что у каждой сущности в проекте всегда есть как минимум одно свойство: внутренний идентификатор (уникальный для каждого экземпляра этой сущности).

Навигационная модель

Схема навигации в примере максимально простая:

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

Внутри каждого года может находится произвольное количество инфоблоков — я не стал их отображать на схеме, чтобы не усложнять восприятие:

Под капотом

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

В нашем случае логика такова:

1. пользователь загружает страницу конкретного слоя на сайте;
2. браузер делает запрос к серверу, в котором указывает идентификатор этого слоя и идентификатор композитора;
3. сервер принимает эти параметры и делает соответствующий запрос в базу данных;
4. в результате у него появляется массив инфоблоков, которые ему теперь нужно отсортировать.

Как же происходит сортировка? Здесь тоже всё просто:

1. все инфоблоки разделяются на периоды;
2. периоды сортируются по порядку;
3. внутри периодов происходит объединение инфоблоков по годам;
4. годы также сортируются по порядку внутри периодов;
5. внутри каждого года по порядку сортируются сами инфоблоки.

В результате в браузер пользователя прилетает многомерный массив, который потом просто разбирается на странице.

Связи сущностей

Как я уже говорил, все сущности связаны. Но связь эта не всегда прямолинейна.

Чтобы связать информационные элементы, к одной сущности нужно прикрепить ссылку на другую. В нашем случае — к «дочерней» нужно прикрепить ссылку на «родительскую». Делать это правильнее (и проще) всего как раз с помощью идентификаторов.

• Композитор — главная и независимая сущность.
• Слои единые для всех композиторов и вообще — для всего проекта, они ни от чего не зависят.
• Период у нас уникален для каждого композитора, а значит, ссылается на него (имеет в своих свойствах идентификатор того композитора, которому принадлежит).
• Годы тоже едины для всего проекта, независимы от остальных сущностей.
• И только инфоблоки, как низшая сущность, зависят от всех остальных информационных элементов системы. У них в свойствах прописаны идентификаторы всех остальных сущностей.

Вот так выглядит схема зависимостей в нашем примере:

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

Проблема

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

Какая здесь появляется проблема? Мы должны спроектировать хранение связей в инфоблоке таким образом, чтобы добавление новых сущностей и связывание их с инфоблоками (как минимум с ними) не вызывало особенных проблем.

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

А что, если это связь нелинейная? Не «один ко одному», а «один ко многим»? Если конкретный инфоблок может содержать в себе связь с несколькими треками? Сможем мы в одном свойстве инфоблока сохранить несколько идентификаторов треков? А если можем, то почему вообще все связи не хранить в одном свойстве?

Решение

А решения нет. По крайней мере, однозначного.

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

Боюсь, я вас запутал. Давайте немножко упрощу.

У нас, казалось бы, два варианта:

1. Хранить каждую связь в конкретном свойстве инфоблока. Это в IA — признак «строгой» или, по другому, «сильной» типизации.
2. Хранить все связи в одном свойстве, массивом. Обычно это отличает «слабую» типизацию.

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

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

Излишне сильная типизация в разы увеличит стоимость поддержки и развития продукта. Разработчики будут ещё сильнее, чем обычно, материть проектировщика/архитектора. Время внедрения и отладки даже маленькой новой фичи станет сопоставимо с операцией Барбаросса в 1941-ом (и, вероятно, закончится так же, — провалом).

Настоящее решение

Грамотный и осознанный баланс — вот залог действительно качественного продукта. Это в полной мере касается и информационной архитектуры.

В нашем случае я выберу комбинированный подход:

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

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

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

Что такое IA

Очень ёмко об информационной архитектуре высказался Алексей Бородкин, основатель Гильдии Вольных Проектировщиков:

Это описание связи всего со всем!

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

Грамотная информационная архитектура упрощает поддержку и развитие продукта, улучшает UX:

• программисты не матерят своих предшественников (или себя) за неудобные для масштабирования роутинг и базы данных;
• контент-менеджеры и администраторы больше не льют кровавые слёзы при работе с внутренней частью продукта;
• пользователи легко и непринуждённо находят то, что им нужно и попадают именно туда, куда хотели;
• сеошники и поисковые системы влюбляются в ваш сайт и не хотят оттуда никуда уходить.

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

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

Стало не сильно понятней, да? Вот так, сходу, всё это может показаться немного запутанным или сложным. Поэтому давайте на каком-нибудь очень простом и понятном примере пройдёмся по базовым этапам создания IA. Пусть это будет абстрактный интернет-магазин одежды.

Этапы создания IA

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

Подготовка

Работа над информационной архитектурой начинается сильно позже старта проектирования. Сперва определяется концепция, суть продукта. Нам нужен базис, от которого мы уже начнём выстраивать IA.

Мы должны как минимум очертить высокоуровневые границы проекта, сформировать базовое понимание его функциональности. И только на этом этапе приступать к информационному проектированию.

В нашем случае базис относительно простой: есть интернет-магазин, есть товары, категории и пользователи. Углубляться не станем, а то всё-таки скатимся к лонгриду.

Декомпозиция

На этом шаге мы разбираем проект на отдельные информационные сущности. Каждая такая сущность обладает определёнными свойствами. Некоторые сущности могут быть вложенными (каталог и товар, например), некоторые — независимыми.

Итак, пусть в нашем примере будет только 5 сущностей:

1. Страница (статические сущности, содержащие какую-то информацию; например, страницы «О компании», «Доставка и оплата»).
2. Товар (да, обычный товар с описанием, фоточками, ценой и тп).
3. Каталог (внезапно, но каталог — это тоже сущность; у него есть свои свойства, вроде параметров поиска или уровня вложенности).
4. Корзина (которая обладает динамическими свойствами: вложенные товары и их количество, скидки, даже связь с конкретным пользователем).
5. Пользователь (тут всё понятно: как минимум, у пользователя есть регистрационные данные, адрес доставки и платёжные реквизиты).

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

Важная оговорка: в контент-проектах «Страница» — полноценная контент-сущность, но в UX-лексике «страница/экран» — это UI-представление, и она не равна сущности домена. Подробнее об этом будет в третьей статье цикла.

На этом и последующих этапах присутствуют некоторые пересечения с дизайном данных, это не страшно и не противоречит концепции информационной архитектуры. Если проектировщик/архитектор хороший, он совмещает оба направления, экономя ресурсы компании.

Классификация

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

A. Классификация пользовательских потребностей (задач) в разрезе информационной архитектуры опирается, как правило, на результаты пользовательских же исследований. Мы должны понимать, что действительно нужно нашим потенциальным покупателям. Исходя из этой информации, мы выясним, как именно следует связать наши сущности как они будут друг к другу относиться.

Для нашего примера классификация задач пользователя будет очень простой:

1. Найти товары (с помощью поиска, фильтрации и сортировки).
2. Сравнить товары (выбрать наиболее подходящий вариант).
3. Почитать про товары (ознакомиться с характеристиками).
4. Купить товары (положить в корзину, оплатить и ждать доставку).

Как видите, все действия напрямую связаны с товарами, и опосредованно — с остальными сущностями (например, поиск товара осуществляется в каталоге, а покупка — в корзине).

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

B. Классификация информационных сущностей — ещё один обязательный этап. Вся информация, которую видит пользователь, должна быть структурирована. Страницы должны объединяться в разделы, товары — в категории. И те, и другие должны быть доступны для поиска, а последние — ещё и для сортировки. У товаров могут быть общие свойства, вроде скрытых от глаз пользователя «тегов/меток» или доступных для просмотра «размеров».

На этапе классификации сущностей мы решаем, по какому принципу они будут объединяться и как пользователю будет удобнее с ними обращаться. Попутно не забываем и про администраторов, которым тоже нужно упростить работу.

Но для начала немного терминологии:

• таксономия — это управляемая схема классификации;
• термины — атомы таксономии.

Например, таксономия «Размер» может содержать несколько терминов: «XXL», «XL», «L», «M», «S», «XS».

В реальных продуктах часть терминов обрастает свойствами и становится «почти сущностями» — это нормально, фиксируем это явно.

В нашем примере добавляем три таксономии и одно общее свойство:

1. Категория (иерархическая таксономия сущности «товар»).
2. Метка (не-иерархическая таксономия сущности «товар»).
3. Размер (не-иерархическая таксономия сущности «товар»).
4. Цвет (общее свойство для всех экземпляров сущности «товар»).

Иерархические таксономии могут быть вложенными: например, категория может иметь подкатегорию (зимняя одежда -> пуховики). А вот у метки, например, родительского термина быть не может.

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

Выявление связей

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

Итак, мы разобрались, что у нас за сущности и таксономии. Теперь нужно понять, как они будут между собой связаны. Связи сущностей могут быть совершенно разными. Если копнуть глубоко, то неподготовленный читатель слегка ошалеет от всех этих «от одного ко многим», «от многих ко многим» и тп. Мы рассмотрим только простые варианты, когда связи являются либо «плоскими», либо «иерархическими».

Плоские связи в нашем случае — это связь терминов таксономии «метки» между собой. У них нет родителей, они «равны». Или связь товаров с одинаковыми «метками» — она тоже плоская. Кстати, связь самого товара с меткой — тоже плоская.

Иерархическая связь, например, у терминов таксономии «категории» — они почти всегда вложенные. Также иерархическая связь будет между сущностями «каталог» и «товар», так как первый всегда включает в себя несколько товаров. Если пойти дальше, то в игру вступают термины таксономии и у нас получается целая цепочка связей: каталог -> категория -> товар.

Иерархия сущностей — вообще отдельная песня. У хорошего архитектора почти все сущности в проекте делится на высоко-, средне- и низкоуровневые.

Фиксация свойств

Во время всей работы над информационной архитектурой мы всё время попутно выясняли, какие именно свойства будут у наших сущностей. Пришло время их зафиксировать.

Мы знаем, что у товаров есть как минимум 10 свойств:

1. Идентификатор (внутренний, в базе данных, он есть у каждой сущности и термина таксономии).
2. Артикул (внешний, для обмена данными, например, с системой складского учёта).
3. Название.
4. Описание.
5. Основное изображение (используется в карточке товара в каталоге).
6. Дополнительные изображения (используются в галерее изображений на странице товара).
7. Цвет (общее свойство для всех товаров: оно не «сквозное», как метки и категории, а может быть уникальным для каждого товара — например, «синий с белым узором»).
8. Размер (прикреплённый термин таксономии).
9. Категория (прикреплённый термин таксономии).
10. Метки (несколько терминов таксономии, на основе которых будут показываться «похожие» товары).

При этом мы знаем, что свойства 8 и 9 являются «ссылками» на конкретный термин таксономии, а десятое свойство — даже на несколько таких терминов.

Таким образом, мы составили информационную модельку нашего товара. Мы молодцы.

На самом деле, конечно, не всё так просто. И в третьей статье цикла мы немного углубимся в тему свойств сущностей. Например, добавим понятие «контролируемый словарь», «фасет» и другие.

Схематизация

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

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

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

Важно: информационная архитектура описывает «что и как связано» (сущности, свойства, таксономии), а навигация — «как по этому двигаться» (меню, крошки, фасеты, поиск).

Об артефактах информационного проектирования можно написать не одну статью. И, возможно, я это ещё сделаю.

Напоследок

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

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

Вместо вступления

У этого поста (как и у всего цикла) нет задачи научить читателей функциональному проектированию. Равно как и дать им в руки универсальные шаблоны проектной документации. Это невозможно сделать и десятком таких статей, но вовсе не из-за сложности предметной области. Просто все проекты разные, а продуктовые подходы могут отличаться даже в рамках одной кампании. Шаблонизировать создание функциональной архитектуры — занятие неблагодарное и неблагородное.

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

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

Этапы

Лично я предпочитаю разбивать работу над функциональной архитектурой на два ключевых этапа: высокоуровневый и детальный. Первый закладывает «скелет» продукта, тогда как во время второго этот «скелет» обрастает «мясом». Детальное функциональное проектирование, чаще всего, является итерационной частью проектного процесса.

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

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

Теория

Высокоуровневое функциональное проектирование — это первое, с чего стоит начать работу над FA. Кажется, что набросать общую структуру проекта проще, чем детально расписывать каждую функцию. Однако это не так. И сейчас я расскажу, почему.

Уровень абстракции

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

То же самое справедливо и для многих продуктовых аналитиков/дизайнеров/проектировщиков. Они с самого начала начинают копать сильно глубоко, детально прорабатывают каждую ветку сценария. Но, в отличии от ситуации с разработчиками, на пользу проекту это не идёт. Из-за высокой степени неопределённости на старте, функциональная архитектура рискует оказаться проработанной неравномерно. Решения, принимаемые без оглядки на общую структуру, часто скрывают в себе ошибки. В лучшем случае вам придётся возвращаться к уже проработанным разделам, и полностью их перепроектировать. В худшем — проект с ошибками будет отправлен в разработку.

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

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

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

При высокоуровневом проектировании нам в обоих случаях достаточно лишь понимать, что такая возможность просто имеется: да, мы можем отслеживать каналы привлечения и конверсию; да, плеер на сайте будет.

Пластичная функциональная архитектура

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

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

Начало работ

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

Однако ранний старт позволяет не только серьёзно сократить сроки проектирования, но и более глубоко «прочувствовать» саму архитектуру.

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

Практика

Окей, по теории прошлись. Теперь давайте обратимся к более практичным вещам. К тому, как формируется функциональная архитектура.

Функциональная иерархия

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

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

Да, в навигационной модели тоже могут быть разделы «регистрация», «настройки», «профиль», «новости», но и только.

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

В примере выше функциональный раздел «Логин и регистрация» включает в себя дочерние разделы:

1. Регистрация.
2. Аутентификация (логин).
3. Восстановление доступа.
4. Авторизация (проверка прав).

В свою очередь, внутри подраздела «Аутентификация» на клиенте могут находиться уже конкретные функции:

1. Отображение окна логина.
2. Заполнение формы.
3. Валидация формы.
4. Отправка формы на сервер.
5. Обработка ответа сервера.
6. Показ сообщений (например, об ошибках).

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

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

Действия пользовательские и системные

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

Проще всего выявлять конкретный перечень функций продукта через его функциональные сценарии. Они часто строятся на основе детального CJM, user flow или аналогов, но включают в себя отнюдь не только пользовательские маршруты. Смотрите.

Компоненты

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

Типы функций

Кроме того, все функции можно условно поделить на несколько типов:

• пользовательские (в схеме логина ниже представлены синими блоками);
• системные (белые блоки);
• проверка условий (ромбы);
• негативные (с красной обводкой);
• позитивные (с зелёной обводкой).

Функциональный сценарий

Подобные схемы позволяют наглядно представлять функциональные сценарии, сильно упрощая работу дизайнерам и программистам:

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

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

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

Взаимосвязи и общие функции

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

Давайте вернёмся к нашему примеру с контентным приложением. У нас там есть глобальный функциональный раздел «Новости», который включает в себя два схожих подраздела:

• «Главная» (список всех новостей).
• «Категория» (список новостей, относящихся к определённой тематике).

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

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

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

Кроме того, некоторые функции могут блокировать выполнение других, или быть их «предвестниками», но об этом мы поговорим позже.

В следующей серии

Остались ещё две статьи цикла. Там мы более глубоко погрузимся в практическую часть, разберём несколько потенциальных проблем, подробно пройдёмся по общим и «зависимым» функциям, рассмотрим примеры описания конкретных функций.

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