just quit your job

데이터를 기반으로 회고하기

2024년 7월 24일2024년 7월 25일 불꽃남자 Leave a comment

2001년 애자일 선언문이 발표되고, 2000년 중후반 한국에서도 애자일 붐이 일었다. 나도 그때 맹신도처럼 XP, 사용자 스토리에 빠져있었지만 대학생인 내가 현실에서 협업을 해본적이 없기 때문에 애자일에 ‘애’자도 이해했을리가 없다. 그때 그게 무슨 말인지 알고, 협업의 중요성을 인지 했다면 아마 전공 수업중에 소프트웨어 공학도 수강 했겠지. 돌이켜보면 코딩만 할 줄 알았지 정말 애송이.. ㅎㅎ

애자일 개발방법론에서 회고는 매우 중요한 이벤트다. 회고 방식도 여러가지가 있다. 그중에서 누구나 한번쯤은 해봤음직한 방법은 이런 방식이다. 프로젝트가 끝나고 회의실에 모인다. 이번 기간에 잘했던 것, 힘들었던 것, 개선하고 싶은 것 등등 시간을 갖고 포스트잇에 쓴다. 벽에 붙은 메모를 읽고 공감가는 곳에 스티커를 붙이고, 적절히 그룹핑하고 이 중에서 더 논의할 녀석을 고르고 논의후에 액션아이템을 뽑아낸다. 그리고 마지막으로 마인드맵처럼 펼쳐진 화이트보드를 기념사진으로 찍고 끝!

이런 방식이 처음엔 신선했다. 하지만 반복되는 액션아이템과 내가 할 수 있는 일보다 누군가는 해줘야하는 일로 액션아이템이 귀결되는 순간부터 의심이 들기 시작했다. 나는 회고를 하고 있는 것인가? 감정을 소화하고 있는 것인가? 이런 회고 방식으로 뭘 바꾸고 싶은것인가? 도대체 회고는 왜하는 걸까? 점점 본질적인 질문을 하기 시작했다.

회고는 왜 하는 것인가?

회고가 개선의 시작이라고 생각했지만, 때때로 회고가 감정 소화의 장으로 변할 때마다 마음이 불편했다. 그래서 회고 방식을 바꾸고 싶었다. 2020년 어느 시점부터는 회고를 준비하며 설문을 만들기 시작했다. 프로젝트를 진행하면서 “이건 아니지” 싶은 것들을 기록해 두었다가 질문으로 변환했다.

질문을 만들 때는 고민이 좀더 필요했다. 실수나 잘못을 인정하는 것도 중요한데 이미 알고 있는 사실이 한번더 언급되면 마음이 편치 않은게 사람 마음이다. 그래서 불편한 감정을 줄이기 위해 사람을 지칭하기보다는 상황을 지칭하는 방식으로 질문을 만들었다. 예를 들면, “작은 팀에서 번아웃된 동료가 있으면 더 힘들다. 만약 우리 팀에 번아웃된 동료가 있다면 어떻게 하겠는가?”

이 질문은 당시 프로젝트 팀과 직접적인 관련이 있지는 않았고, 개인적인 고민에서 비롯된 것이었다. 하지만 이 질문을 통해 꽤 깊은 대화를 나눴던 기억이 있다. 오래된 기억이라 이제는 감정만 남아있지만, 그 때 어린 친구들이 정신적으로 나보다 더 성숙하다는 생각을 했던 것 같다.

질문을 만드는 과정에서는 다분히 주관적인 견해가 들어가기 마련이어서, 사람들의 감정선을 고려하며 균형을 잘 잡아야 한다. 때로는 이런 질문을 만드는 것이 어려울 때도 있지만, 의외로 많은 소득을 얻었던 것 같다. 질문을 통해 종종 팀의 심리적 안전을 확인할 수 있었다. 심리적 안전과 관련된 내용은 다른 글에서 더 자세히 다루기로 하고, 여기서는 이 정도만 언급하고 넘어가자.

아무튼, 회고를 위한 설문은 충분히 회고할 시간을 가질 수 있도록 최소 2시간 전, 길게는 하루 전에 발송했다. 생각할 시간이 충분히 주어져야 깊이 있는 다양한 의견이 수집된다. 처음엔 답변을 모아서 노션에 정리한 후에 회고를 시작했지만, 어느 순간부터 설문을 포기하고 바로 실시간으로 회고를 진행하기 시작했다. 팀원들이 회고방식에 익숙해지고 심리적 안전이 높아질수록 다양한 주제의 이야기가 쏟아진다. 이때부터는 주제가 삼천포로 빠지지 않도록 중심을 잡는 또다른 국면이 펼쳐진다. 개선에 방점이 찍힌 회고라는 것을 팀원들이 인식할수록 액션아이템도 자연스럽게 수집되고 그중에서 합의된 내용은 바로 프로세스에 반영됐다.

프로젝트 참여자가 아닌 사람이 회고 내용을 읽을 때는 회고 분위기와 프로젝트의 맥락이 생략되어 있기 때문에 주의해야한다. 회고 미팅때에도 맥락이 이해되지 않으면 글쓴이에게 맥락을 다시 확인하는 과정을 거친다.

점진적 변화를 위한 전략

회고를 통한 프로세스 개선은 개인적으로 몇번의 시행착오를 거쳤다. 한번은 이전에 경험했던 성공적인 프로세스를 복제해 새로운 팀에 이식한 경우인데 대부분 잘 적응하지 못했다. 일반적인 반응은 “복잡하다” 였다. 두번째 방법은 다소 시간이 걸리더라도 일부러 불완전한 상태로 시작해서 함께 개선하는 경우인데, 이 경우엔 대부분 만족도가 높았다. 경우의 수를 두개로 압축 했지만 실제 사례는 더 다양하다. 예를 들면, 새로운 팀원이 합류하거나 아예 프로세스가 없던 팀에서 컨설팅을 요청한 경우도 있었다. 현실의 다양한 변주들도 결국 크게보면 프로세스를 함께 개선할 여지가 있는가? 없는가에 따라서 반응이 갈렸다. 결과적으로 프로세스를 함께 개선하면 팀의 적응력과 팀워크도 함께 좋아진다.

질문을 통한 회고방식도 반복되면 본질은 흐려지고 창작의 고통만 남는다. 경험상 이 방식은 지속하기 어려웠다. 그래서 팀원들이 회고에 익숙해질 무렵 회고 마스터를 순환하자고 제안했다. 그리고 나는 나만의 회고준비를 위해 통계를 들여다보기 시작했다. 보통 3번의 개선 사이클을 돌면 유의미한 적응 효과가 나타나기 시작한다. 이때가 바로 통계를 들여다볼 시점이다.

우리 팀이 얼마나 일을 잘 하고 있는가를 가늠해볼때는 생산성(Productivity), 효율성(Efficiency), 그리고 효과성(Effectiveness) 3가지 측면에서 바라본다. 이와 관련된 자세한 내용은 이글에서 확인하자.

누적흐름도표 이해하기

먼저 이 차트가 어떻게 그려지는지 이해해보자. 누적흐름도표는 칸반보드에 생성된 이슈들이 각 컬럼에 머문 순간들을 스냅샷해서 보여준다. 그래서 X축에 시간, Y축에 이슈의 갯수를 표현하는데 칸반의 왼쪽 열에서 생성된 이슈들이 시간이 흘러 모두 오른쪽에 쌓이기 때문에 누적흐름도표는 우상향으로 증가할수밖에 없는 특징을 가진다.

