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

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

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

Исходная точка: диагностика

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

Что стоит фиксировать в этой самой исходной точке:

• Продукт или продукты. В идеале, с минимальным функциональным описанием.
• Продуктовые и другие метрики, если они есть. Потом пригодятся.
• Выручка и динамика по ней. Даже если она отрицательная. Даже если за неё пока стыдно.
• Базовая юнит‑экономика и всё, от чего она выстраивалась: от исследований до предположений. Сюда же финмодель.
• Каналы продаж и их базовые особенности: региональность, отличия аудиторий, юридические ограничения и прочее.
• Состав команды, текущие проектные процессы, их состояние с соблюдением.
• Технологическая платформа. Если возможно, с указанием программных и интеграционных решений.
• Юридическая форма, состав инвестиций и прочие лигал-темы.
• Обязательства перед клиентами и партнёрами.
• Ключевые риски: от операционных до финансовых и технологических.

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

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

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

Семь слоёв упаковки

Ниже я приведу довольно большой перечень разнообразных продуктов, систем и артефактов. Часть из них у вас наверняка окажется на этапе самодиагностики. Если же каких-то нет, то не факт, что они вам нужны. Отталкивайтесь от задач бизнеса, особенностей рынка, аудитории и других факторов. Используйте здравый смысл.

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

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

Публичный слой: бренд и маркетинг

Бренд‑платформа. Это не презентация в PowerPoint, а документ, который отвечает на три простых вопроса: кто мы, зачем мы и чем отличаемся от соседей по рынку. Там же — иерархия сообщений: главный зонтик («мы решаем проблему X»), 3–4 ценностных опоры и конкретные доказательства. Добавьте тон голоса (говорим ли мы как «умный друг» или как «суровый консультант») и визуальные правила.

Сайт. Это ваша витрина, и у неё должна быть структура без эзотерики: главная страница, решения/продукты, отраслевые страницы, кейсы, цены и тарифы, блог или раздел с исследованиями, страница «О нас» с командой и сертификатами, контакты, кнопка «показать демо». Всё лишнее — в корзину.

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

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

Маркетинг и дистрибуция. Рисуем карту каналов (SEO, статьи, ивенты, реферальные программы, платная реклама, партнёрские сети), считаем CAC по каждому каналу и планируем контент‑календарь на три месяца вперёд. Без этих чисел разговор про маркетинг превращается в гадание.

Коммерческий слой: инструменты продаж

ICP и персоны. Это портреты ваших клиентов: роли, боли, критерии, по которым они квалифицируются. Красные флаги, по которым вы сразу понимаете, что это не ваш клиент (например, негативные персоны).

Playbook продаж. Настольная книга менеджера: скрипт discovery (какие вопросы задать, чтобы раскрыть боль и ценность), сценарий демо (3–5 сцен, каждая закрывает конкретный риск или боль клиента), готовые ответы на 10 самых частых возражений и чек‑лист того, что должно быть закрыто в договоре.

Материалы. One‑pager для быстрых рассылок, battlecards для борьбы с возражениями/конкурентами, калькулятор ROI/TCO, тарифные карты, SLA/OLA, шаблоны КП и договора. Это рабочий пакет, без которого продавец каждый раз изобретает велосипед.

Продукт и операции

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

Outcome‑roadmap. Это дорожная карта, где вместо «сделаем фичу» записано «закроем проблему клиента и увидим рост конкретной метрики». И сразу связка с North Star Metric (но здесь нужно быть осторожным, можно попасть в «ловушку одной метрики», выставляйте сторожевые).

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

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

Карта фичей и сравнений. Зачем каждая функция существует, её текущий статус и какой эффект она даёт. И честная таблица «мы vs конкуренты» без маркетинговой воды.

Финансы и риски

Финмодель. Полный комплект: P&L, Cash Flow, Balance. Драйверы выручки по сегментам, маржинальность и операционные расходы.

Unit‑экономика. В разрезе сегментов и динамике по кварталам. Ключевые ориентиры: LTV/CAC и срок окупаемости.

CAPEX/OPEX, runway и burn. Сценарии развития (базовый, оптимистичный, консервативный) и чёткие триггеры, когда нужно пересматривать стратегию.

Риски. Стратегические, продуктовые, финансовые, юридические и операционные. Делайте матрицу Вероятность х Влияние и прописывайте план BCP/DR с целевыми RTO/RPO.

Комплаенс. Всё, что связано с законами и безопасностью: GDPR/152‑ФЗ, политики ИБ и реагирования на инциденты, минимальный набор контролей (IAM, журналирование, бэкапы, privacy notice и тд), а для зрелых — сертификация ISO 27001 или SOC.

Команда

Оргструктура. Как сейчас устроена команда и к чему хотите прийти. Кто за что отвечает.

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

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

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

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

