Под редакцией Натальи Владимировны Литвак
Давным-давно, в начале своей карьеры, в одной из фидошных рассылок столкнулся с законом Конвэя:
«Организации проектируют системы, которые копируют структуру коммуникаций в этой организации»
"Прикольная фраза, типа закона Мёрфи или что-то подобное" - подумал я. Но спустя пятнадцать лет и десяток крупных компаний понял, как работает закон Конвэя в реальной жизни.
Предисловие
Последние лет 7 меня приглашают на проекты в крупный enterprise, которым откровенно хана. Уперлись в производительность. Остановились поставки. Завалили отправлениями аэропорты, да так, что из под посылок не достать гробы, которые люди для захоронения самолетом отправляли.
Почему в какой-то момент ИТ перестает эффективно работать? Почему стоимость разработки и сроки устремляются в небо?
Ответ на эти вопросы разберем в следующих публикациях. В этой статье хотелось бы поговорить о корневых причинах, которые приводят к созданию велосипедов и монолитов, всего того, что не позволяет реализовывать задачи в адекватные сроки и за адекватные деньги.
Оговорюсь. Все, о чем я буду писать в цикле статей по закону Конвэя, прежде всего справедливо для очень крупных организаций, у которых штат ИТ-инженеров, задействованных в разработке, начинается от 1000 человек.
Что происходит?
Итак, прихожу в организацию и что я вижу? Начнем с графика стоимости разработки.
Выше график со стоимостью "эксплуатации" программного обеспечения. Под эксплуатацией следует понимать стоимость каждого изменения, которое включает в себя проектирование этого изменения, разработку, тестирование и последующее владение данной системой. Это же справедливо и в части ИТ-ландшафта, когда изменения происходят внутри ИТ-экосистемы крупного предприятия, состоящей из сотни информационных систем.
Очевидно, любое следующее изменение будет стоить не дешевле предыдущего. При этом с каждой следующей итерацией изменений приходится учитывать весь набор знаний для проектирования нового изменения. Чем больше знаний - тем больше времени нам нужно для нового изменяя. Это же касается кода программы, тестов, кейсов в эксплуатации.
Абстрактный пример. Эту часть можно пропустить .
Итак, к нам, разработчикам, приходит бизнес с какой-то задачей. Задача уже обсчитана эффектом, защищена у руководство - нате, родной ИТ, делайте.
Вот мы сели, прикинули, что задача затрагивает N-систем, что происходит дальше в 90 % случаев?
Какой-то абстрактный архитектор, которым может выступать аналитик, разработчик или кто угодно, проектирует решение, это может быть сильно по разному и анти-паттернах проектирования поговорим в другой статье, может хоть на словах со всеми договориться. Но самое главное, что тратит он на это 10х человеко-дней/недель/месяцев. Так как люди слабы, конечное решение презентуется заказчику только в виде условной оценки по трудозатратам, без демо процессов и всякого такого. Ну и поехали задачи в разработку.
Дальше выясняется следующее:
⦁ В команде разработки одной из систем свой бэклог задач, с выставленными приоритетами от бизнес-заказчика, и задача будет сделана через год.
⦁ Другая система работает не так, как представлял себе архитектор.
⦁ В общей архитектуре живет система-монолит, которую мы 10 лет назад написали, и она, вроде бы, работает. При этом изменение в ней могут провести только специалисты, знающие Delphi или Saybase. А таковых у нас только 10 человек на 1000 разработчиков.
⦁ Система-монолит стоит в центре всех бизнес-процессов. Например, это биллинг в телекоме.
⦁ По традиции отсутствует документирование кода. Ведь до сих пор некоторые ИТ-специалисты уверены, что лучшая документация это код!
В результате мы получаем следующее:
⦁ В процессе декомпозиции на уровне команды выясняется, что проще сделать не так как нарисовал "архитектор".
⦁ Для реализации задачи требуется изменение глобальной модели данных.
⦁ Изменения затрагивают больше систем, чем мы предполагали.
⦁ Как вариант, потребуется разработать новый сервис, а для этого нужна команда.
По уму, надо бы перепроектировать решение, но архитектор занят уже другой задачей и столько времени он потратил на эту, включается паттерн "Cover Your Assets".
А сроки поджимают и бизнес требует- плевать, на coupling, делаем хоть как, не будем думать, что нас ждут завтра - надо сделать..
В итоге, мы получаем рабочий функционал, НО: увеличили связанность, создали новые агрегаты данных, дублирующие существующие. Ну и как итог: следующие изменения у нас будут стоить гораздо дороже предыдущих.
И так происходит почти везде.
Что мы имеем, плохого?
- Монолиты. Не важно, просто это монолитная система или макаронный монстр в виде распределенного монолита. Система, изменения в которой неявно затрагивает все или большую часть ее функциональных модулей.
- Bottle neck - системы, которые участвуют в большинстве бизнес-процессов и часто не приносят конечную бизнес-ценность. Ими могут выступать корпоративные шины данных (ESB), BPMN системы, (противником которых я являюсь))), корпоративный API. Бывают и вырожденные случаи. Когда бутылочным горлышком могут являться системы корпоративной отчетности и корпоративные хранилища данных. Один раз видел, когда такой системой была система проектного управления, но об этом даже вспоминать не хочется.
- Команды с приоритетом от одного заказчика. Например, фронтовая система магазинов подчиняется дирекции розничной торговли и для такой команды всегда приоритетом будут задачи этой дирекции. При чем, часто это происходит не явно, баги ретейла будут приоритетнее багов в функционале от других заказчиков. Кто платит деньги тот и главный!
- Неактуальные требования и разрозненный язык их описания. Часто команды вообще пренебрегают требованиями и их фиксацией, они же знают, как их продукт работает. Зачем им тратить время на их фиксацию? Лучшая документация — это код? Нет! В конечном итоге это приведет к Cover Your Assets… в лучшем случае. В худшем мы узнаем, что все работает не так в финале разработки. Нам крупно повезет, если это выяснится на этапе E2E тестирования а не в проде.
- Транзит ответственности только на уровне команды. Здесь речь идет о том, что за конечный результат изменений в ИТ-ландшафте никто не отвечает. Заказчик поставил задачу и ждет результата. Архитектор нарисовал решение и уже занят другой задачей. Проектные менеджеры (если такие есть, а лучше б не было), видят задачи только в MS Project. Команды предоставлены сами себе, о результатах своей работы они узнают только перед релизом. Про транзит ответственности можно написать отдельную статью и я это сделаю.
- Отсутствие оценки результата. Нам же быстро надо? Очень мало компаний, для которых частью DOD по реализованной фиче являются метрики этой фичи. В лучшем случае, это будут деньги. Да и те будут считаться через месяц, квартал, а то и год. В итоге, команды ориентированы на выпуск функционала, а не на его развитие относительно эффекта, это интересно, в лучшем случае, заказчику.
- Эксплуатация по книжке. У нас есть первая линия, вторая линия поддержки, команда. Обращения появляются - мы их решаем, становится больше - заводим баг, еще больше - нанимаем больше. Что еще нужно? То, что развитие взаимодействия пользователей влияет на метрики, то, что инструменты поддержки, документирование, хинты и всякое такое снижает нагрузку на команду, то, что обратная связь - это еще один источник задач для команды, задумывается очень мало людей. Особенно, когда у этих людей много денег и они их получат при любом раскладе.
- Резюме-дривин девелопмент. А чего бы нам не затащить чего-нибудь этакого в проект? Ну там Kafka или Casandra в проект? Пофиг сколько будет стоить изменения в системе завтра или через год, сколько будет стоить инфра и эксплуатация всего этого, за то в резюме я напишу, что знаю эту технологию и потом заработаю миллионов тысячи у другого работодателя. Это происходит не только в энтерпрайзе, консультировал один молодой каршеринг, где между тремя сервисами на PHP крутилась Kafk'a - ну это же корпоративный стандарт и вообще круто..
- Уникальный стек. Тут даже комментировать нечего. Был случай, когда ребята решили решение свое написать на Go и выбор они этот сделали "патамушта Nats прикольный", а то, что сам Go прост только на первый взгляд, подумать было не когда, надо было писать код. Спустя год проект успешно начал разваливаться и что же потом было делать с десятком недоделанных Go разработчиков в компании, где 80% бэкенда на Java?
- Уникальные компетенции. Появляются люди, которые знают какую-то часть бизнеса или системы от и до. И знания эти у них в голове. И вроде заменять их не надо, но у них есть свой капасити и своя значимость. Заменять их вроде и не надо, но подходить к ним нужно на задних лапах и только когда у них есть время. А еще бывает, что они увольняются или как было недавно у меня, умерают..
- Интеграционные релизы. Та история, когда весь функционал должен попасть в прод в один момент. В связи с предыдущими пунктами, часто встречается история, когда одна команда сделала сейчас, а вторая через пол года и функционал первой команды надо переделывать, так как говнари из первой команды в консистентном состоянии уже пол года как реализованный функционал не поддерживали.
Большая часть проблем, описанных в пунктах выше, не является в полной мере следствием действия закона Конвэя, но косвенно усугубляется в следствии его аффектов.
Ну и большинство коллег считают, что и есть enterprise, живем так - нечего не поделать..
При чем тут закон Конвэя?
Структура организации и центров ответственности формирует все те проблемы которые я описал выше.
Колодцы. Цели. Мотивация.
В 100 % крупных устоявш
ихся компаний структура и организация ИТ повторяла структуру бизнес-юнитов организации. Есть розница - вот системы и команды розницы, тут у нас корпоративный бизнес - тут у нас же и команды корпов. Тут же и единое руководство бизнес-юнита(колодца), начальник отдела курьерских систем, к примеру.
Колодцы, вертикали или стаканы, как их еще называют, часто изолированы внутри крупной компании не только целями и организационной структурой, но на уровне бюджетов, коммуникаций, да и амбиций менеджмента, в конечном счете.
Часто Колодцы диктуют большую часть правил игры, от того как ведется бизнес, как учитываются и измеряются результаты, что является целью Колодца - так ставятся и оформляются требования, приоритеты в бэклоге, так определяются приемлемые сроки разработки, так формируется бюджет, в конце концов, на ИТ.
Чем крупнее колодец, тем более обособленный мир складывается внутри подчиненного ИТ: складывается свои искаженные требования к архитектуре, учету требований, используется свой стек, свой CI, свои стенды, свои фреймворки тестирования.
И вот колодец большой, ИТ тоже большой и как же разработать с ним крупные изменения? Сколько придется майнить знания о их системе, как вклиниться к ним в бэклог?
Зачем нам много систем и команд, давайте сделаем одну - ей же проще управлять и все в одном месте? Глупо звучит, но органически так и происходит. Мне проще переиспользовать разработчика в большой системе чем перекидывать его с системы на систему. Тоже глупо?
Другая сторона - это история про маленькие сервисные команды, ну например, мы маршрутизатор для логистики, курьеров, мерчандайзеров пилим. И ценность не приносим и владельца у нас бизнесового нет. В таком случае, "большие" приходят и конкурируют за твой бэклог, при чем часто с позиции силы. Приходят они со своим форматом требований, не зная, может быть до конца, как работает твоя система и вроде пришли к тебе, а тебе приходится майнить их процессы и их архитектуру, перекраивать бэклог посреди спринта, подстраиваться под их релизы и в итоге: растягивать релизы и жить в стрессе.
Третья сторона - большие инфраструктурные системы и платформы. Тут тоже закон Конвэя влияет в полный рост, платформы становятся точкой, где сходятся разнородные коммуникации, цели, мотивация, подходы и так далее. Например, к таким системам можно отнести ESB, банковские ABS или DWH. Часто приходится видеть, что они органически принимают хаос и разножопицу в процессах вокруг и формируют свои стандарты работы(разработки), в силу необходимости соблюдения хоть каких-то сроков. Их паттерны и подходы становятся тяжеловесными, накладывая огромный налог на разработку в других командах.
Еще одна история - сервис в виде ИТ для ИТ или ИТ для бухгалтерии, как хотите это называйте. Какая разница, сколько сотрудник будет оформлять командировку или заказывать себе доступы, главное - выполнить задачу бизнес заказчика, не увеличить штат с бюджетом. То, что компания теряет на непрофильной активности разраба - какая разница.
При этом, причины, указанные выше, отрывают команды от "не их фичей" - размывая мотивацию на сопровождение результата разработки и его развития. Фичи не нашего заказчика - не наши фичи, следите за ними сами. Так же происходит разрыв и между сервисными процессами, такими как инфра и поддержка, их сложно менять - они принадлежат всем. И тут сервисные процессы выходят за границы разработки в Колодце, это просто что-то существующее за пределами команды и принимаемое как должное.
Что мы имеем? Бизнес-метрики для нас важны только в части своих фичей. Наши цели-не наши цели, а бизнеса и мы - команда разработки, а не часть домена приносящего деньги. Происходит искажение мотивации - нужно разработать и отчитаться, а не развивать и улучшать.
Но Колодец живет среди других колодцев и рано или поздно аффекты от такого подхода ведут к колоссальному росту цены изменений в системах и Ландшафте. Перекрасить кнопку мы можем, а завести новый продукт в компании - нет. Почему? Потому, что ценность этого продукта должна быть или донесена до всех Колодцев или быть продавлена через самого главного начальника. И пока мотивация не вынесена в вершину пирамиды целей в компании будет именно так.
А дальше, история про свои стандарты, свои подходы, свой техстек ведут к интеграционным релизам - тот момент, когда нам надо собрать десяток систем в один релиз, наверное как-то протестировать и в одной точке запустить. Учитывая расколбас с приоритетами в бэклогах интеграционные релизы могут стать крайне дорогими процессе разработки, отвлекающими много ресурсов, приводящих к новым итерациям разработки, ломая бэклоги и снижая качество.
С проблематикой, кажется определились. Продолжим в следующих заметках:
- Как организационно бороться с аффектами закона Конвэя
- Стандартизация, транзит ответственности и инженерный подход к разработке.
- Архитектура как код, как это работает в enterpris'e
- Корпоративный архитектор здорового человека, или как пришить инвалиду руки.