생산성 확인하기

단순한 그래프 같지만 차트는 아는 만큼 보인다. 먼저 완료된 일감이 누적되는 기울기를 살펴보자. 기울기가 가파를수록 완료된 일감의 수가 많은거고 기울기가 완만할수록 팀의 생산성은 떨어졌다고 말할수있다. 따라서 1번보다는 2번이 2번보다는 3번 시점에 팀의 생산성이 높다.

와! 우리팀은 시간이 갈수록 생산성이 높아지네! 잘했네! 박수~!! 짝짝짝! 하라고 이런 차트가 있는게 아니다. 생산성에 영향을 주는 요인을 알아야한다.

생산성에 영향을 주는 대표적인 요인

일감을 처리하는 사람의 수
일감의 크기

단순 비교하면 1번보다 3번 시점이 생산성이 높지만 얼마나 효율적으로 일 했는지는 알 수 없다. 팀이 얼마나 효율적인지 비교하려면 일감의 크기와 투입된 사람의 수도 고려해야한다.

병목구간 찾기

누적흐름도표에서 가장 큰 영역을 차지하고 있던 완료 항목을 보고서에서 제외하면 병목을 좀더 쉽게 찾을수있다.

위 예시는 백로그가 급증하고 있음을 보여준다. 백로그와 일감은 차이가 있다.

백로그 – 해결해야할 문제들. 백로그로는 일을 할 수 없다. 즉, 일감이 아니다!!
일감(할 일) – 실제 개발자가 일할수 있는 적당한 크기로 구체화된 일감

백로그나 일감이 증가하기 시작하면 이슈 관리가 필요해진다. 백로그가 많으면 팀에 일이 많은 것 같은 착각을 일으킨다.

백로그가 쌓이는 대표적인 이유

실제 일감으로 구체화 되지 않고 러프하게 만들어진 경우
백로그의 의존성이 파악되지 않은경우
파악된 의존성이 해결되지 않아 그대로 쌓이는 경우
시간이 지나 의미가 없어진 일감을 삭제하지 않은 경우
계획없이 만들어 두기만 한 경우

일감이 쌓이는 대표적인 이유

(팀 케파,처리속도에 맞지 않은) 무리한 일정 계획
부족한 실무자 (PM, PD, SE, QA 모두 포함)
일감을 실무자가 작성하거나 검토하지 않은 경우

진행중 컬럼에 제약이 필요한 순간

누적흐름도표에서 다른 컬럼을 다 제외하고 개발 사이클 구간만 선택해서 살펴볼수도 있다. 개발팀에서 개발자가 실제 일하는 구간을 세분화하면 코드작성 > 코드리뷰 > 코드병합 세 단계를 거친다.

개발 사이클 타임을 줄이기 위해서는 빠르게 코드를 병합해야한다. 위 그림처럼 개발중인 코드가 많아지거나 리뷰할 이슈가 많아지기 시작하면 전체적인 생산성은 떨어진다. 보통 이런 상황에선 컬럼에 제약만 걸어도 병목이 해소된다.

리뷰가 쌓이는 대표적인 이유

여러 버전을 동시에 병렬로 개발하는 팀
일감을 적절하게 자르지 않은 팀
개발자가 너무 많아서 순식간에 리뷰수가 증가하는 팀
개발자가 너무 적어서 리뷰할 여력이 없는 팀

컨트롤 차트 이해하기

컨트롤 차트는 칸반보드에서 생성된 이슈 하나가 완료될때까지 걸리는 전체 산술 평균시간(빨간색)과 기간별로 산출되는 롤링 평균시간(파란색)을 제공한다.

개발팀의 리드타임은 보통 계획된 할일-코드작성-코드리뷰-코드병합 4단계를 의미한다.

따라서 파란색 롤링평균 시간이 빨간색 기준선보다 밑에 있으면 팀은 효율적으로 일하고 있음을 의미한다. 이런 기본적인 이해를 바탕으로 올해 5월 어느쯤부터 팀의 효율이 떨어지고 있네? 아.. 이 팀은 문제가 있네! 라고 평가를 끝냈다면 당신은 애자일의 “애”자도 모르는 사람임을 고백한것이다.

애자일 선언 이면에 숨겨진 12가지 원칙중에 “가치있는 소프트웨어를 고객에게 지속적으로 전달해서 고객을 만족시키고, 작동하는 소프트웨어를 자주 전달 하라는 내용이있다.” 이 원칙을 현실에서 어떻게 구현할까? 생각해보면 단순하다. 고객이 원하는 적합한 일(피처)을 잘 선별하는 작업이 우선 필요한데, 선별 과정은 이 글의 목적을 벗어나기 때문에 일단 논외로하자. 이제 선별된 일을 빠르게 릴리즈하는 방법만 남았다. 이 문제를 피자가게 메타포로 바꿔보자.

고객이 먹고 싶은 피자를 고르고 앱에서 주문을 했다. 그럼 피자 가게에서 주문을 확인하고 피자를 만들기 시작한다. 완성된 피자는 포장되어 배달원을 거쳐 고객에게 전달된다. 고객이 주문에서 피자를 받기까지 걸린 총 시간을 리드타임(Lead Time)이라고 부른다. 그리고 주문을 받고 실제 피자를 만드는 일을 프로세스 타임 혹은 사이클 타임(Cycle Time)이라고 부른다. 여기서 배달원이 배달하는 시간은 또 다른 사이클이다. 수식으로 표현하면 아래와 같다.

그런데, 주문이 폭주하기 시작했다. 여기에 비도 오면서 배달이 늦어지는 상황을 생각해보자. 화덕이 하나인 피자가게는 주문을 감당하지못해 생산하기위해서는 대기해야하는 시간이 존재한다. 배달도 마찬가지다. 생산된 피자를 배달원에게 전달하고 싶은데 배달원을 구하는 것도 시간이 걸리기 시작했다. 이 상황을 수식으로 표현하면 아래와 같다.

다시 제품개발로 돌아와서 빠르게 릴리즈하는 방법을 단순화하면 바로 리드타임을 줄이면 된다. 우리가 성능을 개선할때도 병목을 찾아서 해결하듯이 현실에서 리드타임을 줄이는 일도 병목을 찾아 대기시간을 없애는게 가장 효과적이다. 왜냐하면 현실에서 사이클 타임은 0으로 만들수없지만 대기시간은 0에 가깝게 만들수있기 때문이다. 피자가게의 사이클 타임을 줄이려면 숙련자를 채용하거나 화덕의 갯수와 함께 피자 만드는 사람을 더 늘려야한다. 하지만 사이클 타임 개선은 비용도 들고 주문 폭주가 이어지는 상황이 아니라면 되려 고정비 지출만 늘리는 셈이 된다. 그만큼 사이클 타임 개선은 쉽지 않다. 숙련공을 채용하는 것과 숙련공으로 성장시키는 일중에 무엇이 더 쉽고 장기적으로 이득인지도 잘 따져봐야한다.

리드타임과 사이클타임 구분하기

