여러분은 할일을 맡긴 팀원이 일을 마치지 못할 경우 어떻게 하시나요?

참고로 저는 팀장 업무를 해본적은 없지만
팀장이 일단 본인이 할 수도 없고 관심도 없는 일을 맡은 것이 잘못이라고 생각합니다.
가능했었더라면 좀 더 적합한 팀에게 일을 넘겼어야 하지 않을까요?

뭐 일단 그건 지나간 얘기이고 일단 일이 이 지경이 되었고
제가 팀장이라면 부하직원이 기간내에 그 일을 할 수 있는지 없는지 판단하는 작업을 해야 하지 않을까요?
다른 팀에게 지원을 요청할 수 없다면 자기 팀원을 닥달해야 하겠지요.
기간을 더 주거나 그게 안된다면 같이 밤을 샌다거나.

최선의 조처는 기간 연장이나 완전히 구현되지 않는 버전을 정리해서 보여주는것 같은데요.
대충이라도 할 수 없었다면 그 팀원도 처음부터 덜컥 일을 맡고 일정을 내놓지는 않았을 테니까
정말 어쩔 수 없는 상황이라면 될 때까지 같이 밤을 새야할 것 같습니다.

그럴듯한 개발 계획을 본 팀장이
그럴듯한 개발 진행을 하다가
그럴듯한 개발 문제가 생겨서
그럴듯한 개발 실패를 한다는거군요.

이거 참. 씁쓸합니다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.

그래서 매니저는 매니징을 수행할 능력이 있는 사람이 되야 합니다.
매니징 능력이 없는데 나이 먹으면 매니저로 올라가는(팀장이 위라는 상하수직 구조의 인식 자체도 문제죠. 어떤 분야의 expert가 자생하기 힘듬) 환경 자체은 큰 문제라고 생각합니다.

혼자 하는 일이 아닌데 문제가 생겼든 문제가 뭔지 모르는 문제가 생겼든 그걸 공유하고 커뮤니케이션으로 해결하지 못 한 "쫌해요" 개발자가 일단 큰 문제인것 같고요.
"지금" 못 하거나 버그가 쪽팔린것도 아닌데.. 결국 문제 해결을 못하고 이런 상황이 생긴게 더 쪽팔린건데요.
그 다음은 그걸 알아내지 못 한 팀장 문제입니다. 이런 사람은 매니징하면 안 됩니다. 매니저는 이런 상황도 관리하기 위해 존재합니다.

전체적으로 shint 님 의견에 공감이 갑니다.
프로젝트의 책임은 전적으로 팀장에게 달려 있습니다.
팀원의 능력과 스케쥴, 장애를 파악해서 리스크를 제거하고..
필요시 협력/지원을 아끼지 말아야 하고..
마일스톤 및 태스크에 관한 스케쥴링을 전담해야 한다고 생각합니다.

매니지먼트 트랙과 테크니컬 트랙은 공존하기 어렵지만...
실질적으로 우리나라의 대부분 IT 기업들은 팀장에게 이 두가지 요소를 다 요구하고 있습니다.
그렇다고 해서, 팀원들에게 일을 배분한다고 했을 때 매니지먼트까지 전가해서는 안됩니다.
반대로, 태스크 진행에 걸림돌이 되기 때문입니다.
(그래서 불행히도 직급이 올라가고, 많은 role 이 부여될 수록, 실무/개발과는 점점 멀어질 수 밖에 없습니다.)

그런 상황에서 일정, 즉 데드라인만 갖고 압박을 하면 어떤 일이 벌어지느냐 하면...
기능을 줄이고, 코드의 퀄리티를 떨어트리고, 급기야는 거짓말을 하게 되어 있습니다.
회사 분위기에 따라 다르겠지만, 스스로 '나 능력없소' 라고 광고하는 꼴이 될까 두려워 하기 때문입니다.

프로젝트 결과물(코드 및 기타 산출물), 그리고 성과는 담당자 개인의 것이 아니라.. 팀의 것입니다.
그러나 그에 대한 책임은, 최종 승인자, 팀장의 것인 셈입니다.

