Проектирование архитектуры и управление изменениями

~ 50 минут
Чтобы выявить точки изменений в разных частях продукта и связанных системах, привлечь команды, которые смогут оценить и реализовать изменения, необходимо определить архитектуру. После формирования взгляда на бизнес-архитектуру легче понять изменения в IT-ландшафте компании на уровне более локальных задач и затем принимать архитектурные решения.
Принятые решения полезно оформить в некоторый документ (например, в формате Architecture design record или Architecture vision), который служит для обсуждения процессов разработки с другими участниками. На него ссылаются в спорных ситуациях, он помогает оставаться в фокусе изначальной идеи при дальнейшем развитии продукта, и по нему легко отслеживать задачи.
Когда задачи сформированы, их можно спланировать в виде последовательности работ, или роадмапа, а затем реализовать. Так как в процессе разработки часто происходят изменения, появляются новые требования или новые вводные, полезно использовать практики управления изменениями.
В этом уроке мы поговорим о проектировании архитектуры, практиках дизайн-мышления и о том, как презентовать архитектурное решение стейкхолдерам. Также рассмотрим планирование задач на основе архитектуры и некоторые практики управления изменениями.

Проектирование архитектуры

Изменения в продукте всегда можно запланировать быстро: например, сразу обратиться к команде разработки с инициативой, оценить её и реализовать функционал. Но при этом есть вероятность, что вы упустите важные детали по окружающим бизнес-процессам и интеграциям с другими системами. В итоге задачи не получится реализовать вообще или в установленные сроки.
Чем сложнее продукт и его архитектура, чем больше компания, тем больше неявных связей. Если их не учесть, это может привести к нежелательному результату и компания потратит ресурсы напрасно.
Чтобы учесть максимальное число возможных рисков, функциональные и нефункциональные требования, верно спланировать работы одной или нескольких команд, важно определить архитектуру изменений, то есть сформировать архитектуру решения.
✏️ Под архитектурой решения (solution architecture) понимается результат планирования структуры и взаимодействия компонентов программного обеспечения для достижения целей и соответствия требованиям. Это решение можно оформить в концептуальный документ с описанием, схемами, допущениями и ограничениями, чтобы далее определить конкретный план изменений. Такой концепт часто называют архитектурным видением (architecture vision).
Создание архитектурного видения позволяет из набора различных требований сформировать чёткое понимание реализации. Формат такого артефакта может быть любым, который удобен для конкретного проекта. Это может быть одна простая схема взаимодействия или полное описание архитектуры данных, архитектуры интеграции и инфраструктуры со всеми нужными требованиями.
Мы рассмотрим для этого формат, упоминание которого вы уже встречали в курсе, — Architecture Design Record (ADR).

Architecture Design Record и Architecture Decision Log

✏️ Architecture decision record (ADR) — это явное описание принятых и непринятых в ходе разработки ПО решений, которые затрагивают архитектуру, выбранные технологии и отвечают определённым функциональным или нефункциональным требованиям. Вместе с решением фиксируется его контекст, последствия и альтернативы, из которых делался выбор. Каждая запись ADR фиксируется в журнале Architecture decision log (ADL). Ведение ADL позволяет отслеживать значимые архитектурные изменения внутри проекта или продукта, их историю и накапливать знания для всех участников. Это особенно полезно на долгой дистанции, когда продукт развивается годами: начальная команда может расформироваться, а знания и культура ведения ADL останутся и помогут в развитии продукта.
ADR и их реестр (ADL) полезно вести в каком-то формате, который позволяет легко отслеживать изменения, работать с ними коллективно и ссылаться при необходимости. Для этого может быть использована любая корпоративная wiki-система.
Также ADR можно вести в системе контроля версий вроде git. Можно использовать собственный репозиторий, а для работы со схемами в формате текста — инструменты вроде C4-PlantUML. PlantUML позволяет вести UML документацию как код. А C4 расширяет этот инструмент нотацией C4.
Кроме того, есть специальный язык разметки ADR — MADR (Markdown Architectural Decision Records), он также позволяет вести ADR в формате кода. Подробнее об этих инструментах вы можете прочитать в дополнительных материалах к уроку.