우리는 제품 개발 과정 안에서 다양한 직군과 협업하지만 통상적으로 가장 병목이 되는 자원은 개발자임을 부정하긴 어렵다. 따라서 개발자원은 특별히 더 신경써서 관리되어야한다. 가장 이상적인 상황은 개발팀이 일정한 속도를 지속하는 것이다. 개발자도 사람인지라 날이 좋아서 날이 좋지 않아서 들쭉날쭉할수있다. 좋은 팀이라면 개인의 변동은 팀 차원에서 어느정도 커버가 된다. 하지만 팀이 들쭉날쭉하면 위험신호다.

개발팀이 실제 일하는 사이클타임은 보통 코드작성-코드리뷰-코드병합 이기 때문에 이 단계에 해당하는 컬럼을 필터해서 보면 개발팀의 평균 이슈 해결 속도를 알수있다.

개발팀의 사이클 타임은 보통 코드작성-코드리뷰-코드병합 3단계를 거친다.

위 차트는 현재 내가 속한 팀(퇴사전)의 사이클 타임이다. 입사후 첫 6개월을 제외하고 나머지 기간동안 거의 같은 속도를 유지했다. 심지어 마지막 릴리즈는 불꽃을 태웠다. (빨간선 밑으로 롤링이 내려옴)

그동안 우리팀은 얼마나 생산적이고 효율적으로 일했나?

팀이 얼마나 생산적이고 효율적으로 일했는지 확인하기 위해 같은 기간동안 개발팀의 리드타임을 누적흐름도표와 함께 겹쳐서 확인해보자.

개발팀의 개발 사이클은 일정하기 때문에 올해 5월부터 급격한 리드타임의 증가는 해결해야할 피처의 크기에 비례했음을 알수있다. 따라서 회고할때 이곳에 숨겨진 맥락을 짚는게 중요하다.

회고에 데이터 활용하기

길게 설명했지만 내 결론은 데이터를 회고에 활용하면 좋다는 이야기를 계속하고 있다. 사실 나도 데이터를 처음부터 활용한건 아니다. 회고준비에 지쳐갈때쯤 회고마스터를 순환하기 시작했는데 이때부터 회고 준비에 대한 압박이 사라지고 천천히 데이터를 들여다볼 여유도 생겼다. 역시 사람은 여유가 있어야 새로운 시도도 해보게된다.

데이터를 해석하는 데에는 다분히 주관적인 견해가 들어가기 마련이다. “왜 이런 결과가 나왔을까?”라는 질문을 통해 혼자 가설을 세워보고, 회고를 통해 서로의 견해를 확인한다. 우리는 이 결과가 문제 상황인지, 아니면 어떤 원인으로 인해 당연히 발생한 것인지, 그리고 우리 팀이 감당할 수 있는 리스크인지 또는 개선할 수 있는 것인지에 대해 논의했다.

차트가 보여주듯이 우리 팀은 꽤 건강했고, 실제로도 팀워크가 매우 좋았다. 데이터 회고가 꼭 어떤 문제를 발견하기 위해 필요했던 것은 아니다. 우리가 여전히 잘하고 있음을 성적표로 확인받으면 왠지 더 잘하고 싶어지는 욕구가 생긴다. 그 이유는 나도 잘 모르겠다. 이런 팀은 나도 처음이라…

플래닝에 데이터 활용하기

개발팀이 일정한 속도를 내면 일정 계획을 세우고 예측하는데도 도움이 된다. 나는 스크럼도 좋아하지만 일정 산정에 대한 스트레스가 꾀나 커서 주로 칸반을 사용한다. 개발팀이 일정한 속도를 내거나 이슈의 크기가 일정하게 짤리면 큰 비용 들이지 않고 이슈 갯수를 기준으로 예측을 해보기도 한다. 재밌는건 이런 대강의 예측도 어느정도 데이터가 쌓이면 얼추 잘 맞아 떨어진다.

개발 사이클 타임

개발 리드 타임

우리팀은 기본 개발 사이클이 존재하기 때문에 앞뒤 짜르고 순수하게 20일정도 개발할 내용을 플래닝하곤했다. 그렇게 플래닝한 티켓을 보드에 올려놓고 누적흐름도표에서 개발 리드타임으로 필터해보면 대강 감이 온다. 아! 이번 릴리즈는 힘들겠다. 이번에는 무난하겠네. 한번은 스토리 갯수가 평소보다 7개 많아서 7일정도 더 걸릴꺼라고 예상했는데, 실제로 9일정도 더 걸렸다. 특별한 노력을 들이지 않고 예측한 오차가 2일정면 나쁘지않다.

애자일 회고의 본래 의미

내가 글을 쓰는 동안 여러 질문들을 GPT에게 던지면서 놀라운 사실을 하나 알게됐다. 바로 회고라는 단어가 한국어에선 자기성찰의 의미가 있어서 다소 감정적인 의미로 받아들여 질수있다는 사실이다. 그런데 더 놀라운건 Retrospective 라는 단어의 늬앙스다. 다음은 GPT 내게 준 답변이다.

“Retrospective”는 다음과 같은 의미를 가집니다:

과거를 돌아보는 것

특정 기간이나 사건을 되돌아보고 평가하는 행위.

회상과 평가

과거의 경험, 사건, 행동을 되짚어보고 그 의미와 결과를 분석하는 것.

영어에서 “retrospective”는 일반적으로 중립적이고 분석적인 뉘앙스를 가집니다. 이는 단순히 과거를 되돌아보고, 무엇이 잘 되었고 무엇이 개선될 수 있는지를 평가하는 것을 의미합니다. 따라서 “retrospective”에는 반드시 자기 반성이나 잘못을 탓하는 의미가 내포되어 있지 않습니다. 오히려, 경험을 통해 배우고 성장하기 위한 긍정적인 과정으로 여겨집니다.

회고는 그렇답니다. 끝!

다시 개발자로 돌아가기

2024년 7월 19일2024년 7월 24일 불꽃남자 Leave a comment

팀을 이끌어야하는 역할을 명시적으로 부여 받았을때 실무의 비중을 얼마나 두어야할까? 과연 실무를 내려놓고 개발자가 매니징만 할 수 있을까? 한동안 답을 찾지 못했다. 선배들에게 조언을 구하면 늘 그 자리는 코드의 욕심을 내려놓아야한다는 이야기를 주로 들었다. 하지만 난 그때 실무를 내려놓지 못했다. 누군가를 믿지 못해서가 아니다. 실무는 내게 수많은 맥락을 제공한다. 그리고 그 맥락을 놓치면 나는 그 어떤 의사결정도 제대로 못할 것만 같은 두려움이 있었다.

그래서 실무를 모두 내려놓은 매니저의 삶도 살아봐야겠다는 생각도 했다. 물론 1년을 채 버티지 못하고 스스로 물러났지만 짧은 시간동안 큰 깨달음 얻고 내려왔으니 운이 좋았다. 이 과정에서 내가 배운건 개발자나 매니저나 본질은 똑같다는 거다. 결국 다 회사가 성공하기 위해 필요한 역할에 지나지 않는다. 그동안 조직장을 마치 상위 포지션이라고 생각했던게 나의 큰 착각이었다. 조직 구조도 결국 회사의 성공 확률을 높이기 위해 펼치는 여러 전략중에 하나일 뿐이다. 그러니 회사가 성장할때마다 조직개편을 하는거 아니겠는가?

