2023년 업무능률 스터디

• 개요
• 팀 구성에 대해
  • 인원을 더 투입하지 않고, 그 대신 문제를 쪼갠다
  • 팀원이 많으면 팀 역량을 넘어설 정도로 많은 일을 받게 된다
  • 머릿속에 전체적인 그림을 담고 매일 같이 일하기
  • 팀 쪼개기 전에 미리 계획하기
• 회의에 대해
  • 회의 오너가 회의를 준비한다
  • 필요없는 회의를 열지 않는다
  • 파워포인트 자료는 지양한다
  • 고민할 문제: 회의에서 나가기
  • 내가 2023-03 부터 해보고 있는 시도
• 업무 방식에 대해
  • 스프린트
  • 업무 중복에 대해
  • 계획에 없던 업무와 싸우기
  • WIP limit
    • 바쁜 것보다 여유있게 일하는 것이 더 빠르다?
    • WIP가 너무 많은지 알아보는 방법
    • 나의 결론: WIP limit은 엄청 중요하다
• 참고문헌
• 하위 문서
• 주석

개요

다음은 내가 2023-02-23에 쓴 일기를 일부 발췌한 것이다.

회사생활을 쭉 해오며 느끼는 건 팀으로 작업을 하면 일이 더 잘 될 거 같은데 생각보다 그렇지 않은 경우가 꽤 많다는 것. 예를 들어 어떤 일을 5명이 6달간 작업해서 그럭저럭 만들었는데, 결과를 이야기해보면 나 혼자 작업했으면 3달이면 끝났겠는데? 라고 팀원들이 회고하는 경우가 있다.

물론 결과를 보고 과거의 선택들을 가볍게 생각하기 때문이기도 하지만, 정말로 이런 경우가 있다. 팀 구성으로 인한 오버헤드가 팀을 잡아먹는 경우가 실제로 발생하곤 한다. 혼자, 아니면 친한 동료와 둘이서 작업했으면 일주일이면 됐을 일을 팀 전체가 몇 달이나 잡고 있는 경우도 있는 것.

왜 이런 일이 발생하나? 어떻게 해야 이런 일을 피할 수 있나? → 잘 모르겠음. 그냥 이런 일들이 일어나곤 한다는 것만 알 수 있고, 딱히 누구 탓이라고 할 수도 없고, 리더 탓도 아님. 모든 것이 암흑 속에 있고 마냥 생각하다보면 브룩스의 법칙이 시작부터 적용된 것 같은 느낌이 들곤 한다.

(후략)

나는 다음과 같은 생각을 하게 되었다.

• 팀은 3~8명 정도가 적당하다.
  • 이 규모를 넘기면 쪼개도록 한다.
  • 팀을 쪼갤 때 팀이 관리하기 쉽도록 코드 베이스도 리팩토링해서 합치거나, 분리한다. (확신 없음)
  • 조직이 아주 커지면 프랙탈 구조를 이루는 트리가 되도록 한다.
  • [[/jargon/two-pizza-team]]도 참고.
• 스쿼드 제도는 운영하지 않는 것이 좋은 것 같다.
  • 스쿼드 제도를 굳이 운영해야 한다면 생명주기를 짧게 잡는다.
    • 스쿼드는 특정 목표를 달성하기 위해 만든다.
    • 스쿼드의 목표는 3~5주 내에 완료할 수 있는 것으로 잡는다.
    • 목표를 달성하면 스쿼드를 해체한다.
  • 스쿼드 경계가 약하거나 잘 허물어질 수 있어야 좋은 것 같다.
    • 오래 지속되는 스쿼드가 별로인 이유는 사람이 고인물이 되기 때문이다.
      • 자기 스쿼드 업무만 하다보면 다른 사람들이 하는 일을 잘 모른다.
      • 스쿼드의 지식이 다른 스쿼드로 잘 전파되지 않게 된다.
    • 사람이 조금씩 조금씩 다른 스쿼드로 잘 이동할 수 있다면 스쿼드 제도도 그리 나쁘지 않을 것.
