brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Feb 13. 2023

두레이를 이용한 팀 OKR 활용하기

베터코드 인사이트

지난 3년간 OKR을 익혔고, 회사 업무에 부분적으로 적용했는데 올해는 전사적으로 적용하기로 했다. '전사적으로'라는 말이 오해를 부를 수 있는데, 나는 무엇을 해도 '아기 발걸음'으로 한다. 작은 규모의 팀이나 회사의 경우는 리더가 목표를 정하고 의견을 경청하여 수정하는 방식으로 시작할 수 있다. 그 방법에 대해서는 이미 2년 전 기록이 있다.


두레이 업무 플래닝으로 OKR 칸반 만들기

이번에 내가 새롭게 발견한 것은 두 가지이다. 하나는 진행상황을 칸반 형태로 보는 방법이다. 지난해 개인적으로 검증해 보고 올해는 회사 동료들에게 그 방법을 퍼트리는 것이다. 여기서는 두레이 업무 플래닝에 대해서는 설명하지 않으니 해당 내용을 익히려는 분들은 두레이 매뉴얼을 보면 된다.

두레이 사용법 이외에 OKR을 두레이에 구성하기 위한 방법만 설명한다. 역시 OKR 자체도 설명 대상은 아니다. 나는 OKR의 가장 중요한 초점을 목표를 향한 구성원들 활동(두레이로 말하면 업무)의 정렬이라고 정의한다. 목표 지향적이고, 결과 지향적으로 명확하게 해 둘수록 자율적인 판단과 그에 따른 창의적인 시도가 가능하다고 믿는다. 그래서 간단히 확인할 수 있고 조율의 중심이 되는 칸반이 중요하다.


두레이에서 업무 플래닝을 쓸 경우 마일스톤으로 칼럼이 만들어진다. 그래서 '연간', '해당 월', '해당 분기'와 같이 세 개의 마일스톤을 만들었다. '할 일' 칼럼은 디폴트로 존재한다. 2월이 되면 칼럼 배열을 어떻게 할지 정해야 할 것이다. 연간은 고정되어 있겠지만, 달이 바뀌면 '해당 월'을 변경해야 한다. 분기가 바뀌면 칼럼 두 개를 변동시켜 칸반을 현재 시점에 맞춰 운영할 계획이다.


OKR 프로젝트와 실무 프로젝트

나는 처음부터 프로젝트의 기준을 나눠서 동료들에게 뭔가 익히게(신경 쓰게) 하고 싶지 않았다. 처음에는 앞서 본 칸반 구성용으로 프로젝트를 하나 만들었을 뿐이다. 그리고 아차피 내가 작성하니까 다른 프로젝트에 속한 업무들을 표현할 때 두레이가 지원하는 업무 링크를 이용해서 관계를 맺었다.


그러던 차에 실무 프로젝트(OKR 프로젝트가 아닌 것)에 속한 업무(작업과 혼용) 중에 모니터링 성격의 업무를 발견했다. 그래서 동료에게 두레이 멘션을 통해서 KR로 변경하는 방법을 설명했다. 이제 동료가 해당 내용을 보고 어떻게 피드백하는지 기다리면 된다.

OKR이 익숙하지 않은 동료 코칭하기

OKR 적용은 회사마다 다른 방법을 취하겠지만, 우리는 마치 교통경찰들이 계도 기간이 갖는 것처럼 1년 이상 선택적으로 써 왔다. 올해는 명확한 성과 평가 기준으로 쓰기로 한 원년이라 과거에는 보고 배우라는 식이었다면 이제는 구체적으로 1대 1 코칭을 한다.

작년에 영감을 받은 축구 코칭 기법에서 일부 힌트를 얻었고, OKR에서 꼭 필요한 부분이 배양되는데 초점을 두었다. 예를 들어 칸반은 내가 만드니까 목표 설정은 브레인스토밍 후에 정의는 내가 한다.


코칭이 필요한 부분은 KR만 남는데, 이미 두레이를 쓰고 있어서 업무 설명 중에 '완료 기준'에 해당하는 부분이 성과 평가의 언어로 쓰이게 하는 부분과 추적 두 가지가 골자다. 우리처럼 작은 규모의 회사는 리더가 목표와 정렬을 주도하는 것이 적합하다고 판단했다.


