Comments
> Получается, что OKR с самого начала провоцирует вас на пресловутый выход из зоны комфорта и более смелый подход к планированию

Многочисленные исследования показывают, что заведомо недостижимые цели мотивируют не напрягаться больше, а забить на них с самого начала
Если я правильно понимаю, Wrike — это продуктовая компания. Не могли бы вы привести еще несколько примеров того, какие OKR вы используете для конечных разработчиков, насколько они обобщены или наоборот специфичны? Занимаетесь ли вы сервисной разработкой, и если да, то какие OKR используете в этом случае?
Да, мы продуктовая компания. Если говорить о разработке, то сначала мы ставим OKR'ы на компанию, от них наследуются OKR на всю инженерную команду, от которых уже наследуются OKR на конкретную инженерную команду, которая занимается каким-то скоупом или продуктом. На этом уровне мы останавливаемся и на каждого разработчика OKRы не ставим, что, в целом, соответствует концепции Scrum, где за продукт отвечает команда. В командные OKRы попадают ожидания по релизам значительных фичей а также какие-то существенные улучшения в процессах команды, если они требуются, как например добавление написание юнит-тестов в Definition of Done, и подобные.
>>>Допустим, компания поставила перед собой следующую цель:
Попасть в тройку самых скачиваемых приложений на App Store.

Ключевые результаты:
Увеличить число пользователей приложения на 50%
Повысить рейтинг приложения до 4,5 звезд
Получить 100 положительных отзывов от пользователей
Выпустить 3 новые функции

<<<<

Во-первых, непонятно, почему результаты, а не цели.
Во-вторых, разве выпуск трех новых функций обязательно гарантирует попадание в тройку первых приложений? И 100 положительных отзывов разве достаточно? (В целом впечатление, что все примеры взяты с потолка).
Only those users with full accounts are able to leave comments. Log in, please.