• 스프린트를 통한 업무능률 개선
  • 이론은 완벽한데 할 수 있을까? (자신 없다)
    • 스프린트 → 결과 측정 → 회고 → 개선점 파악, 해결 → 다음 스프린트.
      • 이 과정을 통해 팀 생산성이 높아지고 있는지 파악한다.
      • 다른 단위와 비교가 안 되는 [[/agile/story-point]] 등을 통해, 각 스프린트별 생산성을 측정한다.
  • 스프린트를 팀 생산성 향상이라는 목표로 돌리지 않고, 그냥 프로젝트 업무 단위로 쓰는 경우를 종종 봤다.
    • 그래서 이름만 스프린트인 경우가 좀 있다.
    • 스토리 포인트도 오해받기 쉬운 개념. 왜 스토리 포인트를 사용하는지 공유를 잘해야 한다. (벌써 피곤함)
      • 관리자: 스토리 포인트 10이면 개발자 1명이 10일 걸린다는 거야?
      • 개발자: 스토리 포인트가 뭔지 모르겠다. 그냥 Men-days라고 생각하고 써서 제출하자.
      • 다른팀 사람: 저 팀은 일주일치 작업에 스토리 포인트 5를 주던데 우리팀은 왜 10이에요?
      • 스토리 포인트는 일정 산출용이 아님. 팀 능률 측정용 상대적 단위. 팀마다 다르게 써도 이상한 게 아님.
        • 예: 과거의 우리팀과 요즘의 우리팀의 능률을 비교하는 용도.
  • 이걸 잘 하려면 팀 리더의 강인한 의지와 팀원들의 적극적인 참여가 중요한 것 같다. 쉽지 않다.
• 가능한 모든 업무를 가시화한다. (확신)
  • 그냥 문서를 잘 기록하자의 개념이 아님.
  • 사람은 한 눈에 들어오는 것을 더 잘 이해하고, 더 잘 관리한다.
    • 미니맵이 없는 게임, TOC가 없는 위키백과, Project Explorer가 없는 IDE를 떠올려 볼 것.
  • 업무 미니맵을 만들도록 하자.
  • 칸반도 좋은 방법이 될까? (확신 없음)
• 회의는 효율적으로. (말은 쉽다)
  • 회의 전에 회의의 목적과 진행방향, 숙지할 자료 등을 포함시킨 문서를 짧게 작성해 공지한다.
  • 내가 멍때리는 시간을 최소화해야 한다. (이게 제일 중요)
  • 회의 중에 대충이라도 회의록을 작성한다.
    • 원격 회의 중이라면 채팅창에 다른 사람이 한 말을 요약해 기록한다.
    • 원격 회의는 녹화해도 아무도 안 본다.
  • 회의 포맷을 결정해서, 회의가 끝났는데도 다같이 앉아서 다른 이슈로 이야기가 얼렁뚱땅 건너가는 일을 줄인다.
    • 회의 시작
    • 회의 진행: 안건의 장점과 문제점 파악, 찬성/반대 조사 등등
    • 결론 도출: 다음에 할 일 결정
    • 회의 종료

그리고 이것저것 더 있는데 생각이 정리되는대로 이 문서에 추가할 예정.

팀 구성에 대해

인원을 더 투입하지 않고, 그 대신 문제를 쪼갠다

[인용 D-0]
베이스캠프에서는 거의 모든 프로젝트를 3명으로 구성된 팀이 진행한다. 3은 우리에게 마법의 숫자다. 3인으로 구성된 한 팀은 일반적으로 두 명의 프로그래머와 한 명의 디자이너로 이뤄진다. 그리고 만약 3인이 아닐 경우에는 4인이나 5인이 아닌, 1인이나 2인으로 팀을 구성한다. 문제가 생겼을 때는 더 많은 인원을 투입하는 대신 3인으로 이뤄진 팀이 그것을 끝낼 수 있을 때까지 문제를 쪼갠다. ¹

• (O): 문제가 생겼을 때 더 많은 인원을 투입하지 않고 문제를 쪼갠다는 발상이 좋은 것 같다.
• (X): 모든 프로젝트를 3명이 하는 것은 좀 아닌 것 같다.

팀원이 많으면 팀 역량을 넘어설 정도로 많은 일을 받게 된다

한 팀에 6인이나 7인 또는 8인이 있으면 불가피하게 일이 필요 이상으로 복잡해진다. 주어진 시간과 팀원의 수만큼 할당되면서 일이 확대되는 것이다. 너무 많은 사람이 일을 함께하면 단기간에 끝낼 작은 프로젝트가 순식간에 크고 오래 걸리는 것으로 바뀐다. ²