아무튼 다시 개발자로 돌아왔다. 매니저에서 다시 개발자로 돌아갈땐 아무런 직책도 맡고 싶지 않았다. 그저 방망이 깎는 노인이고 싶었다. 하지만 현실은 나를 그렇게 쉽게 내버려두지 않는다. 이미 내 커리어에 조직장 경력이 있으니 회사는 나에게 리더의 역할도 은근히 기대한다. 나 또한 눈치가 있으니 그걸 모르진 않는다. 하지만 나도 다 계획이 있다.

팀빌딩의 시작

이번 스테이지는 순수하게 개발자로 다시 평가받고 싶었다. 그리고 조직장과 같은 직책 없이 열정 많은 한 개발자가 다른 팀원들에게 어떤 영향을 주는지 테스트해보고 싶었다. 그래서 오로지 개발만 할꺼라고 선을 긋고 입사했다. 어마어마한 코드베이스가 입사 첫날부터 나를 억누른다. 오래된 코드베이스는 전혀 트랜디하지 않았다. 코드를 수정하면 결과를 확인하는데까지 대략 30초. UI 개발에 코드 한줄 고치고 맞는지 확인하는데 30초는 어마어마한 시간이다. 결국 머리로 컴파일 하거나 개발자 도구를 열어서 직접 스타일을 바꾸고 확인한 후에 코드를 수정하고 다시 30초. 몇번을 반복하면 수많은 생각이 떠오른다. 아.. 이래서 다 그만 둔건가? 왜 이걸 아직까지 안고치고 있었던거지? 하아… 한숨이 절로 새어나오고 지금 생각해도 가슴이 턱턱 막힌다. 개발 환경을 트랜디하게 바꾸지 못하면 결국 아무것도 하지 못한다는 각오을 몇번이나 되새기며 시도하고 실패하고 롤백을 두번이나 했다. 그렇게 두번 연습하니 세번짼 성공 하더라. 진짜 혼자였으면 못했다.

개발 환경이 좀 개선됐다고 갑자기 개발속도가 빨라지진 않는다. 거대한 코드베이스 그 자체가 발목을 잡는다. 때론 폴더 구조 개선만으로 리팩토링이 쉬워질수도 있다. 하지만 변경된 파일만 1200개… ㄷㄷㄷ

거대한 코드베이스를 이해하려면 때론 화가가 되어야한다. 그림을 그리고 나면 비로서 맥락이 보이기 시작한다. 하지만 이 변경도 파일 90개, 추가된 코드 천줄, 빠진 코드 천줄!

초반에 이런 작업이 많으면 비동기 코드 리뷰 자체가 불가능하다. 그리고 모두 신규 입사자. 거대 코드 베이스를 연구하는 유적 발굴단처럼 뭔가 발견하면 같이 공유하고 연구해야하는 운명공동체! 그렇게 매일 아침 팀원들과 화이팅 넘치는 수다로 시작해서 PR 리뷰받고 바로 수정해서 병합하기를 반복했다. 그렇게 몇달을 하다보니 자연스레 오전 일과는 팀원들과 함께 보내는 날들이 쌓이고 팀 문화가 되어 버렸다.

그러던 어느날 폴이 말했다. 매일 출근했던 전직장보다 이상하게 더 많이 대화하고 친밀감도 높고 매일 보는것 같다고.. 리모트 환경에서 매일 오전을 함께 코드 리뷰하면서 보낸 시간이 팀워크를 다지는 시간이 됐다. 리모트로 일했던 이전 회사에서도 친밀감을 위해 오전에 의도적인 티타임을 했는데 친밀감을 높이진 못했던거 같다. 그보다 어느 순간엔 시간 낭비라는 생각도들고 티타임은 흐지부지 사라졌다. 그런데 이번엔 좀 달랐다. 어떤 차이가 있는 것일까? 아마도 공통의 목적을 가진 목적 조직이라서 가능한게 아닐까? 서로 다른 프로젝트를 하는 기능조직에선 내 PR을 들고와서 같이 고민한다는게 쉽지는 않은 것 같다.

다시 심겨지는 잔디

매니저로 있었던 시기나 보안에 민감했던 회사에선 보통 엔터프라이즈 깃헙을 사용하기 때문에 개인 계정에 잔디 심기가 쉽지 않다. 퇴직하고 구직자로 전환되는 순간 이 잔디 심기가 마음에 좀 걸리는데 왜냐면 내가 누군가를 채용하는 면접관이었을 때 나는 항상 지원자의 블로그와 깃헙을 찾아보곤했다. 좋은 사람을 채용하려면 그만한 노력이 수반된다. 짧은 면접에 이사람의 장단점을 극적으로 뽑아내려면 면접관은 FBI가 되어야한다. 사전에 알수있는 정보가 많다면 미리 알고 들어가는게 좋다. 그래야 양질의 질문을 할수있기 때문이다. 지피지기면 백전 백승!

여하튼 이런 이유로 나는 이력서에 블로그와 깃헙 계정이 없는 지원자는 대부분 서류에서 탈락시켰다. 이제 그 화살이 내게 다시 돌아왔다. ㅎㅎㅎ 구직자는 열심히 블로깅하고 깃헙에 액티비티가 없는 이유를 방어해야한다. 내가 이런 글을 쓰고 있는 것도 다 이런 이유가 있는거다!

아무튼 나는 지난 2년 5개월을 충실히 개발자로 살았다. 빼곡한 잔디가 농부의 마음처럼 뿌듯하다. 심지어 이 잔디는 스쿼시 PR 로만 쌓은 커밋이라 자부심 하나를 더 한다.

그리고 나는 한 아이의 아빠로 충실한 삶을 살았다. 결혼하고 아이가 생기면 개발자에겐 큰 시련이 온다. 공부할 시간이 절대적으로 부족하기 때문이다. 재택으로 일 하다 보면 퇴근보다 아이의 하원이 빨라서 강제 육아 모드로 전환된다. 부모로부터 물려받은 성격이 있어서 직업윤리를 벗어나는 행동을 잘 하지 못한다. 그러다보니 하던일을 마무리하지 못하면 육퇴한 밤 11시에 업무로 다시 돌아가곤했다. 그러니까 잔디가 저렇게 금요일에서 토요일로 넘어가는 경계에도 심겨버린다. 특히 디버깅 중에 육아로 강제 전환되면 헤어나오질 못한다. 아이를 씻기면서도 머릿속에선 컴파일 중이다.

하루는 아이가 미열이 있어 어린이집을 보내지 않았다. 엄마도 5일간 자리를 비운 탓에 온전히 육아와 일을 병행해야하는 상황에 놓였다. 아빠와 노는게 좋은 우리 아이는 늘 그렇듯 아빠 책상 옆에 긴 의자를 하나 대놓고 종이 접기에 한창이다. 만 4살은 종이 접기를 잘 할 수 없는 나이다. 그러니 간간히 놀아달라 접어달라 인터럽트가 꾀나 집요하다. 회의하다말고 마이크를 끄고 버럭 화를 냈다. “기다려! 아빠 회의 좀 하자!” 시무룩해진 아이는 어느새 조용해진다. 그리고 나는 다시 돌아가 30분을 더 떠들고나서야 아이 생각에 옆을 본다. 세상 곤히 잠든 아이… ‘아!… 내가 무슨 부귀 영화를 누리겠다고 이 지랄을 하고 있나..’ 싶은 생각이 들 정도로 기다리다 지쳐 쭈구려 자고 있는 아이를 보면 명치 한구석에서 짠~~ 함이 몰려온다.

