Запуск процессов изменений

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

🔸 Первый - «по классике», по сценарию сверху вниз, когда высшее руководство видит итоговую цель внедрения. Руководство само, либо с помощью бизнес-аналитика раскладывает все по полочкам и спускает по нисходящей на подчинённые структуры.

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

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

Во втором сценарии в каждом уютном уголке компании идут независимые процессы улучшений. Устанавливаются свои процессы, внедряются свои инструменты и методы работы. Такой зоопарк тяжёл для систематизации и понимания занятого руководства. Оно как правило туда и не погружается, и не заимствует лучшие практики к себе, на уровень выше, не интегрирует положительные эффекты. Процесс проталкивания наверх средним менеджерским звеном слишком энергозатратный и встречает кучу сопротивлений: «Вы не первый с предложениями. Это уже не актуально для нас. Это не даст эффекта сейчас…» Но необходимые процессы внедряются независимо от формального согласования. В результате получается разрозненная компания с невнятным управлением, с сильной зависимостью от конкретных менеджеров подразделений, с непростой миграцией сотрудников внутри структур, и с зашаренными знаниями.

И тот и другой изолированный вариант ущербны. Совмещенный подход с учётом обоих направлений движения является разумным вариантом, который учитывает интересы всех сторон.

В течение многих лет я являлся сторонником KPI систем. Далеко не везде удавалось внедрить их изнутри организации и адаптировать все процессы. Тем более тяжело довести внедрение до стабильной стадии решив все противоречия и сопротивления. В последнее время интересуюсь и экспериментирую с OKR. Эта система более адаптивна к частым изменениям и более интересна для продуктовой разработки. Она хорошо дружит с обоими описанными сценариями. Заметил, что и внедрение этой системы проходит проще.

@aheadofthepack