Изменения в организации без бунтов и саботажа

Опыт построения системы непрерывных улучшений в отдельно взятой организации на протяжении 10 лет.

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

В статье расскажем, как и почему работает система непрерывного совершенствования у нас в инжиниринговой компании. Мы – это Uniscan Research. Мы делаем наукоёмкие приборы серийным продуктом.

Нас 60 человек, это достаточно много для ручного внесения изменений и управления. Управление в ручном режиме гарантировало результат, но не оставляло времени на развитие. В итоге мы решили потратить время и путём проб и ошибок создали систему непрерывных улучшений. Сегодняшний рассказ об этой системе.

Первое, с чем мы столкнулись – нужен не просто вектор или цель. Нужен ответ на вопрос «Зачем что-то вообще менять?». Улучшения ради улучшений не взлетели. Даже если речь про какие-нибудь новомодные управленческие практики, эффективность которых подтверждена половиной планеты. Если мы не можем коллегам ответить на вопрос, зачем именно нам это внедрять, то вполне ожидаемо получаем либо прокрастинацию, либо активное сопротивление.

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

Пример цели: увеличить выручку. Показала себя, как супер-абстрактная и не очень вдохновляющая разработчика. Хотите увеличить выручку – наймите больше продавцов, я-то тут при чём? Зачем мне что-то менять в своей работе? Такого рода цели нам никак не помогли.

Другой пример цели – запустить плюс одну продуктовую линейку. Такую цель усилиями одного отдела реализовать уже проблематично. Новую продуктовую линейку нужно и разработать, и организовать производство, и научиться продавать. Хоть из самой цели не понятно, как надо измениться, но каждому понятно, что изменить что-то придётся.

Плюс, в такой цели есть немного и вызова, и возможностей для профессиональной реализации. Такого рода цели нам помогли продвинуться дальше в процессе совершенствования.

Очень заманчиво скинуть цели в какую-то команду или каким-то начальникам и радоваться их реализации. У нас такой подход не сработал. За пару лет мы поняли, что нужна отдельная сущность, боевая единица — команда изменений. Директор или начальник должен быть частью этой команды. И эта команда не должна быть набором случайных начальников или сотрудников.

Ниже наш список требований, каждое из которых возникало в результате проб и ошибок.

1. В команде изменений должно быть достаточно полномочий, чтобы изменения проводить.

Довольно очевидный тезис, но он отрезает всякого рода «экспертов» со стороны. Полномочия выдаются вместе с ответственностью. А «эксперты» ни за что не отвечают и расхлёбывать последствия вместе с вами не будут. Подробно про этот феномен написал Н.Н. Талеб в своей книге “Шкура в игре”. Если знаний в команде маловато и без эксперта совсем никак, то его можно сделать подрядчиком, но никак не членом команды.

2. За реализацию целей должна отвечать вся команда, а не персоналии.

В компаниях, которые мы видели, зоны ответственности поделены между начальниками. Задачи по улучшениям в таком случае становятся «персональными»: если нужно что-то изменить у технологов, то отвечать за это начальнику технологов. Мы не сразу поняли, что это приводит к тому, что сильные начальники быстрее изменяют свою часть компании. А если не помогать тем, кто послабее, то общая цель не достигается.

3. Уровень доходов в команде изменений должен быть одинаковым.

Это требование является поддерживающим для предыдущего. Если каким-то образом удаётся уйти от персональных оценок и отвечать за результат всей командой, то, наверное, можно и не выравнивать. Мы в итоге пришли к тому, что во всех командах изменений доходы одинаковы. Это несколько упростило и коммуникации внутри команды, и позволило сместить фокус на общую цель, а не на персональные достижения.

4. В команде должна быть культура взаимоуважения.

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

Если команда собралась, то можно с ней согласовывать цели. Чем больше требований из списка выше удовлетворено, тем легче это было делать. У нас есть опыт, когда подойти к общему пониманию целей не получилось без последнего пункта требований к команде. Оказалось, что это довольно важный этап. Здесь итеративно и формулируются цели, с которыми дальше можно будет работать.

Про раскапывание и согласование общих целей есть много книжек и статей. Ниже пара лайфхаков, которые сработали у нас:

- коллективные обсуждения с командой;

- обсуждение внутренней мотивации, сравнение с целями;

- дробление целей на две группы: «Что нужно компании» и «Что нужно команде»;

- игры типа Moving Motivators из набора практик Management 3.0.

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

Обратная ситуация. Внутренняя мотивация команды изменений – «сохранить текущий уровень жизни». При такой внутренней мотивации довольно трудно добавить какую-то цель на рост. Если вся команда или большая её часть с такой мотивацией, то стоит задуматься о реструктуризации и разделении ответственности. Одна команда — на рост, другая – на сохранение. У нас нет хороших примеров, когда удалось согласовать цель на рост с командой, которая в нём не заинтересована.

Мы распробовали и освоили три источника проектов по изменениям:

1. Стратегирование.

2. Анализ нежелательных явлений с помощью инструментов Теории Ограничений.

3. Ретроспективы в командах.

Мы применяем все три одновременно и получаем вполне качественный пул проектов.

