Проблема когда с точки зрения бизнеса это один продукт, но пилят его 1к человек. И планы / KPI общие

а, понятно.

up-front design:
- это артефакт СА или архитектора
- задает верхнеуровневую декомпозицию задачи
- определяет правила взаимодейсвия сервисов

а дальше - учитесь общаться и договариваться о деталях

Ну а если одна команда убежит вперёд по срокам на месяц, что делать будете?

так же up-front design нужен для оценки планов направления

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

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

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

На предыдущей работе у нас была такая двумерная структура. Опыт исключительно положительный.

У нас аналогично. Правда “вторая” иерархия ориентирована на технологический стэк. Знания о технике распространяются уже хорошо. А вот предметные области технической иерархии совершенно неинтересны.
Наверное нужна какая-то третья иерархия, держатели экспертизы о прикладном домене.

У нас вторая иерархия распространялась на всех, не только на программистов. Другими словами, это деление было на всю компанию, включая C-Level

Кто у вас был держателем знания о прикладном домене?

Тот, кто в соответствующей области наиболее компетентен :)

Коллеги, подскажите чат админов ms, есть вопрос по ad

Набег из Анализа Систем

Что-то прям сегодня в чате как на берегу моря - тишина, и только новые люди набегают волнами 😊
Аж непривычно

всем привет! думал, куда бы вопрос задать, потом вспомнил, что есть же такой чатик специальный про архитектуру... вопрос сорри нубский, но буду признателен за ваше мнение.
Есть 3 сервиса. Один получает из api набор данных, к примеру новостей. Второй эти данные обогащает. Третий стоит на раздаче большому количеству пользователей. Бизнес-объект не очень простой, т.е. внутри него могут быть коллекции, например. Но сериализуемый. Поток всегда в одну сторону. Вариант 1: просто гонять между сервисами эти объекты по RabbitMQ. Вариант 2: гонять по RabbitMQ только ID этих объектов, а сами объекты хранить в какой-нибудь реактивной монге.
Какой выбрать? От чего зависит такой выбор?

от объема трафика, который складывается из:
1) среднего размера одного набора данных
2) среднего кол-ва наборов, передаваемых в единицу времени

есть еще вариант в какой-нить протобуф заворачивать для уменьшения объема

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

спасибо большое, в целом ход мысли понятен