소프트웨어/프로젝트

팀장 딜레마…에 붙여

falconer 2007. 6. 27. 09:26

많은 회사들이 개발자들의 경력 관리에 있어서 딜레마에 빠집니다. Jason님의 팀장 딜레마를 보면 모험과 개선을 위한 일과 안정적인 일 사이에 인력을 어떻게 배치 할지 어떤 사람을 들어 써야 할지 참 애매할 때가 많습니다. 바로 아래와 같은 경우죠.

- 팀에서 개발 잘하는 사람이 팀장을 합니다. 그렇게 되면 개발을 제일 잘하는 사람은 없어집니다.
- 팀이나 회사나 새로운 성장 동력을 찾아야 하는데, 제일 일 잘하는 사람은 기존(안정적인) 일에서 쉽게 뺄 수가 없습니다. 혁신은 그만큼 리스크가 따르기 때문에 현재 상태를 유지하는 일도 챙겨야 하기 때문이죠.
- 제일 일 잘하는 사람이 개선도 그만큼 잘 할텐데, 그걸 알면서도 쉽사리 결정할 수 없는 딜레마에 빠집니다.
팀장 딜레마 중에서

제 주변에서도 이런 일을 흔히 겪고 있습니다. 개발 잘 하는 사람이 곧 매니징을 잘 하는 사람은 아니기 때문에 꼭 사람을 관리하는 주 업무에서 시행착오를 겪게 됩니다. “팀장 되니 사람 바뀌더라” 또는 “팀장이 제대로 방어 못한다” 등등… 새로 팀장 된 사람들은 매니징의 굴레속에 번민 하기도 합니다.

국내 대부분 IT 회사의 개발자 커리어 패스가 결국 PM과 HR이 혼합된 팀장으로 가고 있기 때문에 나타나는 현상입니다. 그렇다고 무턱대고 외국 처럼 아키텍터 그룹을 만들기도 쉽지는 않습니다. 제가 생각한 방법은 한 팀 내에 관리팀장(Project Manager)과 기술팀장(Technical Manager)을 두는 것입니다.

관리 팀장은 대인 관계가 원만하고 프로젝트 일정을 꼼꼼히 챙기며 업무 분담을 잘 주고 관리할 줄 아는 사람으로 두고 기술 팀장은 프로젝트 중 기술 컨설팅과 개발자 교육 및 스킬업 등등을 챙기게 하는 것입니다. 개발팀이 하나인 회사에서는 관리팀장과 기술팀장이 정말 친하고 맘이 맞는 사람으로 합니다만 의사 결정은 관리팀장이 하도록 합니다.

개발팀이 여러개인 곳에서는 기술팀장들만 따로 풀(Pool)을 운영 합니다. 기술팀장들은 각 팀의 프로젝트 단위로 업무에 관계 합니다. 초기 프로젝트 기능 명세를 작성할 때 들어가 어떤 프레임웍을 사용할 것인지 어떤 방식으로 개발 할 것인지 어떤 개발 기법을 사용할 것인지를 컨설팅 해 줍니다. 또한, 프로젝트 중간 중간에 생기는 문제를 그때 그때 관리팀장의 요청을 받아 해결 해주러 들어갑니다. 또한 마지막 QA 시 기술팀장들이 마지막 점검을 합니다.

기술팀장 풀에는 아키텍쳐, QA, 문제 해결 담당 등 역할에 따라 업무를 나누어서 필요할 때 각 개발팀을 지원해 주는 업무를 하는 것이죠. 기술 팀장들은 업무의 일부(30%) 정도를 기존 업무 개선 활동에 참여 합니다. 서비스 운영을 하는 유지 보수 개발자들과 인터뷰 하면서 기술 멘토링과 더불어 개선 사항이 있는지 찾아 냅니다. 개선 사항이 있다고 판단 되면 관리 팀장에게 이야기 해서 개선 일정을 잡도록 합니다.

이들은 개발을 잘하는 사람들이 모여 있기 때문에 밤에 남아 종종 프로토 타입도 만들고 아이디어도 구현해 볼 수 있습니다. 이렇게 나온 아이디어는 서비스 프로젝트로 발전할 수 있을 것이구요. 그렇게 되면 기술팀장들이 다시 개발 프로젝트에 컨설턴트로 참여 합니다.

회사의 입장에서는 두 명의 팀장을 둬야 하는 리스크가 생깁니다만 비용적인 측면에서 어차피 한명이나 두명이나 조율만 잘 하면 그런 것은 큰 문제가 안되고 오히려 이를 통해 생산성이나 효율성 그리고 창의성이 올라간다면 충분히 투여 가능한 비용이 될 것입니다.

문제는 기술 팀장 조직 혹은 관리 팀장 및 기술 팀장 사이를 잘 조율한 기술 담당 임원이 필수적입니다. 그냥 무턱 대고 기술을 잘 모르는 사장이 두 명을 따로 뽑아서는 효과를 얻기 힘들고 나중에 문제가 생겼을 때 조율하기도 힘드니까요. 이런 방식은 한 사업본부에 하나의 개발팀만 있는 조직에는 적용하기 힘들고 가급적 직능별로 모여 있는 조직에서 수용하기 쉬운 방식입니다.

이 방식은 2005년에 개발팀이 여러 개인 조직에서 아주 짧은 기간 진행해 봤던 방식이었는데, 매니징을 원하지 않는 시니어 개발자와 매니징 업무를 하는 팀장 그리고 일반 개발자들 사이에도 꽤 만족도가 높았던 것으로 기억 합니다. 하지만, 이 방식을 선택해서 생기는 문제에 대해서는 이 블로그는 책임지지 않습니다.^^



출처 : 챠니

'소프트웨어 > 프로젝트' 카테고리의 다른 글

[질문] 개발자들 이거 없으면 못 만든다!!!~~~  (1) 2007.05.30
[PMP강의정리] 1. 프로젝트 관리 개요  (0) 2007.05.30
PMBOK2000 한글 번역  (0) 2007.05.30
PMP  (0) 2007.05.30
PMP관련 Link  (0) 2007.05.30