flOwKRs - цели и ключевые результаты в потоке

Все показатели эффективности равны, но некоторые равнее. У вас нет времени, чтобы отслеживать всё, поэтому вы выбираете несколько метрик, которые будут направлять команду к успеху. Эти метрики вы и возводите в ключевые. Повышение и понижение значимости KPI может происходить в любое время. Иногда я отслеживал серию ежедневных пробежек. Иногда для меня может быть важна средняя скорость.

Что такое цель? Давайте начнем с нескольких примеров:

• Раскатать новый дизайн
  
• Предложить клиентам классный MVP
  
• Достичь большей конверсии среди платных пользователей
  
• Мигрировать всех клиентов на новую платформу
  
• Дать пользователям возможность автоматизации работы с задачами

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

Цель должна быть:

• Релевантная (Relevant) - есть конкретная область для улучшений. Не выбирайте цель, которая не предоставляет ценность и не улучшит чей-то опыт.
  
• Вдохновляющая (Inspirational) - вы мотивируете команду. Нет ничего хуже, чем работать на цель, которая никого не волнует. Людям нужна причина по которой они будут утром вставать с кровати.
  
• Выровненная (Aligned) - свяжите цели разных уровней. Цель не должна быть навязанной, но и не должна быть полностью независима. Команды на разных уровнях двигаются в одном направлении.
  
• Обсужденная (Negotiated) - улучшайте цели с учетом обратной связи от других команд и стейкхолдеров. Это требует прозрачности. Команда автономна, но принимает во внимание все мнения.
  
• Коллаборационная (Collaborative) - чтобы достичь цели, требуются усилия всей команды. Цель, в которой всю работу делает один человек, не считается.
  
• Разделяемая (Agreed) - все участники команды чувствуют приверженность выбранной цели. Все участники команды в одной лодке, на одной странице.
  
• Привязанная ко времени (Time-bound) - вся команда знает, когда должен быть достигнут запланированный эффект. Обычно правила без конкретной даты или привязки к событию не работают.

Эти семь принципов для цели сокращаются как RIANCAT. Не имею представления, что это значит. Варианты принимаются.

Но постойте! Мы ещё не закончили. Для каждой цели нужен хотя бы один KPI, чтобы вы могли оценивать прогресс её достижения. Как иначе вы узнаете, достигли ли вы того, на что рассчитывали?

Давайте снова начнем с нескольких примеров:

• Получить 10 000 новых регистраций
  
• Достичь конверсии из бесплатной версии в платную свыше 50%
  
• Снизить затраты на инфраструктуру с X до Y
  
• Достичь не менее 3 ссылок на продукт на пользователя
  
• Увеличить удовлетворенность пользователей с X до Y
  
• Оценка рекомендации не ниже 8
  
• Увеличить NPS с 30 до 60

Чтобы сказать "да, мы сделали это!", нужны конкретные целевые величины. Поэтому попробуйте заполнить пустые места в предложении:

В терминах OKR целевые величины называются ключевыми результатами, и их лучше определить несколько. Каждый ключевой результат должен быть:

• Измеримым (Measurable) - убедитесь, что он отвечает на вопрос "мы достигли эту цель или нет?". Если ключевой результат нельзя оценить, он не покажет нам, достигли мы его или нет.
  
• Ориентирован на изменение поведения (Outcome-oriented) - следует измерять изменение поведения клиентов, сотрудников, стейкхолдеров. Просто выполнять задачи не считается!
  
• Простым (Simple) - целевые величины не должны быть двусмысленными, они должны быть простыми для понимания всеми участниками команды. Не делайте своей метрикой сложную формулу с множеством переменных.
  
• Сбалансированным (Balanced) - покрывает серые зоны в целевых показателях одной группы. Например, если один ключевой результат покрывает количество, другой мог бы покрывать качество.
  
• Амбициозным (Ambitious) - пусть участникам команды будет немного неуютно. При значительных усилиях результат должен быть достижим, но не должен быть прост. Иными словами, это должен быть вызов.
  
• Реалистичным (Realistic) - в то же время, несмотря на амбициозность, участники команды должны ощущать, что работа им по силам, чтобы стремление к результатам имело смысл.
  
• Не бинарным (Trackable) - наконец, убедитесь, что результат достижения метрики не выражается простым да / нет. Команда должна иметь возможность видеть продвижение к цели.

Эти семь принципов ключевых результатов сокращаются как MOSBART. И мне интересно узнать, что это значит.

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

