더 나은 개발팀을 구축하는 방법.

  

 

사람들은 어떤 경우에 최선을 다 하며, 후회 없이 그리고 즐겁게 일할 수 있을 것인가.내 나름대로 후회 없는 팀 구성을 위한 노하우를 적어본다.

 

1.     프로젝트 핵심 인력의 생각 일치.프로젝트에는 핵심 인력이 있기 마련이다. 즉, 프로젝트 매니져, 각 팀장 등이 이 인물들에 해당 할 것이다. 팀안에서는 물론 팀장과 메인 개발자 정도 될 것이다. 어떤 생각이 일치 되어야 하는 것일까? 모든 생각 하나하나가 다 일치 할 수는 없다. 오히려 모든 이들은 각자 환경과 생각과 이념과 세상을 바라보는 눈이 다르므로 생각이 다를 수 밖에 없다. 이 사실을 인지하고, 머리를 맞대고 어떠한 의사 결정에 대해 오픈마인드로 접근하자는 데에 동의해야 한다.  개인적으로 생각하는 최적의 가이드 라인은 아래와 같다.프로젝트 매니저는 큰 줄기와 전체 프로젝트의 철학에 대한 길을 각 핵심인력과 공유하고 이해시킨다. (이것은 가급적 다수결이나 이런 의사합의 보다는 전체리더의 성향에 의해 통일되고 또한 핵심 인력들이 이를 지지하도록 하는 것이 바람직하다.)기획팀장은 매니저의 생각을 디테일 하게 표현하고, 문서로 기술한다. 물론 이 디테일의 과정에서 자신의 기량을 펼치며 다른 팀원의 의견을 받아들이는 등의 또 다른 역량을 펼칠 수 있다.디자인 팀장은 세계관, 철학, 느낌 등에 있어 매니저에 서포트 해 주어야 하며 이를 세부화 한다.프로그램팀장은 위를 모두 종합한 최종 결과에 대해 현실적인 가능성을 제공, 서포트 한다. 단, 모든 팀장은 일정이나 기타 과정에 대해 매니저에게 솔직해야 하며, 매니저는 이에 대해 위로는 회사와 아래로는 팀장들과 절충안을 찾아야 한다.

 

2.     비젼의 제시와 수치와 검증을 통한 설득.각 프로젝트에는 각각의 비젼이 있고, 철학이 있다. 리더는 반드시 이것을 가져야 하고 모든 개발인원들에게 이를 인지시켜야 한다.이를 모르는 개발인원에게는 일이 일 그 이상이 되기 어려우며 이에 동의하지 않는 개발원은 과감히 포기할 줄도 알아야 한다.(만약 이것이 없다면 그 프로젝트 역시 좋은 반응을 얻어 내기 힘들 것이다.)또한 수치와 검증을 통한 설득은 개발인원에게 리더에 대한 신뢰감을 더욱 두텁게 한다.

 

3.     야근의 지양.우리가 하는 지식산업은 정확한 시간으로 업무량을 산출하기가 사실 쉽지가 않다. 따라서 일반적으로 일반 작업 시간의 120% 정도의 시간을 주어 일정을 정하고 개개인에 책임 여부를 지우는 것이 일반적이며 적당하다.야근을 하기 시작하게 되면, 회사자체는 사람이 북적거려 늘 바쁘고 열심인 듯 보일 수 있겠지만, 생산성에 있어서는 전혀 그렇지 못하다.(그렇다는 결과 보고는 어느 문서에서도 찾을 수 없다.)하지만 이것은 개발자의 이상일 뿐 , 현 대한민국의 산업 구조에는 실질적으로 이루기 어려운 것이 사실이다.이에 관련 개발진과 경영진은 합의를 봐야 한다.일정이라는 것이 없다면 스케쥴링을 할 수가 없고, 그렇다면 적당한 결과도 기대하기 어렵다. 따라서 때때로 모자른 시간을 보충하기 위한 야근이 필요할 수도 있다. 그렇지만 이는 만성화 되기 십상이고, 정치화 되지 쉽다. 즉, 오래 남아서 일하는 놈이 이뻐 보일 수 있다는 것이다. 또한 만성화된 야근은 결국 생산성을 저하시켜 야근을 위한 업무 저하가 수반된다. 이것은 궁극적으로 야근의 기본 목적이 아니다. 이를 모두 해결 방법은 업무시간에 직원들이 업무에 집중하도록 하고, 퇴근시간에 퇴근하게 만들어 주는 회사의 환경 조성이다. 다음과 같은 방법들이 있다.

 

기본적으로 경영진이 (야근==생산성 향상)의 등식이 성립하지 않음을 인지한다.내규에 야근을 주 2회 이상을 금지하고 이를 초과시 벌금에 준하는 벌칙을 부여 한다. (원칙적 야근 금지)일정 준수에 대한 인센티브를 제공한다.8시 출근 오후 5시 퇴근으로 업무 시간 변경 (많아진 저녁 시간으로 개인 스스로 시간 활용도 높힘)             등…

 