육아와 일을 병행하는 부모라면 엄마 아빠 할 것 없이 모두 이와 비슷한 경험을 했을 것이다. 그래서 나는 당분간 시대가 필요로 하는 개발자이길 포기했다. 육아와 업무만으로도 벅찬데, AI 시대에 LLM 공부를 어떻게 하나? 물론 나도 책은 사뒀지만 읽기가 참 어렵더라. 지속적인 학습이 되지 않는 상황이라면 도로묵이다. 과감히 투자를 포기한다. 한때 기업 강의를 꾸준히했던 덕에 여기 저기서 들어오던 강의 요청도 모두 거절했다. 나는 아이가 10살이 되기 전까진 뛰어난 개발자보다는 그냥 좀 더 성숙한 아빠가 되고자 한다.

개발자도 사람이다.

일정 수준에 도달한 이후 공부를 하지 않는 개발자에 대한 이야기가 한동안 돌았다. 내심 찔리긴 했지만 몰라! 나는 지금 그게 중요하지 않다. 아이가 지금 짠 한데 무슨 천자문 공부냐? 나는 그럴수록 더 다짐한다. 개발자이기 전에 성숙한 더 나은 사람이 되자.

그런데 재밌는건 시니어 개발자의 기준을 어떻게 가르나요? 라고 동료 개발자들에게 물어보면 코딩을 잘 한다거나 지속적인 학습을 하는 개발자라고 딱히 시니어라고 평가하지는 않았다. 오히려 그 외적인 모든 것을 기준삼는 경우가 많았다. 예를 들면 그 중 하나가 소통 능력인데 아이러니하게 아이와 대화하다보면 소통 능력과 인내심이 발달한다.

아이는 모든 것에 서툴고 실수 투성이다. 인내심도 어른 같지 않아서 징징대고 떼쓰기 일쑤다. 그런 아이를 보고 있노라면 나도 모르게 버럭 할때가 있다. 그럼 또 미안해서 사과하면 괜찮다며 이해한다고 나를 위로해준다. 이게 어른인지 애인지 가끔 헷갈린다. 한번은 어린이집에서 길을 건널때 손들고 건너야 한다고 배웠나보다. 나와 건널목을 걷는데 나에게 왜 손을 들지 않냐며 아빠도 어서 손을 들라고 성화를 내 길래… 일단은 손을 들어 건넌 후에 차분히 아이에게 설명했다.

“라일아, 길 건널때 왜 손 들고 가야하는지 알아?” / 쭈볏쭈볏 (내심 그 이유는 모르는것 같다) / “아빠가 설명 해줄께. 잘 들어봐! 라일이는 키가 작아서 운전하는 사람이 잘 못 봐. 그래서 키 작은 사람은 손을 들어줘야 운전자가 보고 멈출수있어. 그래서 아빠 어릴땐 큰 노란색 카드를 들고 다녔거든. 그런데 지금은 아빠가 키가 커서 노란색 카드도 필요 없고, 굳이 손들고 걷지 않아도 돼”

이날 이후 우리 아이는 내가 손을 들지 않아도 뭐라고하지 않는다. 하루는 아이에게 다시 질문했다.

“라일아, 길 건널때 왜 손들고 걸어야해?” / “어..왜냐면 내가 키가 작아서 운전하는 사람이 날 잘 못봐 그래서 손을 안들면 나를 쾅~하고 치고 갈수있어. 그래서 손드는 거야” / 덜덜덜… 물어본 내가 바보다. 이미 한방에 이해하고 있었다.

여하튼 나와 아내의 육아관은 아이에게 ‘너 자꾸 떼쓰면 망태기 할머니가 너 잡아간다’ 라는 과장된 이야기를 하지 않고, 정확한 이유를 설명하고 있는데 이게 습관이 되다보니 직장 생활에서도 이어진다. 평소에도 되짚는 질문을 많이 하는데 다행히 동료들도 내 질문을 공격적으로 받아들이진 않는것 같다. 되려 본질을 다시 고민해서 좋다고 피드백받아서 안심했다.

팀워크의 본질

육아 하면서 아이에게 배우는게 참 많다보니 사회생활에서 주니어와 시니어를 나누는 것 자체가 모순이라는 생각이든다. 시니어라고 항상 완벽하고 누군가를 이끌어야하는 존재도 아니고 주니어라고 항상 배워야하는 존재도 아니다. 우리는 모두 불완전한 존재다. 그러니까 팀으로 일한다.

7년전이었나? 넷플릭스 인재상이 한때 유행한적이 있었다. 모든 것에 유능한 만랩 개발자! 나 또한 이 인재상을 차용해 팀원들과 일대일 면담을 할 때 나만의 원통형 개발자 이론을 열심히 설파했던 적이 있었다. 원통형 개발자는 이런거다. 마치 축구 게임의 레이더 그래프처럼 슈팅, 스태미너, 패싱, 롱킥, 태클, 수비 등등 능력을 표현하는 요소들이 무수히 많고, 그 능력치가 만랩인 사람이 최고의 개발자라는 지론 그리고 그런 사람하고 일할때 나는 너무 좋았다. 그러니 너희들도 만랩이 되어라… 라고 설파한건 아니다.

7,800개의 Radar graph 이미지, 스톡 사진, 3D 오브젝트, 벡터 | Shutterstock

원통형 인재의 핵심은 “너만의 핵심 팩터를 스스로 결정하고 그 파이의 크기를 키워라” 라는게 나의 핵심 골자다. 왜냐면 축구팀에 메시만 존재하는건 아니니까. 위치에 따라 혹은 대항하는 팀에따라 다양한 능력의 선수들이 기용되기 때문이다. 다 각자 개성대로 쓸모가 있다.

어쨌든 이런 사고의 시작은 넷플릭스 만랩 개발자에서 영향을 받은건 사실이다. 그래서 팀을 상상할때도 만랩 개발자들이 있는 팀에서 일하고 싶은 욕망이 강했다. 이상적인 팀이란 그런 만랩 개발자가 모인 팀이라 생각했다. 그리고 그런 팀이라고 생각했던 회사를 다녔던 적도 있다.

그런데 이번 스테이지에서 생각이 바꼈다. 현실에서 팀원 개개인은 만랩일수없다. 그리고 생각해보니 만랩이라고 생각했던 팀에서 나는 혼자 일한 경험이 더 많다. 만랩 개발자는 굳이 팀으로 일할 필요가 없다. 오히려 만랩 개발자들이 모여서 불협화음을 낸 팀도 봤다.

팀을 만드는 이유는 개인이 불완전하기 때문이다. 불완전한 개인을 보완하는 수단으로 현실에선 팀으로 일한다. 나는 팀안에서 나의 부족함을 수혈받는 경험을 지난 2년 동안 무수히 많이했다. 대표적인 예시는 이런거다. 하루종일 혹은 밤새며 몇일간 버그와 씨름하고 있다. 그러다가 도저히 머리가 안돌아가서 다음날 아침에 팀원들에게 가져가면 여지없이 5분만에 해결되는 경험을 하게 된다. 또 이런 경험들이 쌓이면 팀안에서 안정감마저든다.