Формат и шаблоны ADR

ADR может содержать достаточно простые решения (например, использовать только REST-формат взаимодействия). Или более комплексные — например, описание архитектуры работы с платёжной системой в процессе оформления заказа. Кроме текста в ADR могут быть включены схемы, таблицы и другое. ADR могут ссылаться друг на друга, если это необходимо.
Что именно должно быть в ADR, каждая команда может определить самостоятельно, но есть минимально необходимые элементы:
  • Контекст — то, при каких условиях принимается решение;
  • Решение — в чём суть принятого решения;
  • Последствия — к чему приведёт решение.
Так как ADR стоит вести в составе реестра, важно, чтобы в каждом был номер, дата и автор. Одним из популярных шаблонов является Y-statement. Он состоит из следующих элементов:
  1. Контекст (context) — на что решение влияет и в каких условиях принято. Это могут требования или условия работы конкретного компонента.
  2. Причина (facing) — проблема, которую нужно решить, или определённые нефункциональные требования.
  3. Принято (we decided for) — принятое решение, аргументация и причины.
  4. Отклонено (neglected) — альтернативы, которые рассмотрели, но не стали выбирать.
  5. Чтобы достичь (to achieve) — преимущества решения и ожидаемый результат.
  6. Нужно учесть (accepting that) — недостатки или то, как решение повлияет на другие элементы.
Пример
  1. Контекст. Для взаимодействия сервисов в проекте необходимо выбрать протокол, формат передачи данных и правила описания контрактов API.
  2. Причина. Если не договориться о протоколе, то процесс разработки может замедлиться и могут возникнуть проблемы с тестированием. Всё это потому, что будут постоянно возникать споры о том, как должно быть сделано API сервиса.
  3. Принято. Используем формат HTTP/REST второго уровня зрелости со спецификацией по Open API и методы GET, POST, PUT и DELETE.
  4. Альтернативы. Рассмотрели вариант использования gRPC: модель имеет свои преимущества, но так как у команды нет практики применения, а сроки проекта сжатые, то её использовать не будем.
  5. Для достижения того, чтобы у каждого разработчика было понимание, как должно быть разработано API. При тестировании и интеграции можно будет использовать готовый интерфейс Open API.
  6. Нужно учесть. Нужно подготовить примеры описания API, которые мы считаем эталонным, отдельно принять ADR по работе с кодами ответов.
Такой формат удобен, если нужно принимать решения в процессе разработки, но его можно использовать и для более сложных решений.

Сергей

А если нужно что-то специфичное?

При необходимости можно сделать свой шаблон. Например, следующий шаблон наиболее нагляден для описания архитектуры сложного решения со схемами и различными требованиями.
Название задачи: Номер и название задачи.
Автор: Кто принял решение.
Дата: Она будет полезна для последующих обсуждений.
Функциональные требования: По сути, это контекст принятия решения, соответствует разделу «контекст» в Y-statement. Здесь можно привести описание FURPS+ требований или таблицы use cases.
Нефункциональные требования: Описание нефункциональных требований и архитектурно значимых требований — соответствует разделу «причина» в Y-statement.
Решение: Принятое решение, его описание, аргументация и последствия, а также схемы взаимодействия компонентов (например, в формате C4). Cоответствует разделам «принято», «чтобы достичь» в Y-statement.
Альтернативы: Описание наиболее важных альтернативных решений, которые не были приняты, — соответствует разделу «отклонено» в Y-statement.
Недостатки, ограничения, риски: Описание недостатков, ограничений и рисков выбранного решения — соответствует разделу «нужно учесть» в Y-statement.

Создание ADR на примере компании N

