Как донести здравый смысл до заказчика. Инструменты архитектора

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

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

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

Расскажу, в чем заключается мой способ.

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

Если вы начинаете чувствовать, что обсуждение буксует, – рисуйте картинку.

Версионируйте картинки.

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

Рисовать картинки – обычно уныло. Если на бумажке или на маркерной доске рисовать ещё как-то удобно, но в цифровом виде все это выравнивать, соединять стрелочками – довольно уныло.

Поэтому нужны удобные инструменты.

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

• Mind Maps,

• BPMN,

• Archimate

• и на сладкое – PlantUML.

Mind Maps. Объясняем самому себе

Самый простой инструмент – это Mind Maps или «ментальные карты». Он помогает объяснять не кому-то, а самому себе, такое тоже иногда бывает.

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

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

Ментальная карта выглядит как иерархическое дерево.

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

Поэтому берём Mind Maps и рисуем проект по пунктам.

• сначала надо себя как-то доставить туда – создаем ветку «Доставка»;

• добавляем билеты в обе стороны – можно файлы приложить, чтобы не потерялись;

• добавляем гостиницу – сохраняем документы на номер в отеле;

• продумываем, что с собой брать, какая будет в это время погода в городе;

• работаем с темами докладов – добавляем тезисы и т.д.

История начинает оформляться в дерево, в карту памяти.

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

Например, проект по запуску кофейни – с чего начать, что не забыть, как подготовить. Какие-то темы, подтемы и т.д.

Для рисования таких карт я использую программу FreeMind.

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

Чем хорош FreeMind?

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

• Ты можешь записывать эти ветки дерева, укрупнять темы, подтемы, выстраивать связи – все с клавиатуры. Подумал – записал.

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

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

BPMN 2.0. Выясняем пробелы в постановке задачи

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

Как запускать такой проект, и как работать с заказчиком, когда ты чувствуешь, что бизнес-процесс ему самому до конца не понятен? Заказчик примерно понимает, что хочет, но не до конца.

Для этого я использую инструмент BPMN – Business Process Modeling Notation.

Это нотация, некий стандарт рисования и представления бизнес-процессов на языке бизнеса.

BPMN работает строго, как язык программирования. Это не просто какие-то схемы бизнес-процесса, а схемы, которые могут запускаться на выполнение. Для этого в платформах Apache Camunda и Activity есть специальные инструменты. Например, там есть сервер, который занимается оркестрацией всех интеграций: если пришло письмо с определенным текстом, нужно вызвать такой-то сервис, а если с другим текстом – другой сервис. И все это выражено в терминах бизнеса и реальных процессов реального мира. В этом мощь BPMN – там отражается процесс всего бизнеса, а не та малая его часть, которая происходит внутри компьютеров.

Это классная вещь и супермощное средство для поиска недопродуманных бизнес-процессов.

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

У него исторически есть список клиентов в старых системах, а сейчас его компания внедрила новую CRM, и он хочет профили всех клиентов свести туда.

Он хочет открывать одно окно и видеть: что человек у него покупал, когда, какие договоры заключались – все исторические данные свести в новую CRM.

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

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

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

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

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

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

Давайте разберем эту задачу подробнее. Действующие лица процесса:

• менеджер по продажам, который работает в CRM (приложение на React);

• клиент – юридическое лицо, которое создает заказы в личном веб-кабинете, написанном на Java. В своей учетной записи клиент видит, когда и что заказывал, когда ему отгрузили товар или когда этот товар будет отгружен;

• и есть оператор склада, который отгружает эти заказы, он это делает, например, в «Управление торговлей 11» – мы можем только предполагать, на чем она написана.

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

BPMN – это простая нотация, у ее немного ключевых узлов:

• начало процесса;

• конец процесса;

• какие-то развилки или наоборот, сведение процессов;

• ожидание наступления каких-то событий;

• синие квадраты – это уже какое-то конкретное действие руками или с помощью автоматизации.

Немного элементов позволяют описать практически все бизнес-процессы.

Начинаем исследовать.

Нам нужно свести записи клиентов в одну базу. А что такое клиент? Кого мы считаем клиентом, и как он появляется в фирме?

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

Как мы понимаем, что это наш клиент? Когда он с нами заключит договор, тогда он и станет клиентом.

Так и фиксируем:

• Работа по воронке продаж.

• Проверка – начал ли клиент с нами работать.

• Если начал, заводим запись как клиента.

Процесс начинает немного выстраиваться.

Опрашиваем заказчика дальше.