• 팀 리소스가 많아지면 주어지는 일도 많아진다.
  • 문제는 그러다보면 팀 역량을 초과하는 일도 주어진다는 것.
  • 왜 이런가? 팀의 역량과 업무 난이도가 정확하게 측정되지 않았기 때문.

보통은 '상품 스쿼드', '주문 스쿼드' 이런 식으로 스쿼드가 나뉘기 때문에 도메인과 관련된 업무가 주어질 뿐이고, 각 스쿼드의 업무 역량이 대충 봐서 부족할 거 같으면 한두명을 더 투입하던가 다른 스쿼드보고 도와주라고 한다.

• 인용 D-0의 방식은 사람을 더 투입하는 방식이 아니라 일을 쪼개는 방법을 선택한다는 점에서 조금 더 바람직해 보인다.

머릿속에 전체적인 그림을 담고 매일 같이 일하기

각자 전문 분야가 있었지만(보통 에번은 인프라를, 존은 핵심 프로덕트 서비스를, 나는 API, 웹, 지불 결제 시스템을 담당했다) 셋이 하나의 뇌처럼 움직인다고 할 수 있을 정도로 모든 분야를 충분히 알았다. 머릿속에 전체적인 그림을 담고 매일 함께 일하면 놀라울 정도로 빠르게 일을 진행할 수 있다. 바로 소규모팀의 힘이다. 일을 대신 처리할 사람이 없으므로 고객 문제가 발생하면 코드를 직접 작성해 해결하는 것이다.

이것이 스타트업을 그토록 특별하고 생산적으로 만드는 마법이다. 관리해야 할 인력이 거의 없고, 협업에 들어가는 에너지도 매우 적으며, 직원이 고객 및 미션과 매우 가깝기 때문에 내적 추진력이 엄청나다. 스타트업의 성공과 실패를 좌지우지하는 수많은 요소 중에 동기와 속도가 치명적인 결함이 되는 경우는 드물다. ³

• 작은 팀: 머릿속에 전체적인 그림을 담고 있는 동료들과 일하면 능률이 좋다.
  • 그림의 규모가 머리 속에 담기 어려울 정도로 커지지 않게 해줘야 한다.
  • 작은 팀의 장점을 잘 살리려면?
    • 팀의 규모를 작게 유지한다. (당연)
    • 팀이 담당하는 일의 규모와 방향도 적절히 유지한다.
    • 담당하는 일의 규모가 커지고 방향이 여러 방향이 된다면 팀을 분리한다.

팀 쪼개기 전에 미리 계획하기

가장 중요한 문제는 대체로 팀을 어떻게 나누느냐이다. 이는 상황에 따라 달라진다. 프로덕트의 기능에 따라, 기능의 계층에 따라, 고객 부문에 따라 다르지만, 가장 중요한 것은 고객, 미션, 핵심 지표, 코드베이스를 팀과 함께 묶는 것이다. 마지막 코드베이스는 미리 계획해야 하기 때문에 가장 어려운 부분이다.

보통 시스템이 하나의 거대한 코드베이스로 구축돼 있기 때문에 팀을 나누려면 두 개의 팀이 독자적으로 관리할 수 있는 두 개의 코드베이스로 시스템을 리팩터링해야 한다. 이 작업에는 시간이 걸린다. 대개 이런 팀 분할은 최소한 6개월 전에 미리 계획한다. ⁴

생각은 쉬운데 실천은… 주의깊게 접근해야 하는 방법 같다.

• (O): 팀을 쪼갤 때 코드베이스를 팀과 묶도록 한다. (좋은 방법 같다. 그러나 어려울 것 같다)
  • 고객, 미션, 핵심 지표는 많이 봤는데 코드베이스를 묶는 걸 제대로 하는 건 거의 본 적 없는 것 같다.
    • 보통은 팀을 쪼개도 코드베이스는 그대로 둬서 팀별 코드 관리가 어려워지는 경우가 많았던 것 같다.
• 6개월 전부터 팀 분할을 준비하며 코드 작업을 한다는 것은…
  • (O): 계속 리팩토링하게 된다.
  • (O): 이 작업을 하면서 기술 부채도 줄일 수 있다.
  • (?): 해야 하는 업무에 리팩토링 업무도 추가된다.
    • 평소에 리팩토링은 원래 알아서 하는 것이라 생각하는 사람들이라면 문제없다.
    • 운영 업무가 너무 많은 팀이라면 리팩토링에 소홀해질 수 있다. 팀 분할 준비에 부실해질 수 있다.
  • (?): 스타트업에서 6개월 후를 어떻게 안단 말인가?
    • 괜한 리팩토링을 하게 될 수도 있다.