Вернувшись к кейсу компании N, представьте, что команда с менеджером продукта и руководителем проекта выявили, что наиболее приоритетными для реализации в MVP являются следующие требования из прошлого урока:
Вот так будет выглядеть структура IT-ландшафта компании N с дополнительной информацией о технологиях:
Развёрнутые технологии, сервисы и приложения
  • Система производства контента. В ней работают продюсеры, которые отвечают за производство контента. Разрабатывают систему несколько программистов из IT-отдела. Клиент-серверная система, клиентское приложение под Windows разработано на QT (C++) и сервер на Java Spring. В качестве СУБД используется Oracle. В ней ведётся библиотека контента компании.
  • CRM-система на платформе Bitrix. Системой пользуются менеджеры по продажам, работающие с каналами. Поддержка осуществляется внутри IT-отдела.
  • Сайт. Собственная разработка на PHP. Поддерживается разработчиками из IT-отдела.
  • 1С: Зарплата и управление персоналом. В системе работают HR-отдел и бухгалтерия, поддерживается разработчиком внутри IT-отдела.
  • 1С: Бухгалтерия. Используют бухгалтеры, поддерживается разработчиком внутри IT-отдела.
Далее начнём описывать ADR по шаблону:
Название задачи: MP-ADR1 MVP Медиаплатформы N
Автор: —
Дата: 12.10.2024

Шаг 1. Определить функциональные требования

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

Шаг 2. Определить нефункциональные требования

Выделим нефункциональные требования и архитектурно значимые требования в отдельную таблицу. Рассмотрим только требования категорий R, P и +, так как эти требования могут влиять на архитектуру решения.
Нефункциональные требования:

Шаг 3. Принять решение

Далее построим схему взаимодействия компонентов решения, исходя из определённых Use Cases и с учётом нефункциональных требований. Используем нотацию C4 от общего к частному: сначала описываем схему первого уровня и при необходимости детализируем до второго уровня.
Чтобы построить схему первого уровня:
  1. Переносим всех действующих лиц и системы из Use Cases.
  2. Далее отражаем взаимодействия так, чтобы каждый Use Case достигал своей цели, на стрелках можно подписать названия Use Cases или конкретные взаимодействия, которые выявляются, если пройти каждый шаг из Use Case. Например, для UC5 — оплата подписки — нам нужно отразить взаимодействия пользователя с платёжной системой, платформы на создание платежа и обратный вызов от платёжной системы, при дальнейшей детализации мы определим, с какими компонентами систем будет происходить взаимодействие.
  3. Возможно, нужно будет сразу принять какие-то архитектурные допущения, например, в UC1 — регистрация ― и UC2 — авторизация ― платформе нужно отправить СМС с кодом, это можно сделать только через телеком-оператора, поэтому мы вводим систему телеком-оператора. В дальнейшем интеграция с телеком-оператором может потребовать создания отдельного ADR, так как надо определить правила интеграции с ним и сравнить несколько вариантов.
Диаграмма C4 первого уровня уже позволяет определить, что функциональные требования удовлетворяются. Так можно понять, какие системы будут задействованы в решении, и можно даже определить, какие задачи потребуется реализовать и где именно это нужно сделать, чтобы всё решение заработало. Но чтобы этот процесс был более точным и были учтены нефункциональные требования, нужно детализировать схему до диаграммы C4 второго уровня.
Чтобы построить схему второго уровня:
  1. Детализируем контейнеры медиаплатформы, учитывая нефункциональные требования
    • Требование +R1. В качестве технологий для основных сервисов выбираем Java, для интерфейса React.js/Node.js.
    • Требование +R2. Для микросервиса отправки СМС используем стек PHP/Laravel, так как это дополнительная функция.
    • Требование +R3. Придерживаемся принципов микросервисной архитектуры, но, учитывая, что рассматривается MVP, реализуем основой функционал в одном сервисе API медиаплатформы. В дальнейшем можно будет разбить функционал отдельно на сервис авторизации, сервис главной страницы и сервис платежей. Это решение позволит отложить проблему управления общей базой пользователей на следующие этапы.
    • Требование +R5. Основную логику реализуем в API медиаплатформы, чтобы в дальнейшем с ней могло работать мобильное приложение, а не только браузер.
    • В качестве баз данных используем PostgreSQL как допущение. Так как дополнительных требований на этот счёт нет, можно выбрать СУБД в рамках отдельного ADR под каждую функцию или сформировать дополнительные нефункциональные требования.
  2. Детализируем контейнеры системы производства контента, учитывая нефункциональные требования.
    • Требование +R4. Так как система производства контента не может обеспечить требуемое время отклика, а за хранение контента в компании отвечает она — значит, нужно реализовать какой-то способ снижения нагрузки. В стратегии по созданию платформы была предусмотрена необходимость модернизации системы для общей работы с контентом со стороны платформы и системы производства контента. Возможно, задача по модернизации системы потребует отдельного архитектурного решения с определением требований. Мы сделаем допущение, что проблема с нагрузкой возникает в части базы данных. Можно вынести функционал работы с контентом в отдельную базу и микросервис, с которым будет работать система производства контента и медиаплатформа. Пока можно также использовать БД Oracle, а при развитии функционала перейти на более подходящее хранилище (например, по типу S3).