Когда люди не разделяют "что" и "зачем", есть риск забыть о "зачем" и фокусироваться только на "что". Это приводит к ситуациям, слишком хорошо знакомым бесчисленным сотрудникам в слишком многих организациях.

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

Обещанные цели это те, под которыми команда готова подписаться, потому что уверена, что может полностью достичь этих целей. Фелипе Кастро описывает их как "выстрел в потолок", потому что уровень неопределенности значительно ниже. Алан Келли называет их утилитарными OKR, потому что для команды их выполнение означает делать больше того, что она уже делает. Команда знает, как это делать. У команд, работающих в режиме исполнения, будут в основном обещанные OKR. Они работают на поставку и не ожидают внезапных сюрпризов на своем пути. На практике ожидается 100% исполнение таких OKR.

Поговорите со своими командами, что они должны быть честными с самими собой! Помечая обещанные OKR как "желанные", команда, без всяких на то оснований, настраивает себя на неудачу. А отмечая желанные OKR как "обещанные", команда может подвергнуть себя лишнему стрессу.

Считается, что большинству команд проще начать с только обещанных OKR, так как желанные OKR требуют культуры психологической безопасности. В этом есть смысл, потому что для людей лучше укрепить уверенность в новом поведении, начиная с того уровня, которым они могут управлять. Планку всегда можно поднять позже (сделав OKR более желанными).

Я считаю, что выбор между желанными или обещанными OKR - не бинарный. Это шкала. Практически каждый стартап - это предприятие с шансом 10 или меньше процентов выйти на интенсивный рост. Исследователи и ученые привыкли проводить эксперименты с мизерными шансами на успех. И я знаю, что в компаниях вроде Booking и LinkedIn гипотезы подтверждаются A/B-тестами в среднем в 30% случаев. Эти инициативы, которые осуществляются "не смотря ни на что".

Мы можем отразить это в OKR, используя обозначение уровня желанности / обещанности.

• 100% - мы обязуемся полностью достичь цели, потому что это исполнение в домене, с которым мы хорошо знакомы.
  
• 70% - мы целимся в полное завершение, но существует неопределенность, так как часть нашей работы - это исследование, а не исполнение.
  
• 50% - хотя мы хотим все, реалистично мы должны признать значительную неопределенность, и пройти половину пути было бы не так плохо.
  
• 30% - эта цель похоже на тест. В какой-то степени мы знакомы с предметной областью, но почти всё, что мы делаем, мы делаем в первый раз.
  
• 10% - эта цель похожа на идею для стартапа. Вероятно, она не выстрелит, но мы твердо уверены, что попытаться стоит.

Есть много примеров целей с малыми шансами на успех.
IT-компании, принимающие решение участвовать в тендере на проект разработки, понимают, что шансы выиграть тендер это 50/50, а возможно меньше. Писатели знают, что даже с отличной рукописью и колоссальным терпением, шансы публикации у крупнейшего издателя это 30% или меньше. Спортсмены, стремящиеся выиграть Олимпийскую медаль, осознанно ставят себе цель, шансы на достижение которой 10% или меньше.

Хорошая новость в том, что многие команды могут увеличить свои шансы на победу, уменьшив масштаб экспериментов и итеративно, последовательно проводя больше таких экспериментов. Таким образом, многие 30%-ные OKR можно довести до 50, может быть даже до 70%. Однако такая стратегия- это всегда вызов и она не всегда возможна. Альтернатива - это проводить эксперименты параллельно портфельным способом (см. ниже).
Факт остается фактом: если вы хотите, чтобы люди были по-настоящему амбициозными, вам нужно предоставить им больше вариантов, чем просто 70% и 100%. Ставя вызов себе как бегуну, на этот год я с легкостью могу поставить OKR на 100%. Но спроси меня о готовности стать автором бестселлера, я бы поставил себе OKR на 10%. Да, я буду упорно работать, чтобы продать миллион копий. Но если я продам и десятую от этого, то это будет для меня поводом для праздника.

Слишком много - это сколько?
У вас может быть любое количество OKR, но чем меньше, тем лучше. В теории целеполагания концепция соревновательности целей говорит, что самым большим препятствием для достижения ваших целей являются все остальные ваши цели. Вам нужно фокусироваться! Меньше - лучше. Постарайтесь ограничивать количество OKR в работе. Три - нормально. Два - лучше. Один - идеально.
Если вы решили целиться в несколько целей одновременно, то стоит задуматься о приоритизации OKR. Ответьте на вопрос - "если у нас внезапно останется меньше времени или меньше людей, какие из этих целей мы можем отбросить?".

