잘못된 OKR(목표 및 주요 결과)이 많이 보입니다. 일반적으로 OKR 이름이 지정된 KPI(핵심 성과 지표)일 뿐입니다. 그들은 다음과 같은 경향이 있기 때문에 이것들을 알고 있습니다.

목표: 제품 제공 x

주요 결과: 제품 x가 생산 중입니다.

목표: 제품 y 채택 촉진

주요 결과: 제품 y에 온보딩된 5개 팀

이 글에서 나는 좋은 OKR이 어떤 것인지에 대한 나의 정의를 적어보기로 했다. 내 생각은 오래 전에 기억에 남지 않는 대화, 블로그 게시물 및 책에서 처음 배운 것에서 발전했으며 이제 지난 10여 년 동안 팀 목표를 설정하기 위해 사용한 경험을 기반으로 합니다.

목표

목표 는 본질적으로 내러티브이며, 찾고 있는 일반적인 결과뿐만 아니라 해당 결과 달성에 대한 전략적 초점과 의견을 표현합니다.

예를 들어 저는 퍼블릭 클라우드 마이그레이션 노력의 일부인 팀을 운영하는 역할을 자주 맡았습니다. 규모/복잡성에 관계없이 모든 회사에서 퍼블릭 클라우드 마이그레이션은 다년간의 이니셔티브입니다. 따라서 "회사를 클라우드로 이전" 또는 "클라우드 채택 가속화"와 같은 상시 목표를 가질 수는 있지만 일반적으로 이렇게 광범위한 목표를 설정하지는 않습니다.

대신, 우리가 해야 한다고 생각하는 이러한 잠재적인 작업, 클라우드로 전환하는 데 발생하는 문제를 살펴보고 집중해야 하는 전략의 다음 핵심 부분을 식별하려고 노력합니다. 예를 들어, 1년 목표는 다음과 같았습니다.

(회사 이름)을 Cloud Ready로 만들기

이 목표는 광범위했고 퍼블릭 클라우드를 활성화하고 사용하는 것과 직접 관련된 작업을 포함했지만 당시 클라우드로 마이그레이션했는지 여부에 관계없이 컨테이너화 및 기타 기본 개선 사항을 통해 애플리케이션을 클라우드 네이티브로 전환하는 작업도 다루었습니다. 아니면. 이 목표는 우리가 모든 것을 퍼블릭 클라우드로 옮길 것인지 여부에 관계없이 "클라우드 네이티브" 아키텍처 및 운영을 원하는 경우 필요한 기본 관행이 추진하는 데 중요하다는 의견을 표명했습니다.

의견을 표현하는 목표를 작성하는 데 한 가지 예외가 있는데, 그때는 늘 변함없는 가치와 초점 영역을 표현하는 목표가 있을 때입니다. 나에게 그것은 항상 "운영 우수성"입니다. 매년 저는 Python 3 마이그레이션, 중요 시스템의 수고 감소 또는 기타 주요 운용성 및 안정성 중심 영역과 같은 문제를 해결하는 데 필요한 중요한 프로젝트에 태그를 지정하는 운영 우수성 OKR을 설정합니다. 나는 이 작업이 다른 주요 이니셔티브만큼 나에게 중요하다는 점을 강조하고 싶고, 더 나아가 모든 팀이 다른 작업을 수행하더라도 이 작업에 어느 정도 집중하기를 기대하기 때문에 이 작업을 수행합니다.

주요 결과

목표는 일종의 의견이나 가치 진술로 높은 수준의 전략을 표현합니다. 주요 결과 는 집계된 신호를 제공하고 해당 목표를 달성하는 데 미치는 영향 또는 진행 상황을 예상하는 방식에 대한 측정값을 제공합니다.

주요 결과에 대한 유혹은 영향보다 수행된 작업에 대해 더 많이 만드는 것입니다. 주요 결과가 배송 시스템, 프로젝트 완료 또는 배송 이정표 달성에 관한 것이라면 수행할 수 있다고 예상한 작업을 수행하고 있는지 여부를 실제로 측정하는 것입니다. 나쁘지는 않지만 두 가지 단점이 있습니다.

첫 번째 단점은 목표를 달성하는 방법에 많은 유연성을 허용하지 않는다는 것입니다. 이는 상당히 제한적입니다! 엔지니어가 계획에 대해 갖는 불만 중 하나는 계획이 매우 엄격할 수 있다는 것입니다. 광범위한 OKR을 작성하는 연간 프로세스에 대해 이야기할 때, 여러분은 그 해에 수행할 작업을 예측할 뿐만 아니라 수행해야 할 중요한 프로젝트가 무엇인지 예측하려고 합니다. 상황이 바뀌고 모든 사람을 EKS로 이동할 필요가 없고 대신 많은 사람을 ECS로 이동해야 하는 경우(예: "100개의 앱을 EKS로 마이그레이션")의 KR이 즉시 빨간색이 되고 똑같이 엄격한 "50개 앱을 EKS로 이동하고 50개 앱을 ECS로 이동"에 찬성하여 다시 작성해야 합니다. 가능하다면 방법 에 유연성을 허용하는 KR을 작성하는 것이 더 낫다고 생각 합니다.그들은 일년 내내 달성됩니다.