이미 데드라인을 밟고 후속조처가 필요한 상황이라면...
현재 상황 (진척도, 잔여 작업, 장애/지연 요소 등) 에 대한 보고서를 요청해서...
얘를 파기할지, 늦더라도 마무리를 지어야 할 지 판단할 시점으로 보입니다.

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』

자신의 능력과 한계를 오픈한다는 것이

제가 경험해 본 고수 분들의 공통된 모습이었어요.

이게 참 힘들더라고요. 부족하면 감추고 싶은게 인지상정이라;

감추려는 사람과, 그 모습을 못 본 척 혹은 못 본 사람이 만들어 낸 상황이 아닌가 싶어요.

메니저는 감추려는 사람의 심리를 따끔하게! 까발릴 수 있는 능력이 필요한 것 같에요.

개발자는 최소한 주간보고에서라도 스스로를 까발릴 수 있는 용기가 필요하고요.

켄트백씨의 글에서 용기라는 단어를 처음 봤을 때 피식 웃었어요.

기술 문서에서 뜬금없이 용기라니;

하지만 대가는 대가인가 봐요. 개발 일 수가 늘어나면 늘어날수록

지금 내게 필요한 건! 용기! 를 속으로 매일 외치고 있거든요;;

중간에 확실한 체크가 필요 합니다.
대부분 코앞의 Open을 앞두고 무언가 안된다는 것은 팀장이 확실히 체크를 안한 경우가 대부분이더라구요.
중간에 체크를 확실히 안하니까..개발하는 사람도 그냥 대충 합니다.
일에 있어서는 신의와 믿음, 상대에 대한 배려 보다는 확인과 보고 검증이 필요하다고 생각합니다.
이런 확인/보고/검증을 제대로 못했다면, 그건 팀장의 책임 져야할 것이죠.
일을 하는데 있어서 자신의 관심 분야가 아니라고 등한시 한다면, 머하러 팀장할까요.... 그냥 프리랜서로 뛰는 것이 정답이지요.
(프로젝트나 패키지 개발에서 신의와 믿음 상대에 대한 배려때문에 고생한 적이 많아서요.)

우리나라는 그렇지 않은 경우가 많습니다만...

팀장이라면 당연히 테크니컬 하게 팀원들을 보살펴 줄 수 있어야 합니다. 팀원에게 일을 시킬 때는 충분히 할 수 있는 일은 혼자 시키고 그렇지 않은 일은 보살펴(?) 주면서 함께 일해야 하는 겁니다. 팀원에게 일을 맡기고 그 일이 마지막에 가서 잘못되는 것을 발견했다면 팀장에게도 문제가 있고, 그것을 그 상황까지 끌고 간 팀원에게도 문제가 있는 겁니다.

제가 있는 팀에서는 그런 일이 일어나기 힘듭니다 - 즉, 팀원이 일을 못마치는 사실을 마지막 순간에 알게되는 일. 한달이상 걸릴 일이라도 일주일 내에 그 팀원이 그 일을 끝낼 수 있을까 없을까 알수있습니다.

제 일터에서는 새롭고 잘 모르는 일을 할 때는 전체 문제 중 축소판으로 가장 중요한 것만 일주일 안에 수행해보고 어떻게 할 것인지 판단합니다. 어렵다면 그만큼 시간과 인력을 투입해야 하는데, 우선순위가 밀리면 안하는 것이고 여유가 되면 하게되는 것이죠.

무작정 맡기고 어떻게 되겠지 하는 안이한 생각이 여러사람 병들게 합니다. (오늘도 팀리더와 설계 및 코드 리뷰 하는데, 미처 생각지 못한 사실들을 지적하고, 간단한 버그라고 생각한 것을 끝까지 집요하게 추적해서 아주 중요한 버그로 만들어 버리더군요. 10분 걸릴 리뷰라고 생각했던 것이 총 1시간 반정도 걸렸지만, 모두 재미있었다고 웃으면서 마칠 수 있었습니다. 팀 리더라면 당연히 그렇게 할 수 있어야 한다고 봅니다)

내가 똑똑한 팀 리더와 일하며, 그도 나를 인정하면서 일하는 보람도 느껴야 즐기면서 다닐 수 있는 일터라고 생각합니다.

'대충 알아' -> 스킬적으로나, 관리적인 측면에서 내공이 많이 부족한듯 보입니다.

