Сегодня было интересно — начинаем процессные изменения в Российском ИТ подразделении одного из международных банков.

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

Вообще, выстраивание партнерских отношений разработки и бизнеса — один из ключевых трендов последних пары лет. Процессы процессами, но ориентация всех участников разработки на быстрое и качественное создание бизнес-ценности (business value) выглядит как очередное «допонимание» Agile-манифеста (это в России; понятно, что на западе тренд начался уже лет 6-7 назад с появлением leankanban сообщества). Но об этом напишу отдельный пост, чтобы сейчас не отвлекаться :)

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

Первое решение было быстрым и единогласным — конечно, снизу! Ведь наша цель — улучшить взаимодействие команды разработки и бизнеса. А менеджеры (руководители управлений и отделов) — это конечно тоже важно, но не в первую очередь.

На самом деле, мы (в ScrumTrek) несколько раз пробовали действительно начинать «улучшения снизу», выстраивая более прозрачный процесс в команде разработки. И это работало. Нет так, чтобы на 100%, но первые улучшения были видны для руководства буквально через пару недель — доска задач, понятно кто что делает, есть демо и тп. Вроде бы хорошо.

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

У Хенрика Книберга есть даже такая поговорка:

Корпоративная культура ест процессы на завтрак.

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

Поэтому, моей основной задачей было показать, что необходимо начинать изменения как минимум параллельно — не оставляя без внимания руководителей управлений.

Очень помогла сильно упрощенная версия упражнения Future Backwards от Дейва Сноудена, который на прошлой неделе проводил свой тренинг в Москве по Sense-Making.

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

Самое интересное, что коллеги, начав с событий внутри команды разработки, сами в итоге добрались до двух ключевых, исходных событий:

• Руководители должны сами использовать и «транслировать вниз» такой стиль общения с бизнесом
• А для этого — Руководители должны сами понимать, почему это важно и что это означает на практике!

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

И тогда можно менять самое сложное, что есть в компании (особенно в банке) — корпоративную культуру, которая складывалась десятилетиями.

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