위와 같은 사항들은 단기적으로 회사에 불이익을 줄 수도 있다. 하지만 직원들은 결국 회사에 종속된 사람들 이라고 봤을 때, 이들은 회사에 대한 배려를 프로젝트의 완성도로 보답할 것이며 이는 system에 대한 신뢰와 직결된다. 이것은 즉, 회사에 대한 신뢰인 것이다.Ps.) 습관화된 야근의 폐해.심신이 지치므로 창의적인 사고가 어려움.개인 업무를 볼 시간이 줄어들므로 결국 업무시간에 개인 업무를 보게 됨.결과물의 완성도가 낮아지므로 개발자의 만족도도 낮아짐.작은 업무도 일부러 시간을 맞추기 위해 늘여서 하는 경향이 생김.이직률이 높아지고 이는 전체적인 사기 저하로 연결됨.

 

4.     절차적 단계를 통한 결과물의 공개.개발에 대한 단계에 test 단계와 그로 인한 피드백 단계를 추가한다.즉, 제시 -> 기획 -> 개발 -> 오픈(혹은 다음 모듈) 이 아니라제시 -> 기획 -> 개발 -> Test 및 피드백 -> 재 기획 -> 재 개발 -> 오픈 선언(혹은 Test 과정 반복)이어야 한다는 것이다. 일반적인 개발사에서는 개발에 Test 및 피드백 기간이 포함되어 있는 경우가 많은데, 이것의 진정한 문제는 이것 자체가 아니다. 오픈이 정해져 있음으로 인해서 이 Test 및 피드백 기간에 결과물에 대한 협상을 한다는 것이다. 즉, 시간이 없으니까 퀄러티를 낮추자는 쪽으로 귀결되기 십상이라는 것이다.이는 개발사가 특정 기간에 결과물을 오픈해야 한다고 느끼는 (마케팅적) 압박 이상으로, 개발자 스스로도 결과물의 퀄러티에 대해 중요하게 생각한다는 것을 이해해야 한다는 것이다. 사람은 느낌과 기분의 동물이고, 본능적으로 만족을 찾는다. 각자의 만족은 차이가 있지만, 자신의 결과물에 대한 퀄러티의 만족과 그로 인한 사회적 인정은, 직원이 회사에서 원하는 최상의 가치, 바로 그것이다.

 

5.     막연한 자율 주의에서 탈피한다.무조건 자율주의가 좋은 것은 아니다.개발사에서 팀장이나 그 이상 직책은 일반적으로 그 회사나 업계에 오래 있었음으로 인해 그 자리에 있는 경향이 많다. 즉, 전문성 보다는 신뢰성에 의존한 인사인 것이다. 필자를 포함해 이러한 사람들이 ‘관리’에 적합하지 않다는 것은 아니다. 그러나 부족한 것은 사실이다. 절대적인 학습이 필요하다. 막연히 잘되겠지, 아무 문제 없으니까.. 등은 프로젝트에 큰 문제를 야기하지는 않겠지만, 좋은 영향도 미치지 못한다. 또한 막연한 격려도 마찬가지다. “힘내세요” “최선을 다합시다” 등의 효과는 1시간도 가지 못한다. System과 체계에 의해 잘 할수 있게 길을 마련해 주는 것이 관리자의 역할이다. 그런 가운데서 격려도 도움도 빛을 발하는 것이다.

 

6.     기타+ 모든 것을 팀원에게 물어보고 조율할 필요는 없다. 프로그램팀의 경우, 코드 표준 등은 팀장이 지정하면 그대로 가는 것이 좋다. 다수를 위한 통일은 개개인의 차이는 존재하지만 다수가 편안한 것으로 팀장이 지정하면 다수가 따르는 것이 바람직하다.+ 의사결정 시 둘 중 한 사람이 기분이 안 좋아졌다면 제대로 된 결정이 아니다. 토론으로 인한 의사 결정에는 아래와 같은 단계가 있다. 1)     도출된 의견으로 양자가 기분 좋은 단계2)     한사람이 불쾌해 해며 다른 이는 좋은 단계3)     두 사람다 불쾌해 하는 단계나는 2단계 이상은 기싸움 이상도 이하도 아니라고 평가한다. 일반적으로 1단계에서 결론이 나지 않는 사안은 이해관계가 없는 제 3자의 결론 유도를 이용한다.예를 들면 그러한 사안에 대해서 팀원들의 다수결로 결정을 하는 등의 방법이다. 이러한 방법을 통해 당사자들은 기싸움이 아닌 핵심 사안의 논리 그 자체에 집중하는 토론을 할 수 있다.