Юридический блок

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

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

Data Room

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

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

• 0_Executive
• 1_Corporate
• 2_Financials
• 3_Product
• 4_Sales_Marketing
• 5_Legal
• 6_Team
• 7_Customers
• 8_Intellectual_Property
• 9_Security_Compliance

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

Как это сделать за 6–8 недель

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

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

Фреймворки от вкусовщины

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

• Value Proposition Canvas. Фиксирует соответствие «боли/выгоды» клиента и вашего предложения. Помогает сверять фичи с ценностью и доказательствами.
• Jobs To Be Done (JTBD). Смотрим на «работы» клиента, контекст и триггеры выбора. Используем job stories в демо и продуктовых решениях.
• Opportunity Solution Tree (OST). Дерево от цели к возможностям и экспериментам; дисциплинирует приоритизацию и формулировку исследовательских вопросов.
• RICE‑приоритизация. Быстрое ранжирование бэклога: Reach x Impact x Confidence / Effort.
• Kano‑модель. Помогает различать базовые ожидания (must‑have), характеристики, напрямую влияющие на удовлетворённость (performance), и «вау‑факторы» (delighters).
• AARRR (Pirate Metrics). Скелет воронок роста: Acquisition → Activation → Retention → Revenue → Referral.
• OKR. Связка целей и измеримых результатов, цикл квартальной фокусировки.
• Wardley Maps. Карта ценностной цепочки и стадий эволюции компонентов — помогает принимать архитектурные и продуктовые решения.
• Business Model Canvas. Быстрый способ описать бизнес‑логику: сегменты, ценность, каналы, отношения, доходы/издержки, ресурсы и партнёры.

Итог

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

Запись Упаковка бизнеса: от диагностики до метрик и артефактов первой появилась на Павел Шерер.

Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.

Признаки проблемы

Если вы нашли у себя хотя бы 2-3 из указанных ниже симптомов, то эта статья для вас:

1. Унификация ради унификации. Понятно, почему нельзя, непонятно — зачем.
2. Любая, даже самая мелкая, фича сначала упирается в дизайн-систему. Маркетинговые лендинги-однодневки не создаются на скорую руку по гайдам, а вынуждены проходить полноценную верификацию.
3. Метрики и эксперименты застревают, потому что гипотезы ждут внедрения в ДС дольше, чем живёт бизнес-задача.
4. Часто звучит «в системе так не предусмотрено», и на этом обсуждение заканчивается.
5. Команда обходит систему втихаря, если ДС не помогает, а мешает. В итоге создаются костыли и подпольные клоны библиотек.
6. Медиана времени от «хочу» до «запустили» растёт месяц за месяцем. ДС начинают воспринимать не как инструмент, а как бюрократию.
7. Уходят лучшие практики: упор делается на контроль и одинаковость, а про доступность или производительность забывают.
8. Дизайнеры и разработчики начинают дублировать работу вне ДС, тратя двойные усилия.
9. Дизайн ради дизайна: решения принимаются для красоты системы, а не для пользы продукта.
10. Люди перестают воспринимать ДС как источник ценности: обновления видятся как «еще одна миграция».

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

Корни проблемы

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

Подмена цели

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

Решение: пересобрать цель ДС и зафиксировать её в понятной форме. Главный показатель — скорость и надёжность работы. Одинаковость интерфейсов должна быть лишь средством, а не самоцелью.

Ошибка уровня абстракции

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

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

Полицейская модель управления

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

Решение: перевести Design Ops в сервисную модель. Ввести сроки ответов, понятную поддержку и чёткую роль «помощников», а не «надзирателей».

Недостаток обратной связи

ДС-команда редко общается с продуктовой командой и разработчиками. В результате её решения оторваны от реальных задач и проблем пользователей.

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

Замороженные токены

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

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

Отсутствует экспериментальный контур

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

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

Недостаток прозрачности

Участники не понимают, кто и на основе каких критериев принимает решения о дизайн-системе, отклонении или принятии инициатив. Это рождает недоверие и ощущение произвола.

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

Гейткипинг без SLA

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

Решение: ввести фиксированные сроки для рассмотрения (например, 3 дня), назначать ответственных для каждой инициативы.

Отсутствие приоритизации

В дизайн-систему пытаются внести всё подряд, не разделяя на must-have и nice-to-have. Это перегружает команду, размывает ценность и создаёт ощущение работы без реального результата.

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

Игнорирование локальных контекстов

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

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

Отсутствие SLA и метрик самой ДС

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

Решение: ввести набор простых показателей. Замерять их регулярно и менять процессы по результатам. Ниже — примеры таких показателей.

Метрики токсичности дизайн-системы

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

median time to ui change Среднее время (желательно медиана) до изменения UI. Работает, если есть какие-то исторические данные. Просто сравните показатель до внедрения ДС и после, чтобы понять, реально ли система ускоряет работу.

