Константин Коптелов - Порядок в Хаосе. Objective and Key Results (OKR)

Почему это важно, нужно и хорошо?

Когда компания маленькая, а проекты небольшие и несложные, достаточно просто выделить зону влияния и ответственности каждого отдельного человека. В этом случае мы можем спокойно работать с фрилансерами, просто распределенными сотрудниками. Обратите внимание, с фрилансерами, а не с командами фрилансеров. Есть разница. Когда у нас набор разных сотрудников и мы им раздаем задачи, благодаря им достигаем результатов, ― это как раз показатели в зоне ответственности одного человека. Это – KPI. Все в данном случае будут очень хорошо работать.

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

Разберем на примере:

Представим завод, где введена система KPI для мастера, который стоит за станком. Его задача ― чем больше деталей он выстрогает, тем больше денег получит. В итоге к чему это приводит? Мастер весь рабочий день, с 8 до 18 часов, «с утра до ночи», строгает. Если он «стахановец», то перевыполняет норму насколько только может. Но к чему это приводит? К тому, что в конце условного конвейера люди, которые с этими деталями должны что-то делать, например, встраивать в механизм, не успевают, машина ломается, останавливается производство и образуется большой склад незавершенных деталей. Грех перепроизводства.

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

Наличие групповых показателей, которые есть в OKR, позволяет балансировать. Нам же очень важно не то, чтобы все работали на максимум производительности. Это, разумеется, хорошо, но это не must. Идеально ― это когда все сбалансированно. У нас есть команда: кто-то брифует клиентов, кто-то пишет технические задания (далее ТЗ), еще один человек код пишет, другой тестированием занимается, а другой выгружает контент на живую систему. И здесь не нужно, чтобы у каждогоиз них была максимальная производительность, а важна общаяэффективность, сбалансированная и максимальная. Общая максимальная эффективность иногда достигается тем, что кому-то нужно работать меньше, чтобы не появлялось перепроизводство. В книге Элияху Голдратта «Цель. Процесс непрерывного совершенствования» очень хорошо и подробно это описано, показана разница между точечными и групповыми показателями. Рекомендую изучить.

Линейность и фрактальность методик

Подход Waterfall ― это каскадный метод управления проектами: мы расписываем этапы проекта, дедлайны, рисуем диаграмму Ганта и работаем. А есть гибкий, так называемый Agile-подход 1 1 Agile software development; agile-метод/подход (с англ. «гибкая методология разработки») – обобщающий термин для целого ряда подходов и практик для гибкой разработки программного обеспечения. Сюда входят экстремальное программирование, DSDM (Dynamic Systems Development Method), Scrum, FDD (Feature driven development), BDD (Behavior-driven development) и некоторые другие. ― Примеч. ред. , где мы работаем итерациями с принтами, кусочками, набором экспериментов. Так вот, KPI-подход он waterfall-ный, каскадный, линейный. В этом случае мы говорим, у нас есть цель на год, делим ее на четыре и получаем цель на квартал. Условно есть одна стратегическая сессия (далее стратсессия), которая проходит чаще всего в начале финансового года: это либо декабрь, либо июль. В разных компаниях по-своему, может быть и другой месяц. Раз в год проводится стратсессия, ставятся годовые цели. И потом, исходя из годовых целей, проводится декомпозиция на каждый квартал или на каждый месяц. В целом подход хороший. В некоторых случаях его можно комбинировать с OKR.