Всем привет, сегодня мы собираемся поделиться бизнес-архитектурой, но мы не говорим о том, что такое бизнес-архитектура и как это сделать с точки зрения менеджера по продукту? Вместо этого, с точки зрения технического архитектора, он описывает, как создать бизнес-архитектуру или как оценить тенденцию изменения бизнеса и заранее отреагировать на системную архитектуру, когда бизнес-архитектуры нет.
1. История
У специалиста по исследованиям и разработкам есть техническая архитектура, а у менеджера по продукту — бизнес-архитектура (обычно один человек).Когда технический архитектор не понимает бизнес-архитектуру, появится следующий диалог.
Сяо Ван, технический инженер: «Менеджер по продукту снова изменил спрос. Вчера он сказал мне, что заказ должен быть разделен в соответствии со статусом запасов. Я только что вышел в интернет, и сегодня он сказал мне разделить заказ в соответствии с типом продвижения. "
Архитектор Сяо Сунь: «Бизнес быстро развивался. В тот день он сказал мне, что хочет разделить его по объему продукта, но я его заблокировал».
Сяо Ван, технический инженер: «Отлично, у вас еще есть право говорить».
Я считаю, что все часто сталкиваются с подобными проблемами, но если технический архитектор понимает бизнес-архитектуру, это станет следующей сценой диалога.
Технический инженер Сяо Ван: «Менеджер по продукту снова изменил спрос. Вчера он сказал мне, что заказ должен быть разделен в соответствии со статусом запасов. Я только что вышел в интернет, и сегодня он сказал мне разделить в соответствии с типом продвижения. К счастью, вы мне в прошлый раз говорили об этом правиле.Оно изменчиво,давайте я разобью логику разных порядков на атомизацию,я могу изменить конфигурацию и сделать это,достойно быть архитектором,откуда вы знаете эту изменчивую штуку?Знаете ли вы гадание?"
Архитектор Сяо Сунь: «Ха-ха, предсказание будущего изначально является обязанностью архитектора».
Технический инженер Сяо Ван: «Научи меня быстро».
Теперь давайте узнаем, как предоставить техническим архитекторам возможность прогнозировать будущее развитие бизнеса.
Два, решение
Техническим архитекторам необходимо разбираться в бизнес-архитектуре, но им не нужно знать так много, как менеджеры по продуктам, такие как цепочка создания стоимости и другие концепции. Что ему нужно знать, так это то, как определить тенденцию развития и изменения бизнеса, а также структурировать и расширить техническую архитектуру соответствующей части. Сегодня я представлю простой метод — модель знаний MIT. Проще говоря, это 1: картографирование (Mapping) 2 идентификация (идентифицировать) 3 запрос (спросить о)
Отображение (отображение) : все требования могут быть отображены на следующем систематическом и структурированном языке, в каком сценарии (событии) компьютерная программа начинает действовать, какие данные (сущности) программа должна считывать и в каком порядке (действия), кто (организация/роль) выполняет правила (задачи) и какие данные (сущности) будут сгенерированы после выполнения. Но для конкретного сценария порядок (действия), правила (задачи) и кто (организация/роль) изменить проще.
Определите (идентифицируйте) и спросите (спросите о **) : поэтому, когда мы сообщаем требования менеджерам по продукту, самое главное — определить последовательность и правила** (организация/роль обычно настраивается в модели RBAC системы разрешений). , и не надо считать). Как быстро определить порядок и правила?
1. Последовательность: несколько бизнес-операций в сцене, обычно отображаемых в блок-схеме бизнес-процессов менеджера по продукту, например, функция представления продукта, которая должна пройти несколько этапов, таких как «понимание», «выбор», «инвестиции». , «юридические дела» и т. д. Узел бизнес-процесса. Найдя этот заказ, вы можете судить о том, можно ли его изменить, в основном задав продукту два вопроса: «Различается ли этот заказ для разных клиентов/каналов/категорий или разных каналов?», «Это заказ из-за краткосрочного онлайн-давления и компромисс просто упрощен». Обычно менеджеры по продукту получают эту информацию при проведении исследований. Если менеджер продукта не уверен, вы можете попросить менеджера продукта изучить эту информацию.При обработке системной архитектуры существуют различные способы решения проблемы масштабируемости.Вы можете создать несколько микросервисов или использовать инструменты механизма процессов для реализации масштабируемости. .
2. Правила: обычно (если A, затем B) режим, он обычно находится под каждым последовательным узлом, например, когда продукт представляет «понимание» бизнес-операций, если встречаются следующие слова: «Если продукт является основным устройством, Необходимо учитывать фактор конкурентоспособной цены», «Если продукт медленного типа, вам не нужно участвовать в инсайте» и так далее. Если вы найдете такие термины, вы можете в основном судить, что они являются правилами; конечно, есть еще некоторые правила, которые скрыты и требуют от нас выкопать, например, в случае ** «Заказы разделены по состоянию запасов . Я только что вышел в интернет, и сегодня я сказал мне разделить в соответствии с типом продвижения. "分", ** На самом деле здесь нет очевидного шаблона (ЕСЛИ А, ТО В), но обычно глаголы с прилагательными могут меняться (например, разделение в соответствии с инвентарем). положение дел). Но если вы покопаетесь или хорошенько подумаете, вы увидите, что две логики разделения должны быть условными или последовательными, иначе разделение того же порядка будет перепутано. Если в это время мы задаем два вопроса о продукте: «1. Действует ли это правило при определенных условиях, таких как разные клиенты/каналы/категории или каналы, периоды времени и приоритетный порядок». «2. Для этого правила могут быть другие правила для разных клиентов/каналов/категорий и других концов или каналов». Аналогично, если продакт-менеджер не уверен, можно попросить продакт-менеджера изучить эту информацию.При обработке архитектуры системы можно по-разному обрабатывать масштабируемость.В качестве модели стратегии можно использовать простейший код, либо использовать конфигурационные файлы, инструменты механизма правил и т. д. для достижения масштабируемости.
3. Анализ случая
С помощью приведенной выше простой модели мы восстанавливаем сценарий спроса, который архитектор Сяосун сообщил менеджеру по продукту для клиента.
Менеджер по продукту Сяо Ли: «На этот раз мы собираемся заняться бизнесом и выполнить заказ. Это мой PRD, давайте посмотрим сегодня ...»
Архитектор Сяо Сунь: «PRD очень подробный. С помощью моего PRD мы понимаем функцию выполнения заказа. Вы можете видеть, прав ли я, говоря следующее: функция выполнения заказа должна считывать данные заказа. Разделите и отметьте последовательность, генерировать несколько разделенных заказов и передавать их в систему логистики.Обычно эти задачи автоматически обрабатываются системой без вмешательства человека.Правильно?
Менеджер по продукту Сяо Ли: «Да, основная логика такова»
Архитектор Сяо Сунь: «Порядок разделения и маркировки здесь разный для разных клиентов/каналов/категорий или разных каналов. Является ли компромисс просто упрощением из-за краткосрочного онлайн-давления?»
Менеджер по продукту Сяо Ли: На этих этапах я изучил 4 клиентов, 3 канала заказов и конкурирующие продукты. В настоящее время нет возможности посмотреть новые узлы.
Архитектор Сяо Сунь: «Хорошо, тогда я рассмотрю стоимость. Сначала я спроектирую узлы процесса как фиксированные, а затем вы вовремя уведомите меня, если обнаружите здесь какие-либо меняющиеся сценарии. Кроме того, я вижу, что вы упомянули, что заказ соответствует заказу в процессе разделения. Разделение статуса запасов, здесь все заказы разделены в соответствии со статусом запаса?"
Менеджер по продукту Сяо Ли: «Мм, я так думаю»
Архитектор Сяо Сунь: «Я предлагаю вам исследовать, есть ли разная логика для разных клиентов/каналов/категорий и других терминалов или каналов», обычно действия с прилагательными могут меняться.
-- спустя некоторое время
Менеджер по продукту Сяо Ли: «Да, клиент А сказал, что в дополнение к инвентарю у него также есть стоимость доставки, подарочные карты и логика разделения объема продукта, которая будет выполняться по порядку».
Архитектор Сяо Сунь: «Хорошо. Я разработал эту часть для масштабируемости»
4. Резюме
Послушайте, для архитектора на самом деле довольно просто иметь бизнес-предсказуемость или деловую чувствительность: просто найдите подходящую позицию и задайте больше вопросов, что может снизить большую нагрузку на передовые исследования и разработки. Во многих случаях эту способность также можно назвать деловой чувствительностью. Таким образом, проектирование масштабируемости системы должно быть неотделимо от бизнес-ввода, но как быстро найти место, где бизнес меняется с помощью нескольких простых вопросов, решается моделью MIT, которой я поделился на этот раз. Вы также можете проанализировать изменяющиеся точки бизнеса в соответствии с этой моделью знаний MIT в соответствии с бизнес-сценарием.
Источник: Сообщество разработчиков JD Cloud.
Автор: Ли Чунли из JD Retail (пожалуйста, не перепечатывайте без разрешения)