개발자가 버거워하면 거기 맞춰서 대안을 제시해야 되는데 이것도 아니고 저것도 아니고....

그렇다고 책임 지는것도 아니고.....

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

2개월~1년 정도의 다양한 팀 프로젝트에서 검증된 지속가능한 개발 프로세스입니다.

1. 계획 단계

A. 작업을 분할합니다.
통상 5일(1주일), 잘 모르면 3일 단위로 분할합니다.
어떤 작업의 기간이 너무 길면 더 세분하고, 너무 짧으면 유사기능과 합쳐야 합니다.
어쨌든 작업을 1차로 분할합니다.
모든 작업은 결과물 확인이 가능해야 합니다.

B. 팀원이 예상 일정을 제시합니다.
각 작업에 대한 팀원이 예상일정을 채워 넣습니다.
이 때, 해당 작업을 전에 해본적이 있는지 경험의 유/무를 기록합니다.
또한 해당 작업이 쉬운지 어려운지 난이도의 상/하를 기록합니다.
즉, ''제시일정-숙련도-난이도''를 팀원이 채워 넣습니다.
이 때, 우리나라에서는 상-중-하 등으로 하면 안됩니다. 왠만하면 중으로 쏠려요.

C. 팀장과 팀원이 계획을 수립합니다.
팀장이 팀원의 계획표를 보고 함께 토의합니다.
이견이 없게 분할됐으면 공식 들어갑니다.

숙련도     난이도      안전율(초기값)
상         하          2
상         상          3
하         하          4
하         상          5

예, 팀원이 제시한 일정에 안전율을 곱한 것이 계약을 위해 외부에 제시되는 완료 예상 일정입니다.
정해진 기간을 초과할 것 같으면 기능을 줄이거나 팀원을 늘이기 위해 협상하는 것이 팀장의 역할입니다.

2. 개발 단계

A. 일정별 작업 들어갑니다.
팀원이 작업을 하는 동안 시간단위, 일단위, 주단위, 결과물 단위 등등 팀장이 알아서 편하게 관리합니다.
어쨌든 결과물이 나오는 실제 수행 일정을 기록합니다.

B. 안전율 보정합니다.
팀원의 수행 일정에 맞도록 계획표 상에서 제시한 일정에 적용한 숙련도-난이도 공식의 안전율을 조정합니다.

3. 팀장의 역할

A. 팀장은 작업을 분할하는 통찰력을 키우고, 팀원이 난이도 및 숙련도를 잘 평가하도록 유도합니다.
시스템의 설계나 개발 계획이 관리 및 확인에 적합하고 팀에 맞게 분할되도록 고민 해야합니다.
또한 팀원의 안전율이 고르게 분포하는지 기록을 확인하면서 함께 고민합니다.

B. 전체 프로젝트 기간에 대해 팀원별 또는 팀별 안전율, 즉 계획 대비 실행이 평균적으로 2 이하가 되도록 관리합니다.
적절한 작업 분할, 기술 교육, 업무 환경 개선, 상벌 등을 적절히 활용합니다.

C. 3개 이상의 프로젝트에서 계획 대비 실행의 안전율이 1.7 미만이 되면,
쓸데 없이 더 이상 줄이려고 노력하지 말고
TOC학회등 관련 학회에 우수사례로 보고하면서 회사에 인센티브를 요청합니다.

연구에 따르면 1.6 밑으로는 드물다고 하고, 경험에 의하면 2정도가 상급이고 1.7 정도면 전설로 남습니다.

이상입니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================

제가 겪었던 사례가 있습니다.

이직을 하면서 어느 프로젝트에 개발자로 투입이 되었는데 이 프로젝트가 실은 몇 달 전에 시작되었고 마감까지는 한 달 남은 시점이었죠. 그리고 이런 프로젝트가 둘이었습니다. 이를테면 소방수로 투입이 된 거였죠.

당연히 불가능한 일정이었지만(게다가 개발자는 저 혼자였습니다. 엄밀히 말하면 개발팀 인원이 둘이었으나 실제 작업가능한 인원은 한 명이었죠) 위에서는 이 일정은 꼭 지켜야 한다고 못을 박더라구요. 뭐, 결과는 당연히 실패였습니다. 그것도 대실패였죠. 저는 일 주일에 두 번, 고양이 밥주러 집에 들리기만 하는 생활을 몇 주간 지속했고, 회사도 납기일을 맞추지 못함으로써 손해를 보았고요.