Точно также вы можете приоритизировать ключевые результаты в рамках каждого OKR. Ответьте на вопрос, "если у нас внезапно останется меньше времени и людей, какие показатели получат больше нашего внимания"?
Если вы сделаете так для ваших целей и для их ключевых результатов, вы найдете свою метрику Полярной звезды - самый главный ключевой результат самого важного OKR. Метрика Полярной звезды для Facebook (насколько я знаю) - количество активных пользователей в день, Daily Active Users, DAU. У Uber (насколько я знаю) - количество поездок в неделю.
Метрику Полярной звезды часто определяют как единственную метрику, описывающую главную ценность, которую вы поставляете клиентам [или другим стейкхолдерам].
Пройдя через все сложности выбора и приоритизации ваших целей и целевых величин, вы проделаете всю работу, чтобы найти этот единый KPI. Он показывает самый критичный разрыв между текущей и будущей ценностью, который надо закрывать.

Единственное исключение из правила ограничения количества OKR в работе - это работа с портфелем возможностей.
Венчурные инвесторы знают, что для получения приемлемого шанса на возврат инвестиций, вкладываться надо в двадцать разных стартапов. У каждого стартапа шанс на успех может быть около 10%. Это означает, что инвесторам не нужен фокус; им нужна диверсификация, чтобы сбалансировать портфель.
Если ваша команда проводит дюжину высокорисковых экспериментов, вы находитесь в похожей ситуации. Каждый из экспериментов имеет шанс на успех в 10%. Если эксперименты достаточно малы, можно управлять ими как инициативами (см. ниже). Тогда вы можете обернуть всю дюжину одновременных экспериментов в одну цель с 70%-ной оценкой успешности.

Когда каждый из двенадцати экспериментов имеет шанс на успех всего в 10%, шанс, что хотя бы один из экспериментов будет успешным - 72%. Теория вероятностей была одной из моих любимых тем в средней школе.
Однако, если бюджет или временные рамки этих экспериментов большие, вы можете управлять портфелем экспериментов с двенадцатью OKR с 10%-ной оценкой успешности. Принцип управления рисками портфеля параллельных экспериментов остается прежним, вне зависимости от масштаба.
Когда в ваших целях только эксперименты, вы можете задуматься о том, чтобы называть их стратегическими ставками. Ставки для менеджеров звучат намного лучше, чем эксперимент или гипотеза. Менеджеры не любят участвовать в экспериментах, они любят делать ставки!

Заметили ли вы что-то вроде войны методологий относительно "Scrum против Kanban" в сообществе Lean-Agile? Нет? Тогда вы пропустили много интересного!

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

Во фреймворке OKR по умолчанию применяется итеративная парадигма. Итерации для OKR обычно - три месяца. Они начинаются с планирования целей и заканчиваются обзором целей. Во время обзора команда определяет уровень успешности. Они говорят "Окей, время вышло! Как мы поработали?" Если команда неуспешна в отношении OKR, она может решить перенести его на следующую итерацию. Так же работает и Scrum.

Как альтернативу, ваша команда может выбрать непрерывный поток. В этом случае планирование (или пополнение) OKR может происходить в любое время. Как и собрания по обзору. Каденция для этих встреч является рекомендованной практикой, но она не должна быть зафиксированной или синхронизированной с квартальным циклом, и их можно организовать чаще. В этом случае во время чек-инов ваша команда будет все время спрашивать "Мы уже закончили? Мы уже закончили? Мы уже закончили?" Команда работает на OKR пока не решит, что может передвинуть его ближе к цели и заменить следующим. Это похоже на то, как работает Kanban.

Все книги и статьи по OKR рекомендуют итерации. Довольно интересно, что защитники метрики Полярной звезды описывают непрерывный поток. Я не буду выбирать за вас, потому что лучшая стратегия управления работой зависит от вашего контекста и предпочтений. Не начинайте войну. Делайте то, что работает у вас (хотя если вы угостите меня кофе, вы сможете подловить меня на том, что я считаю непрерывный поток довольно крутым).

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

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

Думаю, что слово бэклог может быть самым глупым в Agile сообществе. Изначально оно значило "вещи, которые мы ДОЛЖНЫ сделать и должны были уже сделать" (например, выполнить неудовлетворенные запросы). В первоначальном смысле это скорее чек-лист, чем список пожеланий.

