2016년 11월 10일 목요일

칸반 (Kanban) (2) - 진행 중인 업무량 제한

  앞 선 글에서 현재 진행 중인 프로젝트들에 칸반 (Kanban)을 도입 한 후 나타난 문제들을 나열해 보았다.


  칸반을 프로젝트에 적용했는데, 개발자로서 개발을 진행하는데 있어서 조금의 이점도 느끼지 못한 나는 (내가 PM (Project Manager)이 아니지만, 프로젝트 관리 상의 이점도 잘 느끼지 못하겠다.) 도대체 칸반이 무슨 이점이 있고, 우리가 진행하는 방식이 맞는 것인지 엄청난 궁금증이 생겼다.

  그래서 "칸반" 책을 사서 읽기 시작했다.

http://book.naver.com/bookdb/review.nhn?bid=8400313


  이제 도입 부분을 막 지나서 읽고 있는 중이다. 도입 부분 중 저절로 고개를 끄덕이게 만드는 내용이 하나 있었다. 진행 중 업무의 양을 줄이면 리드 타임 (개발의 시작에서 종료까지의 시간)이 줄어든 다는 것이다. 이것은 책에 나오는 것처럼 자세한 분석 데이터가 없을지라도, 평소 개인적인 경험을 토대로 하더라도 충분히 수긍할 수 있는 내용이다.

  하기는 이에 대한 나의 2가지 개인적인 경험이다. 다른 사람들도 아마 평소 업무를 하며 많이 느끼던 일들일 것이다.

1) A라는 프로젝트를 진행 하던 중, B라는 프로젝트에서 문제가 발견되어 나에게 할당되었다. 내가 속한 기능팀의 팀 리더가 지금 진행하고 있는 개발을 마무리한 후 B 프로젝트의 문제를 분석하는 것이 좋을 것다고 말했다. 그리하여 팀 리더가 해당 프로젝트의 PM에게 A프로젝트를 마무리한 후, B프로젝트의 문제점을 분석하겠다고 협의하였다. 따라서 나는 A 프로젝트의 기능 개발에 전념할 수 있었다.

< 쉴드 감사합니다. 팀 리더님 ㅋㅋ>

2) C 프로젝트의 신규 기능 개발 건을 인도 개발자에게 맡겼다. 그리고 얼마 후 C 프로젝트의 요구 사항 변경 6 건이 우리에게 전달되었다. 일단 나는 해당 변경 건 중 3건을 인도 개발자에게 할당하고 개발 상황을 체크하였다.
  유심히 인도 개발자를 살펴보니 신규 기능 개발 진행하랴, 자기에게 할당된 요구 사항 변경 건도 분석하랴 엄청 바쁘게 업무를 수행하고 있었다.

  그런데 문제는.... 내가 인도 개발자에게 할당해 준 신규 기능 개발 건의 진척 상황이 너무 느렸다. 사실 C 프로젝트에서 가장 염려 되는 부분이 신규 기능 개발 건이 었기 때문에 나의 마음은 점점 타들어 가고 있었다. 인도 개발자도 시간이 지날 수록 자기도 마음이 급해졌는지, 자기에게 할당된 3건 중 2건을 내가 처리해 줄 수 있느냐고 물었다. 그래서 나는 인도 개발자에게 할당해 준 3건의 요구 사항 변경 건을 내가 모두 가져갈테니, 신규 기능 개발 건에 더 집중해 달라고 하였다.

  결과적으로 인도 개발자는 내가 예상한 마무리 시간보다 2일 정도 더 빨리 일을 끝마쳤다. 그리고 그가 예상보다 더 빨리 일을 끝마쳤기 때문에, 내가 그에게서 가져왔던 요구 사항 변경 건 중 1건을 다시 그에게 할당해 줄 수  있었다 ㅋㅋ. 또한 그가 내가 예상했던 시간보다 일찍 일을 마무리 지어서, 그의 일처리 능력에도 약간 신뢰가 쌓였다. (+1점쯤? ㅋㅋ)

<물론 10점 만점에 1점이 되었다....>

  사실 진행 중인 일의 양을 제한하는 것이 어떤 이득을 지니고 있는지 과학적인 데이타가 없어도, 평소 사람들은 하나의 일에 집중하여 마무리 짓는 것이 여러 가지의 일을 동시에 진행하는 것보다 더 효율적이라는 것을 경험적으로 알고 있다.

  다만 칸반을 사용하면 개개인의 판단하에 결정하고 수행되던 그러한 일들이, 업무 프로세스에 정립되므로 진행 중인 일의 양을 제한하는 것에 대한 장점을 프로젝트에 참여하는 모든 사람들이 누릴 수 있는 기회를 제공하는 것 같다.

블로그내 관련 글
1. 칸반 (Kanban) (1) - 프로젝트에 칸반 도입 후의 문제점들
2. 칸반 (Kanban) (3) - 지속적 개선과 여유 시간

0 개의 댓글:

댓글 쓰기