위 이미지에서 DoD는 Definition of DONE의 약자로 KR을 성과 추적용 완료 기준으로 쓰자는 내 말 습관의 일부다. 두레이 업무로 변환해 달라는 표현은 조직의 습관과 연결시켜 지속성을 확보하는 예시로 이해할 수 있다.


두레이 업무로 OKR 표현하기

앞서 요청한 내용을 동료가 반영한 후에 세밀한 조정을 하는 내용이다.


1. 태그를 이용한 OKR 구분

태그를 붙여주어 다른 업무들과 구분되게 만들었다. 앞서 만든 OKR 칸반에 연결하는 일은 안내하지 않고, 내가 관련 작업이 필요할 경우 추가로 한다. 앞서 리더가 목표와 정렬을 주도한다는 틀에서 보면 칸반의 구성도 리더가 직접 편집하는 편이 좋다.


2. (비대면 소통으로) 동료의 의도 확인하기

다만, 해석의 여지가 있는 경우 임의료 완료 기일이나 KR 태그를 붙이면 의미를 강제하는 듯한 오해를 살 수 있다. 재촉할 뜻이 없는데, 비대면이니 동료가 그렇게 느낄 수 있다. 이런 경우는 질문을 하여 확인한 후에 처리하는 식으로 미세 조정을 한다.


3. 원하는 형식으로 유도하기 (표준화)

템플릿으로 만들면, 생산성이 높아진다. 이를 위해 (지루한 사전 교육을 하지 않기 결과만 얻기 위해) 비대면(댓글)으로 상황별 코칭을 할 수 있다. 아래는 댓글로 KR을 쓴 경우, 다시 말해서 요구에 대응하여 두레이 형식을 무시하고 결과만 만든 동료가 두레이에 우리가 만들어가는 질서 속으로 들어가도록 유도하는 일이다.

아래 경우도 유사하다. 담백하게 내용만 있는 경우에 형식에 대해 구구절절 설명하는 대신에 시간이 걸리더라도 단계를 거쳐 두레이를 익히도록 유도하는 글이다.

4. 정원 관리

표준화를 어느 정도까지 해야 할까? 답은 없다. 나는 두레이 템플릿으로 만들 수 있는 수준이 적절한 지점인 듯하다. 그 이후에 하면 좋지만, 안 해도 별 문제가 없는 부분은 정원 관리로 접근했다. 두 가지 예를 든다.


태그를 붙이고 완료 기일을 지정해도 좋지만, 칸반(두레이 플래닝 보드)을 쓰려면 마일스톤을 붙이는 것이 좋기 때문에 안내하는 문구다.

다음으로 다른 OKR과 연결을 하이퍼 텍스트 형태로 만들어 가는 팁을 안내하는 예시다.


5. 밈(meme)으로 문화 만들기

정원 관리와 유사하지만, 이는 내가 직접 하는 방법이라면 다른 사람들의 행동을 장려하여 퍼져나가게 하는 방법도 있다. 아래 예시로 설명을 대신한다.


지난 베터코드 인사이트 연재

1. 추적성(Traceability)과 그 쓰임새

2. 베터 어드민의 아기 발걸음 그리고 작명

3. Funnel을 마케팅 말고 engagement 분석에?

4. 디지털 대전환기란 나에게 무엇인가?

5. 기술 부채는 무엇인가?

6. 폭포수 방식 설계는 기술 부채를 남긴다

7. 기술 부채는 낮은 코드 품질에 대한 것이 아니다

8. loosely-coupled: 빠르게 재구성하는 힘

9. 건강한 조직이 만들어지는 배경

10. 구축 사업 관리에 가려진 기술 부채

11. 기술은 쓰임새(use case)에 따라 고르고 조합한다

12. Ubiquitous Language 만들 결심

13. 회사 대표가 엔지니어에게 충분한 권한을 주는가?

14. Cloud Native가 무슨 말인가?

15. Cloud Native가 만드는 규모의 경제

16. Cloud Native 승자는 집적이 가능한 개발 조직

17. CNCF는 PaaS를 대체한다

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari