Комментарии 4
У нас уже который год в компании пытаются использовать ОКР для разработки (для каждой команды). По мне это не очень адекватно, т.к.:
Заставляет разработчиков придумывать! ключевые результаты. Что чаще всего выливается в лучшем случае в "сделать x задач в модуле Y", в худшем в абстрактных попугаев в вакууме
Многие результаты зависят от других команд (например, увеличить количество покупок пользователями)
Размывает ответственность. По мне проджект/продакт менеджер должен держать в голове план и понимать путь развития. Т.е. ключевые результаты должны исходить из этого. А когда это делают разработчики, то это очень странно, т.к. они отвечают за реализацию и техническое развитие, а не бизнес стратегии.
Приводит к "одноногим" решениям и техническому долгу. "Ребята, в этом месяце квартале мы будем повышать показатели X". При том, что Y, Z могут полностью провалиться. И на качество решения тоже пофиг, главное ведь X. Не скажешь ведь потом, что мы сделали (X-5) но зато хорошо
Ну т.е. вполне вероятно у нас его неправильно готовят. Но за 3 года работы я никакой пользы не ощутил, кроме митингов по имитации бурной деятельности (придумыванию ОКР и придумыванию, как мы будем показывать, что этот ОКР закрыт).
Как по мне, ОКР конфликтует с законом гутхарда.
В моём видении:
Компания определяет "ключевые" направления развития (чтобы не было сильной расфукосировки)
Определяются основные проблемы, мешающие этому развитию
Рабочее время на X% выделяется на устранение этих проблем, а на 100%-X% на то, что команды решают важным (другие показатели, технические улучшения, аналитику)
Единственное чему вы их не научили - это расставлять приоритеты. Когда вы сталкиваетесь с реальной работой коллектива, то неизбежно проходите через этап, когда приходится учится выбирать "что делаем здесь и сейчас", а "что может подождать в еженедельнике", не менее важно как и учитывать интересы коллектива в контексте интересов собственных.
В остальном можно было много рассписать. Много вычиркнули ближе к окончанию, из-за чего концовка выглядет отторванной. Но это мелочи. Приведу только случай из личной практики.
Года 3 назад я как-то консультировал администратора одного портала, известного в специфических фанатских кругах. Человек с никнеймом Random. По масштабу они чуть больше Хабра, исполнение более классическое, без костыльных привязок, перегруженных департаментов - компактный коллектив из группы энтузиастов. У них в сущности была точно такая же проблема - они долгое время не могли расставить приоритеты в ходе собственной стратегической сессии. По ходу консультирования я этим вопросом и занялся, разобрали тогда очень многое, но вот не задача - в ковидный 2020-й год ситуация зависла, а спустя ещё некоторое время закисла в том состояние, в котором мне пришлось тогда её оставить.
А всё просто: администратор не программист и не разработчик. Менеджерские качества есть, а кадров под рукой нет. Спасибо автору за статью, жаль я не знаю его имени, она помогла мне понять очередной кусочек в пазле превентивных предрассудков российского управления. То есть стало ясно, какой следующий шаг нужно сделать непосредственно мне, чтобы помочь одному из любимых порталов решить их головоломку.
Автора зовут Гай.
Он скромно назвал компанию своим именем - Gai.Company.
Ошибки при внедрении OKR как системы исполнения стратегии. Опыт Хабра