Таким образом, мы получили итоговое архитектурное решение, которое позволяет детально определить изменения для создания MVP платформы, запланировать и оценить задачи с командами разработки. При описании ADR необязательно настолько детально расписывать логику принятия решений, важно привести схемы и основные тезисы с аргументами.

Шаг 4. Описать альтернативные решения

В этом разделе можно рассмотреть альтернативные решения, которые кажутся важными.
Альтернативы
  1. Масштабировать базу данных системы производства контента и не разрабатывать отдельный микросервис.
Недостатки, ограничения, риски
  1. Медиаплатформа имеет большую монолитную часть, в будущем это может создать риски масштабирования функционала и усложнить разработку.
  2. Большую часть платформы надо разрабатывать на целевом стеке Java — могут быть проблемы с загрузкой команды, можно было бы больше функций выделить в микросервисы на PHP.
Так мы на примере показали создание достаточно сложного архитектурного решения в формате ADR.
Как вы заметили, проектирование архитектурных решений содержит большое количество допущений и вариантов реализации, которые мы выбираем в качестве используемых или, наоборот, отбрасываем. Функциональные и нефункциональные требования задают контекст задачи и помогают сделать архитектуру, удовлетворяющую требованиям, но, чтобы прийти к какому-то итоговому варианту, нужно рассмотреть различные альтернативы. Выбор подходящей альтернативы, поиски альтернатив и их сравнение могут быть непростой задачей, так как обычно решения нужно принимать в условиях неопределённости, мы никогда не можем знать, что учли все требования и риски.
Чтобы немного уменьшить сложность этого процесса, полезно вспомнить о целях бизнеса и потребностях пользователя и рассматривать проектирование архитектуры как процесс, близкий к разработке концепций новых продуктов на уровне бизнеса или при проведении UX/UI-исследований. Для этого используются практики дизайн-мышления, их можно применять как некоторый набор шагов, помогающих в создании элементов архитектурного решения и его реализации.

Дизайн-мышление