% blocked PR Процент запросов (например, product request), заблокированных аргументом «не соответствует ДС». Доля задач, которые останавливаются не по сути, а из-за формальных правил.

number of forks & overrides Количество (да и вообще наличие) форков от репозитория с ДС и локальных override’ов. Сколько команд вынуждены городить обходные решения вместо использования ядра.

adoption rate Какие продукты реально подключены к ядру ДС и используют его обновления, а какие живут на клон-сборках и по сути поддерживают собственные версии.

number of experiments Количество экспериментов по сравнению с прошлым периодом. Если гипотезы стали запускать реже — система мешает развитию. Тут могут быть и другие причины, поэтому на этот показатель нужно опираться осторожно.

time to review Среднее время на ревью и согласование изменений в ДС. Если этот процесс занимает недели, значит система тормозит.

contribution success rate Доля предложений в дизайн-систему, которые дошли до внедрения. Если большинство инициатив отбрасывается или зависает, то ДС становится барьером.

update lag Задержка между выпуском новой версии ядра ДС и фактическим обновлением продуктов. Большие лаги показывают, что миграции слишком болезненны.

a11y & performance coverage Процент компонентов, проверенных на доступность и производительность. Если метрика не растёт, ДС концентрируется на унификации, а не на качестве.

user satisfaction Удовлетворённость продуктовых команд работой с ДС (например, через регулярные опросы).

Если исторических данных нет, можно использовать альтернативы: опросы, журналы использования (например, в Figma Library Analytics можно анализировать использование компонентов за последний год).

Не доверяйте только одной метрике, делайте связки, кросс-чек. Если медиана времени растёт, но adoption высокий — проблема не в ДС, а в процессах (например, гейткипинг).

Используйте триангуляцию. Например, 3+ метрики + качество: процент заблокированных + доля форков + опросы. Если заблокированных много, но форков мало — команды просто игнорируют ДС. Если форков много — ДС недостаточно гибкая.

Один показатель (например, рост экспериментов) может быть из-за сезонного пика, а не из-за качества ДС. Комбинируйте с бизнес-метриками (ROI, time-to-market) для полной картины.

Итог

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

Запись Дизайн-система как тюрьма первой появилась на Павел Шерер.

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

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

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

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

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

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

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

• Глаголы: название функции, как правило, должно отражать действие. Например, из названия 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 первой появилась на Павел Шерер.

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

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

Состав концепции

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

Краткое описание проекта

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

Эта часть нужна для того, чтобы:

• отбросить всё лишнее, сформулировать ядро проекта;
• обеспечить плавное погружение читателей в вашу документацию;

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

Цели и задачи бизнеса

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

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

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

Потребности пользователей

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

Описание основной механики

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

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

Состав продукта и его технические особенности

Самый технологический пункт. Здесь мы решаем, из чего будет состоять наш продукт: мобильное ли это будет приложение, или хватит качественного адаптивного сайта; чат-бот нужен нашим клиентам или полноценный голосовой помощник.

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

Иногда при описании компонентов не хватает даже моих познаний бывшего fullstack-разработчика. Тогда я прибегаю к помощи более опытных технарей, в этом нет ничего зазорного.

Ограничения

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

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

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

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

Структура концепции

Обычно здесь у меня четыре ключевых слоя: проект, бизнес, пользователи и техническая экспертиза. Я предпочитаю вести документацию в Confluence, завожу там раздел «Концепция», а в нём 4 подраздела:

Проект

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

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

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

Бизнес

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

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

Пользователи

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

Техническая экспертиза

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

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

В заключение

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

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

Откуда это всё?

Идея концепции в том виде, которую я здесь изложил, родилась в стенах Цифровой Артели Eleven. Если интересно подробнее узнать о нашем подходе – можете полистать книгу моего партнёра по артели, Вадима Митякина, там много интересного.

Запись Состав и структура концепции цифрового продукта первой появилась на Павел Шерер.

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

Почему концепция

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

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

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

Единое информационное поле

Говоря об информационном поле, я подразумеваю комплексное, однозначное и единое представление о будущем продукте у всех участников проектной команды: от разработчиков до клиента, CEO или владельца продукта. Почему важно, чтобы каждая деталь концепции, основа и базовые границы проекта виделись всем участникам проекта одинаково? Если этого не сделать до начала непосредственного проектирования (а уж тем более, до начала разработки), то процесс пойдет намного медленнее и болезненнее. Клиент будет вносить спонтанные, как вам кажется, правки; разработка – использовать не те инструменты, которые следовало бы; а маркетинг готовить совсем другие метрики.

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

