Я разработчик программного обеспечения, и у меня нет глубоких знаний о передовых методах работы с целями и ключевыми результатами (OKR), поэтому я основываю свой вопрос в основном на том, как они используются в моей компании.
Каждый квартал у нас есть неделя OKR, на которую мы добавляем личные OKR в зависимости от того, что мы планируем закончить в этом квартале. Мои OKR в основном представляют собой эпики из системы отслеживания проблем, поэтому меня беспокоит небольшое дублирование. Но это мелочь.
Что меня действительно беспокоит, так это то, что я получаю ощущение водопада от самой идеи планирования вещей на 3 месяца вперед (а затем первая строка реального кода делает этот план устаревшим). Это может хорошо работать для стабильных, старых компаний, но для нас, как для стартапа, это не представляет большой ценности, поскольку все имеет тенденцию меняться очень быстро (по иронии судьбы, на этот раз это произошло на следующий день после завершения OKR за квартал). .
Я хотел бы знать, прав ли я в своем отношении, или, может быть, я просто что-то упускаю?
Я понимаю OKR так, что они предназначены для того, чтобы прояснить людям ожидаемые результаты, а не обязательно то, как вы их достигнете (например, завершите конкретную эпопею).
Например:
Цель: увеличить ежемесячный регулярный доход
--
Так что, возможно, эпопея, которую вы должны выполнить, помогает решить 1 или все 3 из этих ключевых результатов, сама по себе она не является ключевым результатом.
Хорошо иметь индивидуальную цель завершить эту эпопею за определенный период времени, возможно, OKR просто не являются подходящей структурой или процессом для этого на индивидуальном уровне.
Удачи!
OKR связаны с Agile только в том смысле, что компании, которые первыми разработали и продвигали модель OKR, также приняли значительные части Agile Manifesto и фреймворков, которые мы считаем Agile.
Однако OKR никак не связаны с Agile. Это означает, что они могут фантастически хорошо работать в Agile-среде или совершенно ошибаться.
Чаще всего они связаны с Lean Startup, а не с Kanban или Scrum.
OKR расшифровывается как «Цель и ключевой результат» и отличается от идеи KPI. Он был изобретен (расплывчатый термин) Энди Гроувом из Intel, а затем через щупальца венчурных капиталистов и Силиконовой долины был быстро принят значительным числом компаний, особенно теми, в которые инвестировал Kleiner Perkins.
Проще говоря, Цель — это единая объединяющая цель, которая определяет цель организации и помогает ей эффективно расставлять приоритеты. Это не заявление о миссии или возвышенное стремление. Это конкретная, доказуемая, смелая цель.
Ключевые результаты — это 3-5 измерений, которые помогут вам достичь цели и обеспечат уровень планирования на уровне организации ниже цели.
Итак, для цели продать 100 миллионов устройств нам могут понадобиться ключевые результаты
и т. д. и т. д.
Эти ключевые результаты становятся целью для нижнего уровня (поэтому отдел продаж принимает план продаж ключевых результатов для АН в качестве своей цели. Они производят 3-5 ключевых результатов, которые становятся целями нижнего уровня и так далее вплоть до отдельного человека). рабочий.
Таким образом, каждый отдельный результат можно проследить до всеобъемлющей цели всей компании.
Цель служит мощным указателем в будущее и позволяет компании игнорировать все, что не поддерживает цель.
Google продвигал (а затем отбрасывал) идею личных OKR. Это было основано на идее автономии и мастерства для команд. Как только цель поставлена, хорошей практикой было спросить самих команд, каковы должны быть наши ключевые результаты? Как мы будем измерять успех?
По крайней мере половина ключевых результатов должна быть целостной и направленной снизу вверх.
Затем это стало переплетаться с идеей профессионального развития, отзывов о результатах, премий и выделения части вашего времени для личных OKR , таких как
В либеральной среде Силиконовой долины личные OKR могут быть привязаны к благополучию, продвижению по службе, благотворительности и т. д. Джон Дорр говорит об этом в книге «Измеряй то, что имеет значение», размещая свои OKR на стене своего кабинета.
В конце концов Google отказался от него, и у их собственной платформы OKR возникли некоторые проблемы.
Но эта практика все еще существует в других компаниях, поскольку они перенимают руководство OKR от Google Ventures, Medium и других популярных блогов, даже несмотря на то, что Google отказался от некоторых аспектов. Легенда живет...
Ну, проще говоря, ваш продукт или услуга должны быть привязаны к корпоративной цели . Если эта группа функций работает над продуктом или услугой, она должна иметь 3-5 ключевых результатов, которые показывают, как она поддерживает корпоративную цель.
Это уровень, на котором OKR взаимодействуют с Agile.
Если вы навязываете что-то более низкое, чем фактически, вы не используете OKR, вы будете использовать SLA или KPI с обязательными результатами доставки.
В любой момент вы должны иметь возможность задать вопрос владельцу продукта.
Как этот продукт/услуга поддерживает OKR компании?
Разработчики должны иметь возможность спросить
Как эта эпическая или пользовательская история поддерживает OKR продукта?
Это так просто и всегда должно быть так просто, ничего более сложного.
Если вы ищете отличный пример , Gitlab публикует все свои OKR вместе со своими дорожными картами разработки и даже своими эпиками и пользовательскими историями. Это комплексное тематическое исследование.
Саров
СибирскийГай
Ицньютон