Связывает ли это нас каким-то образом с практикой картирования историй? Точно! С помощью карты историй вы можете визуализировать всё, что вы делаете в рамках инициативы. Вы можете сделать основу из "путешествий пользователя" и иметь множество историй в рамках нескольких запланированных релизов. Давайте, прорисуйте это всё. Просто помните, что всё, что вы делаете, должно, каким-то образом, двигать стрелку в одном или нескольких показателях ваших OKR.
А что насчет эпиков? Что ж, это целиком зависит от того, как вы определяете этот термин. Слово бэклог просто запутывает. Термин эпик почти противоречив. По поводу значения эпика нет единого мнения, так что я оставлю это мысленное упражнение вам.

Вероятно, при выборе целей вы будете должны говорить "нет" некоторым из них. Может быть, даже слишком многим из них. На самом деле, вы, скорее всего, будете говорить что-то вроде "да, но не сейчас". Отложенные цели должны попадать в очередь кандидатов. Если вы потратите немного времени на их приоритизацию, вы сможете относиться к ним как к высокоуровневой дорожной карте.

Когда вы знаете, сколько времени занимает поставка OKR, вы можете предоставлять стейкхолдерам осмысленные прогнозы. Вы можете сделать два-три OKR за трехмесячную итерацию? Тогда список из оставшихся десяти целей займет год. Ваша пропускная способность примерно месяц на цель? Значит за следующие десять месяцев вы сможете сделать ещё десять целей. Простая математика.

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

Помните - вы не сжигаете бэклог. Вы последовательно работаете над целями.

Наверное, самая большая проблема целеполагания в том, что команды оказываются в ситуации "поставил и забыл". Они не отслеживают цели на регулярной основе, чтобы понять всё ли в порядке (посмотрите, ну надо же!) Смысл делать ваши ключевые результаты отслеживаемыми в том, чтобы часто с ними сверяться. То же самое следует делать с метриками здоровья (см. ниже).

Сверка это то, что команды обычно делают раз в неделю. Scrum-команды могут это делать как часть (или между) обзора спринта и ретроспективы. Конечно же, сверка OKR должна быть завершена незадолго до планирования в Scrum или встречи по пополнению Kanban, так чтобы у команды была самая актуальная информация относительно состояния их целей. Это улучшит дальнейшее принятие решений.

Некоторые команды используют "уровень уверенности" - индикатор своей веры в то, что они смогут достичь цели. Они определяют уровни уверенности, такие как "высокий", "средний" и "низкий", или "в порядке", "отстаем", "под риском". Уровень уверенности подталкивает участников команд озвучивать любые проблемы или риски, о которых они знают. Было бы довольно неловко не выполнить OKR помеченный высоким уровнем уверенности. Провал в OKR не должен быть сюрпризом.

В какой-то момент команда прекратит работать над целью, потому что закончится время (в случае итеративного подхода) или потому что у команды есть основания заменить её (в случае непрерывного потока). Тогда команда решает, выполнен ли OKR успешно или нет. Эту оценку можно делать как часть регулярной сверки, но, возможно, лучше делать её на отдельной встрече со своей периодичностью, чтобы было больше времени на обсуждение и рефлексию.

Оценка OKR означает проставление результата от 0 до 100% в зависимости от измерения ключевых результатов. Во многих случаях это привносит долю субъективности. Выручка в день, вероятно, измеряется и оценивается более объективно, чем количество комплиментов в день. Но пока команды оценивают собственную эффективность сами (а не под стимулирующим воздействием менеджмента), у них мало или совсем нет оснований обманывать систему (я не вижу смысла подделывать свой прогресс - пробегать 2500 км в год. Но если бы кто-то платил бы мне за эту цель большой бонус, у меня был бы соблазн запрыгнуть на самокат, когда бежать стало сложно).

В какой момент нормально выбросить OKR?

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

Условия меняются, контексты меняются, команда может столкнуться с абсолютно новой, возможно, безнадежной ситуацией. *Кх-е*, пандемия COVID-19, *кх-е*. Смотрите на это как на отмену спринта в Scrum или на удаление задачи "в работе" в Kanban. Это явно решение команды. По моему мнению, это надо отмечать как форс мажор.

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

Более короткие каденции позволяют вам быстрее реагировать на изменения, но излишние затраты на коммуникацию должны быть малы, иначе вы обнаружите, что проводите слишком много встреч. Более длинные каденции дают больше времени, чтобы делать работу, но требуют меньшего уровня неопределенности от вас.