Любой план устаревает сразу же после того, как он был написан. Мы склонны этому верить, поэтому стараемся корректировать стратегию непрерывно. Чем чаще удаётся поразмыслить над глобальными целями и скорректировать план, тем лучше.

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

Что помогает:

Желательно лететь на запад. В таком случае все письма и сообщения в ваше утро будут из прошлого, так как на вашем основном месте рабочий день закончен или близится к концу. Довольно занятный трюк: отключиться от операционки проще, когда не можешь на неё повлиять.

Выезд из офиса в любое подходящее помещение убирает из виду все триггеры на операционку: доски со стикерами, монитор перед глазами, снующих коллег.

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

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

Мы используем не всё и не так академично, как в книгах. На всякий случай, напомним. Это дерево из логических цепочек, в узлах которого — либо факты, либо нежелательные явления. На вершину помещается ключевое нежелательное явление, которое хочется убрать. Например, цель в формулировке: «мы не достигаем цели».

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

Чтобы проверить адекватность дерева, достаточно зачитать его вслух. Например, «мы срываем сроки отгрузок, потому что мы узнаем о сроках за неделю до отгрузки И нам требуется две недели на изготовление И мы не можем сдвинуть срок». Такая структура выглядит логичной.

В этом примере предпосылки объединены логикой «И». Это значит, что можно избавиться от любой из них, чтобы развалить всё дерево и избавиться от верхнего явления. В качестве решения, мы можем договориться о возможности называть сроки самим, либо выстроить систему так, чтобы сроки называли не позднее двух недель до отгрузки.

На выходе получается ветвистое дерево с множеством явлений и фактов в корне. Анализ этих явлений даёт кандидатов в проекты по изменениям компании.

Ретроспективы являются обязательной практикой в Agile-командах. Ну или хотя бы хорошим тоном. Мы используем практику ретроспектив не только в командах разработчиков, но и в командах изменений и просто в отделах.

Суть ретроспективы в двух словах: команда регулярно собирается и обсуждает, как улучшить свой процесс так, чтобы дело двигалось лучше.

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

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

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

Итого, в результате стратегирования, анализа деревьев нежелательных явлений и ретроспектив, мы имеем пул проектов по изменению организации. Осталось все эти изменения как-то в организацию внести.

Выше по тексту мы уже упоминали термин «проекты по изменениям». Именно проектной логикой мы и руководствуемся при внедрении изменений. Проектному подходу мы учились в своей основной деятельности — разработке приборов. Считаем, что кое-что умеем в области проектного управления. Если в вашей организации есть проектная логика, то перетащить на эти же рельсы изменения в организации – дело техники.

Итак, у нас есть команда изменений и есть пул проектов. Чтобы не перегружать команду и не плодить незавершённую работу, мы формируем очередь из проектов. В работу берём столько проектов, сколько позволяет фокус команды изменений. Обычно это значит, что на одном человеке — по одному-два проекта.

Когда проект переходит в работу, то он приобретает все необходимые для проекта атрибуты. Мы используем только самые важные:

1. Центровой, или «живчик», или менеджер проекта. Тот, кто проект будет двигать.

2. Исходные требования на проект.

В них описываем текущее состояние организации и к чему мы хотим перейти. Например, сейчас у нас конструкторская документация оформляется тотально по ЕСКД, а мы хотим перейти к состоянию, когда ЕСКД используется только там, где это нужно. Тогда в исходных требованиях мы опишем, что мы понимаем под конструкторской документацией, кого и как коснётся изменение, что означает «там, где это нужно» и как мы поймём, что целевое состояние достигнуто.

3. Опрос стейкхолдеров.

Перед стартом проекта, пока пишем исходные требования, опрашиваем всех, кого изменение коснётся. Это помогает включить в требования задачки, которые на этапе формулирования проекта были не очевидны и подготовить почву для изменений.

4. Демонстрации.

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

5. Отчётность.

Все проекты записаны в одном месте и можно посмотреть статус: «в очереди», «в планировании» или «в работе». Хорошо, если канбан-доска с проектами висит где-то на физическом носителе в общедоступном месте. По тем проектам, которые ушли в работу, менеджер пишет короткий регулярный отчёт (комментарий) и рассказывает о состоянии дел на регулярных встречах вокруг доски.

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

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

Второй слой — несогласие с решением. С ним нам помогает общение при запуске проекта с теми, кого затронет проект. Ну а дальше работает общая прозрачность, регулярность отчётности и ретроспектив.

1. Формируем команду изменений вокруг общей цели.

2. Создаем условия для коллективной ответственности.

3. Согласуем и регулярно корректируем цели через стратегирования и разговоры.

4. Декомпозируем цель в проекты через деревья нежелательных явлений.

5. Используем простой канбан-метод вокруг пула проектов.

6. Используем проектный подход ко всем проектам.

7. Пополняем пул проектов через ретроспективы и стратегирования.

8. Крутим цикл, пока не надоест.

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

Принимать решения системно — это главная часть нашей системы улучшений. Найти подходящие инструменты, скомпоновать и подогнать под свою специфику — просто дело техники.Мы понимаем, что наша система далеко не единственная и уж точно не лучшая. Расскажите в комментариях, как устроена ваша система внедрения изменений?