이로 인해 작업 출력 KR의 두 번째 단점이 발생합니다. 영향을 고려하지 않는다는 것입니다. 사용자가 목표를 달성하는 데 도움이 되는 것이 가장 유용한 것인지 묻지 않고 자신이 만들고 전달해야 한다고 생각하는 것을 만들고 전달하는 데 집중하는 것이 플랫폼형 엔지니어링 팀의 특별한 사각지대입니다. 임팩트 있는 KR을 작성할 때(새 클라우드 애플리케이션 온보딩 시간을 2주에서 2일로 단축(또는 50%, 또는…)) 사람들은 다음 질문과 씨름하게 됩니다. 영향?

실제로 작업 출력 KR에는 세 번째 단점이 있는데, 이는 대규모 조직을 운영할 때 더 많이 나타납니다. OKR에 대한 저의 개인적인 규칙은 다음과 같습니다: 각각의 목표는 4–5개 이하의 KR을 포함하여 5개 이하입니다. 가장 일관된 감독 단위가 무엇이든 간에 팀이 50명이든 500명이든 이 단위를 고수하십시오. 다양한 팀에서 대규모 작업 포트폴리오를 나타내려고 할 때 낭비할 여지가 없습니다. 주요 이니셔티브에 대한 KR 및 작업 결과 KR은 귀중한 KR 지점을 낭비할 수 있습니다.

당신은 약간의 작업 출력 KR을 갖게 될 것입니다. 그것은 불가피합니다. 해야 할 일이 있고, 그 일을 하는 일은 보고할 진행 상황으로 측정하고 싶을 만큼 충분히 어렵습니다. 그러나 게으르지 마십시오! 모든 단일 작업 결과 KR을 면밀히 조사하고 순수한 전달보다 영향에 더 기반하여 이것을 측정하는 더 좋은 방법이 있는지 스스로에게 물어보십시오.

이 모든 것이 어렵다

이것은 내 초기 요점으로 돌아갑니다. OKR은 어렵습니다. 좋은 목표를 작성하려면 전략적 의견이 있어야 하고, 고객이 원하는 것, 팀이 제공할 수 있는 것, 좋은 KR을 만들기 위해 측정할 수 있는 것에 대한 좋은 아이디어가 있어야 합니다. 영감을 주고 공격적이지만 불가능하지는 않은 OKR을 만들려면 잠재적으로 매우 많은 팀과 프로젝트 모음을 이해해야 합니다.

그리고 물론 당신을 유혹하는 모든 예외적인 경우가 있습니다. 저는 운영 우수성에 대한 개척을 가지고 있으며 일단 거기에서 시작하면 점점 더 많은 개척을 추가하고 싶은 유혹을 느낍니다. 우리는 항상 팀 문화/고용/인재 개발 관련 OKR을 보유해야 합니다. 함수 X를 인식하는 것을 빠뜨릴 수 없으므로 해당 그룹에 대해 특별한 것을 만들어야 합니다. 각각 4~5개의 KR이 있는 4~5개의 Os 모델이 실제로 수백 개를 넘어 확장되거나 모든 유형의 비즈니스에 적합하다고 말할 수 없습니다. 그리고 작업의 특성, 측정 방법 제어, 규모 등으로 인해 OKR이 실제로 필요하지 않은 팀이 있을 수 있습니다.

이것이 OKR의 몰락입니다. 어렵지만 모두가 해야 할 일로 팔리므로 모두가 서투르게 수행하고 대부분의 사람들은 결과적으로 어떤 가치도 보지 못합니다. OKR을 수행할 필요가 없습니다(저를 위해 일하지 않는 한 그럴 수도 있습니다). 적어도 좋은 글을 쓰기 위해 노력하지 않을 거라면 하지 말아야 합니다! 그러나 당신이 일을 한다면, 그들은 당신의 목표에 대해 더 전략적으로 생각하도록 강요할 것이고, 당신이 달성하고자 하는 영향이 무엇인지, 그리고 그것을 어떻게 측정할 것인지에 대해 어려운 질문을 던질 것입니다. 좋은 OKR은 무엇이 중요한지에 대한 이야기를 들려주고, 사람들이 자신이 하고 있는 일을 왜 하고 있는지 생각하도록 영감을 줍니다. 간결한 형태.