Вот только маркетинг думает, что основная задача сервиса с точки зрения монетизации – свести клиентов и ситтеров, тогда как CEO планирует основной доход получать не с процентов за сделку, а с партнерских программ (например, продавать клиентам корм со скидкой).Разработчики, жадные до новых технологий, хотят сделать новомодное веб-приложение на последнем React’е и уже даже начали набрасывать технический прототип – но они понятия не имеют о том, что одной из фишек сервиса будет являться опция видеонаблюдения за своими питомцами. А у асинхронных библиотек есть определённые проблемы с потоковым видео, и это нужно учитывать.

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

Грамотная концепция формирует у всей команды единую картинку продукта. А это довольно сильно влияет на стабильность дальнейшей работы на ним.

Определение и фиксация границ проекта

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

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

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

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

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

Зафиксируют это в концепции, и тогда в конце проектирования не придётся второпях запускать на орбиту спутник, изыскивая на это и так дефицитные ресурсы.

Выявление рисков, недостатков и перспектив продукта

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

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

Допустим, у нас в стартапе есть гугл-карта с доступными ситтерами. Если пользователей станет много и они будут достаточно активны, то бесплатный лимит запросов к картам очень скоро закончатся. Тогда карта просто перестанет работать. И сделает это, возможно, весьма внезапно. А значит, нам нужно завести в Google Cloud Platform платёжный аккаунт и подцепить к нему банковскую карту, на которой всегда будут какие-то деньги. Да, это можно решить и не на этапе концепции, но предусмотреть подобные вещи в начале не сложно – а они могут сказаться на финансовой модели.

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

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

Первичная оценка проекта и проектирования

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

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

Помните наш стартап? Пользователи в нём делятся на 2 типа:

• те, кто отдаёт животных на передержку;
• те, кто принимает питомцев в своих квартирах на обозначенный срок.

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

Что дальше?

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

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

Запись Почему вашему проекту нужна концепция первой появилась на Павел Шерер.

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

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

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

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

Этапы

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

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

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

Теория

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

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

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

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

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

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

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

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

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

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

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

Начало работ

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

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

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

Практика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компоненты

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

Типы функций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но не всё так просто.

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

UPD: спустя год (09.2020)

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

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

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

Почему регистрация

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

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

Проблема

Однако почему же тогда регистрация на большинстве сервисов отнюдь не идеальна?

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

1. Что произойдёт, если Facebook, с помощью которого регистрируется пользователь, не вернул e-mail?
2. Что делать, если соцсеть вообще отвалилась и не работает (например, кто-то из админов поменял конфиги)?
3. А если соцсеть при регистрации вернула e-mail, который уже есть в базе?
4. Как быть, если пользователь восстанавливает доступ, но у него нет пароля, так как он создавал аккаунт через ВКонтакте?
5. Нужно ли при попытке регистрации или восстановления доступа напоминать пользователю, что он уже регистрировался через Twitter?
6. А можно как-то заранее сообщить пользователю (ещё до нажатия кнопки входа), через какую соцсеть он входил в прошлый раз?

И ещё тьма вопросов. Все они относятся к бизнес-логике, интерфейсам и юиксу. И очень часто некоторые из них попросту обходятся дизайнерами. Разработчики тоже не боги. Они сперва делают то, что описано; потом — то что принесли тестировщики; потом — то, до чего додумались сами; а затем — чинят то, что поломали предыдущие два шага. И в части этих работ они уже не обращаются к дизайнерам, а делают «по аналогии». Понимаете, что происходит в такие моменты? Да, UX валится к чертям. Потому что красное сообщение о том, что «пароль не подходит» следовало бы заменить на синенькое «не тупи, ты регался через фэйсбук, у тебя нет пароля».

Не решение

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

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

А общался ли наш дизайнер с разработкой, чтобы пощупать серверную логику и выяснить, можно ли вообще сделать так, как он описал — или это космически дорого и долго?

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

Решение

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

В ней можно описать:

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

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

Отдельно укажем точки входа и выхода из сценариев. А мелким текстом над некоторыми блоками даже укажем названия и состояния относящихся к ним экранов!

Красота же, да?

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

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

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

Сценарии

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

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

• обычная регистрация через e-mail;
• регистрация через соцсети;
• вход в аккаунт;
• восстановление доступа.

Я не стану детально описывать особенности и решения каждого сценария — они прекрасно понятны из самих диаграмм. Если у вас возникли вопросы — пишите в комментариях.

Обычная регистрация

Регистрация через соцсети

Вход в аккаунт

Восстановление доступа

Это не идеальная регистрация

И эту схему можно улучшать бесконечно.

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

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

Исходники

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

В архиве:

1. исходник диаграммы (делал в draw.io, так как работал в Confluence);
2. все диаграммы в SVG и JPG с подсветкой конкретных сценариев из этого поста.

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

Запись Регистрация и логин на стероидах первой появилась на Павел Шерер.