Бег в мешках — кейс внедрения OKR в ограниченном пространстве

OKR (Objectives & Key Results) сейчас набирает популярность в сфере управления бизнесом. Большие и маленькие компании начинают применять OKR для повышения своей эффективности и каждый по-разному подходит к реализации и адаптации OKR под свои нужды. В этой статье я хотел бы поделиться примером сознательного применения элементов OKR и Agile в ограниченном пространстве только ИТ-департамента. «Как это так?» — скажете вы, «OKR — это для всей организации, а не для одного подразделения!» Все верно. Но давайте по порядку…

История начиналась в не таком уж далеком 2017 году в компании-интеграторе решений в области оптоэлектроники, работающей на B2B и B2G-рынках и насчитывающей более 300 сотрудников, почти 20 из которых относилось к службе ИТ. К сожалению, название компании озвучить пока не могу, ввиду запущенного, но незавершенного процесса легализации использования OKR. Знаете, compliance и все такое… Итак, мы в очередной раз сели обсуждать годовые цели внутри ИТ-департамента. Цели, включенные в ранее разработанную долгосрочную стратегию, были в большинстве своем реализованы и нужно было решать, каков наш курс дальше. Получив от руководства не так чтобы детальные, но вполне понятные ориентиры развития, мы приступили. В этот раз решено было привязывать все инициативы к целям бизнеса. Привязывали их достаточно жестко. Каждый внутренний проект имел кодовое название, в котором первый знак указывал на бизнес-цель. Так выстроилось дерево проектов-инициатив на следующие 1-2 года. 1-2 потому, что длительность отдельных проектов была значительной и мы не были уверены, что закончим их в течении года, а ресурсное и календарное планирование было еще впереди.

Инициативы первого уровня, привязанные к требованиям со стороны бизнеса

Тут стоит сделать лирическое отступление и сказать, что такие слова как PMI, PMBOK, Agile, OKR мы только слышали, но никто не погружался в дебри этих практик достаточно глубоко. Поэтому ресурсное планирование для нас заключалось в понимании, кто будет вести проект, а календарное — как раскидать инициативы по месяцам так, чтобы у ответственного было достаточно времени на реализацию.

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

Дело в том, что мы никогда не вели проекты таким образом, не фиксировали прогресс их реализации. Был deadline и к нему все должно быть реализовано. Если к этому сроку не успевали, то обсуждали сдвиг даты или увеличение ресурсов, но никто никогда нас не спрашивал, на сколько выполнен тот или иной проект до его завершения. С точки зрения управления проектом это было замечательно, но нужно было придумать, как вести прогресс, не заставляя коллег ежедневно посвящать этому уйму времени.

Мы начали с диаграммы Ганта и остановились после того, как достаточно детализировали первый большой проект. Нас это испугало. Такие объемы данных поддерживать в актуальном состоянии нам показалось очень сложным и муторным занятием. Решили сделать только верхнеуровневую диаграмму, т.е. не углубляться слишком далеко, но иметь календарный план с одним, максимум двумя уровнями вниз. Одно правило мы договорились соблюдать обязательно: план должен давать понять, что происходит с проектом в середине и в конце месяца, а значит длительность «колбаски» работы в проекте не должна превышать 2 недели.

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

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

Модель деятельности нашего мозга Тима Урбана (из материалов Максима Дорофеева)

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

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

Цели были месячные, основываясь на заветах Google. С одной стороны, это было неудобно, т.к. проекты длились дольше, с другой стороны, уже были утверждены сроки предоставления данных о ходе проектов и мы стали привязывать цели к этим временным вехам. В большинстве случаев KR были типа «действие» (терминология из книги Фелипе Кастро «OKR для начинающих», тогда, конечно, мы это так не называли и не понимали их некорректности). Т.е. цели были в том, чтобы завершить те или иные задачи в проектах. Затем мы стали думать, как их заменить на результаты, которые получаем по завершению этих задач. Таким образом, постепенно мы пришли к подобию Agile похода и KR-показателям. К концу месяца мы должны были сделать шаг к улучшению показателей за счет реализации задач. Далеко не для всех проектов это работало, но одним из показательных примеров для нас стала инициатива по улучшению качества поддержки. Там был наглядный пример показателей — операционные KPI, на них мы и ориентировались. Задачи были направлены на их улучшение. Тематику недельных встреч мы также поменяли. Теперь они стали направлены на решение проблем, которые возникали, а не на отчетность по прогрессу. Коллеги были сфокусированы на достижение месячных целей.

Следующей важной для нас проблемой стали кросс-функциональные цели. Все, как по учебнику. Мы ставили перед собой цель сократить время выполнения конкретных операций, выполняемых коллегами из других департаментов. Цели ставились на основании их запросов и, конечно, коллеги были в них заинтересованы. Но вот со сроками мы всегда не угадывали. То коллеги, не были готовы к приемке реализованных улучшений, то им требовалось больше времени для внесения уточнений в дальнейшие требования. Все сводилось к тому, что сроки, которые мы перед собой ставили, были только наши. Частично удалось справиться с этим за счет ежемесячных встреч, согласования целей и обсуждения сроков с руководителями подразделений, но в большей степени это касалось поддерживающих функций. Также свою роль сыграло предоставление доступа департаментов к реализуемым задачам ИТ и отражение их вовлеченности, но об этом несколько позже. В целом же, без развертывания OKR на другие подразделения сложно было добиться большего.

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

Задача для ИТ видна в разделе проектов в блоке MRP и находится на стадии Analyze, этот же статус и предварительные сроки реализации видит и департамент Логистики из раздела LOG

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

Текущие сроки реализации на верхнем уровне видны с использованием диаграммы Ганта, уровнем ниже представлены отдельные активности по каждому направлению с их сроками реализации

Как видите, мы сознательно «бежали в мешках», ограничиваясь рамками ИТ-департамента: иногда понимая, иногда нет — какие проблемы это принесет.

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