agile-upravlenie_500

Agile трансформация

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

В первой итерации такие разночтения приводили к тому, что внедрение происходило в минимальном объеме. Появлялись «лаборатории» или группы команд, работающие по SCRUM. И они спустя некоторое время показывали неплохие результаты, что мотивировало на масштабирование. На помощь приходил опыт бирюзовых единорогов, и методологий типа LeSS. Часто, это сопровождалось поддержкой CEO/CIO. Что приводило к бессмысленному и беспощадному насаждению Agile повсюду. В командах, работающих в условиях неопределенности это «заходило», в командах, оттачивающих ключевые банковские системы, типа АБС, или платежные системы — начиналась чехарда с релизами, снижение качества, дорогие в решении архитектурные ошибки — и наступление светлого будущего останавливалось. Сторонники agile-трансформации объясняли это все закостенелостью в мозгах и преобладанием культуры контроля над культурой развития. Однако, даже обучение, пропаганда и идейные чистки не смогли в корне изменить ситуацию.

В конце концов, менеджеры, opinion leaders и приглашенные коучи согласились что возможен различный подход, в зависимости от того продукта, который команда развивает. Вроде бы вполне очевидный вывод, но было потрачены миллионы, боюсь, не рублей, и несколько лет на каждую итерацию «трансформаций».

Вдвойне обидно ведь Дэвид Сноуден (другой Дэвид, не тот которого вы знаете из новостей) еще в 1999 году опубликовал свою теорию сложности систем (Cynefin, в транскрипции с валлийского — Кеневин), в которой описал 4 степени сложности, и в зависимости от принадлежности к одной из них, пригодны разные алгоритмы действий, и соответственно, разные схемы управления. Подробнее о фреймворке Cynefin вы можете прочитать здесь.

Если примерить эту концепцию на крупную организацию, в ней в разных пропорциях существуют несколько состояний сложности. А иногда — все 4 разом. Поэтому невозможно внедрить систему управления пригодную для всех подразделений. Бухгалтерия живет в очевидном мире, сервисные функции — в процессном, а разработка и продажи — в сложном, R&D и вовсе — в хаотическом. Как тут возможно применить одинаковый ко всем подход? Нужно ли пытаться бухгалтерию ставить эксперименты? Конечно, нет. Самый здравый вывод, который сделал менеджмент банков совместно с приглашенными экспертами — дать некоторую степень свободы, и организовать продуктовые команды и их вспомогательные функции — в виде доменов, которые сочетаются друг с другом. Отсюда правда, следует что эти домены никогда нельзя будет сравнить, и оценить, т.к. нет общих единиц измерения. И представители банков подтвердили, что оценка по ЦФО / cost unit остается нерешённой задачей. В крупных мазках, конечно, затраты и прибыль каждого домена оценивается, но не учитываются косвенные затраты, взаимодействие внутри юнитов, и «мелочевка», которой слишком много чтобы учитывать финансистами. А что бывает с ведром статистики, если туда капнуть немного грязных данных? — правильно. Ведро грязи. Поэтому оценки экономической эффективности лишь индикативны.

Ранее я cформулировал подход универсальной сервисной архитектуры, которая, по идее, должна была решить вопрос оценки добавленной ценности и затрат каждым юнитом и доменом, однако, я не пробовал её примерить для сложных и хаотических систем. А ведь, становление любой компании начинается именно с этого. И может оставаться в стадии «сложных» довольно долго, если бизнес построен в инновационной сфере. Подходящий момент, чтобы это сделать…

Тэги: , ,

Еще нет комментариев

Добавить комментарий