Как появляется учетная запись клиента в личном кабинете? Мы его в CRM завели, уговорили подписать контракт, но как он получает свою учетную запись – логин, пароль в личный кабинет?

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

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

Выясняем дальше.

Клиенту сделали личный кабинет, он там заводит заказы, смотрит статистику и т. п., а как УТ на складе будет это обрабатывать и отгружать? УТ-шке ведь тоже нужны знания о контрагентах. Начинаем обзванивать, разговаривать и выясняем, что из этого личного кабинета раз в сутки выгружается Excel с новыми контрагентами и загружается в УТ.

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

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

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

Такая же ситуация в УТ – там тоже партнероцентрическая модель в отношении юридического лица.

Т.е. модели данных личного кабинета и УТ уже перестают стыковаться, а мы хотим их данные сводить вместе. В УТ нам нужно создать не на каждый договор из CRM+ЛК одного контрагента, а создать одного партнера и к нему уже договоры. И решения о том, как это состыковать у бизнеса нет. В этом месте на схеме можно рисовать облачко с надписью «МАГИЯ».

Так проясняются нестыковки в бизнес-процессах – с фиксацией каждого действия на пути от заказа к выручке.

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

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

В результате мы:

• нашли открытый вопрос – как приводить систему к единой модели;

• нашли какие-то ручные операции, которые можно исключить и автоматизировать;

• нашли странные интеграции через Excel.

В такой нотации очень удобно обсуждать задачу.

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

• когда в CRM появляется клиент, его данные сливаются в MDM;

• там выясняется, какому юрлицу принадлежит договор – существующему или нет, определяется юрлицо и его договор;

• и в таком виде данные раздаются в целевые системы потребителей (в УТ и ЛК).

• попутно удалили массу дубликатов данных

Все стали счастливы.

Вывод: обсуждать проекты нужно с точки зрения процессов, а процессы прорисовывать сразу в BPMN. Тогда на обсуждении экономится куча времени.

Archimate. Многослойная архитектура

Еще один инструмент, который мне сильно помогает, – Archimate.

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

Чтобы добавить ясности в эти термины, архитектурная группа TOGAF – это такая группа, которая консолидирует лучшие практики по IT в целом в мире – выпустила спецификацию Archimate, которая переводится как «друг архитектора».

Согласно этой спецификации, архитектура делится на слои:

• слой бизнеса;

• слой технологии;

• слой инфраструктуры.

Для описания слоев спецификация Archimate предлагает несколько простых общих блоков: сервис, процесс и функция.

Описание архитектуры зависит от того, с какой стороны мы хотим смотреть на этот архитектурный объект.

Если мы описываем слой бизнеса, у нас есть:

• клиент – Business Actor;

• менеджер по продажам – тоже Business Actor;

• некий процесс, в котором они работают – Business Process

• при этом задействуются бизнес-службы – Business Service – склад и личный кабинет.

Этот склад и личный кабинет работают на основе какого-то софта. Описание слоя софта выглядит так:

• управление складом WMS организовано на УТ;

• работу личного кабинета тоже обеспечивает ряд каких-то сервисов – для аутентификации, веб-интерфейса, внутренние сервисы и т. д.

Т.е. есть некий бизнес-процесс, который поддерживается вот таким софтом.

Этот софт работает на железяках (в нотации Archimate железяки показываются зеленым цветом) – WMS работает на кластере 1C, есть Kubernetes, а между ними Kafka.

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

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

Сейчас самое интересное – то, что мне нравится больше всего.

PlantUML. Рисуем текстом в «Блокноте»

PlantUML – это вещь, которую я полюбил с первых моментов ее использования. Она позволяет рисовать кодом в блокноте самые различные диаграммы, схемы, которые привычны людям – прямо в Visual Studio Code. И тут же видеть результат.

Почему это клево?

• Потому что рисовать картинки муторно: выравнивать стрелочки; думать, где разместить – левее, правее, выше; центрировать какие-то квадраты относительно друг друга. Все это муторно и отвлекает. Это нужно отдать на софт. Пускай железо думает, где какой кубик рисовать, а мне надо смысл донести.

• Нам нужно быстро нарисовать идею. За пять минут в PlantUML можно накидать сложные диаграммы и уже их обсуждать. Обсуждая картинку, вы экономите часы рабочего времени.

• PlantUML поддерживается в Visual Studio Code и во многих других программах.

• Этот фрагмент программного кода можно вставить почти куда угодно

На слайде показан пример диаграммы последовательности для интеграции 1С с сайтом.

В Draw.io устанешь рисовать такую диаграмму: пока выровняешь, пока стрелку нарисуешь, пока привяжешь…

