‘얼마나 많이’가 아니라 ‘얼마나 적게’가 중요하다!
Wednesday, April 28th, 2010대한민국 소프트웨어는 위기다?!
이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.
최근에 가까운 지인이 자신이 참여한 프로젝트에 대한 이야기를 들려 주었습니다. 그 프로젝트는 팀원들의 능력이 좋아서 완료까지 2개월이나 남은 시점에, 기능 개발이 다 끝났다고 합니다. SI 프로젝트에서 2개월이라면, 상당히 긴 시간이죠. 시간이 상당히 많이 남았다는 이유로, PM은 추가적으로 기능을 개발하기로 결정했다고 합니다. 그런데 문제는 이 추가 기능을 개발하면서 생겼습니다.
추가로 개발하는 기능이 예상보다 복잡해서 남은 프로젝트 기간을 다 소모해 버렸습니다. 그리고 원래 개발하기로 한 기능도, 고객이 생각한 것과 달라서 별도의 수정작업이 필요했다고 합니다. 결국 이 프로젝트도, 보통의 SI 프로젝트처럼 조금 기간을 초과해서 끝났다고 하는군요. 물론 팀원들은 야근도 많이 했다고 합니다.
팀원들은 흔히 자신들이 얼마나 많이 일을 할 수 있을까에 대해 생각합니다. 팀원들은 “이번 프로젝트에서 얼마나 많이 개발할 수 있을까?”라는 마음가짐으로 프로젝트를 수행해야 한다고 생각합니다. 이런 생각을 버리고 “얼마나 적게 개발할 수 있을까?”라는 마인드가 있어야 합니다.
From Manage It!
저는 아주 부지런한 편이 아닙니다. 그래서 되도록이면 몸이 고생하는 걸 하지 않으려고 합니다. 하지만 회사일이나 집안일에서 몸을 쓰지 않을 수 없죠. 어쩔 수 없이 몸을 움직여야 한다면, 최소한으로 움직이려고 하죠. 즉 주어진 자원으로 최대한의 것을 얻으려고 합니다. 시간이 되면 이야기를 풀어보겠지만, 주어진 자원으로 최대한의 것을 뽑는 데 애자일 프랙티스만한 게 없다고 생각하기 때문에, 일이나 생활에서 애자일하게 할려고 노력하죠.
이런 이유로 예전에 PM을 하다 보면(요즘엔 주로 실무를 합니디만…
), 팀원들과 사소한 충돌이 생길 때가 있습니다. 가끔 일부 팀원이, 고객이 원하는 이상의 기능을 만들려고 하기 때문이죠. 물론 팀원이 열정을 불태워서 하겠다는데, PM이 그 앞길을 막는 게 도리는 아니죠. 하지만 전체적인 관점에서 팀원이 개발하는 기능이 프로젝트 성공에 도움을 주지 못할 때, PM의 독재가 필요하기도 합니다.
열정적이고 도전적인 우리 개발자들은 무언가 만드는 것에서 보람을 느끼기에, 최대한 많은 걸 프로젝트 기간 내에 만들어 내려고 합니다. 하지만 이런 ‘얼마나 많이’의 사고 방식은 양에만 초점을 맞추기 때문에 질적인 변화를 꾀할 수 없습니다. 반대로 우리가 ‘얼마나 적게’의 관점에서 접근한다면, 적은 것으로 만족도를 높여야 하기 때문에, 양의 사고 방식에서 질적인 사고 방식으로 전환을 이룰 수 있다고 생각합니다.

