팀원의 생산성을 떨어 뜨리는 가장 쉬운 방법

얼마 전 퇴근길에 지하철에서 회사 동료를 우연히 만났습니다. 모 보험사에서 프로젝트를 뛰고 있는 동료였는데 이런 저런 이야기를 하다가 불만에 찬 이야기를 듣게 됐습니다. 무슨 이야기인고 하니 프로젝트가 진도가 잘 나가지 않는다고 판단한 을(대형 SI) 측에서 평일은 오후 9시까지, 주말에는 토요일 근무를 강제했다는 내용이었습니다.

SI에서 어느 정도 경력이 있으신 분들은 한 번쯤 당해봤을 법한 일입니다. 납기가 다가오면서 누군가가 슬슬 개발자들을 쪼이기가 시작하는데, 실행하기 쉬우면서 효과도 그럴듯해 보이는 방법이 출.퇴근 시간 조정입니다. 고객들에게는 늦게까지 일을 하고는 사실을 보여줄 수 있고, 개발자 를 붙잡아 놓고 더 일을 시킴으로써 진도도 더 많이 나가는 일거양득, 양수겸장의 방법처럼 보이기 때문입니다.

하지만, 그 시스템에 내에 속한 누구나가 알고 있는 사실이 하나 있습니다. 강제로 붙잡아 놔 봐야 그네들이 생각하는 것만큼 진도가 나가지 않는 다는 사실입니다. 오히려, 불만만 더 커질 뿐입니다.

제가 생각하기에 개발자의 생산성은 자율성에서 나옵니다. 그렇다고 자율성이라는 것이 그리 대단할 것도 없습니다. 주어진 범위 내에서 자기가 하고 싶은 일을 선택할 수 있는 권한입니다.

제가 아는 많은 개발자는 근무시간을 억지로 정하지 않아도, 일이 바쁘거나, 중요한 문제에 부딪쳤을 때, 기꺼이 야근을 선택합니다. 그리고 주어진 시간에 일을 완료하거나 문제를 해결하면서 기뻐하고, 보람을 느낍니다.

출처

 

사람을 기계처럼 생각하는 개발 문화가 없어졌으면 좋겠습니다. 

또, 그런 면에서 제가 싫어하는 관리 방식 중에 하나가 WBS 기반의 일정/자원관리 방식입니다. WBS가 갖는 근본적인 단점 중에 하나는 사람을 자원으로 취급한다는 점입니다. 주어진 일과 일정이 있으면 자원은 주어진 시간에 해당 작업을 완료하기 위해 배정됩니다. 사람은 그냥 그 시간에 그 일을 할 수 있는 가용한(놀고있는) 자원입니다. 이 기계적인 절차에는 어떤 감성도 끼어들 여지가 없습니다.

하지만 소프트웨어는 개발은 적어도 현재까지는 사람만이 할 수 있는 무척이나 감성적이면서, 인간적인 작업입니다. 그리고 사람은 누구나 컨디션의 기복이 있으며, 좋아하고 싫어하는 일이 있습니다.

애자일 방식으로 일을 하면서 느꼈던 좋은 점 중에 하나가 선택의 자유입니다. 적어도 우선 순위 내에서 하고 싶은 일을 선택할 수 있으며, 또 스프린트 내에서 자신이 더 하고 싶은 일을 선택할 수 있는 자유가 있습니다. 팀원들 중에 UI에 관심이 있는 팀원이 있으면 그 사람이 좀 더 UI관련된 일을 할 수 있도록 배려할 수 있고, 또 배려 받을 수 있습니다.

그리고 적어도 제가 느끼기에 소프트웨어 개발에는 이런 인간적인 접근 방식이 더 효과적인 것 같습니다.

물론, WBS는 그저 도구일 뿐이고 그걸 사용하는 사람에 의해 그렇게 사용될 수도 있고 아닐 수도 있습니다. 하지만, 그 방법이 갖는 근본적인 제약이 사람을 단순히 가용한 자원으로 취급하게 만드는데 영향을 끼치고 있는 건 아닌지, 또 더 많은 시간 동안 일을 시키면 더 많은 것을 만들어 내리라고 생각하게 만드는게 아닌지 생각해 볼 문제입니다.