하루는 팀원들에게 이런 고백을 했다. “나는 시니어지만 시니어라고 모든걸 다 잘하진 않는다. 그래서 때론 불안한데, 우리 팀에서 나는 그 불안함이 없다. 내가 못풀면 내일 아침, 알란이나 폴이 분명 이 문제를 풀어줄꺼란 확신이든다.” 이런 안정감을 주는 팀은 내 커리어 안에서 없었던것 같다. 우리팀이 최고다! 작개는 3명인 개발팀이지만 크게는 목적 조직으로 7명인 팀 안에서 나의 이런 불완전함을 심심치 않게 고백한다. 언제 어디서 이런 팀원을 또 만날수있을까? 감사하고 또 감사한 일이다. 퇴직함으로써 이런 팀원들과 헤어지는건 분명 아쉬운 일이다. 그런데 뭐 헤어짐의 이유가 나의 퇴직은 아니니까. 아쉬워도 어쩔수없다.

내가 2년전 팀에 합류할때 왜 무너진 팀에 합류하냐면 나를 만류하던 지인들에게 무너진 팀을 재건하는게 내 전문이라고 호기롭게 얘기했던거 같다. 그런데 정작 팀 회고에선 어떻게 이런 팀원들을 만났는지 이건 운빨이라고… ㅎㅎㅎ

그래서 다음 스테이지에선 이게 운빨이 아님을 증명하고 싶다. 좋은 팀은 운빨일 수 없다. 좋은 팀은 의식을 가지고 만들어지는거다. 다시 한번 주문을 외울때가 되었다.

퍼스널 칸반으로 생산성과 효율성 높이기

2024년 7월 17일2024년 7월 17일 불꽃남자 1 Comment

💡 이 글은 필자가 구상하고 있는 지라(JIRA)관련 포스트 중에 하나입니다. "퍼스널 칸반"이라는 책 내용이 좋아서 팀원들에게 소개하려고 작성한 글입니다. 그래서 설명 중간중간 현실에 존재하는 지라 프로젝트의 차트를 참고 삼아 붙여넣었습니다. 지라는 제가 좋아하는 도구라서 본질을 설명하기 위한 도구일 뿐이니 큰 의미를 두지 마세요!

<퍼스널 칸반>은 린(Lean)이라는 경영 개념의 원칙과 기법을 바탕으로 한다. 이는 좋은 의사결정을 통해 가치를 창출하는 것이 중요하며, 좋은 의사결정을 위해서는 정보를 쉽게 접근할 수 있어야 한다는 것을 의미한다.

정보 접근성이 높아지면 사람들은 더 존중받는 느낌을 받고, 존중받는 팀은 쉽게 동기부여된다. 동기부여된 팀은 그렇지 못한 팀에 비해 불필요한 소통 비용도 줄어든다.

내 경험으로 볼 때, 정보를 공개하는 것만으로도 정보 접근성이 높아진다. 하지만 개인이 감당하기 어려울 만큼 정보가 넘쳐나면 필요한 정보에 접근할 확률은 오히려 떨어진다. 따라서 정보 접근성은 단순히 정보를 공개하는 것에서 그치지 않고, 핵심 정보를 쉽게 파악할 수 있도록 명확하고 체계적으로 구성되어야 한다.

이런 의미에서 정보를 한눈에 파악할 수 있도록 시각화하는 것은 중요하다. 시각화를 통해 정보를 구조적으로 파악하게 되면, 문제가 쉽게 드러나고 해결책도 찾기 쉬워진다.

칸반의 두가지 규칙

업무 시각화 → 지라 보드 만들기
진행중인 업무의 수 제한 → WIP(Work In Process) Limit

업무 시각화가 필요한 이유

그동안 해야 할 일을 엑셀 표와 같은 목록으로 관리했다면 이제 칸반으로 바꿔보자. 단순한 할일 목록을 칸반으로 전환할 때는 각각의 일들이 어떤 흐름을 가지는지 생각해봐야 한다. 완료 여부에만 관심을 갖는 할일 목록에 비해 칸반은 고려해야 할 포인트가 많다.

우선, 일감이 어디서 시작되고 어떤 흐름을 거쳐 완료되는지 알아야 한다. 이를 워크플로우(workflow)라고 부른다. 칸반은 이 업무 흐름을 구체화하고 가시화하는 것부터 시작한다. 그리고 그 흐름을 들여다보면 생각보다 많은 맥락과 정보를 알 수 있다.

업무 흐름을 관찰하다보면 충분히 알수 있는 정보들

누가 무엇을 원하는지
누가 무엇을 하고 있는지
어떻게 그것을 하는지
누구와 그것을 하는지
무엇을 완료 했는지
무엇을 아직 끝내지 못했는지
얼마나 빨리 일을 처리 했는지
무엇이 병목을 만드는지
언제 그리고 왜 꾸물거리는지
언제 그리고 왜 어떠한 특정 활동으로 인해 불안해 하는지
무엇을 약속할 수 있는지
무엇을 거절할 수 있는지

시각화된 칸반 보드는 마치 차량의 계기판처럼 필요한 정보를 한눈에 알수있다. 현재 상황을 정확히 파악하면 더 나은 의사결정도 할 수 있다. 의사결정은 경영진만 하는 것이 아니다. 우리는 매일 주어진 업무 중에서 오늘 가장 먼저 처리할 일을 선택하는 의사결정을 한다.

칸반보드는 차량의 계기판 처럼 현재 상황과 맥락을 보여주는 현황판 역할을 한다.

개인이 업무를 선택하는 기준은 다양하다. 회사의 업무뿐만 아니라 공과금을 납부하거나, 잠시 자리를 비우고 산책을 하거나, 아이를 목욕시키는 일도 매일 같이 주어진다. 이러한 일들은 상황과 맥락에 따라 우선순위가 변한다.

우리는 상황에 따라 진행할 업무를 선택한다.

특히 기한이 정해진 일(예: 고정된 날짜, 두 번째 그래프)은 정해진 날짜 안에 완료해야만 의미가 있다. 예를 들어, 크리스마스 이벤트 광고를 여름에 집행하는 것은 아무런 효과가 없다. 크리스마스 이벤트는 반드시 크리스마스 시즌에 맞춰 진행해야 한다. 숙제를 미리 한다고 항상 좋은 것은 아니다. 숙제를 하는 동안 꼭 봐야 할 경기를 놓칠 수도 있다.

공과금을 납부하는 일(두 번째 그림)도 납부 기한을 넘기면 연체료가 발생하지만, 납부 기한 전까지는 추가 비용이 발생하지 않기 때문에 우선순위를 미뤄둘 수 있다. 일찍 해결한다고 보상이 주어지지 않는 숙제는 밀리고 밀려 한 번에 해결하는 경우가 많다.

따라서 우리는 업무의 영향력, 시급성, 지연 비용등을 모두 고려해 최선의 의사결정을 해야한다.

칸반으로 일 하기

STEP1. 업무가 시작되어 완료될때까지의 가치 흐름을 만들자.

TODO → DOING → DONE
아주 단순한 흐름

보통 대부분의 일들은 단순한 흐름을 가진다. 하지만 일에 따라서 그 과정은 더 길어질수도 더 복잡해질수도 있다. 채용과정을 생각해보자.