Синхронизация это ещё одна область, в которой вы можете идти своим собственным путем. Стандартная практика OKR - делать так, чтобы все команды синхронизировали недели, в которые они проводят встречи по планированию и обзору. Очевидное преимущество такого подхода в том, что он помогает проще координировать цели между всеми командами. Однако, надо сказать кое-что в пользу независимых встреч. Например, команды разработки в микросервисном окружении редко синхронизируют планирование и релизы своих API. То же применимо к командам и их OKR. Они могут быть и связанными, и независимыми от других команд.

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

Наконец-то, мы почти на месте!

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

Для некоторый команд в вашей организации большая часть повседневной работы это операционка, Business as Usual (BAU). Их KPI это, в основном, метрики здоровья, которые надо отслеживать, чтобы эффективность не упала ниже приемлемого уровня. На ум приходят сервисные команды, HR, бухгалтерия. Не то, чтобы у них нет OKR, но доля времени, которое они могут тратить на цели и ключевые результаты составляет, наверное, от 5% до 20%. Для продуктовых команд все наоборот. От 80% до 95% их работы относится к OKR, но есть небольшой процент, который следует резервировать на операционную деятельность и поддержку.
Это означает, что у вас два типа KPI - ключевые результаты и метрики здоровья.

Представьте огромный набор показателей эффективности с тысячами способов измерить эффективность команд. При формировании OKR те из них, которые вы посчитали ключевыми для цели, становятся ключевыми показателями эффективности. Некоторое время, пока OKR не прошла обзор и не стала считаться выполненной, вы будете их отслеживать. Затем у вас будет два варианта - вы можете продолжать отслеживать их как KPI, переместив их в метрики здоровья. Или вы можете прекратить наблюдать за ними. В таком случае их следует признать обычными (не отслеживаемыми) показателями эффективности.

Таким вы закрываете разрыв ценности и не даете ему открыться.

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

Дискуссия вокруг стратегии и тактики требует разного уровня мышления. Стратегические решения принимаются реже и покрывают большее время, чем тактические, так что имеет смысл иметь разную частоту для этих дискуссий. Планирование и обзор стратегических целей может происходить раз в год, сверки - раз в месяц. На тактическом уровне это может быть раз в квартал и раз в неделю соответственно (при этом стратегические и тактические сессии могут быть организованы для одной и той же команды или на разных уровнях организации).

В любом случае, вне зависимости от того, какие цели выбрала команда, она должна убедиться, что ее цели выровнены как с целями более высокого уровня, так и с целями уровня ниже. Все, что происходит в организации, должно быть подчинено OKR (и метрикам здоровья). Каждое решение как-то связано с KPI.

Последнее, но не по значению. Я повторю настойчивую рекомендацию от множества экспертов, что ни OKR, ни метрики здоровья не должны быть привязаны к бонусам и другим стимулирующим мерам. Оценка эффективности сотрудников никогда не должна быть напрямую связана с оценкой OKR или состоянием метрик здоровья команды.

Одна из причин в том, что OKR и метрики здоровья являются ответственностью команды.Что сделал конкретный участник, чтобы сформулировать и внести вклад в эти цели - это другой вопрос. Другая причина в том, что отличная оценка по обещанным целям может быть менее ценна, чем средняя по желанным целям. Людей следует оценивать по вкладу в исполнение и исследование.

Фреймворк OKR не был задуман как объективный инструмент. Субъективность необходима в начале, когда команда выбирает высшие приоритеты среди множества вариантов, и в конце, когда участники команды оценивают себя, оценивается их эффективность и прежние достижения. Всё начинается с людей и заканчивается людьми же.

В этой статье я предложил вам шаблон процесса, основанный на целях и ключевых результатах (OKR), настоянный на метрики Полярной звезды (NSM), доказательном менеджменте (EBM), соответствии предназначению (F4P), критериях SMART, метриках здоровья и других парадигмах целеполагания. Я описал его способом доступным для любого масштаба, предложил разнообразные точки для выбора (например продукты против портфеля и итерации против непрерывного потока).

Надеюсь, вы найдете этот процесс полезной точкой для начала вашего целеполагания с командой.

Теперь вам предстоит заставить OKR работать. Но, пожалуйста, учитывайте, что система целеполагания важнее, чем отдельная цель, как ваша рабочая жизнь важнее чем отдельное место работы.

И продолжайте бег. :)