В прошлой статье коротко разобрал, влияние закона Конвэя на разработку и её качество внутри компании, конкретно, как организационная структура влияет на качество ИТ и какие аффекты могут быть.
Здесь давайте разберем две темы:
- Какие антипаттерны бывают в борьбе добра против закона Конвэя.
- Какие есть удачные примеры и паттерны перестроения организации для повышения эффективности ИТ.
Вот перечитал я эти пункты и подумал, что если бы лет пять -семь назад задвинул такое про ИТ и перестроение организации, на меня бы как на больного посмотрели, в лучшем случае, теперь же, огромная часть любого бизнеса (если не вся) - это ИТ-решения. И в условиях конкурентной среды, кто первый выкатил продукт, тот и победитель.
Вспоминается случай из консалтинговой практики, когда один очень удачный стартап реализовал некое приложение с картами и запилил Proof of concept системы оплаты с мобильного, пока стейкхолдеры воевали между собой (а это продолжалось больше года), вышли apple pay и samsung pay. Конечно, наши соотечественники не заняли бы значимую долю рынка, но заняли бы. Но получилось, что получилось.
Disclaimer:
Я не являюсь гуру в административной работе, Agile, проектном управлении или организационной трансформации. Мне ближе техническая часть дела и продуктовая разработка. По этому, все, что будет описано в статье, мое, местами, поверхностное мнение основанное не на изучении вопроса, а на моей, хотя и обширной, практике.
Еще раз о проблематике.
Итак, закон Конвэя диктует нам неизбежное влияние организационной структуры на процессы связанные с ИТ в компании.
Коротко повторю не о причинах, а о проблемах, которые лежат на поверхности:
- "Не оптимальный" ИТ-ландшафт, затрудняющий внесение изменений: монолиты, бутылочные горлышки, уникальные компетенции, велосепеды.
- Конкурирование в бэклоге.
- Неоднородное качество.
- Низкая скорость поставки (как TTM, так и Lead time).
Какие шаги неудачные можно предпринять?
Перед тем, как начать рассказывать о анти-паттернах, хотелось бы сделать акцент на очень важной вещи.
Любая активность, любой новый сотрудник, любое новое рабочее место со стулом и компьютером - это деньги компании, которые можно было бы потратить не на эти активности, сотрудника или стул.
Завести проектное управление.
На одной из недавних конференций подошел ко мне СТО одного не маленького интернет-магазинов, по совместительству являющегося сетью магазинов питания. И рассказал вот какую историю:
ИТ начали как стартап, создали монолит вокруг учетной системы, на тот момент была только сеть магазинов, потом появилось производство, потом интернет-магазин с доставкой, появилась партнерская сеть. А система так и осталась, считай, что монолитом. Пришли к тому, что разработка может одновременно тянуть всего несколько задач, да и те делаются по пол года.
-Как собираетесь с этим бороться, спросил я
-Хотим запилить проектное управление, ответил СТО
-Зачем?
-Ну мы сейчас не знаем когда будет сделана наша задача, а хотим знать. Хотим, чтобы кто-то следил за процессом, работал с командами, оценивал задачи, работал с приоритетами.......
-Хорошо, у вас получится, вы увидите буст на горизонте 2-6 месяцев, а потом станет хуже. И еще, а почему сами команды с бизнесом не могут это делать?
Ответа не нашлось и дальше мы обсуждали то, что написано далее.
По моей версии реальности, проектное управление в ИТ - это некий форк от инженерных процессов, который структурирует обязательные шаги, в процессе достижения результата. При этом само проектное управление, по своей сути, не является сугубо административным, но не инженерным процессом.
Фактически, внедряя проектное управление, мы внедряем процесс рядом с производством ИТ решений, который по своей сути является методологией кнута, а не мотивации.
Конечно, можно сказать: мы же платим проектные премии, все такое, но это не такое - это другое.
В прошлой статье, я пытался раскрыть причины появления большого количества проблем, если очень сильно высушить все написанное: это сепарированность целей и отсутствие мотивации к непрерывному улучшению. И в данном случае, чем мотивирован сотрудник, выполняющий проектную задачу, пусть пришедшую от другого продукта или не его стейк-холдера - выполнить задачу в кротчайший срок. Не сделать ее лучше, а именно закрыть задачу.
Буду честен - любой процесс, который мотивирует к производительности, но не мотивирует к качеству и вовлеченности, вызывает подозрение.
На самом деле, как писал в примере выше, действительно, при определенных обстоятельствах, проектное управление даст буст, но буст этот будет весьма ограниченным по времени, хотя и достаточным, чтобы к присутствию ПМ'ов привыкли )), а в случае более-менее адекватных ПМ'ов, сделает процесс относительно прозрачным.
Самое прикольное, что всплывает при наличии централизованного проектного управления - это интеграционные релизы. Не везде, но крайне часто видел такое.
Есть еще один пример.
Жила была одна ооочень крупная транспортная компания. Был себе ИТ такой себе - как у всех. Монолит, вендор-лок, водопады тут и там.
В какой-то момент, решила транспортная компания, что скорость и качество поставки их не устраивает. Сделали развитое проектное управление. Стало необходимо защищать инициативы, готовить кипы документов, выбивать бюджеты.
Что же стало хорошего?
-Начали очень странно, но таки скориться задачи и это хорошо, если бизнес сам не может, то и так - норм.
-Стали прозрачными сроки.
-Стала понятна утилизация ресурсов.
Но при этом:
-Раньше пол года шла разработка, теперь пол года можно ждать своей очереди на валидацию фичи.
-Проектный офис разделил бизнес-проектирование и разработку, фактически разделив цели в компетенциях производственного процесса. Бизнес аналитик перестал отвечать за конечный результат
-Появилось 50+ новых сотрудников
-Монолит как был, так и остался, хотя компания выросла раз в пять - мотивации развивать ландшафт взяться было не от куда.
-Теперь скорость поставки вообще улетела в небеса..
Ну и компания решила пойти по пути следующего антипаттерна.
Нанять корпоративного архитектора.
Паттерн условно негативный, у меня в практике есть пара примеров, когда организация корпоративной архитектуры приносили достаточно мощные положительные результаты.
Тема про корпоративную архитектуру, какая она должна или не должна быть в компании, тема для отдельной статьи и здесь многое, пожалуй пропущу.
Причины появления корпоративных архитекторов в домене разработки я видел всего пару. И самая частая из них - неожиданное понимание о несовершенстве ИТ, проблемы в инфре, узкое место в виде системы-монолита, вендор-лок, низкая скорость поставки и такое всякое.
И естественное желание - найти убер-специалиста, который мог обозреть а-ля hellecoper view на ИТ-ландшафт, техстек и сказать как делать правильно, консультировать разработку, проверять решения на соответствие стратегии и вообще, беречь ИТ от неверных решений.
И тут есть некоторое количество проблем, которые не ведут к успеху:
- Решение принято руководством, сотрудник ставится на руководящую роль и выполняет поставленные руководством задачи. Он мотивирован на их исполнение. И тут может случиться разрыв, когда цели развития продуктов входят в конфликт с виденьем корпоративной архитектуры, которая, в свою очередь, обусловлена целями корпоративной архитектуры.
- Как-то мы привыкли на роль корпоративного архитектора смотреть по западным лекалам, DOR, чтобы быть корпом- это знание какого-то фреймворка оканчивающегося на AF (например TOGAF), проектирования в верхних 2-3х слоях архитектуры и обязательно в archimate и IDFE0, формирование метамоделей, правильные ритуалы и так далее. Проблема в том, что использование таких фреймворков возможна только при определенном уровне зрелости ИТ в компании. Если архитектуры нет в командах, то и корпоративная архитектура не приведет к появлению транзита ответственности и пользу, в целом, не принесет. Это усугубляется и тем, что такие нотации как archimate, а особенно на верхних слоях, подразумевают максимально размытый контекст, с точки зрения реализации изменений в конкретных информационных системах.
- Корпоративная архитектура - это дорого и нанять одного человека, к сожалению не достаточно. Чтобы эффективно управлять корпоративной архитектурой, необходимо перенести в домен корпоративной архитектуры, например, проектирование изменений бизнес-архитектуры. А для этого нужен штат дорогостоящих, а иногда и редких сотрудников. В итоге, часто бывает так: купили пару архитекторов, а дальше все - денег нет и функции корпов начинают резаться до согласования или консультирования.
- В Корп. архитекторы, как это не удивительно, ооочень часто у нас попадают люди, которые никогда разработкой не занимались. Почти всегда, такие люде не понимают, как проектируемые ими решения будут реализовываться в коде, насколько это трудоемко. Кроме того, у таких людей есть проблемы в понимании и с системной архитектуры. Еще хуже, когда внедряемые процессы корп. архитекторы идут в разрез с целями быстрого создания качественного кода.
Хотя бывает по разному.
Был у меня опыт консалтинга в одном маркетплейсе из топ-3 в России.
Сложилась там сложная ситуация, обусловленная клубком проблем в управлении разработкой и бизнесом. Выражалось это в фактическом отсутствии бэклога и постоянной переприоритеиацией задач появления новых и так далее. Здесь тоже можно было бы сделать акцент на законе Конвэя: несмотря на обилие бизнес-направлений и абсолютно разнонаправленные метрики, в компании сложилась жесткая иерархическая структура, состоящая, фактически, из одного юнита, под руководством генерального директора. Все это вылилось в то, что документирования, процессов, проектирования, фактически не было.
Ну оно и правильно, в условиях настолько жесткой валатильности наличие не актуальной документации(архитектуры) хуже, чем ее отсутствие.
Логичен финал, через некоторое время, поставка начала замедлятся, пока почти полностью не остановилась.
В этот момент, в компании сменилось руководство и вместе с ним был нанят корпоративный архитектор здорового человека - мой друг(хотел бы так считать )) Андрей, с которым мы работали в Азии.
Меньше чем за пол года, Андрей не только перепроектировал весь ландшафт, но и поставил процесс architecture as a code - создал пайплайн разработки, включающий проектирование и жизнь архитектуры, фактически, в коде. С его подачи были введены DORA-метрики и много других практик.
Как итог: поставка возобновилась и через те же пол года вышла на темпы сильно превышающие темпы в лучшие времена до того.
Почему так произошло? Кроме менеджмента, который таки разбил структуру на бизнес-юниты со своими целями и KPI. Андрей перестроил подход к разработке, поставив во главу угла трансформацию архитектуры. Почему ему это удалось? Как мне кажется или как бы мне хотелось чтобы оно было на самом деле, ставя во главу угла вынос точки принятия решения на этап проектирования, системную архитектуру и архитектуру вообще в виде не тормозящем, а помогающем разработке, взял на себя ответственность, разработал целостные процессы и решения. Продал их руководству и командам.
Картинно трансформироваться.
Больше всего раздражают незаконченные дела.
Очень много примеров, в том числе и удачных, когда в результате понимания проблем в целеполагании, коммуникациях, ответственности, компании начинают разного рода трансформации.
Тренд этой пятилетки - переход организационной структуры к правилам гибких методологий на основе AGILE-принципов. Хотя есть и другие варианты))
Я утрирую (смотреть дисклеймер), цель - создать условия для повышения скорости разработки и вывода продуктов/фич на рынок через создание организационных и административных условий для максимальной декомпозиции ценности поставляемой компанией, ее бизнес юнитами и конкретными сотрудниками.
И в стремлении к трансформации нечего плохого нет - только хорошее. Но вот примеров оконченной трансформации я видел не много.
Часто или почти всегда, идеологи трансформации руководствуются идеями и принципами: формируя образ конечного результата не на основе целей и метрик, а на базе виденья идеального мира пони и фей в конце пути.
И это важно.
Не оцифровывая конечный результат, не формируя четкое его виденье в финале этапов, не декомпозируя на части, мы и получаем не то, на что рассчитывали.
Понятно, что Agile - про итерационное достижение целей, но эти цели как минимум должны быть определены.
За последние несколько лет более чем работоспособный вид приняли такие фреймворки как SAFe, Less, про такие фреймворки как Scrum и Kanban вообще не говорю, хотя последний, сука, неожиданно с приколами.
Что мешает взять книжку/статьи/практики, нанять аджайл-диванов и сделать все как написано? Видимо из-за нюансов.
И тут не буду разбирать обычные обычные штуки типа невовлеченности ТОП-менеджеров, взгляд на agile-трансформацию как на проект, неприятие Agile и так далее.
- Транзишн. Кажется, что эта та же история как и про цели трансформации, примерно понимаем как сделать - а как это будет в масштабе времени, не что, а как будут меняться процессы в компании - не понимаем. В результате, в той или иной части бизнеса, а чаще ИТ у нас начинает, что-то сбоить и фокус трансформации частично смещается на эти точки сбоев и их исправление.
- Компромиссы. А вот тут у нас особенные люди работают и с ними тяжело, а вот тут у нас vendor-lock и подрядчики нас за бубенцы держат, а тут вообще команда перегружена и ее выводим в исключения. Все это вкупе с не фиксируемыми целями, ведет к тому, что разные части компании имеют разную степень вовлеченности в процесс трансформации, что, в свою очередь, влечет появление "компромиссных" процессов и коммуникаций, не укладывающихся в методологию Agile-трансформации и не соответствующую духу и целям этой самой трансформацию.
- Проектное управление. Мы, как компания, уже один раз попадали в клинч с разработкой и кажется, что раньше как-то нам проектное управление помогло (смотреть первый раздел неудачных практик))). А давайте не будем трогать то, что работало, а трансформацию замутим рядом. Ну да, у нас есть матричная структура, но это сложно - думать о том, как проектное управление и гибкие м+етодологии(на уровне процессов компании) будут конкурировать между собой внутри команд разработки и бизнес-юнитов?
- Наличие бубенцов. И это, наверное, самое частое, с чем я сталкивался. Можно сказать, что это и про вовлеченность топов, но скорее нет. Речь о лидерах и ключевых участников трансформации. Как уже десяток раз писал про цели и мотивацию, часто происходит подмена. Надо отчитаться, а не сделать лучше. Когда видимость подменяет эффективность. Как абстрактный пример: весь год у нас, что-то сбоит, время поставки не то, что не снижается, а даже увеличивается, за то отчитываемся, что план трансформации выполняется, но есть разные не натуралы, которые делают все не правильно и их надо ай-ай-ай. А спустя год, приходит прозрение и при детальном разборе выясняется, что трансформаторы не брали на себя ответственность, не выдирали кишки из текущих процессов в ущерб себе, а просто зарабатывали деньги.
- Локальные трансформации. В целом так тоже бывает, когда отдельный юнит решает жить по новому. Но проблем в внешних коммуникациях, связанных с адаптацией процессов мира Agile к процессам компании прибавляется х10. Силы воли и мотивации нужно на порядок больше, чем при трансформации компании целиком.
- Вялая трансформация. Нужно помнить, что любой транзит от было к стало всегда приносит значительные затраты относительно целевого и базового состояний. Кроме того, в состоянии транзита, появляются накладные расходы на переход к новым процессам, материализующиеся в замедлении ТТМ и lead time. Чем дольше этот транзит - тем больше денег потратит на него компания. Так же, чем дольше у нас дистанция от начала трансформации до первых результатов, тем более размытой становится ценность трансформации. И вялой трансформацию делает целая куча антипаттернов и не правильных подходов, например: "а давайте всех убедим и они сами", "а давайте каждый лид будет отчитываться о том, как он трансформировался". Отсутствие метрик и автоматизированных инструментов их сбора, с большой долей вероятности начнет замыливать процесс, добавляя отрицательных аффектов.
- Хрупкая корпоративная культура. Это отдельная большая, тема. Часто бывает так, что корпоративная культура строится на основе ценностей иерархической организационной структуры и устоявшихся горизонтальных связей. И при трансформации эта культура начинает рушится и без какой-то существенной замены, эта ситуация существенно аффектит на коммуникации, приоритеты.
Много продолжать еще долго, но статья про тезисы, а не про детали.
В любом случае, трансформация - это хорошо, как и код, становящийся лучше через перманентный рефакторинг, так и оргнаизация становится эффективнее через непрерывные изменения.
Какие удачные шаги я видел?
Начнем с тезисов.
- Разбивка на малые бизнес-юниты по изолированной ценности, уравнивает, до какой-то степени, значимость задач в бэклогах.
- Объединение малых бизнес-юнитов и ИТ в композитные юниты, создает общую ценность внутри таких организационных единиц.
- Измеримые бизнес-метрики в виде KPI, должны рассчитываться автоматически и нести ценность для конкретных сотрудников команд.
- Любые действия делаются за деньги и прозрачно бюджетируются.
На этом наверное и все.
Теперь подробности.
Чем меньше бизнес-юнит, тем меньше у него административного веса, состав команд меньше и более контролируемый, с точки зрения бюджета и ресурсов. Что это дает?
- Меньше возможностей сопротивления стандартам компании.
- Выравнивание приоритетов в бэклогах.
- Необходимость в выравнивании правил коммуникаций, за счет увеличенного количества стейкхолдеров - постановщиков задач.
- Контролируемость процессов, за счет унификации и ограниченности бюджетов.
- Ориентированность на результат всей команды бизнеса и ИТ, за счет отсутствия сложной многоуровневой иерархии KPI.
Понятные правила игры.
Как уже упоминал ранее, чудо не случается, не могут люди пропитаться духом трансформации, а так же равенства и братства.
Для любой экосистемы, которой так же является крупная организация, нужны правила существования в этой экосистеме юнитов, их правила коммуникаций.
Соответственно, должны быть прозрачно определены правила игры:
- KPI и методика и инструмента их постановки и расчета.
- Правила формирования бэклога.
- Роли и компетенции должны быть определены и описаны.
- Определены события и ритуалы оркестрации процессов.
- Правила формирования бюджетов должны быть проверяемы, и понятны.
ну и еще всякое.
Оркестрация процессов и ответственность.
Ситуация, когда правила не выполняются или выполняются не всегда приводят к совершенно диким эффектам, например: особенно талантливые менеджеры, могут оперировать наличием или возможностью обхода правил в своих интересах, что ведет к появлению dark-process.
Очень хорошо, когда есть отдельная структура, ограниченная целями (KPI), но не инструментами и процессами, в обязанности которой входит оркестрация и контроль соблюдения процессов.
То, что я написал выше подразумевает не только контролируеще-карательную функцию, но и продуктовый подход к развитию процессов.
Работа за деньги.
История с бюджетированием и расчетом финансового эффекта крайне важна и я бы хотел посмотреть на нее, с точки зрения мотивации к эффективному формированию команд и приоритизации бэклога.
Модель бюджетирования и расчета финансовой эффективности изменений должна приводится в формат детальной оценки активностей бизнес-юнитов и их адекватности, любое действие должно быть оправдано. Невыполненное действие, должно сказываться на мотивацию бизнес-юнита и прежде всего, финансовую сотрудников.
Если мы сто-то делаем, то делать мы должны сугубо для получения прибыли.
Думаю, не стоит развивать эту тему, так как проходил мимо таких процессов всегда по касательной.
CSI - метрика удовлетворенности клиента.
Казалось бы, при чем тут внутренние коммуникации?
Забавный эффект дает введение метрики CSI для внутренних клиентов и собственных бизнес-юнитов. Когда сотрудник может оценить уровень внутреннего клиентского сервиса другого подразделения. Это не дает возможность адекватно оценить уровень открытости конкретного юнита. Но это дает базис для открытой дискуссии и визуализирует обратную связь. Так же, при наличии грамотного оркестратора, аналитика и информация вокруг CI дает возможность корректировать векторов тюнинга процессов.
В качестве резюме.
Возвращаясь к закону Конвэя и его влияние на ИТ, можно однозначно сказать, что организационные изменения удачные и не удачные, напрямую влияют на эффективность ИТ. Как и любые изменения, организационные изменения не могут проходить сами по себе, от понимания участниками процесса их ценности, у изменений должен быть лидер. И очень везет тем, у кого такие лидеры критически смотрят на процессы, оперируют не только своим бэклогом, но и чужим опытом, практиками, умеют всесторонне оценивать и оцифровывать процессы.
Написал и заплакал...
- Как организационно бороться с аффектами закона Конвэя
- Стандартизация, транзит ответственности и инженерный подход к разработке.
- Архитектура как код, как это работает в enterpris'e
- Корпоративный архитектор здорового человека, или как пришить инвалиду руки.