채용 과정에서 지원자가 오퍼를 수락하는 행위 외에도 여러 가지 이유로 이탈할 수 있다. 채용 프로세스를 시각화하면 지원자가 어느 단계에서 이탈했는지 쉽게 알 수 있어 프로세스 개선이 한결 수월해진다. 위에서 표현된 채용 과정의 흐름은 크게 성공(Accepted)과 실패(Rejected)로 나뉘지만, 더 복잡하게 표현할 수도 있다. 또한, 동일한 업무 흐름을 가지더라도 가치 흐름은 개인의 관심사에 따라 다르게 표현될 수 있다.

예를 들어, 채용 과정에서 면접관으로 참여하는 사람이라면 오퍼를 조율하는 과정보다 인터뷰와 인터뷰 후의 논의 과정에 더 의미를 두게 된다. 따라서 아래와 같은 가치 흐름을 만들 수 있다.

지원자 → 인터뷰 → 디브리핑 → 완료

한동안 내가 몸담았던 회사에서는 위와 같은 워크플로우를 이용해 스토리를 정의했다. 꽤나 복잡하지만, 개발자인 내가 관심 있는 영역과 프로덕트 매니저, 디자이너, QA가 보는 관점에 따라 가치 흐름은 다를 수 있다. JIRA에서는 서로 다른 관점의 가치 흐름을 각기 다른 보드로 표현할 수 있다.

이제 업무 흐름을 칸반 보드에 올려보자. 다양한 방향으로 확장되는 업무 흐름도 칸반 보드 위에 올리면 단순해진다. 즉, 왼쪽에서 시작해 오른쪽으로 흘러가는 단방향으로만 표현되는데, 이 흐름이 단순하기 때문에 조절도 쉽다.

지라에서 업무흐름을 가치 흐름으로 변환하기 위해선 적절한 컬럼을 찾아 배치해야한다.

STEP2. 백로그를 만들자.

백로그는 내가 해야 하는 모든 유형의 일을 의미한다. 해야 할 일을 놓치지 않기 위해 백로그에 일감을 쌓기만 하고 구체화하는 과정을 생략하는 경우가 많다. 그러나 백로그를 관리한다는 것은 단순히 일감을 쌓는 행위가 아니라 일감을 구체화하는 행위를 의미한다.

백로그를 관리하다 보면 모호하게 정의된 일감과 명확하게 정리된 일감이 함께 존재하게 된다. 그리고 그 사이의 경계를 만들 필요가 생길 것이다. 예를 들어, 단순히 쌓아놓은 일감, 구체화가 필요한 일감(플래닝), 그리고 구체화된 일감(할일)을 구분하고 싶을 수 있다.

지라의 백로그는 메뉴가 분리되어 있다. 백로그를 사용하려면 원하는 상태값을 드래그엔 드랍해서 백로그로 옮겨둔다.

위와 같이 지라 칸반은 백로그에 워크플로우 상태를 적절히 배치하면 아래와 같이 백로그 작업에 집중할수있도록 별도의 백로그 화면을 제공한다.

백로그 작업이란 모호함을 구체화하는 과정이다. 버전 태깅과 기한 설정, 담당자 지정과 인수테스트 작성 등이 백로그 작업이다.

백로그 작업이 필요한 이유

구조적 명확성이 우리 행동에 미치는 영향을 측정하기 위한 실험이 있다. 아래 3개의 학급에 각각 다른 형태의 과제 마감일을 지정해주었고 과제 제출일이 늦어지면 감점을 받는다. 다음중 가장 높은 점수를 받은 그룹은 어떻게 될까?

고정된 마감일을 지정해준 학급
학생들이 개별적으로 마감일을 지정하도록 허용한 학급
특정한 마감일이 없이 학기 중에 언제든 과제 제출을 허용한 학급

실험 결과
1번 > 2번 > 3번 순으로 좋은 점수를 받았다. 이 실험이 주는 의미는 마감일이 중요하다는 것이 아니다. 마감일은 명확성을 대표하는 하나의 지표일 뿐이다.

우리 업무는 기한이 정해진 일감과 정해지지 않은 일감이 늘 혼재되어 있다. 이 혼재된 일감 중에서 모든 일에 기한을 정하는 것이 목표가 되어서는 안 된다. 모든 일감에 기한이 정해진 시스템은 우리에게 일을 수동적으로 하도록 강요하고, 과도한 기한 설정은 의욕을 저하시킬 수도 있다. 우리가 칸반으로 일을 하는 이유는 기한이 있던 없던 적절하게 조절하여 능동적으로 일을 하기 위함이다. 즉, 수동과 능동의 적절한 균형을 지속적으로 찾아야 한다.

결론
백로그는 일감을 쌓는것이 목적이 아니다. 백로그에 쌓인 일감을 구체화하고 일을 시작할수 있는 상태로 만드는 것이 목적이다.

백로그(Backlog) → 준비(Ready) → 할일 → 진행중 → 완료

STEP3. 진행중 업무의 개수를 제한하자

제이가르니크(Bluma Zeigrnik) 효과에 따르면 사람은 완료된 것보다 중단되거나 미완료된 생각이나 행동을 기억할 확률이 90%나 더 높다고 한다. 이는 우리 뇌가 의미를 처리하기 위해 패턴을 찾는 경향이 있어 빠진 정보에 집착한다는 것을 의미한다. 그래서 완료되지 않은 일감의 수가 증가할수록 우리 뇌는 미완료 된 일감을 끝내기 위해 관심의 경쟁을 하게 되는데, 결국엔 어느 하나 제대로 집중하지 못하고 잡념에 빠져 있는 나를 발견하게 된다. 즉, 생산성 자체를 떨어트린다.

저글링의 예를 들어보자. 처음엔 두개를 가지고 던지고 받다가 익숙해지면 점차 갯수를 늘려가게 된다. 그리고 결국 아무리 연습해도 도달하지 못하는 개수에 도달하게 되는데 개인마다 그 한계는 다를수 있지만 한계치를 넘으면 저글링 자체를 하지 못한다.

진행중인 업무를 제한(WIP Limit, Working In Process Limit)해서 동시에 처리하는 일을 막으면 아이러니하게 저글링 자체를 못하는 상황을 막기 때문에 더 많은 업무를 완수할수있다. 결과적으로 생산성이 높아지는 효과를 얻게 될것이다.

이렇게 내가 지금 해야하는 일에만 집중하게 만들면 불필요한 일을 안하게 되어 결과적으로 더 많은 일을 할수있고 효율적으로 일할수 있다.

JIRA 에서는 Min, Max 값을 조절해 WIP Limit을 조절할수있다.

칸반으로 일 할땐 생산성과 효율성 그리고 효과성을 모두 개선의 대상으로 두고 회고를 통해 균형을 찾아야한다.

생산성, 효율성, 그리고 효과성에 대한 바른 이해

생산성(productivity) – 얼마나 많은 일을 완료했는지에 관한 것(꼭 필요한 일이었는지와는 무관)

누적흐름도표가 가파르게 우상향으로 올라가면 팀의 생산성이 증가하고 있다고 볼수있다.

지라의 누적흐름도표는 우리가 얼마나 많은 일을 완료 했는지 쉽게 확인할수 있다. 그리고 도표의 기울기가 가파를수록 생산성이 높음을 의미하지만 이 지표 하나로 우리가 얼마나 효율적이고 효과적으로 일 했는지는 알수 없다.

효율성(efficiency) – 일을 얼마나 쉽게 완수 했는지에 관한 것(최대의 효과/결과를 얻는 데에도 도움이 되었는지와는 무관)

