Comments 20
Аналитик на начальной картинке слева или справа?
А вы не могли бы еще рассказать зачем у вас на проекте два проектных менеджера? Если проект один конечно, а не матрица из проектов.
По мере разрастания проекта началось выделяться все больше доменных областей, на каждую из которых формировалась отдельная команда разработки. Итого на проекте появилось около 8 доменов и один проектный менеджер уже бы не справился с таким количеством команд (ведь у каждой есть свои "agile церемонии").
Поэтому со временем у нас появился еще один проектный менеджер для помощи и разделения ответственности между командами. К примеру, все что связано с платежами и возвратами денежных средств клиенту ушло к одному менеджеру, а все, что связано с процессингом заказа к другому.
У вас ещё и девопс появится, иначе никто эти микросервисы развернуть не сможет. Ещё потребуется третий менеджер когда количество микросервисы перевалит за 50 + срочно искать второго девопса. А ещё вы юзаете разные языки кто пишет на java, C# python свои микросервисы и так просто уже жонглировать юнитами не получится. Вам нужно будет нанять дополнительного HrR'а который будет подыскивать определенного юнита с определенным знанием и т.д Так как вы на порядок усложнили архитектуру и взаимосвязи между сервисами. И где то маячит уже 3 девопс и четвертый менеджер и ещё вы решили усилить команду так как не справляется выпускать по два релиза в день, а хочется хотя бы стабильно релиза 3 в день. Третьего девопса обязательно посадите писать внутренние статьи, как тестировать все эти 100500 микросервисов и обязательно частенько обновляйте документацию.
Потом постройте граф зависимости между микросервисами, вполне красиво получается, а если раскрасить линии, можно вешать как картину на стену.
Удачи!
Time-2-market. Быстрая доработка ведет к увеличению time-2-market, что, конечно же, большое преимущество для бизнеса.
Пожалуй, наоборот: уменьшению/ускорению
Мне одному кажется, что "распилить монолит" - это современное название процесса "все плохо, надо переписывать заново"?
Я бы сказала, что «распилить монолит» это часть того, что «все плохо, надо переписывать заново». Потому что просто переписать код заново можно и по следующим причинам:
Функционал с багами и плохой обратной связью от пользователя;
Большое количество костылей в продукте, которое также ведет к ухудшению производительности и сложности в разработке новых фичей (необязательно монолит);
Плохо структурированный код, по которому требуется рефакторинг.
Я прочитал статью и не понял в чем же роль аналитика.
Помогает команде провести декомпозицию бизнес-процессов на домены и определить их границы.
В чем заключается помощь? Кофе приносит?
Приводит хаос в порядок и его систематизирует
Слишком абстрактно. Выглядит как "занимается тем, что разработчики посчитали неважным". Скорее всего это действительно не важно.
Понимает ключевые и потенциально опасные части бизнес-процесса и доносит это до разработки.
Это одноразовое действие. А дальше что? Или у вас разработчики не понимают что они автоматизируют?
Оценивает проект целиком и помогает при проектировании API-методов.
Снова кофе приносит? Или в чем помощь при проектировании API от человека, который не имеет квалификации разработчика? А зачем делается оценка?
В чем заключается помощь?
Помощь подробно описана в разделе про исследование текущих бизнес-процессов AS IS и в разделе про проработку и согласование TO BE процессов с разработкой и бизнесом.
Слишком абстрактно. Выглядит как "занимается тем, что разработчики посчитали неважным". Скорее всего это действительно не важно.
Есть конкретные примеры про актуализацию документации и создание карточки микросервиса. Это может быть не важно на каком-то маленьком проекте без функциональных требований, а на проекте, где выделяется большое количество новых микросервисов описание необходимо как минимум для будущих поколений и как максимум для разработки новых фич на последующих интеграционных проектах.
Это одноразовое действие. А дальше что?
Дальше - учитывать новые потребности бизнеса и на основе них описывать функциональные требования для разработки.
Или в чем помощь при проектировании API от человека, который не имеет квалификации разработчика? А зачем делается оценка?
Помощь при проектировании API заключается в том, чтобы выделять бизнес-параметры, на основе которых строятся параметры запроса и ответа. А оценка делается для понятия масштаба проекта.
Я, как разработчик, не могу понять как чье-то исследование бизнес-процесса мне поможет.
Остальное - опять туман.
"Аналитик что-то там делает и это помогает разработчикам". Примерно выглядит как сама статья, так и ваш комментарий. Возможно вы и сами не понимаете в чем же эта помощь.
Кроме того сама тема статьи странная. Процесс возврата денег не зависит от того монолит у вас или микросервисы. Это чисто техническая деталь, неважная с точки зрения бизнеса . Разработчики и сами разберутся как им удобнее проект структурировать.
Я читал статью с надеждой увидеть конкретику про аналитиков и микросервисы, а её нет, только общие слова.
Сложилось ощущение, будто вы прочитали исключительно часть «чем полезен аналитик», пропустив все, что было до этого.
Процесс возврата денег - неважная деталь с точки зрения бизнеса? А что тогда является важной деталью? Абсолютно каждый бизнес-процесс должен быть интересен для бизнеса, если это отдать на откуп разработчику, то он либо молча реализует так, как он это видит, либо будет бухтеть, что недостаточно контекстов.
Автор статьи неоднократно подчеркнул, что в монолите были разные костыли и плохие решения, которые в микросервисы тянуть не нужно, а где-то необходима переработка бизнес логики.
Если не аналитик, то кто по вашему мнению должен заниматься описанием бизнес логики?
Собственно так и прочитал, поэтому что эта часть соотносится с темой статьи.
Процесс возврата денег - важная деталь с точки зрения бизнес-процесса, а монолит это или микросервисы - нет. Но вы, видимо, не прочитали следующее предложение из абзаца, чтобы понять о чем речь.
Что касается описания бизнес-логики: Раньше описания не было? Вот прям совсем? Как же тогда создали этот самый монолит? Если монолит создали без описания, то что мешает распилить его на микросервисы без описания? Если описание раньше было, то почему не использовать его?
Напомню что статья называется "Роль аналитика в <решение организационно-технической задачи>", а в статье написано про описание БЛ, которое в общем случае не имеет отношения к решению организационно-технической задачи.
Чтобы вы понимали более глобально, то монолит делался примерно лет 7-10 назад. Есть ли описание? Все, что я находило было неактуальным или частично актуальным (в статье кстати есть про это).
По вашему мнению, за такое время бизнес-процессы никак не меняются? Ничего не автоматизируется? Костыли не добавляются? Новые методы оплаты/возврата компания не вводит? Заявления на возврат денег с бумаги на онлайн не переходят?
Знание текущего бизнеса-процесса необходимо для распила, чтобы не просто переписать код монолита как он есть сейчас (что в целом не имеет смысла), а учесть все новые изменения в бизнес-логике, корректно разделив функционал на контексты и упростив жизнь пользователям (за возврат денежных средств отвечает целое операционное подразделение компании).
Спасибо за практическую статью!
Есть несколько вопросов:
Участие двух аналитиков в проекте. Как разделяли между собой задачи?
Сколько спринтов в итоге занял «распил»?
Были ли попытки у бизнес-заказчика посчитать ROI проекта , ведь команда из 35 инженеров, достаточно серьезные косты?
You're welcome!
1. Участие двух аналитиков в проекте. Как разделяли между собой задачи?
Задачи между собой разделяли на основе общего бэклога. Например, по доменам. То есть, домен возврата денежных средств и все вытекающие из него задачи были на мне, а аналитика по домену приемки товаров на обратном потоке товаров была на моем коллеге.
2. Сколько спринтов в итоге занял «распил»?
Не сориентирую по спринтам, но активная фаза проекта по "распилу" заняла около 10 месяцев.
3. Были ли попытки у бизнес-заказчика посчитать ROI проекта , ведь команда из 35 инженеров, достаточно серьезные косты?
Насколько я знаю попыток расчета ROI проекта не было, но при защите количества людей на проект отталкивались от потерь по major incidents монолита и так рассчитывали потенциальную не потерю в прибыли.
ZEND - жесть конечно!
Использовать одну базу для операционки и для BI - жесть в квадрате!
Ничего не написали про маркировку. Интеграция с ГИС МТ у вас - отдельный микросервис или как реализовали? Сколько операторов ЭДО используете?
Ничего не написала про маркировку, потому что она в монолит и его распил не входит. У нас работа с ГИС МТ это отдельно выделенный сервис со своей функциональностью и интеграциями. Про операторов ЭДО, к сожалению, не подскажу.
То есть "маркировка" уже изначально является микросервисом или группой микросервисов?
Значит, на ваших схемках далеко не все блоки обозначены! :)))
Попробую объяснить по-другому :)
Опыт описанного в статье проекта касается одного большого монолита в части процессинга заказа. И на схемах нарисованы все блоки, которые входят в этот монолит.
Поскольку монолит был с начала основания компании, а тема с датаматриксом уже гораздо позже, то для работы с ГИС МТ была разработана отдельная система, она не входит в описанный монолит. Ровно как и много других систем и сервисов, которые не входят в монолит - работа склада, ERP, системы настройки параметров доставки и т.п.
Роль аналитика в проекте по распилу монолита