칸반 책에 나온 "우선 순위 부여 케이던스"란 칸반의 입력 대기열에 업무를 등록하기 위해서 관련 담당자들이 "규칙적으로" 모여 우선 순위 부여 회의를 진행하는 것을 말한다.
일단 위의 정의대로라면 현재 우리 회사에서의 우선 순위 부여 케이던스는 존재한다. 한 프로젝트에서의 우선 순위 부여 케이던스의 절차는 하기와 같다.
1) S/W 릴리즈 일정이 고객사의 일정에 따라서 잡힌다.
2) 고객사로부터 기능 구현 및 변경 요청 사항이 들어온다.
3) 들어온 요청 사항을 PM (Project Manager)과 SE (System Engineer), SW/HW TPL (Technical Project Leader)들이 모여 우선 순위를 정한다.
* PM: 프로젝트 팀에서 프로젝트의 전체적인 관리를 맡는 사람
* S/W TPL: 프로젝트 팀에서 S/W팀의 전체적인 관리를 맡는 사람
위의 과정을 따라서 이번에 릴리즈될 S/W에 반영되어야 할 요구 사항들이 정해지며, 정해진 요구 사항들은 각 기능 담당자에게 할당된다. 할당된 업무들은 칸반 보드의 담당자별 백로그에 각각 등록된다. 그리고 각 기능 담당자는 자신의 백로그에 등록되어있는 업무를 한번에 하나씩 처리하면 된다. 그림으로 나타내면 아래와 같다.
기능 담당자 입장에서 여러 프로젝트의 요구 사항이 자신에게 등록되므로
1) 기능 담당자는 자기에게 할당된 업무의 마감일을 확인하고 (대부분의 업무는 마감일이 고정되어 들어오며, 프로젝트마다 마감일이 다르므로)
2) 자신에게 등록된 업무의 개발 소요일을 추정한다.
3) 그리고 업무의 마감일과 개발 소요일을 고려하여 자기에게 할당된 업무의 우선순위를 다시 계산하고, 우선 순위가 가장 높은 일을 입력 대기열에서 당겨와 일을 진행한다.
4) 그런데 입력 대기열에 S/W TPL이 등록하는 업무의 숫자는 제한되어 있지 않기 때문에, 업무가 등록될때마다 다시 위의 1)~3) 과정을 계속 반복해야 한다.
결국 프로젝트 별로 우선 순위 케이던스를 수행하여 기능 담당자에게 업무를 할당하지만, 결국은 기능 담당자가 자기에게 할당된 업무의 우선 순위를 또 다시 재산정하는 일이 벌어진다. 그래서 이러한 낭비를 없애기 위해서 책의 내용을 바탕으로 어떻게 개선할 수 있을 지 생각해보았다.
1) S/W TPL들이 각 기능 담당자의 입력 대기열에 등록하는 업무의 숫자를 제한한다.
2) 입력 대기열에 여유가 생기면, 각 S/W TPL들은 우선 순위 부여 회의를 통하여 입력 대기열에 등록할 업무를 결정한다.
상기 2가지의 개선책을 적용하면 실제 기능 담당자가 끊임없이 반복했던 업무 우선 순위 및 추정 활동을 S/W TPL들이 맡게 된다. 그러면 결과적으로 기능 담당자는 개발에 더 집중할 수 가 있을 것이다.
그런데 상기의 개선책이 현실에서 사실 불가능해 보인다. 그 이유는 하기와 같다.
1) S/W TPL들은 하루에 진행해야 하는 회의가 엄청나게 많다. 하루 종일 회의를 하게 마련인데 거기에 더해서 S/W 팀 내부적으로 우선 순위 부여 회의를 하자고 하면 반발이 클 것이다. S/W TPL 입장에서는 없던 회의가 생기는 것이므로 그만큼 워크로드 (workload)가 증가하기 때문이다.
2) S/W TPL들이 각 S/W릴리즈마다 관리해야 하는 요구 사항들이 엄청나게 많다. 따라서 각 기능 담당자의 입력 대기열에 등록하는 업무의 숫자를 제한하고, 입력 대기열에 여유가 생길때 마다 우선 순위 부여 회의를 한다고 하면 아마 회의가 발생하는 빈도가 상당할 것이다.
그래서 결과적으로는 다른 개선책을 모색해봐야 할 것 같다. 다른 관점에서의 접근이 필요할 것 같다.
0 개의 댓글:
댓글 쓰기