Ситуация, когда компания враз лишается привычных сервисов и нужно срочно менять технический функционал, нынче крайне актуальна. Причем не поймешь, как проще: когда «партия сказала “надо”» и «срок — вчера» или когда цейтнота нет, но зато нужно доказать руководителю необходимость замены и уговорить всех участников миграции.
Меня зовут Алла Царьгородская, я — руководитель группы разработки технической документации в «Лаборатории Касперского». Сегодня расскажу, что сделала наша команда, когда пришла пора мигрировать всю документацию для внутренних сервисов компании, и как нам помог подход Джона Коттера.
Статья будет полезна тем, кто либо оказался в такой же ситуации, как наша команда несколько лет назад, либо хочет понимать основные теоретические подходы и best practices, если придется с чем-то таким столкнуться. А в текущей ситуации с этим столкнутся практически все в IT-индустрии…
Мы — команда технических писателей в «Лаборатории Касперского», нас 15 человек. Наш основной продукт — это документация для администраторов и пользователей внутренних сервисов компании. По нашим документам работает вся внутренняя поддержка — от сервис-деска до команд, отвечающих за инфраструктуру.
Раньше мы, придерживаясь принципа простоты, использовали продукты Microsoft: в Word`е писали, а в качестве системы контроля версий был SharePoint. Когда объектом изменений был один большой документ, то процесс был максимально простым: нам поступал запрос на доработку, мы вносили в документ изменения, затем согласовывали со всеми заинтересованными лицами и публиковали документ. Ну и, конечно, брать в работу новый запрос можно было только после публикации предыдущей версии, иначе бы мы почти всегда находились в процессе согласования и редко бы имели актуальную опубликованную версию.
Но изменения в сервисах происходили все быстрее. Появлялся девопс. Заказчики хотели параллельно обновлять и согласовывать разные фрагменты документов. Но взять и революционно с ходу что-то поменять было очень непросто: тут и сложившиеся процессы, и привычка работать с текущим функционалом, да и очевидная трудоемкость миграции большого объема (500+ документов)…
Еще в 1995 году Джон Коттер, профессор Гарвардской школы бизнеса, гуру в области управления изменениями и лидерства, предложил свой подход к внедрению изменений из восьми шагов.
Если у вас ситуация из серии «хватай мешки — вокзал поехал», то можете переходить сразу к этому месту моего рассказа (а потом при желании пойти по шагам в обратную сторону). Правда, тогда вам может быть трудно понять предысторию нашего опыта, но в целом хватит и теории. Если же вам еще нужно взвесить все изменения и продать их наверх, то рекомендую читать последовательно.
И оставлю за кадром нулевой шаг: сперва мы пообщались с нашей целевой аудиторией (далее — ЦА), чтобы выяснить ключевые требования, затем провели анализ инструментов, сделали прототипы и т. д. Просто скажу, что в итоге выбрали Confluence.
Нужно увидеть/прочувствовать, что есть потребность в незамедлительных изменениях, и только потом можно побудить людей к действиям. Пока люди не почувствуют, что «ппц дальше так жить невозможно», ничего не поменяется.
Логика, разум, анализ тоже важны, и в успешных компаниях они есть всегда и ходят рука об руку. Но суть перемен кроется именно в эмоциях. Сотрудники должны понять, что проблема наступила, они должны начать тревожиться.
У нас были хорошо налажены процессы, но на ежегодном опросе удовлетворенности наш отдел все чаще получал такой фидбэк: «У-у-у, опять надо открывать 100-страничный документ и вычитывать там изменения». Что мы сделали? Показали эти самые результаты опроса команде. И начали тревожиться :)
Правда, Коттер не оговорился, что простого недовольства текущей ситуацией иногда недостаточно. В нашем случае стоило бы сказать что-то вроде «степень остроты потребности в незамедлительных изменениях должна быть максимальной».
Большие изменения не проводят в одиночку. Нужно сформировать влиятельную команду реформаторов-лидеров (еще их называют амбассадорами) с разными скилами. Нужно заразить лидеров, вдохновить их целью, чтобы они сами стали проводниками этих изменений. Вам не надо вовлекать всех сотрудников в рабочую группу, достаточно вовлечь лидеров мнений. Другие потом подтянутся и перейдут на сторону изменений.
Казалось бы, нам повезло, что люди в команду амбассадоров вошли очень естественно и органично. Кто-то присоединился в силу природного любопытства, кто-то (например, сеньоры) — чтобы встряхнуться. А кому-то было просто по кайфу протестировать новое решение. С другой стороны, я не думаю, что с командой амбассадоров могло бы «не повезти»: если у вас тоже большая компания, как наша, их найти нетрудно. Вопрос только в их мотивации (об этом в самом начале абзаца) и вашем уважении к времени, которое амбассадоры уделяют таким встречам. Тогда вы сможете получать от участников рабочей группы такие же фидбэки, как получали мы друг от друга: «Это жесть, конечно, но очень помогает, что я не один».
На этом этапе мне требовалось лишь задать определенную скорость и ритм изменений, мы организовали еженедельные встречи команды: обсуждали, фиксировали action plan, чтобы к каждой новой встрече заранее тестировать необходимые решения и идеи. К чему нужно быть готовым — это фасилитировать встречи, вовремя возвращать разговор в нужное русло, не углубляться в обсуждение некритичных деталей. Ребята были бойкие, поэтому мы могли сильно углубиться в обсуждение какого-то вопроса, который на самом деле был некритичным.
В процессе трансформации лидеру необходимо ви́дение, а также четкая «дорожная карта» с важными рубежами и люди, ответственные за результат. В формировании ви́дения должна участвовать та команда, которая у нас получилась на втором шаге, это не занятие для одного человека.
Совместно с командой амбассадоров мы создали ви́дение, ответив сами себе на несложные вопросы.
Что можно:
Эти ответы помогли нам сформулировать ви́дение, а далее переходить к планированию целей и задач, а также определить, по каким критериям (метрикам) мы сможем оценивать результативность нашего перехода.
А вот с планированием был нюанс. Длиннющий план работ, который я составила, был детализирован вплоть до уровня задач, ответственных, планируемого времени и расписан аж до самого конца проекта. А по факту я потом его переделывала и корректировала несколько раз. Получилось много лишней работы. И поэтому не стоит забывать о методе набегающей волны, то есть детализировать этапы только по мере их приближения.
Пропагандировать новое ви́дение нужно как можно проще, живее, чаще и привлекательнее. Распространять через все возможные каналы связи, тем самым формируя армию фанатов. Здесь недостаточно просто говорить, желательно делать пример/прототип.
Здесь лучше «пере-», чем «недо-». У нас, как мне кажется, едва ли не каждый сотрудник компании был в курсе перехода: тут и формальные встречи со стейкхолдерами, и неформальные встречи по обмену знаниями с другими командами, и опросы линий поддержки. Плюс, так как на этом этапе важно уже что-то демонстрировать, рабочая группа сделала прототипы для разных типов документов, чтобы наши пользователи могли сами увидеть, как будет выглядеть новая библиотека, какова будет ее структура и предполагаемый процесс работы.
И совет из жизни. До того как продавать идею стейкхолдерам, хорошо заручиться поддержкой союзника. Руководитель одной из команд разработки обратился нам с просьбой как можно скорее мигрировать документацию по его сервису и начать работать в новом инструменте. Его мотивировало то, что в старом инструменте его команде было неудобно вносить изменения. А мы, в свою очередь, понимали, что на его сервисе сможем продумывать, как решать технические и процессные вопросы в новом инструменте.
И уже когда мы шли к другим командам «продавать» наше решение, те видели, как оно реализовано у другой команды разработки. Срабатывал принцип «соседа»: а почему у этой команды так, а у нас еще нет? Мы тоже так хотим :-) Итого, благодаря активному продвижению ожидаемых преимуществ в новой системе, в нашем пилоте участвовала документация по 10 сервисам, что составляло примерно 5% от общего объема. Вполне достаточно для пилота.
К слову, обратная связь по пилоту была противоречивой. Например, одна команда просила закрыть им доступ к редактированию, они не хотели что-то самостоятельно вносить в документацию. Другие команды, напротив, настаивали на обязательной возможности вносить изменения и рассматривали для себя это как одну из ключевых фич. Но так как команды, которые просили закрыть им доступ к редактированию, были в меньшинстве, пришлось их убедить, что если они что-то и сломают, то технически мы сможем исправить эту непреднамеренную оплошность.
Далее мы провели опрос нашей ЦА. Результаты показали, что:
Очень близко к закону Парето.
Затем мы, заручившись результатами опроса, пошли к руководству и сказали, что так дальше жить нельзя. Руководитель нас спрашивает: «Зачем? Чем это будет отличаться от ваших предыдущих неудачных заходов? И сколько вам нужно времени? Давайте мне сроки, результаты».
Но конечно, на момент старта перехода мы еще не были готовы предоставить конкретные цифры «как есть» и «как будет». Зато убедительными аргументами для нашего руководства явились четыре основные фичи, которые мы ожидали получить в новой системе документации:
Обязательно в компании найдутся люди, которые будут сопротивляться внедрению изменений. С таким сопротивлением можно и нужно работать.
Почему люди сопротивляются? Например, они могут злиться на то, что не они стали лидерами перемен. Или им может быть сложно переучиваться. Или для людей внедрение изменений стало неожиданностью (например, как сейчас: просто ушел сервис с рынка — и баста).
Больших инсайтов я здесь не расскажу. Если изменение является критически важным для бизнеса, то с сотрудником стоит поработать по формуле «учить-лечить-мочить», и вполне возможно, что вам придется расстаться с теми, кто категорически не готов к изменениям. Но мне, как я и писала выше, повезло: кто-то сразу пошел на обучение, а с некоторыми коллегами мы обсуждали, что лично их беспокоит, и искали решение. В итоге наша команда в полном составе выдержала и поддержала изменения.
Сотрудникам, которые получили необходимые полномочия и стремятся к поставленной цели, помогают быстрые победы. Но первые видимые результаты необходимо получить в кратчайшие сроки. Когда мы демонстрируем успешный результат, сомневающиеся коллеги переходят на нашу сторону, т. к. у них практически не остается аргументов. А у тех, кто был против, снижается градус сопротивления.
Продукт, который мы делаем, предназначен для каких-то очень конкретных пользователей, поэтому мы все время с ними контактировали и часто собирали обратную связь. После того как мы подготовили MVP (Minimal Viable Product), мы продумали процесс миграции и пошли к ЦА. С ними мы обсуждали, все ли их устраивает, а также договаривались о сроках миграции.
С первой линией поддержки у нас была договоренность, что мы делаем фриз на изменения, при этом быстро мигрируем. Но миграция миграцией, а основные операционные задачи с нас никто не снимал, и делать их надо было параллельно. Чтобы уложиться в этот фриз, мы брали в работу операционные задачи только первого приоритета. А чтобы научиться работать в новой системе, подключили к миграции всех сотрудников отдела. Так мы смогли:
Дальше, при последующих работах, мы подключали уже именно коллег, которые лучше всего справились с такой задачей, а часть их операционки перераспределяли между другими сотрудниками отдела.
Со второй и третьей линиями поддержки у нас была другая договоренность. Им было удобнее, чтобы мы мигрировали волнами, то есть те документы, которые не в работе, и определенными порциями. Всех заинтересованных лиц мы предупреждали о старте каждой волны и о ее завершении.
А по окончании крупного блока работ проводили обучение для ЦА. Причем обучение строили, наблюдая за работой: какие у них пользовательские сценарии, какие задачи они решали с помощью нашей библиотеки и как они это делали в новом инструменте (поначалу интуитивно).
Сразу после миграции первых порций документов мы «шли в поля», сидели рядом со специалистами сервис-деска и наблюдали, как они работают с нашей библиотекой, чтобы понять, на что именно сделать акцент в обучении.
После первых хороших результатов в людях зарождается воля к победе. Но рано праздновать большую победу, не время почивать на лаврах, незафиксированный результат все еще может откатиться назад, нужно, чтобы он прижился.
В какой-то момент у нас наступил этап, когда новое еще полностью не работает, а старое все еще надо поддерживать. Такое промежуточное состояние можно сравнить с ремонтом в двухкомнатной квартире, когда ты в одной комнате делаешь ремонт, а в другой живешь, и такой ремонт хочется быстрее завершить.
Самые первые мигрированные документы в рамках пилота какое-то время мы параллельно поддерживали и в Word'e, и в Confluence. Основным считался документ Word, и одновременно мы актуализировали и дорабатывали разделы в Confluence, поэтому на работе сервиса миграция не сказывалась. Но когда обкатали процесс миграции и поставили его на поток (то есть основные подводные камни выявлены, уже понятно, что и как мигрировать), то новое решение стало основным, а Word'овые версии стали резервным решением и уже генерировались одной кнопкой из новой системы. А сейчас это делается вообще автоматом.
Коттер пишет, что на этом этапе появляется множество проблем, как технических, так и коммуникационных, которые можно и нужно преодолевать, не забыв расставить приоритеты. У нас, к примеру, полетел плагин метаданных на большом количестве страниц — наш боевой Confluence отказался обрабатывать тот объем данных, который мы в него уже загрузили. А это было только 20% от планируемого объема. Мы решили не рассчитывать на то, что разработчик плагина исправит свою проблему быстро, и правильно сделали: разработчики плагина исправили свою багу только через год, но мы уже научились обходиться без них.
На этом этапе лидеры должны показать, что наши изменения могут помочь упростить существовавший ранее процесс и убрать часть ненужных — например, дублирующихся — работ. Все еще могут оставаться недовольные нововведениями, но они уже не настолько яростно сопротивляются. Однако всякий раз, когда вы ослабляете усилия, вы теряете потенциал, необходимый для продолжения изменений. Если не довести работу до конца, это может привести к регрессу.
Когда ты переезжаешь из одной системы в другую, то ощущение такое же, как при переезде в новую квартиру: она получше, на несколько метров больше старой, у тебя нет проблем с водой, светом, есть рядом любимый магазин, детский сад, но тебе все равно не все еще удобно. У тебя не все под рукой, во встроенном шкафу больше не включается свет при открытии дверцы, да и нет удобного крючка для ключей при входе.
Также и в работе: часть функционала, которым раньше команда пользовалась, в новом инструменте будет реализована хуже либо его не будет вообще. Это не киллер-фича, мы не ради этого переходили. Но будут детали, с непривычки омрачающие вашу прекрасную новую картину.
Что с этим делать? Либо вы привыкните и перестанете обращать на это внимание, либо вам нужно заранее запланировать время на исследование и решение таких вопросов.
После миграции всех документов и спустя месяц работы в новой системе мы опять провели опрос нашей ЦА. По результатам опроса получили такие цифры:
Из неудобств пользователи отмечали:
По всем этим вопросам мы запланировали время на изучение и решение. Не сразу, но большинство этих вопросов на сегодняшний день мы уже решили.
А теперь давайте посмотрим на цифры, потому что, как говорит главный герой в фильме «Служебный роман»: «Если бы у нас не было статистики, мы бы даже не подозревали о том, как хорошо мы работаем».
Увеличилось количество просмотров документов. Зеленый график – количество просмотров в Confluence, желтый – в SharePoint.
Количество заявок на ревью возросло.
Наша гипотеза, что уменьшится длительность проведения ревью не оправдалась и на длительности каждого отдельного ревью существенно не сказалось. Показано время проведения ревью в днях (ST, Service Transition).
У каждого из вас своя ситуация и своя степень потребности в изменениях. Но если вы как руководитель чувствуете, что эти изменения нужны и они реально принесут пользу, что это не будут изменения ради изменений (не говоря уже о ситуации, когда изменения обязательны и неотвратимы), то начните с вопроса самому себе: действительно ли команда готова. Если ответ будет скорее «да», чем «нет», то начинайте с первого шага, встаньте и идите мутить застоявшееся болото. Не было бы риска — не было бы и прогресса!
Помоги вам Б-г! Напишите в комментариях, какая ситуация у вас — давайте посоветуемся.
Меня зовут Алла Царьгородская, я — руководитель группы разработки технической документации в «Лаборатории Касперского». Сегодня расскажу, что сделала наша команда, когда пришла пора мигрировать всю документацию для внутренних сервисов компании, и как нам помог подход Джона Коттера.
Статья будет полезна тем, кто либо оказался в такой же ситуации, как наша команда несколько лет назад, либо хочет понимать основные теоретические подходы и best practices, если придется с чем-то таким столкнуться. А в текущей ситуации с этим столкнутся практически все в IT-индустрии…
Что мы меняли
Мы — команда технических писателей в «Лаборатории Касперского», нас 15 человек. Наш основной продукт — это документация для администраторов и пользователей внутренних сервисов компании. По нашим документам работает вся внутренняя поддержка — от сервис-деска до команд, отвечающих за инфраструктуру.
Раньше мы, придерживаясь принципа простоты, использовали продукты Microsoft: в Word`е писали, а в качестве системы контроля версий был SharePoint. Когда объектом изменений был один большой документ, то процесс был максимально простым: нам поступал запрос на доработку, мы вносили в документ изменения, затем согласовывали со всеми заинтересованными лицами и публиковали документ. Ну и, конечно, брать в работу новый запрос можно было только после публикации предыдущей версии, иначе бы мы почти всегда находились в процессе согласования и редко бы имели актуальную опубликованную версию.
Но изменения в сервисах происходили все быстрее. Появлялся девопс. Заказчики хотели параллельно обновлять и согласовывать разные фрагменты документов. Но взять и революционно с ходу что-то поменять было очень непросто: тут и сложившиеся процессы, и привычка работать с текущим функционалом, да и очевидная трудоемкость миграции большого объема (500+ документов)…
Как мы это делали
Еще в 1995 году Джон Коттер, профессор Гарвардской школы бизнеса, гуру в области управления изменениями и лидерства, предложил свой подход к внедрению изменений из восьми шагов.
Если у вас ситуация из серии «хватай мешки — вокзал поехал», то можете переходить сразу к этому месту моего рассказа (а потом при желании пойти по шагам в обратную сторону). Правда, тогда вам может быть трудно понять предысторию нашего опыта, но в целом хватит и теории. Если же вам еще нужно взвесить все изменения и продать их наверх, то рекомендую читать последовательно.
И оставлю за кадром нулевой шаг: сперва мы пообщались с нашей целевой аудиторией (далее — ЦА), чтобы выяснить ключевые требования, затем провели анализ инструментов, сделали прототипы и т. д. Просто скажу, что в итоге выбрали Confluence.
Шаг 1. Создайте ощущение необходимости срочных действий
Что говорит Коттер
Нужно увидеть/прочувствовать, что есть потребность в незамедлительных изменениях, и только потом можно побудить людей к действиям. Пока люди не почувствуют, что «ппц дальше так жить невозможно», ничего не поменяется.
Логика, разум, анализ тоже важны, и в успешных компаниях они есть всегда и ходят рука об руку. Но суть перемен кроется именно в эмоциях. Сотрудники должны понять, что проблема наступила, они должны начать тревожиться.
Как было у нас
У нас были хорошо налажены процессы, но на ежегодном опросе удовлетворенности наш отдел все чаще получал такой фидбэк: «У-у-у, опять надо открывать 100-страничный документ и вычитывать там изменения». Что мы сделали? Показали эти самые результаты опроса команде. И начали тревожиться :)
Правда, Коттер не оговорился, что простого недовольства текущей ситуацией иногда недостаточно. В нашем случае стоило бы сказать что-то вроде «степень остроты потребности в незамедлительных изменениях должна быть максимальной».
Первый этап сложился у нас, как в сказке о рыбаке и рыбке: мы трижды забрасывали невод...
В первый раз у нас не получилось внедрить изменения, потому что хоть потребность уже и возникла, но она была недостаточно острой, да и инфраструктура была еще не готова к таким нагрузкам (на тот момент у нас в компании сервис Confluence еще не был передан на поддержку, а был развернут в тестовых целях на одном из компов под столом администраторов).
Во второй раз, спустя два года, у нас не получилось, потому что хоть сервис уже был передан на поддержку, но ресурсов и мощностей Confluence на тот момент все еще было недостаточно, доступность сервиса была невысокой, да и демо было не очень впечатляющим.
Но через год успех уже был на нашей стороне. К этому моменту мы освежили потребности нашей целевой аудитории: в чем-то нужда отпала, зато появилась масса новых требований, которые и склонили чашу весов.
Во второй раз, спустя два года, у нас не получилось, потому что хоть сервис уже был передан на поддержку, но ресурсов и мощностей Confluence на тот момент все еще было недостаточно, доступность сервиса была невысокой, да и демо было не очень впечатляющим.
Но через год успех уже был на нашей стороне. К этому моменту мы освежили потребности нашей целевой аудитории: в чем-то нужда отпала, зато появилась масса новых требований, которые и склонили чашу весов.
Шаг 2. Соберите команду реформаторов-лидеров
Что говорит Коттер
Большие изменения не проводят в одиночку. Нужно сформировать влиятельную команду реформаторов-лидеров (еще их называют амбассадорами) с разными скилами. Нужно заразить лидеров, вдохновить их целью, чтобы они сами стали проводниками этих изменений. Вам не надо вовлекать всех сотрудников в рабочую группу, достаточно вовлечь лидеров мнений. Другие потом подтянутся и перейдут на сторону изменений.
Как было у нас
Казалось бы, нам повезло, что люди в команду амбассадоров вошли очень естественно и органично. Кто-то присоединился в силу природного любопытства, кто-то (например, сеньоры) — чтобы встряхнуться. А кому-то было просто по кайфу протестировать новое решение. С другой стороны, я не думаю, что с командой амбассадоров могло бы «не повезти»: если у вас тоже большая компания, как наша, их найти нетрудно. Вопрос только в их мотивации (об этом в самом начале абзаца) и вашем уважении к времени, которое амбассадоры уделяют таким встречам. Тогда вы сможете получать от участников рабочей группы такие же фидбэки, как получали мы друг от друга: «Это жесть, конечно, но очень помогает, что я не один».
На этом этапе мне требовалось лишь задать определенную скорость и ритм изменений, мы организовали еженедельные встречи команды: обсуждали, фиксировали action plan, чтобы к каждой новой встрече заранее тестировать необходимые решения и идеи. К чему нужно быть готовым — это фасилитировать встречи, вовремя возвращать разговор в нужное русло, не углубляться в обсуждение некритичных деталей. Ребята были бойкие, поэтому мы могли сильно углубиться в обсуждение какого-то вопроса, который на самом деле был некритичным.
Шаг 3. Выберите правильное видение
Что говорит Коттер
В процессе трансформации лидеру необходимо ви́дение, а также четкая «дорожная карта» с важными рубежами и люди, ответственные за результат. В формировании ви́дения должна участвовать та команда, которая у нас получилась на втором шаге, это не занятие для одного человека.
Как было у нас
Совместно с командой амбассадоров мы создали ви́дение, ответив сами себе на несложные вопросы.
Что можно:
- улучшить
- увеличить
- уменьшить
- убрать
- создать
- упростить
Эти ответы помогли нам сформулировать ви́дение, а далее переходить к планированию целей и задач, а также определить, по каким критериям (метрикам) мы сможем оценивать результативность нашего перехода.
А вот с планированием был нюанс. Длиннющий план работ, который я составила, был детализирован вплоть до уровня задач, ответственных, планируемого времени и расписан аж до самого конца проекта. А по факту я потом его переделывала и корректировала несколько раз. Получилось много лишней работы. И поэтому не стоит забывать о методе набегающей волны, то есть детализировать этапы только по мере их приближения.
Шаг 4. Заинтересуйте людей
Что говорит Коттер
Пропагандировать новое ви́дение нужно как можно проще, живее, чаще и привлекательнее. Распространять через все возможные каналы связи, тем самым формируя армию фанатов. Здесь недостаточно просто говорить, желательно делать пример/прототип.
Как было у нас
Здесь лучше «пере-», чем «недо-». У нас, как мне кажется, едва ли не каждый сотрудник компании был в курсе перехода: тут и формальные встречи со стейкхолдерами, и неформальные встречи по обмену знаниями с другими командами, и опросы линий поддержки. Плюс, так как на этом этапе важно уже что-то демонстрировать, рабочая группа сделала прототипы для разных типов документов, чтобы наши пользователи могли сами увидеть, как будет выглядеть новая библиотека, какова будет ее структура и предполагаемый процесс работы.
И совет из жизни. До того как продавать идею стейкхолдерам, хорошо заручиться поддержкой союзника. Руководитель одной из команд разработки обратился нам с просьбой как можно скорее мигрировать документацию по его сервису и начать работать в новом инструменте. Его мотивировало то, что в старом инструменте его команде было неудобно вносить изменения. А мы, в свою очередь, понимали, что на его сервисе сможем продумывать, как решать технические и процессные вопросы в новом инструменте.
И уже когда мы шли к другим командам «продавать» наше решение, те видели, как оно реализовано у другой команды разработки. Срабатывал принцип «соседа»: а почему у этой команды так, а у нас еще нет? Мы тоже так хотим :-) Итого, благодаря активному продвижению ожидаемых преимуществ в новой системе, в нашем пилоте участвовала документация по 10 сервисам, что составляло примерно 5% от общего объема. Вполне достаточно для пилота.
К слову, обратная связь по пилоту была противоречивой. Например, одна команда просила закрыть им доступ к редактированию, они не хотели что-то самостоятельно вносить в документацию. Другие команды, напротив, настаивали на обязательной возможности вносить изменения и рассматривали для себя это как одну из ключевых фич. Но так как команды, которые просили закрыть им доступ к редактированию, были в меньшинстве, пришлось их убедить, что если они что-то и сломают, то технически мы сможем исправить эту непреднамеренную оплошность.
Далее мы провели опрос нашей ЦА. Результаты показали, что:
- Хотели бы перейти в новую систему — 79%.
- Хотели бы остаться в старой — 21%.
Очень близко к закону Парето.
Затем мы, заручившись результатами опроса, пошли к руководству и сказали, что так дальше жить нельзя. Руководитель нас спрашивает: «Зачем? Чем это будет отличаться от ваших предыдущих неудачных заходов? И сколько вам нужно времени? Давайте мне сроки, результаты».
Но конечно, на момент старта перехода мы еще не были готовы предоставить конкретные цифры «как есть» и «как будет». Зато убедительными аргументами для нашего руководства явились четыре основные фичи, которые мы ожидали получить в новой системе документации:
- Ускоренное утверждение.
- Удобный доступ.
- Вовлечение админов/разработчиков.
- Наличие резервных копий.
Шаг 5. Создайте условия для широкого участия сотрудников в преобразованиях
Что говорит Коттер
Обязательно в компании найдутся люди, которые будут сопротивляться внедрению изменений. С таким сопротивлением можно и нужно работать.
Почему люди сопротивляются? Например, они могут злиться на то, что не они стали лидерами перемен. Или им может быть сложно переучиваться. Или для людей внедрение изменений стало неожиданностью (например, как сейчас: просто ушел сервис с рынка — и баста).
Как было у нас
Больших инсайтов я здесь не расскажу. Если изменение является критически важным для бизнеса, то с сотрудником стоит поработать по формуле «учить-лечить-мочить», и вполне возможно, что вам придется расстаться с теми, кто категорически не готов к изменениям. Но мне, как я и писала выше, повезло: кто-то сразу пошел на обучение, а с некоторыми коллегами мы обсуждали, что лично их беспокоит, и искали решение. В итоге наша команда в полном составе выдержала и поддержала изменения.
Шаг 6. Добивайтесь быстрых побед
Что говорит Коттер
Сотрудникам, которые получили необходимые полномочия и стремятся к поставленной цели, помогают быстрые победы. Но первые видимые результаты необходимо получить в кратчайшие сроки. Когда мы демонстрируем успешный результат, сомневающиеся коллеги переходят на нашу сторону, т. к. у них практически не остается аргументов. А у тех, кто был против, снижается градус сопротивления.
Как было у нас
Продукт, который мы делаем, предназначен для каких-то очень конкретных пользователей, поэтому мы все время с ними контактировали и часто собирали обратную связь. После того как мы подготовили MVP (Minimal Viable Product), мы продумали процесс миграции и пошли к ЦА. С ними мы обсуждали, все ли их устраивает, а также договаривались о сроках миграции.
С первой линией поддержки у нас была договоренность, что мы делаем фриз на изменения, при этом быстро мигрируем. Но миграция миграцией, а основные операционные задачи с нас никто не снимал, и делать их надо было параллельно. Чтобы уложиться в этот фриз, мы брали в работу операционные задачи только первого приоритета. А чтобы научиться работать в новой системе, подключили к миграции всех сотрудников отдела. Так мы смогли:
- завершить весь этап миграции быстрее и уложиться во фриз;
- понять на будущее среднюю скорость выполнения таких задач;
- но главное — выявить тех ребят, у кого такие задачи лучше всего получаются.
Дальше, при последующих работах, мы подключали уже именно коллег, которые лучше всего справились с такой задачей, а часть их операционки перераспределяли между другими сотрудниками отдела.
Со второй и третьей линиями поддержки у нас была другая договоренность. Им было удобнее, чтобы мы мигрировали волнами, то есть те документы, которые не в работе, и определенными порциями. Всех заинтересованных лиц мы предупреждали о старте каждой волны и о ее завершении.
А по окончании крупного блока работ проводили обучение для ЦА. Причем обучение строили, наблюдая за работой: какие у них пользовательские сценарии, какие задачи они решали с помощью нашей библиотеки и как они это делали в новом инструменте (поначалу интуитивно).
Сразу после миграции первых порций документов мы «шли в поля», сидели рядом со специалистами сервис-деска и наблюдали, как они работают с нашей библиотекой, чтобы понять, на что именно сделать акцент в обучении.
Шаг 7. Не останавливайтесь на достигнутом
Что говорит Коттер
После первых хороших результатов в людях зарождается воля к победе. Но рано праздновать большую победу, не время почивать на лаврах, незафиксированный результат все еще может откатиться назад, нужно, чтобы он прижился.
Как было у нас
В какой-то момент у нас наступил этап, когда новое еще полностью не работает, а старое все еще надо поддерживать. Такое промежуточное состояние можно сравнить с ремонтом в двухкомнатной квартире, когда ты в одной комнате делаешь ремонт, а в другой живешь, и такой ремонт хочется быстрее завершить.
Самые первые мигрированные документы в рамках пилота какое-то время мы параллельно поддерживали и в Word'e, и в Confluence. Основным считался документ Word, и одновременно мы актуализировали и дорабатывали разделы в Confluence, поэтому на работе сервиса миграция не сказывалась. Но когда обкатали процесс миграции и поставили его на поток (то есть основные подводные камни выявлены, уже понятно, что и как мигрировать), то новое решение стало основным, а Word'овые версии стали резервным решением и уже генерировались одной кнопкой из новой системы. А сейчас это делается вообще автоматом.
Коттер пишет, что на этом этапе появляется множество проблем, как технических, так и коммуникационных, которые можно и нужно преодолевать, не забыв расставить приоритеты. У нас, к примеру, полетел плагин метаданных на большом количестве страниц — наш боевой Confluence отказался обрабатывать тот объем данных, который мы в него уже загрузили. А это было только 20% от планируемого объема. Мы решили не рассчитывать на то, что разработчик плагина исправит свою проблему быстро, и правильно сделали: разработчики плагина исправили свою багу только через год, но мы уже научились обходиться без них.
Шаг 8. Закрепите изменения в корпоративной культуре
Что говорит Коттер
На этом этапе лидеры должны показать, что наши изменения могут помочь упростить существовавший ранее процесс и убрать часть ненужных — например, дублирующихся — работ. Все еще могут оставаться недовольные нововведениями, но они уже не настолько яростно сопротивляются. Однако всякий раз, когда вы ослабляете усилия, вы теряете потенциал, необходимый для продолжения изменений. Если не довести работу до конца, это может привести к регрессу.
Как было у нас
Когда ты переезжаешь из одной системы в другую, то ощущение такое же, как при переезде в новую квартиру: она получше, на несколько метров больше старой, у тебя нет проблем с водой, светом, есть рядом любимый магазин, детский сад, но тебе все равно не все еще удобно. У тебя не все под рукой, во встроенном шкафу больше не включается свет при открытии дверцы, да и нет удобного крючка для ключей при входе.
Также и в работе: часть функционала, которым раньше команда пользовалась, в новом инструменте будет реализована хуже либо его не будет вообще. Это не киллер-фича, мы не ради этого переходили. Но будут детали, с непривычки омрачающие вашу прекрасную новую картину.
Что с этим делать? Либо вы привыкните и перестанете обращать на это внимание, либо вам нужно заранее запланировать время на исследование и решение таких вопросов.
После миграции всех документов и спустя месяц работы в новой системе мы опять провели опрос нашей ЦА. По результатам опроса получили такие цифры:
- Удобно работать в новой системе — 80%.
- Неудобно — 20%.
Из неудобств пользователи отмечали:
- Хотят опять видеть один большой документ (от чего мы уходили).
- Плохо или непонятно как работает поиск.
- Отсутствует функция поиска и замены.
- И некоторые технические, как мой ребенок говорит, шоколадки.
По всем этим вопросам мы запланировали время на изучение и решение. Не сразу, но большинство этих вопросов на сегодняшний день мы уже решили.
Итоги (если вы читали с 1-го пункта)
А теперь давайте посмотрим на цифры, потому что, как говорит главный герой в фильме «Служебный роман»: «Если бы у нас не было статистики, мы бы даже не подозревали о том, как хорошо мы работаем».
Увеличилось количество просмотров документов. Зеленый график – количество просмотров в Confluence, желтый – в SharePoint.
Количество заявок на ревью возросло.
Наша гипотеза, что уменьшится длительность проведения ревью не оправдалась и на длительности каждого отдельного ревью существенно не сказалось. Показано время проведения ревью в днях (ST, Service Transition).
Вместо постскриптума (если вы читали с 1-го пункта)
У каждого из вас своя ситуация и своя степень потребности в изменениях. Но если вы как руководитель чувствуете, что эти изменения нужны и они реально принесут пользу, что это не будут изменения ради изменений (не говоря уже о ситуации, когда изменения обязательны и неотвратимы), то начните с вопроса самому себе: действительно ли команда готова. Если ответ будет скорее «да», чем «нет», то начинайте с первого шага, встаньте и идите мутить застоявшееся болото. Не было бы риска — не было бы и прогресса!