Comments 8
Вы уж извините, но 10 из 10 в булшит бинго. Платформенная команда это такое сборище дармоедов с огромным ЧСВ, которые как-бы формируют стратегию и вообще самые главные. А на деле сборище архитектурных астронавтов, от которых кроме цветных прямоугольничков и слова таксономия никакой пользы. Причем их «очень важные архитектурные решения» зачастую просто кривы (привет хранилищу всего, где данные, которые вообще-то матрица, хранятся по одному числу в записи и записи разных типов в одной таблице), завязаны на их любимые технологии (а у меня, например, другие и выбор их обоснован ровно так-же — мне нравится) или вообще не доходят до тех, кто реально что-то делает (была-же email рассылка в прошлом месяце! почему вы не по стандарту работаете?).
просто в платформенной команде должны быть не одни манагеры, а желательно разработчики, которые будут исследовать текущий опыт в ИТ и брать технологии/библиотеки не «потому что у Васи такая же» или «я с ней 10 лет назад работал», а потому что она лучше подходит для наших задач — вот смотрите бенчмарки.
В общем, рисунок где платфрменные члены команды протикают в продуктовые… команды — плохой вариант. Лучше когда наоборот :)
В общем, рисунок где платфрменные члены команды протикают в продуктовые… команды — плохой вариант. Лучше когда наоборот :)
По поводу рисунка. Я хотел просто проиллюстрировать связь между продуктовыми и платформенными командами через определенных представителей, входящих в состав продуктовых комманд. А кто будут эти представители — обсуждаемо и зависит от конкретного контекста :)
Принципиальна сама разница между этим вариантом и вариантом «Платформа как продукт», где непосредственная коммуникация между продуктовыми и платформенной коммандами не предусмотрена, хотя, конечно, может (и должна) существовать опосредованно. Да и тема не исчерпывается только этими двумя вариантами, они приведены для примера.
Спасибо за Ваш комментарий!
Принципиальна сама разница между этим вариантом и вариантом «Платформа как продукт», где непосредственная коммуникация между продуктовыми и платформенной коммандами не предусмотрена, хотя, конечно, может (и должна) существовать опосредованно. Да и тема не исчерпывается только этими двумя вариантами, они приведены для примера.
Спасибо за Ваш комментарий!
Риск «появления дармоедов» присущ любому коллективу. Тут, скорее, вопрос культуры в организации и командах. Но необходимость наличия платформенных команд мне кажется очевидной по мере роста сложности тех «меж-командных» concerns, которые проиллюстрированы выше. Особенно, если организация предоставляет свою платформу как продукт на рынок (в том или ином виде). И чем выше прогнозируемая сложность, тем ранее должен быть решен вопрос владения платформой.
Спасибо за Ваш комментарий!
Спасибо за Ваш комментарий!
— Проникновение в микросервисные команды, когда в микросервисной команде присутствует представитель платформенной команды (или же один из членов микросервисной команды выделен для коммуникации с платформенной командой). При использовании данного подхода микросервисные команды имеют возможность более быстрой обратной связи с платформенной командой и могут инициировать процесс внедрения в платформу тех или иных изменений.
Первое (наличие представителя платформенной команды в команде микросервиса) — не работает. Второе — работает. Проверено на опыте.
Еще одним интересным следствием описанной парадигмы является возможность полностью аутсорсить разработку микросервиса на сторону. А в головной компании оставить только стратегию. Выгодны понятны — профессионалы в отдельных компаниях, занимающихся профильной деятельностью, уже обучены и готовы работать качественно. Остается вопрос контроля.
И даже платформенное решение может быть построено из сторонних SaaS компонентов (напр., aws, managed DB, Gitlab)
Только не нужно забывать, что платформа — это не только компоненты хостинга, транспорта, данных и т.д., но в большей степени предметно-ориентированная эко-система бизнеса. И тут, как раз, знание «чистых» компонент помогает мало.
Что касается «стратегии в головной», быстро наступает оторванность от реалий. И если с непрофессионалами еще можно казаться молодцом, то как раз профессионалам с вами будет скучно и они предпочтут большую вовлеченность в другой компании или форкнут свой вариант продукта с более прогрессивными характеристиками.
Что касается «стратегии в головной», быстро наступает оторванность от реалий. И если с непрофессионалами еще можно казаться молодцом, то как раз профессионалам с вами будет скучно и они предпочтут большую вовлеченность в другой компании или форкнут свой вариант продукта с более прогрессивными характеристиками.
Полностью согласен с первой частью комментария.
Что касается «оторванности от реалий» — она неизбежна в любом случае если мы перестанем валидировать окружающий нас контекст (организационный в данном случае — интеграцию с другими командами/организациями).
Связанность команд/организаций контрактами никуда не девается. Сторонние микросервисные команды связаны и сверху (потребителями микросервиса) и снизу (платформой). Платформенная же команда зависит и как от consumers (обратная связь от микросервисных команд) так и от своих стратегических целей.
Что касается «оторванности от реалий» — она неизбежна в любом случае если мы перестанем валидировать окружающий нас контекст (организационный в данном случае — интеграцию с другими командами/организациями).
Связанность команд/организаций контрактами никуда не девается. Сторонние микросервисные команды связаны и сверху (потребителями микросервиса) и снизу (платформой). Платформенная же команда зависит и как от consumers (обратная связь от микросервисных команд) так и от своих стратегических целей.
Довольно распрастраненная проблема, что в платформенную команду попадают люди с недостаточным опытом и квалификацией, т.к. у менеджера «людей нет». Максимум один понимающий, а остальные: админ, который «DevOoops» и «пишет на коленке», джуны, которые, на самом, деле интерны-геймеры… И на выходе проваленая поставка, т.к. «они поменяли API, т.к. им этого было достаточно» и «ждут, когда вы напишите сервисы, чтоб потестить API». Эх…
Sign up to leave a comment.
Микросервисы и организационная структура. Какие типы команд обеспечат успех?