Закон Конвея в деле

Закон Конвея звучит так: "Любой программный продукт отражает организационную структуру, создавшую его".

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

Все началось с того, что жили мы в модели управления через центры компетенций. Это была совершенно нетрансформируемая структура, ровным счетом такая же, как и наша на тот момент архитектура. Огромные монолитные системы, которые общаются через ESB, объединяя в себе множество различных контекстов и бизнес-логики.

Структура была «очень простой»: ИТ-директор, а под его управлением - руководители центров. Центров было очень много, например:

1. Центр фронтальной аналитики. 2. Центр системного анализа. 3. Центр мобильной разработки. 4. Центр GO разработки. 5. Центр фронтального тестирования. 6. Центр backend тестирования. 7. Центр мобильной автоматизации и т.д....

У каждого руководителя центра было примерно от 30 до 100 человек. Внутри они назначали «лидов», «руководителей направлений», «экспертов», «экспертов среди экспертов», «старших экспертов» и кого там только не было.

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

На помощь к нам пришла «трансформация». Она действительно нам помогла, и тут первый раз на моих глазах явно сработал Закон Конвея.

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

Таким образом у нас появились первые роли СТО и техлидов. Бизнес-лидер трайба + СТО трайба стали главными владельцами и партнерами своих трайбов. Их KPI были разделены: и тот, и другой отвечал за ит и за бизнес-цели.

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

Под бизнес-лидом в прямом подчинении были все продуктовые ребята (пио, бизнес-аналитики, продуктовые аналитики, ux и т.д.). Под техлидом в прямом управлении - все ит-ребята (тестеры, программисты, системные аналитики и так далее).

Техлиды подчиняются СТО, а бизнес-лидеры стримов - бизнес-лидеру трайба.

При чем же тут Закон Конвея, спросите вы.

Никто не отменял сроки, а когда началась трансформация, она обязательно должна зарекомендовать себя улучшением T2M. Что тут сложного? Ставим больше и четче кпэ на трайбы и короче сроки.

Ребята (сто, техлиды, бизнес-лиды) в продуктовых трайбах (кем был и являюсь я) сразу поняли на своей шкуре, что пилить фичи на множестве коммунальных монолитных систем точно не вариант. Так стали образовываться первые выделенные системы, микросервисный слой, стали выделяться домены. Все это, конечно, шло не быстро - примерно в течение 1,5 лет. В конечном итоге монолитов почти не осталось, а те, что остались, имеют план (разного уровня и длины) по рефакторингу или отказу. С учетом этих планов и договоренностей общими усилиями мы успешно движемся к свету.

Я стал невольным участником всей этой истории, за что благодарен судьбе.

(Продолжение в следующем посте)

Мой канал - https://t.me/carbonka