[일간 애자일#657](3/4) 평가방법 OKR, KPI, MBO 뭐가 다른거에요? 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

평가방법 OKR, KPI, MBO 뭐가 다른거에요?

사람이 사는 사회는 동서고금을 막론하고 평가라는 제도가 없던 적이 있었을까 싶습니다. 상하위구조로 나누어진 사회구조에서 더 많은 것을 가질 수 있다고 생각하는 상향으로 이동하려는 욕망에 부합하려면 그에 맞는 평가기준이 존재해야 함은 당연한 이치였을 것입니다. 한반도 이 땅에서도 역사서에 근간해 보면 물론 그때는 기업이라는 것 보다는 관료들의 역사가 정사로 남아 있는 상황이다 보니 고려시대의 고과법(考課法), 조선시대의 고과법과 포폄법(褒貶法)이라는 것이 존재를 하더군요. 지금의 평가기준과 그리 많이 다르지 않습니다. 단어가 쉽지는 않지만 포폄법에서 ‘포’는 포상을 의미하고 ‘폄’은 폄하를 의미합니다. 고과법과의 차이는 ‘고과’는 관리들의 일반근무동향 – 근무시간/일수준수, 기본 업무 실적, 범죄 유무등-을 파악하는 종합기록제도로 인사관리 기본자료로 활용하고, ‘포폄’은 직속상관에 의한 근무성적 평가제도로 상벌 목적 위주로 활용했습니다. 평가는 일년에 두 번 이루어졌다고 합니다. 직속상관의 근무성적 평가제도가 주관적일 수 있기에 공정성 문제가 있기는 했다지만, 퇴출이나 파직과 같은 지금 현재의 공무원 사회보다는 강력한 성과 관리체계였다는 것이 일반적인 평가입니다.

500년 전의 프로세스이고, 그 당시 계급이 존재했던 상황이었던 점을 고려하자면, 지금과는 많이 다른 평가방법일수는 있으나, 평가기준이라는 것이 명확히 존재했고, 결과에 따른 조치가 매우 세분화되어 있었다는 점은 놀라운 사실입니다.

최근에 새로운 유행어처럼 번지는 OKR(Objectives and Key Results)이라는 것이 있습니다. 인텔의 전설적인 경영자인 앤디그로브가 처음 개념화를 하고 그 보완된 개념이 Google이라는 혁신적인 회사에서 성공적으로 운영되고 있는 성능평가방법으로 인식되고 있습니다. OKR을 가장 쉽지만 표면적으로 설명하자면

  1. 상위목표 Objectives를 달성하기 위한 구체적 계획을 하위목표 (Key Results)로 두고 계층화하여 성능을 추적하는 방법입니다.
  2. 또한 위에서 목표가 떨어지는 것이 아닌, 사원들이 직접 중요결과를 세팅할 수 있도록 하고,
  3. 그 중요결과는 매우 도전적으로 목표치 설정이 되어야 한다는 것입니다.

말로 들으면 아하 그렇구나 이해가 어렵지 않습니다. 그런데 지금까지 많은 기업에서 경험해온 KPI 셋팅이나 MBO관리라는 것과는 무엇과 다를까 갸우뚱 하시는 분들이 당연히 많으시겠죠? 저 역시 개인적으로 그 부분이 OKR를 접했을 때 들었던 질문입니다. 경영의 신이라고 했던 피터 드러커의 경영철학에서 시작한 개념의MBO가 SMART 목표와 만나면서 KPI라는 것으로 성장했는데, 그럼 그 방법이 틀렸다는 것인지 의문이 들 수밖에 없는 것이죠. 서로 간에 중복될 수 있는 부분은 있지만, 두 개념은 분명히 다릅니다. 그래도 KPI와 OKR에 공통적으로 들어있는 ‘K’ (Key)라는 공통단어에 집중하면 조금 이해에 도움이 됩니다. 두 개념이 다르기는 하지만 각자의 개념상에서 가장 중요한 것을 꼽자는 것입니다. OKR이 Results즉 가장중요한 결과에 집중하자는 개념이라면, KPI는 indicator, index와 같은 표식에 집중하자는 것이겠죠. 그래서 오늘은 이 차이점을 좀 설명하고 이해를 도울까 합니다.

원문: http://bit.ly/2OoB5sE


‘일하기 싫어증’ 걸린 직원이 문제? 사기 증진 못시키는 조직이 문제

‘일하기 싫어증’에 걸리지 않은 직장인들이 몇이나 있을까? 작고 소중한 월급, 쏟아지는 업무, 인간관계 스트레스까지 더해지면서 퇴사를 향한 갈망은 커진다. 자연스레 회사에서 열심히 하고 싶은 사기(士氣)는 떨어진다. 의욕이 없는 직원들로 구성된 조직의 생산성이 낮아지는 것은 당연하다. 많은 회사들이 구성원들의 사기를 높이기 위해 사내 복지를 확충하고 회식, 사내 체육대회 등을 통해 단합을 도모한다. 그런데 실효가 있는지는 미지수다. DBR 158호에 실린 기사는 직원들이 ‘다니고 싶은’ 회사를 만드는 방안을 소개한다.

원문: http://bit.ly/307vycV


“굿이에요 굿굿굿”..우리 회사 인싸코드, 적절하게 유머 쓰는 법

유머감각 있는 사람은 남녀노소 가리지 않고 이상형을 꼽을 때 빠지지 않는다. 꼭 연애 상대가 아니더라도 재치있는 사람은 어느 모임에서나 주목받기 마련이다. 회사에서도 마찬가지. “부장님, 역시 유머감각이 따봉입니다!”는 말을 칭찬(혹은 알랑방귀)으로 종종 쓰는 이유다. 실제로 사람들은 유머러스한 사람은 자신감 있고 유능하다고 평가한다. 농담의 성패와 관계없이 우스갯소리를 하는 것 자체가 일종의 위험감수라고 간주해서다.

하지만 적절함의 경계를 넘는다면 뜨악한 반응이 되돌아온다. 특히 리더가 부적절한 농담을 던진 경우 능력 부족에 대한 의구심이 커지면서 그 지위가 흔들릴 수도 있다. 농담 한번 하지 않는 근엄하고 진지한 스타일의 상사보다 최악이라는 시선을 받기 마련이다. 어떤 상황에서 어떤 유머를 구사하는 지에 따라 그 효용을 극대화할 수 있다. HBR 2020.7-8월호에 실린 기사를 통해 상황별 유머의 기술을 알아보도록 하자.

원문: http://bit.ly/38pu823


Three Strategies for Fitting Refactoring into Your Sprints

Teams often struggle to fit refactoring or other technical cleanup into their sprints. First, there’s the challenge of convincing a product owner that technical debt should be paid off rather than allowed to accumulate. And even after a product owner agrees, it can be hard to fit the refactoring into a sprint given all the other distractions, interruptions, and changes many teams endure.

In this post, I outline three common approaches for making time for refactoring. For each, I’ll describe the approach and its pros and cons.

원문: http://bit.ly/2NRnH0F


[일간 애자일#648](2/15) PM/PO로서 올바른 의사결정하기 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

PM/PO로서 올바른 의사결정하기

PM/PO는 매일 많은 종류의 의사결정을 해야 합니다. 결정에 따라 얻을 수 있는 것도 있지만 포기하는 것도 분명 발생하기에, 누군가는 결정에 대한 불만을 얘기할 수밖에 없을 텐데요. 예를 들면 이런 상황들입니다.

•가설을 빠르게 검증하고 싶은데, 개발자들은 기술 부채를 피하고 싶어합니다. 반면 UX 디자이너들은 최대한 멋진 경험을 제공하고 싶어합니다. 어떻게 해야 할까요?
•충분한 데이터를 기반으로 의사결정을 하자니 시간이 너무 오래걸립니다. 이 결정이 맞다는 감이 확실히 오는데, 실행해도 될까요?
•고객들이 불편하다고 느끼는 문제를 해결하는 것이 사업적인 목표와는 연결되지 않는다 해도 우선순위를 높여 해결해야 할까요? 사업 목표에 집중해야 할까요?

이 때 성공 확률을 높이는 의사결정을 하려면, 어떤 점들을 고려해야 하는지 살펴봅시다.

원문: http://bit.ly/2N6QptR


PM을 채용하실 때, 알아 둘 7가지

대부분의 스타트 업에서 CEO는 첫 번째 PM 제품 관리자입니다. 일반적으로 기술 공동 창업자와 함께 비전을 설정하고 제품을 만들어 시작합니다. 고객의 반응이 오기 시작하며, 시장에서 제품을 찾는 고객들이 많아집니다. 마케팅과 디자인 개발에 대한 추가 작업의 요구가 점점 커지게 됩니다. 이제 혼자서 모든 일을 처리해낼 수 없는 시간 이 찾아옵니다. 축하드립니다. 드디어 PM을 채용해야 되는 시기입니다!

대부분의 스타트업에서 CEO는 Early Stage에서 1인 다 역을 맡게 됩니다.

팔방미인처럼 여러 부분들의 일들을 수행할 수밖에 없는 강제적(?) 환경에 놓이게 됩니다. 다행히도 시장에서 제품이 인정을 받기 시작하고, 목표로 하는 지표들의 숫자가 나오기 시작하면 이때부터 본격적으로 엔진이 돌아가기 시작합니다. 더불어 일의 규모와 빗발치는 요구 사항들을 처리해내기 위해 더 많은 인력과 파트가 필요해지게 됩니다.

자연스럽게 분야별 파트와 모든 사람들을 관리하는 것이 관리하기 힘들어지기 시작합니다.
첫 PM을 고용해야 되는 시기가 도래한 것이죠.

스타트업에 필요한 PM의 자질

  • 권위없이 이끌 수있는가
  • 비난을 감수하며 신뢰를 얻어 낼 수 있는 사람인가
  • 불완전한 정보로 강력한 의사 결정을 만들어 낼 수 있는가
  • 실현 가능한, 임팩트있는 작전계획을 만들어 낼 수 있는가
  • 실수와 위기에서 어떻게 회복하는 사람인가
  • 극심한 압력에서도 움직일 수 있는가
  • 무엇을 욕망하는가

원문: https://bit.ly/3rHUELd


애자일 아키텍처

애자일 방식으로 소프트웨어를 개발할 때 가장 모호하다고 얘기하는 기법이 있다. 그것은 바로 애자일 아키텍처라는 개념이다. 개념이 나온지 꽤 오래되었지만, 현재도 여전히 정의하기 어려운 말로 통용된다. 이를 이해하기 위해 먼저, 애자일 아키텍처라는 말이 어떻게 유래되었는지 잠시 살펴보자.

’94년 DSDM(Dynamic systems development method)이라는 프로젝트 딜리버리 프레임웍이 발표되었다. 이는 빠르게 개발을 하기 위해 만들어진 RAD(rapid application development ) 라는 방식에서 발전되어 애자일 프로세스의 한 기조로 자리잡았다. 이 프로세스는 과거 XP, 스크럼처럼 개발 자체에 중심을 둔 방식과는 다르게, 프로젝트 관리와 거버넌스에 중심을 두었다. 추후 확장되어 IT가 아닌 영역에서도 많이 사용되는 프레임웍으로 발전했다.

이 DSDM의 원칙들 중 “확고한 기초(Firm foundations) 위에 점진적으로 제품을 만든다” 라는 것이 있다. 이 확고한 기초라는 말이 이후 2008년에 딘 레핑웰이라는 소프트웨어 아키텍트를 통해 해석되어 필요한 만큼(Just Enough) 구축하는 애자일 아키텍처라는 말로 발전되었다. 필자는 이러한 진화가 정말 의아했다. ‘확고한 기초 -> 필요한 만큼’은 느낌상 많이 다른 느낌이다. ‘필요한 만큼 확고한 기초’라는 의미일까?

원문: https://bit.ly/3qkr79W


“당연하게 누려온 특권부터 인정하라”..리더가 조직내 ‘불평등의 구조’ 타파하려면

ESG(환경, 사회적 가치, 지배주조)는 이 시대의 경영 키워드로 꼽힌다. 특히 팬데믹 기간을 거치면서 기업에게 ‘지속가능한 경영에 좀 더 노력을 기울이라’는 시민사회의 요구가 더해지면서 ESG의 필요성은 한층 더 높아졌다.

그런데 여기에 더해 최근에는 ‘인권’이 이 ESG 경영의 새로운 요소로 덧붙여지는 분위기이다. ‘#미투운동’, ‘흑인의 생명도 소중하다(Black lives matter)’ 등등 인종이나 성별 등에 의해 ‘차별받지 않을 권리’가 지속가능한 경영의 기본 요소로 간주되는 모습이 나타나는 것. 문제는 여전히 ‘자신과 지신의 조직은 차별하지 않는다’라고 막무가내식 믿음을 고집하는 리더가 많다는 점이다. 리더가 불평등의 구조를 타파하고 역동적인 조직 분위기를 만들어내려면 어떤 노력을 기울여야 할까. HBR 2020.11-12월호에 실린 기고문을 통해 알아보자.

원문: https://bit.ly/2N7xHSL


비대면 환경에서도 직원 몰입도 높일 수 있는 3가지 방법

직원들 대부분이 재택근무를 포함한 유연근무에 들어간 뒤, A팀장은 마음 한편이 불편하다. 평소 근무 태도에 문제가 있는 직원을 온라인상에서 제대로 지적하기 어려워졌기 때문이다. 화상회의 때마다 팀의 목표, 과업, 책임감 등을 강조하고 있지만 직원들이 제대로 실천하고 있는 것 같지 않아 리더로서 답답하다. 비대면 근무 환경에서도 직원들의 몰입도를 높이려면 어떻게 해야 할까. DBR 303호 기사를 통해 알아보자.

원문: https://bit.ly/3qmIdEi


[일간 애자일#645](2/8) 덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유

직장인은 조직의 비즈니스에 ‘참여자’로, 리더와 책임을 나눠 갖는다. 지분은 없다. 그럼 직장인은 어디까지 비즈니스를 알아야 할까. 어려운 부분이다. 책에 씌여있는 경영 경제 관련 지식만으로는 어렵고, 그렇다고 모두 경험할 수 없다. 그렇다고 포기도 안된다. 꾸역꾸역 Business Friendly 하는 방법밖에 없다. 그런데, “그게 뭔가?!” 말이다. 급하게 리더급으로 올라선 대다수가 이런 혼란 속에 맴돌고 있다.

비즈니스는 어렵다. 그럼에도, 불구하고 우리는 비즈니스를 위한 노력은 좀처럼 하지 않는다

우리네 직장인은 조직에서 여러 이유로 다툰다.

더 많이 일을 하기 위해, 또는 덜 하기 위해.

하지만, 늘 마음대로 되지 않는다. 왜? 비즈니스를 잘 모르기 때문이다. 비즈니스가 무엇으로 구성되어 있고, 그중에 내가 맡고 있는 책임 영역이 무엇이며, 이것이 누구의 어떤 영역과 연결 및 중첩되어 있으며, 이런 복잡한 상황에서도 주어진 책임을 적절히 수행하고 있다는 증거(KPI)를 무엇으로 제시해야 하는지 말이다.

‘직장인’ 만큼의 근시안적 접근이 한계다.

결국, 우리 조직의 비즈니스가 무엇이고, 그중에 맡고 있는 영역 속에서 자의 반 타의 반으로 발생시켜야 할 가치와 최적화된 방법론에 대한 개발 및 적용은 꿈도 꾸지 못한다. 하루하루 해야 할 일(Works) 때문에 퇴근하기도 벅차다. 대다수가 오늘의 할 일을 어떻게 하면 슬기롭게(?) 내일로 미룰 것인가에 대하여 고민할 뿐이다.

당연히 비즈니스는 안중에도 없다.

회사가 잘 되는 것(성장하는 것)과 자신의 일이 잘 되는 것 사이에 미묘하고 복잡한 상관관계를 따지고 싶지 않다. 머리 아프기 때문이다. 그래서 열심히 머리 박고 주어진 일(Tasks)을 제 때(Due-date)에 처리하는 것만으로 목표를 하향 조정한다. 그리고, 이를 달성했을 때, 일에 대한 만족감을 느낀다. 그런데, 그것도 오래가지 못한다. 금세 익숙해지기 때문이다.

비즈니스를 위한 노력은 커리어를 위한 노력과 맥을 같이 한다.

그 익숙함에 대해 스스로 백기를 들고 환영하면 큰 일이다. 어느덧 경험과 연차가 쌓이며, 좀 더 무겁고 큰 책임을 짊어져야 할 자리에 갈 것이기 때문이다. 나도 모르게 ‘비즈니스에 가까워져’ 버렸다. 아뿔싸, 미리부터 비즈니스를 공부할 것…이라는 후회가 밀려온다.

그렇게 우리는 준비도 없이 리더 혹은 리더에 가까운 위치가 된다

<비즈니스에 고전하는 9가지 이유>

첫째, 시장 경험이 거의 없거나, 다소 생소하고 생경한 ‘비즈니스’에 겁 없이 뛰어들어 일을 해야 한다.
“나는 할 수 있다 또는 해야 한다”라고 무작정 믿는다.

둘째, 비즈니스를 비즈니스로 보는 것에 그친다.
비즈니스 속 여러 요소가 있음에도 ‘돈’만 집중해서 본다.

셋째, 사업에 정해진 길이 있다고 착각한다.
결국, 과거의 경험 또는 몇몇의 타인을 의존하여 의사결정을 한다.

넷째, 자신의 리더십에 대해 과소 또는 과신하고 있다.
자신이 어떤 리더십 스타일을 지향하는지 잘 모른다

다섯째, 함께 하는 동료들을 믿지 않는다.
그저 이용만 하려고 한다. 그걸로 충분하다고 믿는다

여섯째, 목적과 목표를 명확히 공식화하지 않는다.
발생한 문제만 우선적으로 대응 및 대처합니다.

일곱째, 한 단계 높은 성장 및 확장을 위한 복안(腹案) 등을 생각하지 않는다.
다양한 시나리오를 갖고 움직이지 않는다. (Pivoting = Spin off vs Split off)

여덟째, 비즈니스에 대하여 학습하지 않는다.
주어진 상황 안에서 판단만 내리려고 한다.

아홉째, 비즈니스와 자신의 인생 방향을 동일시하려는 노력을 하지 않는다.
비즈니스와 삶을 별도로 두고, 두 가지 페르소나를 갖추려고 한다.

원문: http://bit.ly/3nfYQzn


프로덕트 매니저가 제품 아이디어를 관리하는 방법

프로덕트 매니저로 일하다보면, 여러 경로로 제품에 대한 다양한 제안과 피드백을 받게 됩니다. 새로운 아이디어가 나타날 때마다 ‘앗.. 이거 해야 하나..?!’ 라며 흔들리지 않으려면 분명한 목표와 탄탄한 로드맵이 있어야 합니다. 그리고 그 로드맵 안에서 제안된 여러 아이디어를 잘 조합하고 훌륭한 액션 아이템으로 발전시켜 프로덕트의 개선을 만드는 것이 바로 프로덕트 매니저의 일입니다.

아이디어를 잘 모으고 관리한다는 것이 생각처럼 쉽지 않을 때가 많은데요. 번역/편집해 소개하는 아래 글에서는 아이디어 관리 방법을 단계별로 쪼개어 구체화해두었습니다. 여기저기 흩어진 아이디어는 많은데 어떻게 활용해야할지 고민된다면 참고해보시기 바랍니다.

원문: https://bit.ly/2O7KAMQ


PM에게 유용한 ‘인수 기준’ 작성법

How to Craft Strong Acceptance Criteria for a User Story 원문을 요약했습니다.

제가 일하는 팀은 인수 기준(Acceptance criteria)을 작성하지는 않고, 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당하는데요.

개인적으로 PM이 인수 기준(Acceptance criteria)의 범위와 pass/fail 기준을 신중하게 검토하는 것이 중요하다는 점에 공감이 되어서, 주요한 혹은 유저 스토리 대상으로 사례를 만들어볼까 생각해봤습니다.

인수 기준(Acceptance criteria)은 우리가 마치 장보기 할 때, 사야 할 물건을 정리한 리스트와 유사함. 프로덕트의 기능을 성공적으로 개발하기 위한 체크리스트, 일종의 완료조건.

에자일에서 유저 스토리(user story)는 ‘사용자’ 관점에서 기능이 무엇인지 정의하는 것을 의미함. 좋은 유저 스토리 정의는 필수적으로 좋은 인수 기준((Acceptance criteria)의 작성을 필요로 함. 인수 기준은 팀이 유저 스토리의 범위에 무엇이 포함되고, 무엇이 제외되는지 제품 개발 범위를 이해하는데 도움이 됨.

Best practices for writing acceptance criteria

# 1. Who, When and How?
# 2. Shared understanding and consensus
# 3. Clarity comes first
# 4. Make it testable, measurable and achievable
# 5. The format

원문: https://bit.ly/3pUM4YS


생존을 위한 ‘피벗’…대기업도 별도의 괴짜 조직 만들어야

시장이 급변함에 따라 가설과 검증을 통해 비즈니스 모델을 빠르게 수정하는 피벗 전략의 중요성이 커지고 있다. 변화에 대한 유연한 대처가 핵심인 피벗을 실천하려면 린스타트업 방식을 이해해야 한다. 특히 대기업은 기존과는 다른 방식으로 팀을 디자인하며 혁신 조직을 만들어야 한다. 혁신의 종류에 따라 규정집의 부록 같은 별도 절차를 만들거나 아예 별도 건물에 독립적인 조직을 구축할 수 있다. 린스타트업의 선구자인 ‘스티브 블랭크’ 스탠퍼드대 교수는 기업의 규모와 상관없이 피벗 전략이 중요해진 만큼 구체적인 실행 방안이 필요하다고 강조했다. 그와의 인터뷰를 소개한 DBR 313호의 내용을 통해 알아보도록 하자.

원문: https://bit.ly/3tBhxBG


How Programmers and Testers (and Others) Should Collaborate on User Stories

Have the testers on your team ever struggled with what they should do early in a sprint before the programmers have finished coding a user story?

And have the programmers ever wondered what they should do near the end of the sprint while the testers are verifying the implemented code? Are they tempted, perhaps, to start on the next user story even though it can’t be finished in the sprint?

When a team discovers the right way to collaborate on user stories, these questions vanish. Plus, the team is able to deliver more value more regularly to its stakeholders.

원문: https://bit.ly/3cLjjKw