✏️ Дизайн-мышление — это нелинейная методология создания решений, в основе которой лежит необходимость осознать проблему клиента и предложить, возможно нестандартное, решение. Так создаются удобные и адаптивные системы, эффективно решающие задачи благодаря ориентации на реальный пользовательский опыт.
Работа над проблемой через дизайн-мышление состоит из нескольких этапов, рассмотрим их на примере компании N.
Управление производством контента хочет реализовать функцию по передаче статистики просмотров в MVP платформы. Но у команды уже есть бэклог задач, который был приоритизирован важными стейкхолдерами, и реализовать это вряд ли получится. Допустим, эта задача обсуждается на встрече, где участвует менеджер продукта, команда продукта, архитектор и представители бизнеса.
Так можно посмотреть на задачу через дизайн-мышление и, возможно, найти вариант решения проблемы.
  1. Эмпатия. Здесь участники встречи пытаются определить источник проблемы клиента, встать на его место. Для начала нужно задать вопрос: «Зачем это нужно реализовать и какую проблему мы решаем?». Представители управления производством контента утверждают, что это нужно для построения отчёта по просмотрам, который сможет анализировать директор по производству, сейчас есть статистика по каналам, рейтинги и отзывы. Информацию по просмотрам через платформу также надо передавать руководству. Так выявили проблему — продюсерам нужно передавать руководству отчёт по контенту.
  2. Анализ и синтез. После сбора информации о возникающих проблемах нужно проанализировать, систематизировать информацию и убрать всё лишнее. С одной стороны, проблему выявили, но стоит ещё раз убедиться, что эта проблема — верная. С какой целью используется отчёт руководителем? Продюсеры говорят, что директор по производству может менять приоритеты в графиках съёмок для наиболее популярного контента. Вывод: данные о просмотрах нужны, они служат для определения графика производства и приоритизации.
  3. Генерация идей. Теперь нужно рассмотреть разные варианты решения проблемы, даже неожиданные. Команда разработки предлагает отправлять статистику в систему производства через Kafka или вызовами API, команда системы производства говорит, что может принимать файлы и готова сделать такую доработку. Менеджер продукта говорит, что реализовать это быстро вряд ли получится, но можно сделать после запуска MVP. Кто-то из участников (например, архитектор) предлагает вообще не делать эту задачу, сотрудники поддержки будут раз в месяц делать выгрузку вручную и отправлять на почту продюсерам. Эта идея всем нравится, но сотрудников поддержки интересуют детали.
  4. Прототипирование. Здесь нужно смоделировать решение проблемы любым способом (например, нарисовать на доске). В случае с проблемой компании N достаточно описать по шагам, как будет происходить отправка отчёта, с какой периодичностью и как не забыть, что это нужно сделать. Было решено, что ответственный продюсер будет раз в месяц создавать команде задачу в таск-трекере, которую сотрудники исполнят в течение дня, и приложат отчёт.
  5. Тестирование. Когда прототип готов, и кажется, что он может решить задачу, надо попытаться его проверить и устранить недостатки. Для задачи компании N выяснилось, что у продюсеров нет доступа в таск-трекер. Доступ обеспечили — они смогли завести задачу, поддержка определила формат отчёта и сделала тестовую выгрузку.
  6. Сторителлинг. На последнем этапе нужно обобщить информацию об итоговом решении и сформировать итоговую историю, чтобы точно убедиться, что проблема будет решена. Для этой задачи продюсеры могут рассказать о новом процессе директору, чтобы тот подтвердил, что его устраивает такой вариант решения проблемы.
Мы рассмотрели пример, где задача по разработке в итоге была решена вообще без неё. Поэтому при проектировании решений важно вспоминать о том, какая проблема решается, — ведь может оказаться, что сформированные требования противоречат изначальным целям или проблему можно решить по-другому, или такой проблемы вообще нет.
В задаче, которая потребовала бы определить изменения в архитектуре, последовательность шагов была бы такая же, но в качестве прототипа выступал бы какой-то вариант архитектурной схемы, а в качестве тестирования — успешное завершение Use Case, если пройти его шаги через интеграции на схеме.
💡 Метод дизайн-мышления не является линейным, ничего не мешает возвращаться на прошлые шаги, менять исходную проблему и предлагать другие варианты решения.
Часто архитектурные решения нужно презентовать команде проекта или продукта, бизнес-экспертам, чтобы все участники были в одном контексте и при необходимости могли дать обратную связь по вариантам реализации. Поговорим о презентации архитектуры.

Презентация архитектуры

Сложное решение бывает непросто презентовать людям, которые не находятся в контексте реализации или не имеют достаточно технических знаний. Чтобы презентация была успешной, полезно следовать нескольким правилам построения рассказа:
  1. Пояснить проблему, которая решается. Например, определение архитектуры новой медиаплатформы.
  2. Фокусироваться на решении бизнес-задачи. Лучше акцентировать внимание стейкхолдеров не на описании элементов схемы, технологиях и принятых допущениях, а на том, как решается исходная бизнес-задача, ради которой нужно спланировать изменения и определить архитектуру. Для этого можно рассмотреть основные Use Cases, которые были определены в решении, и пройти каждый из них с пояснением того, какие элементы решения в нём участвуют. Например, для Use Case с авторизацией мы можем рассказать, что пользователь вводит телефон и пароль, а API медиаплатформы вызывает внутренний сервис для работы телеком-оператором, после чего пользователь получает СМС. Это поможет всем участникам проекта, даже не имеющим технической экспертизы, понять контекст и логику решения.
  3. При описании решения фокусироваться на Use Cases основного потока выполнения, не уходя в детали и ветвления процессов.
  4. Озвучить альтернативы и почему они не рассматриваются в итоговом решении.
  5. Рассказать об ограничениях и рисках.
  6. Получить обратную связь, ответить на возражения. В этом поможет детальный анализ альтернатив, ограничений и заранее определённые требования.