안된다는 것을 안된다고 말하지 못하는 상황, 어떻게든 해 보겠다고 대답할 수 밖에 없는 상황을 바꾸지 못한 제 책임도 있다고 쿨한 척 생각하고 앞으로는 그러지 말아야지, 할 말은 해야지 하고 결심했습니다. 뭐 그 이전에 그런 상황, 개발자 없이 프로젝트를 진행하(는 척 하)다 막판에 개발자를 투입하는 상황도 문제지만요.

저런상황에서 팀원이였던 적도 있었고 팀장이었던 적도 있었는데
팀장이라면 사고수습하고 일정 조정다시하고 팀원하고 같이 붙어서 일해야죠.
저런 상황에 이르지 않게 중간 중간 결과물을 확인하는게 가장 좋겠죠.

-------
매일 1억명이 사용하는 프로그램 nProtect가 있습니다.

어찌되었건 자기 팀의 일입니다.
결국 팀장의 책임이 가장 큽니다.
팀원한테 조치 운운할 일은 아닌듯 하군요.

위에 많은 분들이 지적하셨듯이
일정 관리를 제대로 못했습니다.
처음에 스케줄 한번 만들고(그것도 자기가 만들지도 않은)
나중에 그대로 내놔 하는 것은 누구나 할 수 있습니다.
제대로 된 매니징이 아니라는 거죠
중간중간에 계속 일정 조정을 해서 과정을 체크해야합니다.

그리고 커뮤니케이션의 문제도 보이는군요
왜 아무말없다가 마지막에 와서야 일정을 맞추기 힘들다라고
얘기하는 걸까요?

결국 제 생각에는 대충알아 팀장이 매니저 교육을 받던지
스스로 매니징에 대한 공부를 해서 제대로 된 매니저가 되어야
한다고 생각합니다.

마지막으로 '대충알아' 때문에 이런 문제가 발생한게 아니라
'난 몰라 관심없어 결과만 내놔' 때문에 문제가 발생한듯 하군요..

언제나 처음처럼 ~~

이 글에 관련된 이야기를 하려는건 아니고요.
이 글은 소프트웨어 개발자와 개발팀 및 팀장에게만 도움이 되는게 아니라 시스템 관리자, 시스템 엔지니어 및 우리나라 모든 IT 분야의 프로젝트 팀과 관련 기업에 도움이 되고 피와 살이 되는 논의로 생각되는 군요. 몇 달 전 글이긴 합니다만...
-- 이여송 --
HomePage: http://lys.lecl.net/
Blog: http://www.lecl.net/lablog
LECL: http://www.lecl.net/
E-Mail: yeosong@gmail.com ysnglee2000@lecl.net
MSN: ysnglee2000@hotmail.com

경험에 비추어 몇가지 의견 드립니다.

1. 짧은 검증 사이클이 중요합니다 - Scrum Sprint 나 XP Iteration 를 검토/도입해서 처음에는 2주단위로 프로젝트를 끊어서 진행하고 점검해보십시오. 각 Sprint / Iteration 후 반드시 각 결과물 검증 및 위험요소 분석/대책을 통해 시간과 리스크를 더 효율적으로 관리할 수 있을겁니다.

2. Prototyping 을 하십시오- 새로운 부분 혹은 위험요소가 있는 경우 특히 Design & Prototyping 을 반드시 진행하세요. 예를 들어 첫번째 2주간 Sprint / Iteration 으로 Prototyping 을 진행해서 결과물을 검증하고 문제점을 미리 파악하고 다음 방향 및 대책을 세울 수 있을 겁니다. 팀원들의 자신감도 올라갈 것이구요.

3. 책임/역할 분담 - 팀장이 기술부분을 책임지지 못한다면(않는다면), 별도의 기술담당 검토/책임자가 반드시 필요합니다. 결국 좋은 팀웍은 적절한 역할분담과 책임의식에서 생기므로 이 부분이 바탕이 되지 않으면 프로젝트의 성공이 쉽지 않을 겁니다.