Во всем виноват Конвей (#менеджмент)
Закон Конвея звучит в вольном переводе так: Любая организация, которая проектирует систему (в широком смысле), создаст проект, структура которого будет копией коммуникационной структуры организации.
Фишка его в том, что он действует (привет тем, кто считает иначе), но с точки зрения бизнеса имеет один важный изъян - не адаптирован к изменениям. Люди в компаниях меняются. Организационные структуры меняются. Команды меняются. Культура меняется. Бизнес-цели меняются. Коммуникации меняются. Но производство не останавливается. Спроектированные в "прошлой жизни" системы становятся дико неудобными в разработке, нестабильными и с кучей накладных расходов. Компании массово меняются с бешеной скоростью и в произвольных направлениях. Плюс к этому в нагрзуку - текучка и аджайл головного мозга у лиц, принимающих решения.
Можно бесконечно спорить на эту тему, но у рулей на всех уровнях, а не только у бизнеса, должен быть опорный план на случай изменений, например, в виде стратегии. В том числе и по причине его отсутствия конторы любят переписывать свой софт раз в пару лет. Новые менеджеры (эффективные по большей части) спать не могут без реформ. В отсутствии стратегии через пару лет в компании люди сменятся, а вместе с ними уйдет первоначальный замысел - т.е. некоторая стратегия, которую коллеги сочинили и следовали ей, пока колбасили продукт. Соответственно, если ее нет в бумажном виде - спасут только ветераны, которые смогут как в примере ниже отвечать на вопросы вида "какого хрена так, а не по другому". И в итоге часто всей лавкой втыкаемся в состояние, когда вообще непонятно, как и куда сделать следующий шаг. И в этот момент возникает мысль переписать все к такой-то матери и сделать нормально. Машина запускается заново. Такая же история происходит на всех этажах. Хороший бизнес планирует себя на много лет вперед. Все крупные конторы имеют "план 2030-2040", понятно, что он очень условный и сто раз изменится, но из того, что я видел, при изменениях меняется и этот документ. Таким образом конторы поддерживают свой вектор развития и осуществляют преемственность лидеров. На местах же все не так круто.
Р(азработчик): почему в этом куске кода все через опу?
В(етеран труда): Ну, это потому, что чувак (которого вышибли после этого) решил, что он точно знает как.
Р: а почему у нас 5 языков программирования используется?
В: сначала мы из овна и палок сделали продукт А, а потом пришли ребята и сделали продукт Б на новых технологиях
Р: а чо это за репозиторий?
В: Ну, некоторое время назад одна из наших предыдущих команд решила переписать всю систему. С тех пор они уволились. Теперь никто больше не знает, как использовать этот проект. Поэтому мы отказались от него, он просто есть.
И приходит белый зверек. Оп, и не пригодна архитектура твоего решения под новые реалии, оп, и структуры данных и подходы к работе с ними не подходят, оп, и оказывается, что команды перестают мочь договариваться, что приводит к очаровательным сбоям вида "мы тут новую апиху запилили". А самое главное - рули не успевают договариваться и находить ответы на ключевые вопросы: по каким принципам мы запускаем новое и меняем старое? А что с технологиями? А кто принимает решения? А бизнес-процессы? А риски? А что делать, если что-то идет не так?
И очень быстро (sic!) становится понятно, что таки нужна стратегия, которая инкапсулирует большую часть ответов на эти вопросы, тем самым снизит флуктации при изменениях внешнего мира: архитектура систем должна уметь эволюционировать, и это не только микросервисы в кубернетисах, данные должны быть сложены так, чтобы их можно было переложить на время и поддержать изменения в внешнем мире, процессы должны быть гибкими и прочными одновременно, должна быть синхронность с бизнесом. И все это вчера. И для всех. Иначе не полетит. Уже не летит, если сравнить затраты на создание чего-то с результатами.
Закон Конвея звучит в вольном переводе так: Любая организация, которая проектирует систему (в широком смысле), создаст проект, структура которого будет копией коммуникационной структуры организации.
Фишка его в том, что он действует (привет тем, кто считает иначе), но с точки зрения бизнеса имеет один важный изъян - не адаптирован к изменениям. Люди в компаниях меняются. Организационные структуры меняются. Команды меняются. Культура меняется. Бизнес-цели меняются. Коммуникации меняются. Но производство не останавливается. Спроектированные в "прошлой жизни" системы становятся дико неудобными в разработке, нестабильными и с кучей накладных расходов. Компании массово меняются с бешеной скоростью и в произвольных направлениях. Плюс к этому в нагрзуку - текучка и аджайл головного мозга у лиц, принимающих решения.
Можно бесконечно спорить на эту тему, но у рулей на всех уровнях, а не только у бизнеса, должен быть опорный план на случай изменений, например, в виде стратегии. В том числе и по причине его отсутствия конторы любят переписывать свой софт раз в пару лет. Новые менеджеры (эффективные по большей части) спать не могут без реформ. В отсутствии стратегии через пару лет в компании люди сменятся, а вместе с ними уйдет первоначальный замысел - т.е. некоторая стратегия, которую коллеги сочинили и следовали ей, пока колбасили продукт. Соответственно, если ее нет в бумажном виде - спасут только ветераны, которые смогут как в примере ниже отвечать на вопросы вида "какого хрена так, а не по другому". И в итоге часто всей лавкой втыкаемся в состояние, когда вообще непонятно, как и куда сделать следующий шаг. И в этот момент возникает мысль переписать все к такой-то матери и сделать нормально. Машина запускается заново. Такая же история происходит на всех этажах. Хороший бизнес планирует себя на много лет вперед. Все крупные конторы имеют "план 2030-2040", понятно, что он очень условный и сто раз изменится, но из того, что я видел, при изменениях меняется и этот документ. Таким образом конторы поддерживают свой вектор развития и осуществляют преемственность лидеров. На местах же все не так круто.
Р(азработчик): почему в этом куске кода все через опу?
В(етеран труда): Ну, это потому, что чувак (которого вышибли после этого) решил, что он точно знает как.
Р: а почему у нас 5 языков программирования используется?
В: сначала мы из овна и палок сделали продукт А, а потом пришли ребята и сделали продукт Б на новых технологиях
Р: а чо это за репозиторий?
В: Ну, некоторое время назад одна из наших предыдущих команд решила переписать всю систему. С тех пор они уволились. Теперь никто больше не знает, как использовать этот проект. Поэтому мы отказались от него, он просто есть.
И приходит белый зверек. Оп, и не пригодна архитектура твоего решения под новые реалии, оп, и структуры данных и подходы к работе с ними не подходят, оп, и оказывается, что команды перестают мочь договариваться, что приводит к очаровательным сбоям вида "мы тут новую апиху запилили". А самое главное - рули не успевают договариваться и находить ответы на ключевые вопросы: по каким принципам мы запускаем новое и меняем старое? А что с технологиями? А кто принимает решения? А бизнес-процессы? А риски? А что делать, если что-то идет не так?
И очень быстро (sic!) становится понятно, что таки нужна стратегия, которая инкапсулирует большую часть ответов на эти вопросы, тем самым снизит флуктации при изменениях внешнего мира: архитектура систем должна уметь эволюционировать, и это не только микросервисы в кубернетисах, данные должны быть сложены так, чтобы их можно было переложить на время и поддержать изменения в внешнем мире, процессы должны быть гибкими и прочными одновременно, должна быть синхронность с бизнесом. И все это вчера. И для всех. Иначе не полетит. Уже не летит, если сравнить затраты на создание чего-то с результатами.