Обсуждение решения может происходить не только с бизнес-экспертами. Часто это решение нужно обосновать коллегам в командах разработки и, возможно, принять коллективно.
Так как в компании может быть много различных инициатив, которые требуют определения изменений и их архитектуры, то предварительное создание решений и их коллективное обсуждение может быть встроено в процессы разработки продуктов. Например, создаются группы технических экспертов, которые смогут оценивать и коллективно принимать различные архитектурные решения перед началом разработки и планирования, такую группу называют архитектурным советом.
Создание такого совета позволяет не замыкать принятие всех решений на одном человеке (например, одном техническом лидере или архитекторе). Это позволяет рассматривать решения с разных сторон коллективно, в том числе используя шаги из дизайн-мышления.

Планирование реализации

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

План работ и роадмап реализации

Нас интересует набор достаточно крупных задач в рамках системы, а также задач, которые касаются взаимодействия разных систем. Именно такие задачи несут самые большие риски, так как требуют взаимодействия нескольких команд и синхронизации сроков окончания. В различных Agile-подходах такие крупные задачи часто называют эпиками, которые уже делятся на задачи поменьше. А более детальное планирование каждая команда впоследствии может провести самостоятельно.
Оформим в таблице возможные задачи на основе архитектурного решения и диаграммы C4 второго уровня.
Далее необходимо определить порядок выполнения: это удобно сделать в виде роадмапа. Продолжительность задач пока может быть произвольной на выбранном горизонте планирования. После того как команды проведут оценку задач и детальное планирование, менеджер проекта сможет детализировать роадмап и конечные сроки реализации.
Рассмотрим роадмап реализации для задач на горизонте шести месяцев, как это было ранее определено в стратегии цифровой трансформации компании N. Модернизация системы производства контента изначально была запланирована и должна начаться с Q2 2025 и закончиться до конца Q3 2024. Создание платформы должно начинаться с середины Q2 2025 до конца Q3 2025.
В роадмапе важно, чтобы система по производству контента сделала микросервис для работы с библиотекой до начала разработки главной страницы и функции стриминга. Сервис работы с телеком-оператором должен быть готов до окончания создания регистрации и авторизации. Функции управления подписками и интеграцию с платёжной системой сделаем в конце проекта.
Далее можно провести детальное планирование в командах, уточнить роадмап и приступить к реализации.

Управление изменениями

Проекты по разработке редко следуют намеченным планам по разным причинам. Может быть неверно оценена сложность, могут измениться приоритеты и даже при условии проектирования архитектуры и ответственного подхода к определению изменений могут появиться не учтённые раньше задачи. Чтобы проект лучше реагировал на возникающие изменения, ими необходимо управлять.
✏️ Управление изменениями (change management) — это процесс планирования, внедрения и контроля изменений проекта. Для этого нужно минимизировать негативные последствия и достичь поставленных целей.
Методов работы с изменениями несколько:
  • Предиктивный — мы заранее держим в голове риск того, что случится какое-то изменение, и имеем план на этот счёт. Например, в компании N определили, что платёжным шлюзом будет партнёр Simple and Fast Payments. Если он откажется сотрудничать с компанией или изменит условия, чтобы предотвратить риски, стоит заранее определить ещё одного или нескольких партнёров для проведения платежей.
  • Реактивный — мгновенная реакция на случившееся изменение. В этом случае снизить риски уже не получится, но на него можно оперативно отреагировать. Например, если платёжный шлюз не сможет принимать платежи, отправлять клиентам счета на оплату по email вручную.
  • Последовательный — это систематический подход к работе с изменениями, он состоит из нескольких этапов и как раз заключается в построении модели управления.
