OKR 작성을 요구한다. 그러나 그 맥락은 무엇인지 궁금했다. 결론은 그냥 뭔가 성과를 보고 싶은 마음의 시도.
TED OKR 영상 보고 거의 신앙이라고 생각했다. 사실상 '느낌'이나 '영감'을 강조하는 건 개인에게 좋지만. 그것에 구성원 모두를 동조시키는 건 또 다른 이야기다.
상하향식을 조합해서 쓴다고 하는데, 이경우 상위의 목표를 잘 이해하면서, 그것을 위해 '자유'롭게 잘 '알아서' 새롭게 일을해야할 필요가 있다.
[최상위] 비전
......
[상위] 서비스 안정화
[하위]프론트 안정화
[구체목표] 개발문화(코드리뷰), 코딩 컨벤션 정의, TDD 도입, 요구사항 명확화 등등
일단 작성해서 올리면 승인은 해주겠지만, 여기가 스타트업인(문화를 가졌는)가? 그만한 시간도 있고 권한도 위임하는 상황인가?
프리랜서를 오래하다가 다시 입사한 정직원 생활이라 이것저것 다양한 역할을 요구하는 상황과, 다양한 역할을 하지 않으면 서비스 자체가 구체화가 안되는 상황이 참 낯설다.
일단 아래의 글을 보면서, OKR 에 도전적 목표를 적는 것은 잠시 내려좋기로 했다.
https://www.mobiinside.co.kr/2020/03/05/udv-okr/
이제는 실무자가 알아서 필요한 IT 기술과 트렌드를 학습하고 프로젝트의 의사결정을 내리고 주도적으로 시장에 뛰어들어야 한다. 너무나 세상이 빠르게 변하기 때문이다. 권한 위임은 특히나 IT기업에선 필수다.
......
다시 말하면, OKR은 권한 위임이 필요하지 않거나 불가능한 경우에는 효용 가치가 현저히 떨어진다. 굳이 OKR일 필요가 없는 것이다. 또한 구성원들이 도전적인 목표 설정을 하지 못하게 압박받는 구조에서도 쓸모가 없어진다.
......
마이크로 매니징과 OKR은 양립하기 어렵다. 실무자 입장에서는 뭐 할 때마다 감시자가 자기 업무를 컨트롤하려 하니 ‘도전적인 목표’ 설정이라든지 주도적인 업무가 어려울 수밖에 없다. 실무진을 못 믿으니 자꾸만 의사결정을 자신이 되가져오는 것이다. 권한 위임이 제대로 이루어지지 않는 환경에서 OKR은 이름만 OKR이지 그냥 회사의 마일 스톤이든 KPI든 뭐로 부르던 상관없는 흔한 목표가 되어버린다. 만약 권한을 많이 위임하는 것보다 고관여로 매니징 하는 게 우리 사업 모델과 조직에 적합하다면 OKR을 도입할 게 아니라 그 방식을 고도화시키면 되리라.
