birdkr's home

어떤 프로젝트에서 다음과 같은 시나리오를 볼지도 모른다. 오전 10시, 열(Column) 안에 정렬된 카드로 덮인 커다란 벽에 붙은 차트에 한 개발자가 성큼성큼 걸어 간다. 개발자는 카드 두 개를 진행 열에서 완료 열로 옮긴다. 그러고 나서 개발자는 대기 열에 있는 카드를 살펴 보다, 카드 하나에 자신의 이름을 적고 이 카드를 진행 열로 옮긴다. 하루 동안, 개발자와 테스터는 아 과정을 반복한다.

오후 3시쯤, 테스터가 작업 보드로 걸어와서 진행 열에 있는 작업 카드 하나에 빨간색 점을 찍는다. 오후 4시, 팀은 작업 보드 주위로 모인다. 문제가 있는 작업을 나타내는 빨간색 점을 확인하면서, 자료를 모으고 그 문제를 분석하기 시작한다. 개발자 두 명이 문제를 해결하기 위해서 협동한다.

이 팀에 있는 사람들은 자신이 무엇을 해야 하는지 알고 있으며, 그 일을 한다. 사람들은 일일 작업 지침이 필요 없으며 원하지도 않는다. 팀의 관리자는 장애물을 제거하고, 코칭하며, 팀의 능력을 향상 시키는데 초점을 둔다.

이것은 마술이 아니다. 관리자가 사람들이 계획, 진행, 완료의 작업 상태를 보도록 도와 주는 기술을 사용할 때 사람들은 무슨 일을 할지 알며, 그 일을 한다. 크고 눈에 띄는 차트(Big Visible Charts, BVCs)는 모든 사람이 목적에 맞게 일하는지 보게 한다.

우리가 아는 한 관리자는 프로젝트 포트폴리오를 눈에 띄게 하기 위해서 화이트보드에 손으로 그린 도표를 사용했다. 제일 왼쪽의 열은 프로젝트 목록이고, 남아 있는 각 열은 한 주(Week)를 나타냈다. 팀에 있는 모든 사람마다 자석 일곱 개를 나눠줬는데, 이 자석은 다음 7주 동안 사람마다 어떤 프로젝트에서 작업할지 보여 주었다.

한번은 관리자의 상관이 관리자의 팀이 더 많은 일을 하길 원했다. 관리자는 상관을 화이트보드로 데리고 가서 물어 보았다. "제가 무엇을 하길 원하시죠? 어떤 작업에서라도 사람을 줄여서, 원하시는 업무에 사람을 늘릴 수 있습니다." 데이터가 상관의 눈 앞에 있었기 때문에, 상위 관리자는 단순히 작업을 추가하는 것이 아니라 타협안을 도출해야 한다는 사실을 알 수 있었다. 단지 작업을 추가하지 않고 말이다.

BVCs는 단지 프로젝트 업무와 프로젝트 데이터를 위한 것이 아니다. 우리는 BVCs를 부서 동향, 결함 추세, 결함 밀도, 즉 팀 구성원 모두가 알아야 하는 모든 정보를 한눈에 볼 수 있도록 해준다. 단정해야 한다거나 컴퓨터로 차트를 작성해야 한다거나 하는 고민을 하지 말자. 가시성이 목적이지, 멋 부린 표현이 목적은 아니다.