컨트롤 차트의 빨간색 기준은 전체 기간의 산술적 평균으로 이슈 하나가 끝나는데 얼마나 걸리는지를 알수있다.

지라의 컨트롤 차트는 우리가 이슈 하나를 완료하는데 얼마나 시간을 들이고 있는지 알수있다. 파란색 롤링 평균이 아래로 내려가거나 빨간색 평균 이하로 내려가면 효율적으로 일 하고 있음을 의미한다.

효과성(effectiveness) – 적합한 일(right work)을 적시(right time)에 완수 했는지에 관한 것(지속 반복이 가능한지는 또 다른 문제임)

칸반보드의 스윔레인과 필터과 그리고 자동화를 이용해 내가 해야하는 일을 효과적으로 선택할 수 있다.

지라 칸반보드는 스윔레인과 필터 그리고 자동화를 통해 다양하게 시각화를 할수있다. 시각화된 일감은 어떤 일이 구체화가 필요한지, 얼마나 지연되고 있는지, 내가 일할 여력이 있는지 다른 누군가가 나의 도움이 필요한 상황은 아닌지 다양한 정보를 파악하고 효과적으로 의사결정을 할수 있도록 도와준다.

STEP4. 일감을 당겨오기(pull)

당김(pull)은 내가 작업할 준비가 되었을때만 일감을 진행중 칸으로 끌어오는 것을 의미한다. 효과적으로 일하려면 현재 나의 상황에서 적합한 일의 우선순위를 따져서 당겨와야한다. 그리고 일감을 당길때는 WIP 제한 이상으로 당겨서는 안된다.

어떤 것이 가장 급한 작업인가?
회의 가기전 30분 동안 할수있는 일이 무엇인가?
어떤 작업들을 함께 묶어 일괄 처리 할수 있을까?

퍼스널 칸반의 WIP 제한은 개인의 영역이지만 팀으로 움직일땐 WIP 제한은 합의가 필요하다.

퍼스널 칸반은 내 업무만 집중하기 때문에 WIP 설정에 자유도가 높지만 협업할때는 상호간의 합의가 반드시 필요하다. 일반적으로 WIP 제한은 협업자의 수 만큼으로 제한한다.

수용량과 쓰루풋에 대한 바른 이해

수용량(capacity): 얼마나 많은 업무를 최대로 수용할 수 있는가? → 공간적 개념
쓰루풋(throughput): 얼마나 많은 업무가 실제로 빠르게 처리되고 있는가? → 흐름의 개념

수용량은 정해진 크기에 무언가를 담는 개념으로 하루를 업무로 채울 수 있다.

우리에게 주어진 시간을 업무로 채우는 수용량의 개념으로만 생각해보면 하루 일과를 업무로 꽉 채우는 것이 가장 좋을 것이다. 하지만 업무는 채우기만 한다고 끝나는게 아니다. 채워진 업무를 완료해야 비로소 의미를 가진다. 따라서 우리 업무는 보유하는 것이 아니라 처리하는 흐름의 개념으로 이해해야한다. 즉, 수용량이 아닌 쓰루풋으로 바꿔야한다.

처리량(쓰루풋)은 도로에 비유할수있다. 양방향 4차선 도로에 상행선(좌 ← 우) 도로는 수용량이 높지만 흐름이 원활하지 않기 때문에 일정 시간동안 한 구간을 지나는 차량의 수는 많지 않다.

반면, 하행선(좌 → 우) 도로는 수용량은 적지만 흐름은 원활하다. 하지만 수용량 자체가 높지 않기 때문에 일정 시간동안 한 구간을 지나는 차량의 수(쓰루풋)는 많지 않다.

따라서 우리는 처리량을 높이기 위해 통행이 원활한 적절한 수용량을 찾아야한다. 우리의 하루 일과를 업무로 꽉 채우면 생각보다 많은 일을 완료하지 못한다. 도로에 적절한 공간이 있어야 통행이 되는 것처럼 우리의 업무 사이에도 적절한 여백과 휴식이 필요하다.

STEP5. 성찰(reflect)을 하자.

칸반은 흐름에 집중하기 때문에 일정기간이 지나면 반드시 오른쪽 끝에 그동안 내가 해온 업무들이 쌓인다.

지라에서 완료한 업무는 릴리즈 행위를 통해 한꺼번에 없애거나 자동으로 필터해서 없앨 수 도 있다.

일정기간 완료한 업무가 많다는 것은 내가 생산적으로 살았음을 의미하지만 효과적인지는 알수없다. 효과적으로 살아왔는지는 시간을 내어 스스로 질문해봐야한다.

어떤 일을 특히 잘 했나?
어떤 일을 행할 때 기분이 좋았나?
어떤 일을 완료하기 어려웠나?
적합한 일감을 골라서 적절한 시간 안에 처리했나?
완료한 일이 어떤 의미가 있나?

셀프 회고는 주기적으로 하는 것이 좋다. 1주일이든 한달이든 자신만의 보드를 만들고 회고를 해보자. 지라 보드를 사용하면 자동으로 수집된 통계 데이터를 활용할 수 있어 감정적인 회고를 피하고 데이터 기반의 회고를 할수있다.

지라 보고서 활용하기

다양한 보고서를 활용해 데이터 기반으로 회고를 해보자! 프로젝트 회고와 관련된 내용은 다른 글에서 다룬다.

지라는 업무흐름(workflow)에 따라 가치흐름(보드)을 만들어 잘 사용하기만 하면 다양한 후행지표를 만들어준다. 대표적인 후행 지표가 누적흐름도표와 컨트롤 차트다. 이런 지표들은 결과를 수치로만 반영하기 때문에 일하면서 발생하는 수많은 맥락이 생략되어 있다. 따라서 지표가 이상하다 싶으면 회고 과정을 통해 그 속에 숨어있는 맥락을 찾아내야한다.

평균 수명 보고서

미해결(Resolution is Empty)된 이슈의 평균 수명 ( 현재시간 – 생성시간 )

완료된 이슈가 많을수록 미해결 평균 수명은 줄어든다.
프로젝트에 남은 이슈가 해결되는데 필요한 평균 리드 타임으로 예상할수있다.
리드타임이 줄어들수록 고객에게 전달되는 가치 전달주기는 짧다.
그만큼 회고 주기가 짧아지고 개선할 수 있는 여지가 많아진다.
이슈의 평균 수명은 이상적으로는 배포 주기와 비슷하거나 배포 주기보다 작아야한다.
평균 수명이 리드타임을 훌쩍 뛰어넘는 방치된 이슈가 없는지 확인한다.
방치된 이슈가 많으면 일은 많은 것 같은 착시를 불러 일으킨다.

생성대비 해결된 이슈 보고서

생성 대비 해결된 이슈 보고서: 생성된 이슈 갯수와 해결된 이슈 갯수의 차이

백로그가 쌓이는 속도와 해결되는 속도를 비교해볼수있다.
백로그가 쌓이는 속도와 해결되는 속도가 비슷하거나 해결속도가 높아야 팀이 건강해진다.
백로그가 쌓이는 속도가 해결속도보다 높으면 해결을 위한 분석이 필요하다.
해결 가속도(기울기)가 일정하면 팀이 안정적임을 의미한다. 일정한 기울기가 아니라면 분석이 필요하다.