240429 한 주 회고

업무 선택의 기준

• 이번 분기 OKR 가운데 ‘업무 스콥 분류’ 작업은 다음 기준에서 적절하지 못했다.
• 나조차도 이 업무의 다음 요소에 확신을 갖지 못했다.
• 얼마나 걸릴지?
• 업무의 목적은 무엇인지?
• 어떻게 분류할지? 어떤 기준으로 분류할지? 어떤 도구를 사용할지?
• 구체적이고 생생하게 그려지는 기대 효과, 팀원들이 느끼는 효용

• 업무를 선택할 때는, 우선 나 스스로부터 확실하게 설득해야 한다

• 중요하게 느껴지지만 해결하기엔 너무 크고 막막한 문제와 마주했다면
• 일단 후퇴
• 더 쉽게 해결 가능하고, 더 빠르게 효용을 가져다줄 수 있는 업무가 없는지 찾아보자
• 다시 말해 Low-hanging Fruit를 찾자

• 이런 걱정은 있다
• Low-hanging Fruit가 너무 많다
• 사실 그냥 Fruit가 너무 많다
• 해결해야 할 일이 산더미라 손 닿는 곳에 놓인 ‘할 일’도 많을 뿐이다
• 낮게 달린 열매들을 다 따면 언젠가 위에 있는 애들도 건드려야 한다
• 나는 높이 달린 열매를 딸 수는 있는 사람일까?

내가 할까 너한테 시킬까

• PO의 핵심 역량은 우선순위 결정과 역할 배분
• 우선순위의 문제는 위에서 다뤘다
• 이번에는 역할 배분에 관한 문제

• 노코드(로우코드) 툴로 어드민을 구축하면서, 제승현도 간단한 기능 개발이 가능한 상황이다
• 하지만 당연히 개발자 분이 개발하는 게 더 빠르다
• 그러나 우리 팀의 개발자는 두 분
• 그리고 굉장히 바쁘다

• 이럴 때 딜레마는
• 내 눈 앞의 개발 공수를 내가 비효율적으로 해치울까
• 개발자 분에게 이미 쌓여있는 다른 급한 업무들의 후순위로 부탁할까

• 핵심은
• 작은 업무 단위로 쪼갤 수 있는지 분석하고
• 각 업무 단위마다 예상 작업 공수를 도출하고
• ‘개발자라면 빠르게 해결할 수 있는 간단한 업무지만 제승현이 대신 할 수는 없는’ 것들 위주로 적절히 위임
• ex. API 개발
• 위임할 때는 한 눈에 봐도 이해할 수 있도록 명확하게 요구사항을 정의