ну вот и проанализировали бы тугеза

спасибо) если не забуду и будет возможность - можно попробовать)

давай, ага

У нас
Проблема таже - бесконечные чатики, созвоны, неконструктивные диалоги и тд.

Владелец записал видео по поводу комуникаций в команде, есть на ютубчике могу пошарить.

Некоторые рекомендации для комфортного общения в команде.

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

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

Так же мне видится проблема в том что у вас есть вот эти "стадии" - дизайн базы, дизайн микросервисов (как это вообще? микросервисы с общей базой?), протобуфики и т.д.

Для решения описанной проблемы нужно больше полномочий и автономии спускать внизы. Что бы архитект только направление задавал, мол какая команда чем заниматься должна. А такие мелкие вещи как "че как кого дернуть" - должен быть свод правил и ограничений какие данные куда передавать можно (по умолчанию никакие и никуда) а какие нельзя ни при каких обстоятельствах (PHI/PII какие).

Тут как с код ревью. Нужно определить что ревью требует а что можно и без него. Начните с того что бы из всего спектра выбрать те вещи которые "не то что бы сильно требуют апрува архитектора" - это и дизайн базы (у вас же микросервисы вы че)  и протобуфы. Уменьшите скоуп только до "вот мой сервис ходит в тот сервис за такими-то данными и потом на основе этого решение делает - это ок?". Дальше уже можно идти в сторону формализации таких правил. Мол что ревью у архитектора нужно только если вам надо стучать в другой сервис. или еще чего делать что не описано в зависимостях вашей команды. Так постепенно можно уменьшать скоуп зависимостей.

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

давай, думаю будет полезно)

Алексей, а расскажи потом, что как?

Четкая агенда звонков + модератор кто за агендой следит, все просто же

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

Но по итогу все действия направлены на то что ты сказал

Это нужно было донести команде.
Есть люди которых хлебом не корми дай потрандеть о чем либо.

у нас база - монолит ms sql с вагоном схем, таблиц, и хранимок. очень много бизнес логики в ней. был огромный монолит на симфони с вынесением также многих модулей в отдельные репы. потом внедрили микросервисы, в итоге сейчас еще пара десятков го микросервисов, тарантул, и мемкеш. тарантулы отдельные под микросервисы, да. но основная бд - монолит. ревью у нас тоталитарное. минимум 2 ревьюера, а лучше 2 разраба и 1 тимлид чтобы были. четкого скоупа нет, команды только только начали внедрять раздельные, и пока что все +- отвечают за все (по крайней мере область ответственности очень обширная). протоспека да, вся обсуждается с архитектором, ну кроме разве что совсем мелких вещей и фиксов. в целом не только это, конечно, я даже толком не знаю чем он занимается, но с доступностью у него большие проблемы, как и у тимлидов. ну а так да, прото - про межсервисное взаимодействие. то, что в рамках одного микросервиса (а таких задач почти нет) - это можно и с тимлидом, человеком из команды и мейнтейнером микросервиса решить без архитектора.

У нас все проще - никто не знает кто чем занимается и кто за что отвечает. При этом митинги больше потому что иначе непонятно что происходит

у нас звонки по любому поводу. есть вопрос - поперли делать созвон в зуме (вот если честно хз что можно хуже зума для созвонов придумать, но у нас он)

растратчики!

+- да, напылесосили человек 30 наверное за последние пол года, может больше, и в итоге никто ничего не понимает пока, переходный хаос

Ну то есть необходимость микро менеджмента есть отсутствие доверия

бабла безлимит у конторы)

да, доверия нет, все верно. как толком нет и тестов.