Не надо этого делать. Нужно обсуждать смысл – кто, кому, когда и что посылает. Такая диаграмма зарисовывается за 10 строк кода за 1-2 минуты.

Сразу можно обсуждать и кидать письмо коллегам, говорить: «Вот такая схема вас устраивает или нет?». Удобно.

PlantUML поддерживает большое количество нотаций: последовательности, алгоритмы, статусные переходы, компоненты. Их огромное количество.

Из плюшек – документация к PlantUML на русском языке.

Диаграмма статусных переходов состояния

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

Под статусом может подразумеваться все что угодно – события, состояния или переход между ними. Просто слово «Статус» звучит весомо и красиво.

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

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

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

При этом названия статусов абсолютно вторичны.

Опять же, берем PlantUML, пишем статусы заказа, и получается диаграмма.

Обратите внимание на статусные переходы:

• сначала у нас есть телефонный заказ в статусе «черновик»;

• потом мы набрали корзину – получили статус «ожидает оплаты»;

• потом, если заказ в течение пяти дней не оплачен, он переходит в статус «не оплачен» – к нему подключается менеджер;

• клиент обещал оплатить – опять же статус «ожидает оплаты» и так далее.

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

Нарисовали десяток строчек и получили диаграмму, которую можно обсуждать легко и весело. А главное – недолго и эффективно.

Эта история может расширяться:

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

• Потом это можно завернуть в отдельную библиотеку или сделать плагин для VS Code и выложить его в маркетплейс.

• С помощью директивы «!include» мы можем подключить библиотеку наших собственных компонентов и использовать ее вместе с коллегами.

• Поскольку VS Code – это расширяемый редактор, там можно сделать подсказку через точку, чтобы VS Code подставлял блоки диаграмм самостоятельно. Это возможно, но я еще не пробовал.

Коллективная работа. Библиотеки компонентов, версионирование

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

• Во-первых, все они основаны на текстовых форматах. Нотации BPMN и Archimate – это XML, PlantUML – это маленькие текстовые скрипты.

• Все это можно складывать в Git. Например, когда мы прорисовывали все наши потоки интеграций по компании, мы работали втроем – складывали схемы PlantUML и присылали друг другу пул-реквесты: «Ты прорисовываешь склад, а ты прорисовываешь другое». Каждый рисовал свои компоненты, а потом мы мержили это в какой-то один документ.

• Этот документ потом экспортировался в PDF, HTML и так далее. Т.е. на основании скриптов PlantUML мы сгенерировали набор красивых PDF. С таблицами и рисунками.

При этом мы работали в Git – присылали друг другу пулл-реквесты и ревьюили. Код-ревью картинок – это весело.

Какие преимущества мне дает визуализация процессов при затянувшемся обсуждении:

• Это быстрое получение результата.

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

• С картинкой мы решили это за час.

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

• Не просите заказчика рассказать о процессах, лучше сразу вместе с ним рисуйте – так вы сэкономите огромное количество времени.

Напоминалка:

• Если хочется зафиксировать самому себе какую-то неоформившуюся мысль, создавайте карты памяти – с помощью FreeMind, XMind, FreePlane. Мне нравится FreeMind за его минималистичность и возможность работы чисто с клавиатуры, не отрывая рук от кнопок.

• Для BPMN я использую Bizagi, но можно пользоваться Camunda или VS Code. Там есть плагин, вы его ставите, графически создаете файл BPMN, накидывая элементы в VS Code, а на выходе получается XML-файл. Очень удобно.

• Archimate – это многоуровневый редактор Archi от TOGAF.

• Все остальное – это PlantUML.

  • Диаграмма последовательности – кто, кому, когда, что посылает при интеграции.

  • Слышите слово «статус», открываете PlantUML и рисуйте переходы, потому что половина статусов не нужна. Важны не статусы, а дуги между статусами. Именно они приводят к статусам.

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

  • В PlantUML огромное количество диаграмм, все документировано на русском на сайте plantuml.com и все редактируется в виде текста.

Что почитать

• https://plantuml.com

• mellarius.ru/architecture – классный сайт с огромным количеством материалов по архитектуре, по-моему, его автор даже 1С-ник.

• www.archimatetool.com – информация об Archimate.

• bpmn2.ru

• camunda.com – это оркестратор бизнес-процессов. Он позволяет гибко менять интеграции в микросервисной среде. Это классный инструмент, но требует внедрения, потому что это серверы и приложения, а не просто рисовалка. Рекомендую изучить, в этом что-то есть.

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.