Архитектурные причуды организационных форм разделения труда

Источник: vk

Архитектурные причуды организационных форм разделения труда

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

Повестка, конечно, со временем претерпевает изменения. Сегодня мы обсуждаем проблемы, порожденные продуктовой логикой разделения ИТ-команд и переходом на микросервисную архитектуру. Классическими сложностями, вокруг которых бурлит архитектурное сообщество, остаются вопросы (1) многократной параллельной разработки одного и того же функционала и (2) неконтролируемых расходов на разработку вспомогательных функций.

Типичная история выглядит следующим образом.

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

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

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

Во-первых, это собственные потребности IT-команды, порождаемые в процессе производства и сопровождения программ: функции логирования, мониторинга, механизмы репликации, хранения данных, оркестрации, обеспечения надежности, автоматизации развертывания и т.п.

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

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

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

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

Какие есть варианты разрешения этой проблемы?

Первый вариант — сосредоточить всю ответственность в руках бизнес-подразделения и включить все расходы в его бюджет. Но может ли бизнес адекватно оценивать расходы и нести ответственность за решения в областях, в которых у него ограниченная компетентность, только на основе рекомендаций или требований, выработанных подразделениями, которые за них ответственности не несут? Бизнесу придется собирать все эти компетенции и функции у себя внутри, но это приводит к росту затрат и падению качества их деятельности из-за потери экономии на эффекте масштаба и отрыву от профессиональной среды.

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

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

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

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

Но это требует, чтобы участники этих подразделений, во-первых, были способны мыслить на этом уровне, во-вторых, имели навык и стимул выходить за узкие рамки эгоистической или экспертной позиции, продиктованной их частными интересами и функциональной ролью. А это значит, требуются дополнительные расходы на поиск и развитие сотрудников, на построение процессов коммуникации между ними и на саму эту коммуникацию, а также отказа от простой и линейной привязки системы вознаграждения и продвижения руководителей к своим локальным KPI или PnL.

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

Но есть еще и технологическая.

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

Почему же команды пишут этот зоопарк велосипедов? Ведь есть много способов сэкономить затраченные на их разработку или даже сопровождение средства!

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

Второй вариант — заказать разработку такого продукта под конкретные нужды у внешней организации в собственной экосистеме, но разворачивать ее у себя и сопровождать самим.

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

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

• Во-первых, рациональность выделения такой команды появляется только на определенном масштабе.
• Во-вторых, возникает сложный вопрос о способе определения размеров финансирования такой команды и его соотнесения с поставленными перед командой задачами.
• В-третьих, у бизнес-подразделений возникает зависимость от этой команды, порождающая конкуренцию за ее ресурсы и ограничивающая свободу маневрирования приоритетами своих задач.
• Наконец, разработка общего сервиса, способного удовлетворить разнородные требования многих команд, выливается в производство высокоуниверсальных систем и разных no-code конструкторов, что порождает огромные накладные расходы на поддержание этой универсальности и ее освоение.

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

Брезжит ли свет надежды на выход из этого технологического тупика? Пожалуй, да, спасибо что мы живем в период расцвета когнитарного производства.

Как могло бы выглядеть "идеальное решение" указанной проблемы? Оно должно снимать противоречие, позволяя одновременно:

1. Открывать возможность пользоваться уже разработанным другими командами функционалом

2. Использовать собственные ресурсы команды для доработки решений согласно собственным приоритетам

3. Получать максимум выгоды от эффекта масштаба за счет шеринга объединенной инсталляции

4. Минимизировать расходы на непродуктивные процессы развертывания и сопровождения

И такое решение имеется: это совместная разработка по принципам открытого исходного кода в условиях полной автоматизации деплоя в виртуальной инфраструктуре.

Однако такое решение тоже не дается бесплатно. Оно, конечно, требует дополнительных расходов и на высококачественный DevOps, без которого такая система не работает.

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