В компании N этапы управления изменениями могут выглядеть так:
  1. Идентификация изменений. Представьте, что в ходе реализации проекта появляется риск не успеть реализовать работу с оплатой подписки в медиаплатформе. Нужно искать альтернативу. Ранее обсуждалось требование о ручном оформлении подписки сотрудниками отдела продаж в CRM компании. Пользователь может отправлять запрос на подписку, менеджер высылает ему реквизиты оплаты в СМС, пользователь оплачивает, а затем менеджер вручную подключает подписку прямо из CRM.
  2. Документирование. Детали изменения полезно фиксировать: это можно делать, например, в корпоративном wiki и на каждую инициативу по изменениям создавать специальный документ — запрос на изменения (change request). В этом запросе фиксируется вся информация по изменению. Это поможет лучше понять, почему команда отклонилась от первоначальных планов по проекту, если будет решено принять изменения.
  3. Оценка. Нужно определить, насколько сложно будет реализовать изменения и стоит ли рассматривать такой вариант. Этот этап не отличается от начального планирования изменений при создании проекта, то есть надо определить требования, архитектуру, провести планирование и оценку для этой локальной задачи. Для компании N мы бы описали требования, Use Cases, сформировали ADR, перепланировали и оценили задачи с учётом разработки в CRM и её интеграции с медиаплатформой.
  4. Авторизация. Если есть оценка и понятен план работ, то можно принять решение, идти таким путём или нет. Важно согласовать этот этап с заказчиком проекта: может оказаться, что стоит рассмотреть другой вариант или немного сдвинуть срок запуска.
  5. Контроль. Реализация изменений по плану.
💡 Системный подход к управлению изменениями помогает фокусироваться на исходной цели создания продукта. А если условия изменились — поможет верно учесть все риски при появлении новых требований.

Задание 1

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

Задание 2

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

Итоги

  • Изменения в продукте можно запланировать быстро, но без учёта всех деталей, связанных с бизнес-процессами и интеграциями, результат может быть непредсказуемым. В сложных продуктах и крупных компаниях множество неявных связей, игнорирование которых может привести к срыву сроков или лишним тратам. Чтобы минимизировать риски, важно разработать архитектуру решения, которая обычно оформляется в единый документ — ADR (Architectural Decision Record). Этот документ фиксирует структуру и взаимодействие компонентов, цели, допущения и ограничения, а также служит основой для чёткого плана изменений.
  • ADR описывает принятые и отклонённые архитектурные решения в разработке ПО, включая их контекст, последствия и рассмотренные альтернативы. Записи ADL хранятся в журнале Architecture Decision Log (ADL) — он помогает отслеживать историю изменений, накапливать знания и поддерживать развитие продукта, даже если команда меняется. Для ведения ADR можно использовать корпоративные wiki-системы или системы контроля версий.
  • Состав ADR определяется командой, но минимально необходимыми элементами являются контекст (условия принятия решения), само решение и его последствия. Один из популярных шаблонов — Y-statement — дополняет это описание другими элементами: причиной, принятым решением с аргументацией, отклонёнными альтернативами, ожидаемыми результатами и ограничениями, которые необходимо учитывать.
  • Найти баланс между бизнес-требованиями, техническими ограничениями и пользовательскими ожиданиями в проектировании архитектуры очень помогает подход дизайн-мышления. Это нелинейная методология, направленная на осознание проблемы клиента и создание ориентированных на пользовательский опыт решений.
  • В реальности проекты разработки часто отклоняются от изначального плана, процесс управления изменениями (change management) помогает минимизировать риски и достичь целей через планирование, внедрение и контроль изменений. Существует три подхода: предиктивный (заранее предусмотренные планы на случай изменений), реактивный (оперативное реагирование на непредвиденные события) и последовательный (систематический подход с созданием модели управления). Выбор метода зависит от характера изменений и стратегии команды.