회의에 대해

[[/better-work/meeting#book-amazon-meeting]] 참고.

회의 오너가 회의를 준비한다

회의 일정은 누구나 볼 수 있는 공개 일정표에 기입된다. 회의가 열리기 이틀 전, 참가자들은 발표 내용을 문서로 정리해 공개한다. 모든 참석자는 회의 전에 문서를 읽고 와야 한다. ⁵

• (O): 회의 전에 문서를 읽고 와야 한다는 것은 좋은 것 같다.
  • 아마존에서는(?) 회의 시작할 때 몇 분간 다같이 조용히 문서를 읽고 시작한다는 것을 들었던 것 같다. 아무도 이의가 없다면 그대로 회의 종료.
• (?): 회의 이틀 전은 너무 이른 것 같은 느낌. 하루 전이나 반나절 전으로도 충분하지 않을까.
  • 아니다 그만큼 회의 주최자가 오너쉽을 갖고 회의를 설계하게 되니 좋은 일일 것도 같고. 해봐야 알겠다.

필요없는 회의를 열지 않는다

즉, 결과가 어떠한지 담당자가 발표하고 이를 모든 사람이 공유하는 것뿐이라면 굳이 회의를 열 필요도 없다는 말이다. 필요한 숫자와 데이터를 배포하는 것으로 충분하다.

관계자에게 미리 물어보고 숫자에 이상이 없을 때, 지적해야 할 점 또는 공유할 내용이 없을 때는 회의 오너는 그 주의 진행 관리 회의를 취소해도 된다. ⁶

• (O): 회의를 위한 회의는 안 하는 게 좋은 것 같다.

파워포인트 자료는 지양한다

왜 아마존에서는 항목별 파워포인트 자료가 금지된 것일까?

항목별로 작성하면 행간을 읽으면서 사람에 따라 해석의 차이가 발생하기가 쉽기 때문이다. 게다가 발표자도 행간에 여러 가지 생각을 집어넣어 설명하는 경우가 많아서, 나중에 그 내용을 떠올리기가 매우 어렵다.
(중략)
이런 오해는 처음에는 별것 아니다가도 시간이 지남에 따라 큰 해석의 차이로 발전할 수 있다. 그 결과 최종적인 아웃풋이 크게 어긋나버려서 본래의 목적을 달성하지 못하고 마는 결과가 될 수도 있다. ⁷

• (O): 파워포인트 자료는 만드는 것도 힘들고 시간도 많이 필요하다.
  • "결론을 도출하는 논리적인 과정"이 생략되는 경우가 많다.
  • 페이지가 많아서 읽는 사람도 한참 봐야 한다.

아마존의 1 pager, 6 pager.

• 아마존에서는 회의 자료를 서술형 에세이 형식으로 작성한다.
  • 분량은 1쪽, 6쪽으로 제한한다.
• 회의 전에 회의 주최자가 회의 자료를 '서술형'으로 작성한다.
  • 회의를 시작하면 모든 사람에게 자료를 나눠주고, 모두가 자료를 읽고 나면 회의를 시작한다.
  • 자료를 읽는 시간은 1 pager 5분, 6 pager 15분.

고민할 문제: 회의에서 나가기

회의 때문에 일이 늦어지는가? 나는 회의를 다루는 아주 간단한 규칙을 갖고 있다. 다음과 같다.

회의가 지루해지면 나가라.

예의를 갖춰야 한다. 대화가 잠잠해질 때까지 몇 분간 기다린 다음 참석자들에게 말하라. 여러분 생각에 여러분의 의견은 더 필요하지 않을 것 같아 보이는데, 해야 할 일이 많이 쌓여 있으니 다른 일을 하러 가도 될지 물어보라. 회의에서 나가는 걸 두려워하지 말라. 회의에서 나가는 방법을 터득하지 못한다면 어떤 회의는 여러분을 영원히 붙잡아 둘 것이다.

또한 대부분의 회의 요청은 거절하는 편이 현명하다. 길고 지루한 회의에 갇히는 일을 피하는 최선의 방책은 애초에 요청을 정중하게 거절하는 것이다. 무언가를 놓칠까 두려운 마음에 넘어가지 말라. 진정으로 여러분이 필요하다면 여러분을 부를 것이다.

누군가가 여러분을 회의에 초대한다면 정말 참석해야 하는 자리인지 확인하라. 여러분은 몇 분밖에 시간을 낼 수 없고, 회의가 끝나기 전에 나가야 할 가능성이 높다는 점을 회의 주최자가 이해했는지도 확인하라. 그리고 꼭 문에서 가까운 자리에 앉으라.

여러분이 그룹의 리더나 관리자라면 팀원들의 회의 참석을 줄여서 팀원들의 생산성을 지키는 일이 여러분의 주요 업무 중 하나라는 점을 잊지 말라. ⁸

• 로버트 마틴은 이 글에서도 당황스러울 정도로 과격한 표현을 하지만, 생각해볼만한 내용이긴 하다.
  • (X): 지루해지면 나가라.
  • 내가 결정권자라면 나가면 안됨. (당연)
  • (O): 내 의견을 더 말할 게 없고, 내가 더 알아야 할 것도 없다면 회의 참석자들이 기분나쁘지 않게 나가는 걸 고려해 보자.
    • (?): 처음부터 나갈 생각하고 있으면 회의에 소극적으로 참여하게 되지 않을까?
  • (O): 처음부터 내가 가야 하는 회의인지, 거절할 회의인지 파악하는 것은 중요.

내가 2023-03 부터 해보고 있는 시도

• 회의를 시작할 때 회의 목표를 글로 적어둔다.
  • 모든 참여자가 듣도록 크게 목표를 이야기하고 회의를 시작한다.
  • 주기적 회의라면 회의를 시작 3분 안에 참가자들과 회의 목표를 결정한다.
• 회의 목표를 달성했다면 회의를 끝내도록 한다. 질질 끌지 않는다.
  • 25분만에 회의 목표를 달성해 "목표 달성! 회의를 끝냅시다" 라고 했는데 반응이 괜찮았다.
  • 또는 회의 목표 2를 선정하는 것도 고려할 수 있다.
  • 회의가 끝나면 약 3분간 각각 돌아가면서 한마디씩 회고를 한다.
    • 좋았다/나빴다만 들어도 의미가 있는 것 같다.
    • 비판이나 불만이 나온다면 중요한 개선 단서가 될 거라 생각한다.
• 회의 도중에 그닥 중요하지 않은 건이 있다면 제한 시간을 걸고 결정한다.
  • "이건 1분 안에 결정하고 넘어가죠."
• 회의는 빠르게, 결과물은 구체적으로.
• 회의 시간을 마지막 1분까지 꽉 채우지 않도록 주의한다.
  • 마지막까지 채우는 회의는 대부분의 경우 낭비인 것 같다.
  • 가능한 한 효율적으로 빨리 끝내려 노력해야 더 좋은 회의가 되는 것 같다.

업무 방식에 대해

스프린트

[[/agile/story-point]] 문서 참고.

업무 중복에 대해

두 회사가 있다고 하자. 각각 효율성과 자율성의 스펙트럼 양쪽 맨 끝에 있는 회사다. 한 회사에서는 모든 팀이 완벽하게 동기화돼서 업무 중복이 발생하지 않는다. 모든 팀이 각자의 역할뿐 아니라 다른 팀에 의존하는 업무 역시 알고 있으며 일이 중복될 것 같으면 주도권을 양도한다. 훌륭해 보이지만 이런 식으로 작업이 돌아가는 경우는 드물다. 사실 저마다 연관된 팀을 기다리는 일이 빈번하다. 한 팀의 계획이 틀어지면 나머지 모두에 영향을 미치고 서로 잘못한 팀을 탓하게 된다. 물론 중복은 발생하지 않는다. 하지만 일이 잘못되면 비난할 사람이 너무 많아서 결과에 대한 주인의식도 사라진다.

이제 반대편 회사를 살펴보자. 혹시 다른 팀에서 중복 업무를 하고 있지는 않을까 하는 걱정은 접고 모든 팀이 고객에게 봉사하기 위해 신속하게 움직인다. 팀의 모든 동력은 고객이 선택하고, 고객을 만족시키고, 매출을 올릴 수 있는 성공적인 프로덕트를 만드는 것뿐이다. 이 회사에서는 개발자가 다른 팀에 허가를 얻거나 다른 팀과 일을 조정하지 않아도 된다. 팀들이 각자 다른 물리적 공간에서 작업하고 다른 이메일 도메인을 사용하는 걸 머릿속으로 한번 상상해 보라. 다른 회사라 해도 좋을 정도다. 동기화도 안 되어 있다. 짐작처럼 여러 팀이 함께 일하는 경우가 별로 없기 때문에 업무가 중복되는 때가 많다. ⁹

• 각 팀의 중복 업무(개발)을 최소화하기 VS 중복 업무를 신경쓰지 않기
  • Twilio 창업자 제프 로슨은 이 문제를 "효율성,위계질서 중시 VS 속도,자율성 중시"로 표현. 후자를 선호한다고.
• 중복 개발 최소화 정책으로 가면…
  • (X): 경험상 여러팀이 조인하는 회의가 엄청 많아진다.
  • (X): 많은 일에 순서가 생기고, 어떤 팀은 다른 일을 하며 기다리게 된다.
    • 기다리다 퇴사자가 발생하거나 레거시가 더 복잡해지기도 한다.
  • 이 순서를 아주 디테일하게 정의하긴 어려워서 순서가 종종 바뀌기도 한다.
  • (X): 각 팀별로 시비가 붙어 팀끼리 사이가 나빠지기도 한다.
  • (X): 사이에 끼게 되면 몹시 스트레스 받았고 회사 일이 아주 힘들어졌다.
• 중복 개발 허용 정책으로 가면…
  • (O): 상대적으로 마음 편하게 다양한 작업을 할 수 있을 것 같다.
    • 확실히 속도에 이점이 있을 것 같다.
  • (X): 단일 진실 공급원(SSOT)은 이렇게 만들면 안된다.

계획에 없던 업무와 싸우기

계획에 없던 업무와 너무 많은 진행 중 업무의 관계는 꼬여 있고, 서로 종속돼 있으며, 예상하지 못한 일더미가 쫓아갈 수 없을 만큼 쌓이게 된다. 쌓여가는 일을 처리하지 못하는 상황이 계속되고, 계획된 일들을 완료해야 한다는 책임감에 괴로워진다. 과도하게 일하는 습관은 결국 역기능과 불균형을 일으키므로 '계획에 없던 업무' 도둑이 만들어내는 문제를 가능한 한 자주, 그리고 빠르게 발견하고 해결하는 방법을 배우는 것이 중요하다.

(중략)

업무를 시각화하는 일은 '계획에 없던 업무' 도둑과 싸우기 위한 중요한 무기이며, 칸반의 핵심이다. ¹⁰

• 계획에 없던 업무가 많아질수록, WIP도 많아진다.
• 업무를 시각화하는 것은 '계획에 없던 업무'에 대처하는 방법을 학습하는 출발점이라 할 수 있음.
  • 말 된다. 눈에 보여야 대처하기도 좋고, 계획도 세울 수 있으며, 경험도 구체적으로 쌓을 수 있을 것이다.
  • 업무를 하나하나 빨리 쳐내는 것보다 더 중요할 수도 있겠다.

우리는 불확실성으로 가득하고, 모든 것이 늘 변화하는 세상에 살고 있다. 사람들은 직접 눈으로 볼 때까지 자신에게 필요한 것이 무엇인지 모른다. 이것이 항상 계획에 없던 업무가 생기는 이유이며, 계획에 없던 업무를 계획해야 하는 이유다. 계획에 없던 업무는 목표를 지워버릴 수 있기 때문에 시각화할 만한 가치가 있다.

(중략)

그림 19의 보드는 계획에 없던 업무를 시각적으로 보여준다. 눈에 보이지 않는 문제는 고치기 어렵다. 업무상의 문제점을 시각화하면 알지 못했던 문제를 발견하는 데 도움이 된다. 어떤 문제는 눈으로 확인하기 두려울 수 있다. 하지만 일단 시각화하면 문제 해결을 시작할 수 있다. ¹¹

WIP limit

바쁜 것보다 여유있게 일하는 것이 더 빠르다?

제품을 출시할 때 시간과 비용을 먼저 고려하는 경우가 많다("일단 테스트를 건너 뜁시다. 우리는 이걸 출시해야 해요. 나중에 다시 테스트합시다."). 항상 '바쁘다'는 점을 강조하는 최근의 기업 문화는 어리석다. 업무는 사람들이 '바쁠 때' 방치된다. 그러나 바쁜 사람들은 가치를 전달하지 못하기 때문에 높은 생산성을 보여주지 못한다. ¹²

• 바쁘게 일하게 되면 몇몇 업무들이 방치되는데, 그 중에 중요한 것들이 섞이기도 한다.
  • 기술 부채로 이어지게 되겠지.

이 문제는 [[/jargon/20-percent-project#queueing-theory]]{대기열 이론의 관점}에서도 생각해 볼 수 있는 것 같다.

• 수용량 활용률 100%로 리소스를 가동할 때 대기 시간이 높은 확률로 발생하게 된다.
  • 컴퓨터가 100% 사용량에 가까워지면 응답이 느려지거나 멈춘 것처럼 보이게 되는 것을 떠올려 보자.
  • 고속도로의 경우 사용량이 100%에 가까워질수록 교통 정체가 심해진다.

WIP가 너무 많은지 알아보는 방법

다음과 같은 상황이라면 진행 중 업무가 너무 많은 것이다.

• 문맥 전환이 흔하다.
• 이전 업무가 끝나기 전에 새로운 업무가 시작된다. 앞에 놓인 다른 많은 일을 다 끝내지 않았지만 "예, 할게요."라고 말하는 상황이다.
• 일을 방치하고 묵힌다.

본인이 자주 문맥 전환을 하거나 "5분 정도 시간 돼?"라는 질문을 받았을 때 그렇다고 답한다면 스스로 업무의 흐름에서 벗어나 멀리 돌아가는 꼴이 된다. ¹³

나의 결론: WIP limit은 엄청 중요하다

WIP_{Work In Progress}의 수를 제한하는 것이 중요하다는 결론을 내리게 됐다.

• 사람은 한 번에 신경쓸 수 있는 일의 수가 거의 정해져 있다.
  • 컨텍스트가 복잡할수록 처리 가능한 WIP의 수는 줄어든다.
• 팀도 마찬가지.
  • 팀이 한 번에 처리할 수 있는 일의 수는 생각보다 많지 않다.

WIP limit을 걸어두는 이유?

• 멀티 스레드 프로그래밍에서 스레드 수를 제한하는 것과 비슷하다.
  • WIP limit이 너무 크면, 컨텍스트 스위칭이 많아져 성능 저하.
  • WIP limit이 너무 작으면, 병목이 발생해 성능 저하.

그렇다면 WIP를 어느 정도로 제한해야 하는가?

• 팀에 따라, 사람에 따라, 프로덕트에 따라, 프로젝트에 따라 달라질 수 있다.
  • 따라서 고정된 값이라고 생각하며 접근하면 곤란하다.
  • 업무 사이클을 돌려가면서 회고를 해보고, 회고 결과에 따라 WIP limit을 조금씩 조절해보는 방법.

보드에서 WIP 리밋이 꽉 찼는데, (뭔가 기다리고 있다던가 해서) 당장 할 일이 없다면 어떻게 해야 할까?

• 다른 column에서 병목을 찾아, 그것을 해결하도록 한다.
  • 업무가 특정 사람에게 완전히 바인딩된 것으로 생각하지 않도록 한다.
  • 다른 사람이 어떤 WIP를 계속 붙잡고 있다면 상황을 물어보고 도와주도록 한다.

참고문헌

• 개발자에게 물어보세요 / 제프 로슨 저/박설영 역 / 인사이트(insight) / 초판 1쇄 발행 2023년 03월 27일 / 원제: Ask Your Developer
• 소프트웨어 장인 정신 이야기 / 로버트 C. 마틴 저/정지용 역 / 인사이트(insight) / 초판 1쇄 발행 2023년 03월 09일 / 원제: Clean Craftsmanship: Disciplines, Standards, and Ethics
• 아마존처럼 회의하라 / 사토 마사유키 저/류두진 역 / 반니 / 1판 2쇄 발행 2021년 04월 23일 / 원제: AMAZON NO SUGOI KAIGI by Masayuki Sato
• 업무 시각화 / 도미니카 드그란디스 저/유지은, 김혜주 역/조승빈 감수 / 에이콘출판사 / 발행: 2020년 01월 31일 / 원제 : Making Work Visible
• 일을 버려라! / 제이슨 프라이드, 데이비드 하이네마이어 핸슨 저/우미정 역 / 예문아카이브 / 초판 1쇄 발행 2019년 12월 15일 / 원제: IT DOESN’T HAVE TO BE CRAZY AT WORK

하위 문서

주석