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

brain2012의 이미지

회사에 '대충알아'팀장과 '쫌해요'팀원이 있습니다.

이 두팀장과 팀원은 전공분야가 다릅니다. 관심있어 하는 분야도 틀리구요.

여기서 '쫌해요'팀원의 분야인 A라는 작업이 있습니다.

'대충알아'팀장은 '쫌해요'팀원에게 전체 프로젝트의 일부분인 A라는 업무를 맡기려 합니다.

이 A라는 작업을 시작하기 전 부하직원 '쫌해요'팀원은 A라는 작업에 대해서

강한 자신감을 보이지는 않았지만 자신이 "할 수 있는 일"이라고 했습니다.

그래서 2달이라는 작업 기한을 가지고 시작되었지요

처음에는 작업을 위한 자료조사, 데이터 시트 읽기 등을 합니다.

자료조사와 어느정도의 시간이 지난후 '쫌해요'직원은 '대충알아'팀장이 보기에 그럴듯한 개발 계획을 내놓습니다.

'대충알아'팀장은 그대로 개발을 진행하라고 하지요

중간중간 개발 진행 상태에 대해서 물어보고 브리핑을 요구하면 '쫌해요'직원은 계획대로 "열심히" 하고있다고 합니다.

어쨌든 시간은 흘러흘러 작업의 기한이 다되어 갑니다.

그리고 작업의 기한을 일주일 남겨둔 시점에서 '쫌해요'팀원은 '대충알아'팀장에게 결과물이 나오기 힘들 것 같다고 이야기 합니다.

무엇이 잘못 되었는지를 물어보면 처음 자료조사하고 알아볼때는 쉬워보였는데 직접 작업을 해보니 자신에게 너무 어려운 작업이었다는 것입니다.

그래서 대안을 달라고 하지만 일단 결론적으로 대안은 없고, 그리고 이런 상황에 대한 대안 생각은 팀장의 할 일이 아니냐고 합니다.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

자 이쯤에서 전제 조건이 깔립니다.

1. 연봉은 동결입니다 (연봉협상시 '감봉'이나 '인상'등의 조치가 없다는 말입니다)

2. 해고는 가능하지만 A라는 작업외에 다른것도 해야할 '일손'입니다.

3. 법적인 절차를 따져 손해배상 같은건 하고싶지 않습니다.

4. 팀장은 A라는 작업의 결과물이 필요하긴 했지만 세부 개발에 관한 기술정보에 대해서 알고 싶어하지 않습니다.

오로지 결과물만 생겨나면 좋겠습니다. 그리고 이런 팀장의 생각을 지적할 사람이 없습니다.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

여러분이 만약 팀장이라면 '쫌해요'직원에게 어떻게 하시겠습니까?

여기서 "어떻게"란 위의 전제조건에 해당하지 않는 모든 말,행동,조치 등을 가리킵니다.

참고로 저 팀장 아닙니다 :p

(제가 저상황에서 팀장이라면 어떻게 해야 다음번에 이런일이 발생하지 않고 잘 진행될지를 고민하다가 올리게 된 글입니다ㅋㅋ)

shint의 이미지

팀장은 최소한 매주 가능성을 검증해야합니다.
물론. 개발자도 항상 매주 상황을 보고 해야합니다.
- 팀장이 기획했다고 해서 지금과 같은 문제가 없으란 법은 없습니다.
- 부하직원의 기술능력이 높다고해서 일정능력과 일치 할 수도 없습니다.
- 실제 프로젝트의 진행은 경험자가 아닌이상 일정을 반드시 성공하도록 만들 수 는 없습니다.
- 실패 할 수 있습니다.
- 게다가 부하에게 그 책임을 떠넘기고 나몰라라하게 된다면. 결과는 뻔합니다.

주변에 아무도 몰라.라는 것은 그만큼 책임을 회피한다는 말이 됩니다.
사장. 기획. 마케팅. 디자이너. 이 분들에게 프로젝트 실패의 책임을 물어보거나.
당신의 능력이 부족해서 실패했다고 말할 수 있습니까?

왜 개발자에게만 실패의 책임을 묻는겁니까.

이 글에 나오는 회사는.
성공하기 위한 노력은 하든말든 상관하지 않지만. 실패에 대한 책임은 확실히 하고 싶은것처럼 보입니다.

개발의 경우. 프로젝트를 진행하기 위해서는.
- 프로젝트기간 이전에 테스트검증기간을 가져야합니다.
- 프로젝트로 진행해도 되겠다는 판단이 서게 된다면. 그때 프로젝트 일정을 잡고 진행하는것이. 안전합니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지


일단 상황은 개발자에게 책임을 묻는 상황은 아닙니다.

제가 궁금한 것은 저 위의 상황에서 '팀내에서' 어떤것을 변화시키면

다음번에는 지금과같은 실패를 겪지 않고 프로젝트를 잘 진행할 수 있을까 입니다;;

그리고 무엇이 어떻게 문제인지 말이죠

팀장도 팀원도 자신의 지식수준 내에서 최선의 선택을 하며 A라는 업무를 진행했다고 생각합니다.

그런데도 실패하면 어쩔 수 없지.. 라는 것보다

다음번엔 어떻게 하면 실패하지 않을까를 고민합니다.

kasi의 이미지

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

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

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

shint의 이미지

프로그램은 기능의 조합이라고 생각되는데요.
일단은 자신이 가능한 수준에서 업무를 할당받은후에.
차근차근 업무를 진행하면서 앞으로 진행할 프로젝트에 대해 연구하다가.
그 연구 결과가 좋으면. 그때 프로젝트로 진행해야지.

주구장창 밤샌다고. 된다는 생각은 잘못된겁니다.

그러니까.
그 어쩔 수 없는 상황으로 몰아가는것 자체가.
가장 큰 문제가 되는겁니다.

프로젝트의 실패뿐만 아니라.
IT 업계의 실패가 되는 잘못된 생각입니다.

물론. 그것의 이면에는 단가와 일정이라는게 있을것 같은데요.
애들 후려쳐서 살림 좀 나아지셨습니까? 라고 말하고 싶군요.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

kasi의 이미지

네. 저도 밤 새는 것은 안 좋다고 생각합니다.
위에서 써 놓았듯이 이미 일이 틀어진 상황에서
최선의 조처는 일단 구현된 부분만 정리해서 릴리즈하거나 기간 연장(재조정)이라고 합니다.

다만 정말 이게 안되서 정말 회사의 큰 피해가 발생 한다고 가정한다면
하는데 까지는 해보는게 좋지 않을까 해서 적은 것입니다.
저도 밤샌다고 안되는게 된다고 생각하지는 않습니다.

shint의 이미지

회사에 큰 피해가 가는군요.
아무도 할줄은 모르고.
팀장은 뭔지도 모르고.
일은 벌어졌으니. 책임은 개발자가 져야하고.

성공은 공유하고
실패는 솔로잉하는
아직도 그런 회사가 있군요.

게다가... 전제조건을 보니.
2. 해고가 가능하지만
3. 법적인 절차를 따져
4. 팀장은 관심도 신경도 쓰고싶어하지 않습니다.
- 그냥 프리를 뽑지 그러세요.
- 개발자 입사시켜놓고. 역시 싼게 비지떡이라는 말이나하는 쓰레기류의 인간은 거기 없겠죠?

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지

회사에 피해가 오는것은 사실입니다.
아무도 할줄은 모르는건 아니고 '할줄 안다고 생각했던 사람'이 있긴 했었습니다;
팀장은 전체 프로젝트에서 한 모듈인 A라는 작업에 대해 입력과 기능은 정의해줄 수 있지만
구체적인 개발기술에 대한것은 전공도 아니고 관심도 없습니다. 그런데 어쨌든 전체 플젝을 위해서는 필요합니다
일은 벌어졌으니 책임은 팀장이 집니다. 다만 어떻게 해야 다음엔 이런일이 일어나지 않을까 고민합니다.

성공은 팀장이 가져갑니다.
실패도 팀장이 가져갑니다.

그리고 그 팀원은 다른 개발도 하긴 하지만 뽑게된 계기가 이 프로젝트 모듈을 개발하기 위해 채용한 계약직입니다.
사람에게 싼게 비지떡이라는 비인간적이고 혐오스러운 말을 하는 사람은 아직 회사내에서 못본것 같습니다.

kasi의 이미지

제가 글을 읽고 미처 제일 아랫 부분을 잘 캐치 하지 못하고

(제가 저상황에서 팀장이라면 어떻게 해야 다음번에 이런일이 발생하지 않고 잘 진행될지를 고민하다가 올리게 된 글입니다ㅋㅋ)

지금 발제하신분이 제시하신 상황에 대해서 어떻게 무사히 넘길 수 있을까 하는 관점에서 적게 되어서
shint 님하고 견해 차이가 발생한것 같습니다.

brain2012의 이미지

두분 사이에 뭔가 오해가 있으신것 같더라구요 ㅎㅎ;

물론 책임도 중요하다고 생각합니다.

하지만 실패를 경험한 사람이 실패한 '원인'을 알아내서 방법론 적이던 기술적이던 수정 보완하여

그 실패를 되풀이 하지않는것이 '훨씬 더' 중요하다고 생각합니다.

무사히 누구도 다치지 않고 넘어가는 것이 문제가 아닌

어쨌든 프로젝트라는 하나의 그림을 완성하기 위해 모인 팀이니까요ㅎ

brain2012의 이미지

밤샘한다고 해결될 문제였다면 2달이란 시간이 지날동안 그래도 뭔가 나왔지 않았을까 라는 생각이 듭니다 ㅠ_ㅠ

밤샘은 오히려 업무효율 저하등의 후유증이 심하기때문에 지양해야 할것이 아닌가 합니다.

아참 그리고 프로젝트의 결과물은 그냥 옆에서 보기엔 "별것 아닌 것처럼" 보이는 통신 모듈이었습니다.

전체 프로젝트로 본다면 부분적인 모듈로서 말이죠

다만 특이한 프로토콜을 사용하는 방식이었기 때문에 원하는 규격의 상용 제품이 없었구요

shint의 이미지

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

이거 참. 씁쓸합니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지


씁쓸하지요 ^_^;

저로서도 답답한 상황입니다.

큰 규모의 회사가 아닌이상 모든 개발에 대해서 세분화 시킬수가 없다보니

통신이면 통신전공, 하드웨어면 하드웨어 전공, 펌웨어면 펌웨어 전공 정도까지만

큰 뭉텅이로 분업되어 팀이 구성되어있다 보니 그런듯 합니다.

어쨌든 위에서 말씀하신 그 그럴듯한 말들 속에 정확히

무엇이 빠졌기 때문에

무엇이 부족했기 때문에

어떻게 잘못했기 때문에

등의 원인을 파악하고 다음번에는 실패를 되풀이하지 않으려 노력할 뿐입니다.

shint의 이미지

구글 스프레드시트'를 작성한후에
- 날짜/일정내용 을 색으로 체크해서 한눈에 확인할 수 있도록 했습니다.
- 대화의 도구를 이용해서 개발자의 문제나 상황을 항상 체크할 수 있었습니다.
- 매일 대화를 진행하면 개발자가 힘들어집니다. 체크는 매일하되 대화는 일주일단위로 하는게 좋았습니다.

일정체크시에는 예상일정과 진행중인 일정이 있는데.
그 오차가 클수록 프로젝트 진행이 문제가 있슴을 알려주고.
일정을 변경하기가 용이합니다.

정리하면.
- 프로젝트 이전에 테스트개발기간을 두고 개발해서. 실패를 최소화하고. 그 경험을 바탕으로 일정을 세분화한다.
- 표나 도구를 활용해서 누구나 프로젝트 일정을 한눈에 확인할 수 있고 대화할 수 있어야한다.
- 문제가 있다면 바로바로 대응해서 동적인 프로젝트를 진행한다.

프로젝트를 진행하다보면. 성공과 실패를 따지지만.
성공도 실패도 큰차이를 보이는것은 아닌것 같습니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지

개인적으로 구글캘린더만 사용하고있었는데 스프레드시트라는것이 있었군요 +_+

사용해본후 팀내 사용을 건의해봐야겠네요

좋은정보 감사합니다 :D

일단 현재는 날자/일정내용을 엑셀로 작성하여 팀장이 관리중이긴 한데 표현할 수 있는 정보가 한정되어있는 느낌이 있었습니다.

문제는 문제의 대응에 대한 것인데요 기술적인 난관에 봉착하면 외주를 생각하게 되는데 이것마저 업체 혹은 턴키방식의 사람을

구하기조차 쉽지 않더라구요 ㅠ_ㅠ

brain2012의 이미지


아참; 그리고 위의 상황은 개발 성공여부를 가늠해보고 진행할 수 있는 상황이 아니라

그냥 무조건 수단과 방법을 가리지않고 하늘에서 떨어진 프로젝트에 대해서 뭔가 결과가 나와야 하는 상황입니다;;;;

(여기서 프로젝트의 양이 많다는게 아니라 주어진 일에는 어떻게든 결과가 나와야한다는 것입니다)

shint의 이미지

일정을 늘리고.
개발 일력을 늘리고.
외주를 주면 됩니다.

어떻게해서든 개발자가 해결해야한다는 생각이신데요.
개발자가 포기하면 어떻게 하시겠습니까?

능력은 없고. 욕심만 많으면 거위배를 가르고 꼬메고. 가르고 꼬메더군요.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지

일정은 늘리고 싶습니다. 하지만 이것또한 팀위에서 픽스되서
'통보되는'것이지 '개발자(팀장포함)'의 의견에 의해 조율되는 상황이 아닙니다.
개발인력을 늘리는 것 또한 불가능합니다.
팀장이나 팀원들이 개발이 힘들다고 판단된 것 또한 외주를 줍니다.
이번건의 경우는 주제글에 쓰여진 것처럼 힘들다고 판단한 상황이 아니었습니다만;;

그리고 어떻게든 팀에 주어진 인력과 재원을 가지고 해결해야 하는 상황입니다.
개발자가 포기하더라도 어떻게든 결과물은 나와야만합니다. 참 곤란한 상황이지요.
그런데 회사가 그런걸 어쩌겠습니까; (이직하세요 라는 식의 말씀은 사양합니다)
위의 부장급에게 '해당 기술을 가진 개발자가 없어서 못하겠네요'라고 하면 어떤 대답이 돌아올지 짐작은 하시겠지요ㅠ_ㅠ

능력이 부족하지만 욕심을 저희가 부리는 것이 아니라 '위에서'부립니다.
그 욕심때문에 거위(개발자)의 배를 가르고 있는 것은 저희지요
이 구조가 잘못된 것은 알고 바꾸려 '위에' 이야기도 해보지만 약발이 안먹혔습니다.

shint의 이미지

그것을 진심으로 이해하고 해결하고자하는 동료가 필요한것 같습니다.

직원이 커버 못하면.
팀장이 커버 못하면.
그위에 사람도 함께. 그 문제를 알고. 해결하기 위한 모든 수단과 방법을 동원해야할것으로 보입니다.

여기서 직원 탓이나. 팀장 탓이나. 그 누구의 문제다. 라는 해결도 안되는 답은 없었으면 합니다.

방법은 모두의 책임공감과 책임지겠다는 마음과 의지면 될것같습니다.
그것이 그 회사의 강력한 힘이 될것으로 보입니다.
이것이 저의 최종 결론이 되는군요.

그런데. 다시보니.
결국에 회사는 아무것도 바뀌지 않았더군요.

어쩔 수 밖에 없다고 하면서요? 아주 쉽게 사는데요? 뭐하자는거죠?

제도와 구조는 그대로면서
사원이 바뀌기를 바란다라.... 이미 그것자체가 실패인겁니다.

이런건 회사가 바뀌지 않는이상.
어쩔 수 없습니다. 가 정답입니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지


솔직히 전 '쫌해요'팀원이 개발시 정직하고 정확한 보고를 하지 않은

잘못에 대해서 '뭔가 조치가 필요하지 않나' 라고 생각하고 있었는데

(진행상태를 물었을때 어디서 막혀서 안되고있어요 라고 말이죠)

그건 아닌건가요?;;

회의는 일주일에 한번씩 하고 그때 문제 사항을 보고하지 않으면 팀장은 모르는 상황이었습니다.

shint의 이미지

대화가 가능하다는것은 관심도 포함됩니다. 항상 결과에대해 확인해야합니다.
자신이 하는것이 맞다고 착각할 수 있습니다.

그런데. 그런 관심과 대화가 있고.
3년이상 C 경력자라고 하더라도.
문제에대해 알리는 구조가 되어있지 않다면. 그것은 대화하기 어렵습니다.
그건. 그 원인이 프로젝트 자체에 있기 때문입니다.

예전 프로젝트에서 10인이상의 개발자들에게 일정을 물었지만.
모두가 제대로 된 답을 할 수는 없었습니다.
지금 이때까지 하라메. 근데 무슨 일정을 따지래. 라고 하죠.
물론. 해본적도 없는것들입니다.

그리고.
3개월안에 무조건 해. 라는 전제가 있다면.
무슨 대화가 됩니까. 무슨 대화가 필요합니까. 무슨 일정이 필요합니까?

자신이 한다고 생각해보세요. 답 나옵니다.

그리고. 개발자가 정직했더라면. 같은 표현을 쓰셨는데요.
정직한 일정과 해결방법을 이미 아시고 계시지 않습니까?
그런데 정직한 개발자라고 넌지시 말씀하시는건 끝까지 책임 추궁하시겠다는겁니다. 아주 무서운 분이시군요.

정직한 일정을 주시면. 정직한 개발자가 되지 않겠습니까?
거짓된 일정을 주시면. 거짓된 개발자가 되지 않겠습니까?

http://blog.naver.com/jooworld/80085571745
이걸 보세요. 이러면서 뭘하자는걸까요?

나 300원 밖에 없는데. 어떻게든. 새우깡 점 사와. (콜라도 사오면 좋고)
맞습니까? 틀립니까?

설사 사온다고 해도. 그게 정당한 방법으로 얻어진것입니까?
아닙니다.

이러면서 정직한이라니... 프로젝트 자체에 문제가 있습니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지

일단 생각하고 계신 상황과 다른점이 있음을 알려드립니다.

첫번째, 개발에 들어가기 앞서 이것을 자체적으로 팀원에게 맡길것인지, 외주를 줄것인지 논의하는 시기가 있었습니다.

두번째, 정직한 일정이라고 하셨는데 그 정직한 일정은 팀원과 상의하에 결정된 시간입니다.

세번째, 새우깡 사오라는 상황을 예로 드셨는데 전 이런 상황을 들겠습니다.

사수 - "야 폭탄터지기 10분남았는데 선자르게 너 공구상 가서 니퍼좀 사와 얼마나 걸리고 돈은 얼마줄까?"

부사수 - "니퍼사본적은 없는데 한 이천원이면 되지않을까요? 갔다오는데 6분쯤 걸릴꺼같구요"

사수 - "그래? 터지기전엔 오겠네 삼천원 가져가봐"

[[[[ 5분 30초뒤 ]]]]

부사수 - "니퍼 오천원이라는데요 외상 안된데요 -_-;;;; 그래서 그냥 왔어요;;;"

이상황에 여러분이 '사수'라면? 인 상황입니다

그럼 우린 니퍼도 안챙겨주고 폭탄제거하라고 보낸 위를 욕해야겠지만 위를 욕한다고 터질 폭탄이 안터지진 않습니다.

(물론 다른점은 위에서는 중간에 상황을 보고하는 프로세스가 없는 예이긴 합니다만 일단 각설하겠습니다.)

그리고 넌치시 말하는 것이 끝까지 책임을 추궁하겠다는 것처럼 들리셨나본데

같은 팀원입장에서 중간에 정직하지 않은것은 실패의 책임을 따지지 않더라도 잘못된 것이라고 생각되기 때문입니다.

그리고 개발자는 무조건 피해자고 무고하다고 생각하시는것 같은데 저도 개발자 입장에서 그건 아닌것 같습니다-_-..

(이상황에서 저 팀장아니라고 다시 말씀드려도 안믿으실려나 -_-;;;;;)

ymir의 이미지

혹시 팀장에게 일 시키신 분? ^^

대충 얼마면 되겠네요.. 라는 심정적으로 가능할 것 같은 예상은...
통계적으로 3배 이상 초과되는 경우가 많더라.. 라는 내용을 SE 관련 책들에서 본 기억이 있습니다.
대개 이런 일정은 미리 '정확하게' 스케쥴링 되어 있는 일정을 아무런 방해/위험 요소 없이...
최상의 컨디션으로 진행을 하는 경우에나 가능한 경우가 많습니다. 그리고 규모가 작으면 작을 수록...

그 산출한 일정이 어떠한 근거로 산출되었는지, 위험요소/장애요소는 없는지..
마일스톤이나 태스크는 적절하게 리스트 되고, 선/후 관계가 명확하게 표시되었는지..
그 외에 누락되었거나, 뭉뚱그려 대충 표시된 내역은 없는지 그 타당성을 검토한 후에..
진행을 했어야 했다고 봅니다.

실질적으로 개발 내용은 잘 모르겠더라도, 최소한 스케쥴에 대한 검토는 가능할 것입니다.

어쨌든 이미 벌어진 일이라면, 일단은 수습하는게 급선무이고...
이러한 사태가 벌어진 원인을 파악해서, 개선/방지책을 세우는건 다음 일이겠군요..
직원을 추궁하거나, 책임을 지우는 일은 전혀 득이 없다고 생각됩니다.

거짓말을 했다라는 것도, 잘 따져보다 보면..
의도적으로 피해를 입히기 위해 사실을 숨기고.. 허위를 보고한 게 아닐 가능성이 높기 때문입니다..

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

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

shint의 이미지

제가 이런 상황에 처했다면.
똑같은 생각과 질문을 했을겁니다.

이런때 의지되는건. 올바른 판단력과. 진정한 의지를 가지고 함께할 동료 뿐 입니다.

그런데. 정작 중요한것은 구조입니다.
이럴 수 밖에 없는 구조라고 하면서
그 늪을 헤어나오거나 모래로 메꿔서 바꾸지는 못한다고 합니다.

난 100원밖에 없으니. 300원짜리는 먹어야겠고...
회사가 안바뀌면서 답을 찾는건. 뭐하자는걸까요.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지

그런데 생각해보면 회사의 구조만을 탓할 수 있는 상황은 아닌것 같습니다.

회사의 구조 또한 외부의 산업 구조 때문에 그렇게 된 것은 아닐까요?

적어도 제가 알고 있는 시장구조에 의하면 마지노선이란게 있어야 합니다.

그런데 경영자들은 마지노선(플젝의 규모 대비 비용, 보유한 기술력 여부 등)이란걸 생각하기보다

일단 돈이란걸 벌어들여야 직원들에게 월급을 주기 때문에

수많은 업체들과 경쟁하는 과정에서 가격을 낮추게 되고

그 마지노선이란건 그냥 집에 놀러온 애인이 넘어오지 말라고 그어 놓은 선처럼

넘으면 누군가 반발할 것이라는 걸 알면서도 넘어갈 수밖에 없습니다.

그럼 자연스럽게 그 밑에있는 사람들은 줄줄이 즐거워지기 시작하죠 (반어법인거 아시죠? -_-ㅎ)

그 즐거워짐으로 인해 결과물의 퀄리티는 떨어지겠지만

해당 기술 개발에 대한 개념조차 제대로 안서있는 (스팩좋으시고 바닥을 굴러본적이 없으신)

박사급 책임이 관리하는 대기업 혹은 국가의 프로젝트 책임자는

최대한의 마진을 남기기 위해 가장 싼곳을 선택하기 마련이고 (그래야 자기 인센티브가 높아지니까요)

해당 기술에 대한 지식도 아주 얕은 경우가 많은듯 합니다.

결국 결과물의 기능에 대해서 그냥 슬쩍보고 "오 동작하네"라고 '생각되면'

(그것이 내부적으로 무슨 꼼수를 쓰던 사기를 치던 그걸 검증할 생각은 안하고) 오케이 사인을 날리니

그리고 나중에도 점점 싼것만 찾게 되니 이런일이 반복되는 것이 아닌가 싶습니다.

이건 누구 하나가 바뀌어서 되는 것은 아니겠지요

새로 자라나는 학생들 그리고 개발자를 희망하는 이들에게 이 문제점에 대해 충분히 알리고

이 문제점을 알고 있는 사람들이 많아져야 한다고 생각합니다.

그 사람들이 자라서 어떤 위치에 섰을때 자신의 위치에서의 문제점은 무엇이고 그것을 고치려 노력할때

점점 나은 구조가 생겨나지 않을까요 ㅠ_ㅠ

강이 오염된 것을 알았을때 그 강을 되살리기 위해서는

많은사람이 그 강이 오염되었다는 것을 알고

많은 사람들이 오랜시간 노력해야만 되살아 나듯이요 :D

소타의 이미지

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

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

shint의 이미지

이것은 회사 구조상의 문제입니다.
그것은 팀장과 팀원의 대화문제입니다.
제대로 검증하지 않았던 문제입니다.
최종적으로 개발에 미숙한 개발진의 문제가 됩니다. 근데. 이게 문제가 됩니까? 업무배분을 잘못한겁니다.

개발자만의 문제일까요?
지금과 같은 상황이라면.
대부분의 개발자가. 그렇게 될겁니다.

일주일마다 업무분석을 통해 검증한다면.
그나마 더 빠른 판단을 할 수 있었지 않았을까 생각됩니다.

사실 이 시나리오에 답은 개발자에게 개목걸입니다.
뻔한 답. 상식화된 답. 그런거 다 저런 상황이 만든겁니다.

회사의 그 누군가가 더 노력한다면. 저딴일 적어질겁니다.
그리고. 벌어진다고 해도. 회사가 모두 이해할겁니다.
누군가의 책임 따위로 몰아세우는 지금의 단답형식의 문제접근 방식은. 아주 이가 갈리는군요.

이건 논리도. 대화도. 뭐도 아닌.
단지 개발자 매도 시나리오중에 하나로 보입니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

소타의 이미지

음;
개발자가 일정과 계획을 내놓고 난 후에 "개발 과정 중에 생긴 문제"입니다.
제 생각엔

Quote:
중간중간 개발 진행 상태에 대해서 물어보고 브리핑을 요구하면 '쫌해요'직원은 계획대로 "열심히" 하고있다고 합니다.

부분이 문제라고 생각합니다.
기한이 계획에 비해 무리가 있다는 전제도 없습니다.
개발자는 개발 과정중에 생긴 문제를 빨리 공유하지 않아서 다른 문제로 확대될 때까지 공유하지 않았습니다. 혼자 하는 프로젝트면 모를까 팀단위 작업에서는 커뮤니케이션이 중요합니다.
매니저는 계획대로 되어가는지를 검증하지 않았습니다. 매니저는 개발자를 도와주는 사람입니다. 대화를 할 수 있는 분위기를 만들어야 하고 크고 작은 문제를 캐치해서 그걸 해결할 수 있게 해줘야합니다.

회사가 어떻고는 상관없죠. 회사가 크던 작던 좋은 프로세스를 가졌던 안가졌던 상관없이 두 사람이 역할을 제대로 하지 않은것이 문제입니다.
이 두사람은 아무리 좋은 회사나 분위기에서도 실제로 이렇게 일을 한다며 문제를 야기할 수 밖에 없을 것 같습니다.
이딴일을 적어지게 만들 회사의 노력하는 누군가는 이 두 사람 모두가 되어야 합니다.

shint의 이미지

규칙적인 관심과 대화.를 통한
프로젝트의 진실탐구가. 프로젝트의 성패를 좌우한다고 생각합니다.

물론. 외부의 강압적인 일정등의 조건과 목적이 전제되는 대화가 존재하지 않는다면 말입니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

brain2012의 이미지


저도 강압적인 일정 등의 외압이 없는 상황에서 일을 하고 싶습니다만 모든 일에는 일정이 있습니다.

R&D에서 '그래 하는데까지 해'라고 하면서 결과가 나올때까지 기다려 주는 조직은

짧은 사회생활이었지만 아직 들어보지 못한것 같습니다.

shint의 이미지

마음이 씁쓸합니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

powerson의 이미지


소타님 의견에 공감합니다. 둘다 문제인거지요. 저도 한번 팀장을 해본적이 있는데, 부하직원의 상태를 체크하는데, 무진장 애를 먹었었습니다. 쉽지 않은 일이지요. 근데, 팀장으로써 꼭 해야 할 일이기도 한거지요. 다만, 지금도 잘 모르겠지만, 위와 같이 쫌 해요 하는 부하직원들의 경우 자부심이 강해서 자신의 개발 현 상태를 100% 완전 공개 안하는 경우가 많은 거 같습니다. 특히나 문제점은요. 왜냐면, 남은 기간에 자신은 해낼수 있을꺼란 자부심이 있으니깐요. 문제는 기한이 다가오게 됐을 경우 포기하는 경우인데, 그 전까진 어떻게든 포장해서 보고를 하는데, 이걸 어떻게 캐치해낼 수 있는지.. 이게 저 역시 궁금한 상태입니다.

------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.

------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.

minias의 이미지

왠지 소타가 소타같지 않아보임.. ^^; good job.

조금이나마 구멍가게에서 팀장해본경력이 있어 몇자 적습니다.

저도 소타님의 의견에 동감합니다.

한국의 매니저와 외국의 매니저의 R&R의 정의가 좀 틀려보이는것 같기도 합니다.

매니저는 어떤 경우에도 프로젝트의 결과에 책임을 져야합니다.

모르면서 프로젝트를 맡아서도 안되고, 너무 많이 알아서도 안됩니다.

매니저는 주어진 프로젝트의 전제조건이 적합한지 예측이 가능해야되며, 인력구성에 대해서도 신경써야 하며,
리스크관리도 해야 합니다.

거기에 현재 업무 스케쥴이 제대로 진행되는지 짧게는 일일,주단위, 길게는 월단위로 확인하고 이상 유무 파악하여
프로젝트가 최상의 조건으로 가고 있는지 확인할 의무가 있습니다.

항상 그렇듯이 모든 프로젝트가 잘 풀리지 않습니다.

또한 예기치 못한 변수에도 대처능력을 매니저는 가지고 있어야 합니다.

거기에 커뮤니케이션 능력도 있어야합니다.

팀원과의 업무조율과 윗선에 대한 커버링도 어느 정도 해주어야 합니다.

그래서 어느 조직이나 중간위치가 제일 빡신 자리라고 생각합니다.

뛰어난 매니져라 하더라도 프로젝트의 위기는 있을 수 있으며, 이때 매니저의 역활을 어떻게 위기를 모면? 극복할 수있는지를
결정하고, 그 결정에 대해서 자신이 책임져야 하는겁니다.

역량부족인 팀원에게 일을 시킨것도 매니져였으며, 관리 소홀한것도 매니져입니다.
위의 사례를 보자면... 매니저에게 큰 비중의 잘못이 있다고 생각됩니다.

제가 위 사례의 매니져라고 가정한다면, 가장 시급한 문제는 프로젝트의 문제(기간상 끝낼수 없음)를 해결하기 위해서..
팀원과 업무 조율, 윗선 보고때 현사태 보고 및 스케쥴 조정, 또는 인력분배 변경, 프로젝트 성과 조절 및 2차 프로젝트 분리등 시도할것 같습니다.
노력하지 않는 꿈은 꿈으로만 남는다. - 미니어스

노력하지 않는 꿈은 꿈으로만 남는다. - 미니어스

ymir의 이미지

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

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

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

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

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

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

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

dipole의 이미지

제보기에 글쓰신 분은 전개중에 이미 답을 다 말하고 계십니다

대충알아 팀장이 프로젝트의 시작을 판단하고 중간에 체크하고 진행되던 것이

마감시간이 얼마 안남아 쫌해요 직원으로 부터 폭탄 통보를 받는다.

다음부터는 어떻게 하면 이런 일을 피할까요?

팀장이 핸들할수 없는 업무를 하겠다는 것이 첫번째 에러.
할수 있다고 얘기하는 사람의 중간 보고에 대한(외주든 내부든) 신뢰성을 확보하지 못한 것이 두번째 에러.

팀장은 자동차를 만들고 싶은데 어떻게 만드는지 모른다면 일을 맡아야 할까요?
최소한 어떤 과정을 거치고 무엇이 필요하다는 전체적인 과정에 대한
이해와 문제 발생 소지를 머릿속에 그릴 정도는 되어야 팀장을 하죠.

가장 중요한 문제는 준비되지 않은 팀장.
두번째 문제는 첫번째 문제로부터 발생가능한 상황중의 하나일 뿐입니다

너는 누구냐?

obbaya의 이미지

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

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

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

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

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

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

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

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

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

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

shint의 이미지

대화할 수 있는 구조가 되야할것 같습니다.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

obbaya의 이미지

구조 탓인지 사람 탓인지 아리송하네요.

shint의 이미지

상황과 조건. 목적으로 대화하는 전제가 깔리게 된다면.
귀에 걸면 귀걸이.
코에 걸면 코걸이.
말장난이 되는겁니다. 유리한쪽으로...

지금까지는 개발자가 내가 잘못했구나. 내가 야근해야지. 라고 생각했었지만.
제 지나간 기억을 더듬어보니.
저 이후의 개발자들은. 그렇게 살지 않게 해야겠습니다.

개발자에게 잘못을 뒤집어 씌우고 싶다면. 그 상관들과 회사도 책임져야할겁니다.

http://blog.naver.com/jooworld/80085571745 이걸 보세요. 이러면서 뭘하자는걸까요?
이해 되십니까?

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

rubenz의 이미지

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

shint의 이미지

나는 널 믿어.
한마디하고 끝입니다. 정말 쉽죠.

얼마후 건네지는 말은 같습니다.
내가 널 믿었는데.

뭘 믿었을까요?

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

rubenz의 이미지

머 대안은 아니고 저도 PM일때 저런 경우 당한적 있습니다.
그때에 저는 이랬습니다.
출근후, 회의 및 진도 확인.(약 15분에서 20분 정도)
점심먹구, 회의 및 진도 확인.
저녁 먹구 회의 및 진도 확인.
퇴근하기 전에 회의 및 진도 확인.
이렇게 했습니다.(한명 붙잡고 2주정도 저랬습니다.)
대안이랄께 별것 없습니다. 안되면 되게 하라는 명제라면, 저도 책임있고, 그사람도 책임있고, 모두 몸으로라도 뛰어야지요..
사실, 저도 괴로웠지요..;;

shint의 이미지

저같은경우는
그와 비슷하게 투명하게 공개된 개발진행을 했었는데요.

상대가 개발진행의 조언자이자 도움이 되는 협력자로 인식될경우는
즐겁게 대화하면서 개발했습니다.

반면. 일 부려 먹으려고 관리하려는 사람으로 인식된다면
개발에 부담을 주게되면서 프로젝트를 망치기도 하더군요.

관리자이기보다는.
조언자이자 협력자. 동료로써 업무진행을 하는게 어떨까 생각됩니다.

행복을 함께하는 동료보다.
아픔을 함께할 수 있는 동료나 상사가 필요한 시대인걸까요.

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

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

sunyata01의 이미지

위에 글보면 제가 쫌하는 팀원으로 보이는데..참으로 씁쓸합니다.
그럼 당신도 그런 상황이 온다면 그러실건가요?
그리고 좀하는 팀원 입장에서 생각해보면,
개발자가 일을 하면서 자기가 아는 것만 한다면, 개발자가 아니라 로직좀 짤고 배운거 응용하는 숙련공이 아닐까요?
그래서 한번 해보고 싶고 새로운거 하고 싶은 마음에 할려는거 아닐까요?
좀더 얘기하면 회사에 도움주기 위해서 선택한 것이 아닐까요?

brain2012의 이미지

처음 글을 올린 글쓴이 입니다.

스트레스를 받으셨다면 죄송합니다ㅠ_ㅠ;

개발자가 자신이 관심 있는 분야에 대해서 트라이 하면서

어떻게 해야 실패의 리스크를 줄일 수 있을까도 한 주제이긴 합니다.

회사에 도움이 되기도 하고 개인적으로도 득이 되겠지만

안타깝게도 그것은 성공한 상황에서 의미가 생기는 것 같습니다.

그래서 위의 상황처럼 진행되는 프로젝트에서 어떤 것이 문제인지 파악하려 하는것이고

그것을 찾아서 개선하면 프로잭트 실패의 리스크가 줄어들고 자신에게도 회사에게도 득이 되는 방향이 궁금한 것입니다.

전 이제 이십대 후반이고 학업과 일을 병행하는 단계라서 부족한 것이 많습니다.

여러 개발자 선배님들께 의견을 구하고자 글을 올린 것이니

기분 상하셨다면 다시 한번 사과드립니다.

johan의 이미지

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

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

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

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

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

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

brain2012의 이미지

사실 좋은 그리고 실력있는 팀장을 만나는 것도 복인 것 같습니다.

그리고 그 실력뿐만이 아니라 자신의 팀원의 문제를 지적하면서

자신의 기술적인 노하우도 내비칠 수 있는 인간성(?)도 중요한 것 같습니다.

인간성이라고 표현하긴 뭐하지만 자신이 알고있는 것이 있음에도 불구하고

자신만 알고 까기만 하는 팀장을 만난다면 참 곤란할꺼같군요;;;

참 쉽지 않은길인것 같습니다ㅎㅎ

BSK의 이미지

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

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

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

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

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

freestyle의 이미지

이유는 윗분들이 말씀해 주셨듯 일정/인력 관리를 제대로 못한 것이라는 점과
최종 책임은 팀장에게 있다는 점입니다.

팀원(사원) 입장으로써 일정관리 제대로 못 하거나 의견조종 제대로 못하는 팀장은
하루 빨리 자리를 떠나야 한다고 생각합니다.

특히 악독한 사람은 특정 팀원에게 그 책임을 돌리거든요.
----------------------
Go to the U-City

----------------------------------------------------------------------------------------
Don't Feed the Trolls!
----------------------------------------------------------------------------------------

shockyhan의 이미지

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.
===========================================================================

===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================

brain2012의 이미지


절차는 간단해 보이면서도 좋은 방법인듯 합니다.

그런데 안전율 평균이 1.7이하로 떨어진다는 경우가 있다는 것은

숙련도 상 / 난이도 하 - 2점 일때보다 점수가 더 낮은 상황도 있다는 것 같군요 :D

좋은글 감사합니다.

leafriend의 이미지

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

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

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

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

M.W.Park의 이미지

둘 다 잘못이 크네요.
경중을 따지기힘들지만, 책임을 물어야한다면 팀장에게 물어야하겠죠.

같은 팀이라면 그런 방식으로 일하면 안되죠.

자기 실력을 제대로 모르고 설치는 팀원과 그 팀원의 실력을 모르고 있는 팀장과의 차이는 직급정도 밖에 없을 듯...

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

bungker의 이미지

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

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

volatile의 이미지

팀원에게 왜 보고하지 않았냐고 이제와서 말하는건 무책임한 태도입니다.
모든책임은 팀장 자신에게 있다는걸 알려줘야 될듯.

doogie의 이미지

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

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

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

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

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

언제나 처음처럼 ~~

언제나 처음처럼 ~~

magingax의 이미지

팀장이란 직무가 그런걸 사전에 체크하고 조정하는게 일이죠..
일던져놓고 납기까지 해서 가져와..이런건 정말 무책입한겁니다.
직원이 그분야 전문가가 아닌걸 알고도 일을 시켰다면..
중간중간 가시적 결과물을 체크했어야죠.
아니다 싶으면 업무를 다시 조정해야했고요.
'저 사람이 할수있다고 해서 시켰는데..못했어요..저사람을 처벌해야합니다.'
이런 무책임한 사람이 어디있습니까.
직원입장에서야 위에서 시키니 못한다고하기 어려운니 해볼려고 애쓰다가. 해보니안된건데..
그걸 처벌하시겠다는건..말이 안됩니다.
이런 경우는 100 프로 팀장 책임입니다.
프로젝트에 대한 이해가 없는 사람이 팀장을 하면 배가 산으로 가지요
팀장을 보직해제 해야합니다.

거창하게 무슨 공정관리 그런거 할필요도 없이.
일주일에 한번씩 모여 현황파악하고, 업무분장하고,
가끔 점심먹고 개발자 자리에 가서 개발된 모듈좀 돌려보라고해서 확인하고.
못하면 몇번더 예기하다가 그래도 안되면 업무 바꿔주고.
팀장 잘못으로 프로젝트가 엎어지게 생겼는데.
직원에게 법적책임을 묻는다는 예기까지 나오는 회사라면..회사도 문제가 있죠.

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

사랑천사의 이미지

이 글에 관련된 이야기를 하려는건 아니고요.
이 글은 소프트웨어 개발자와 개발팀 및 팀장에게만 도움이 되는게 아니라 시스템 관리자, 시스템 엔지니어 및 우리나라 모든 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

사람천사

infantry의 이미지

다녔던 회사 하고 비슷한데요

근데 조금 틀린게 있습니다

메인글에는 대충알아 팀장과 쫌해요 개발자 이지만..

다녔년 회사는.. 썅.. 대충알아 팀장과 대충알아 개발자 였습니다..

저는 뭐했냐고요?. 대충알아 팀들 말아먹은거 뒷처리하다 보니 회사가 없어지더구요..

쓰앙..

fadeback의 이미지

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

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

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

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

Never give up!

poiu990의 이미지

할 수 있다고 해서 시켰는데 막판에 가서 나자빠진건데

회사가 보는 입장에서 팀장이나
팀장이 보는 입장에서 팀원이나 마찬가지죠.

회사는 팀장이 할 수 있다니까 외주 안 주고 원하는 일정 줬는데 못한다고 한거고
팀장은 팀원이 할 수 있다니까 외주 안 주고 원하는 일정 줬는데 못한다고 한거고

여기서는 개발자를 옹호하는 분이 많은데
프로라면, 할 수 있다고 얘기했으면 오히려 아무런 관리, 감독 없이도 해내야 하고
그게 안되면 적어도 사고가 나지 않도록 스스로 요구를 단순화하건, 지원을 청하건
어떻게든 알아서 했어야 합니다.

팀장이라면 어떻게 했어야 하는가?
팀원보는 안목을 키워야죠.
가만 나둬도 될 사람은 믿어주고
못 믿을 사람은 계속 귀찮게 해서 못견디고 나가게 하건 견뎌서 믿을만한 사람으로 만들건..

저희는 개발부서는 아니지만 아예 검증 안된 사람 안받으려는 부서도 있습니다.
있어봤자 도움도 안되고 괜히 부서에서 인당 하는 일만 깍아먹는다고요.

maddie의 이미지

전 그런 경우 개발자가 제시하는 일정에서 추가일정을 넣어 보고합니다. 보통은 15일 정도로 두죠.(업력이 좀 되면 이게 딜레이 될 경우 어느 정도 딜레이될 것인지 보이기도 합니다.)
사기치는 것 같지만 물론 개발자 본인에게는 그런 사항을 이야기하지 않습니다.

문제가 터지면...사실, 문제는 반드시 터집니다. 누구나 장인정신이 있는 개발자들은 특정 문제를 해결을 하기 위해 추가 시간 소모가 당연하기 때문입니다. 물론 그런거 무시하고 QA기간동안 하자는 사람들도 있지만요.
(그래서 전 정말 기계같이 코딩해서 납기일 맞추고 QA기간을 늘리게 만드는 개발자들을 그닥 좋아하지 않습니다.)

이 경우는 사실 좀 아쉬움이 있는 것이,
납기일이 미뤄져서 회사에 손해가 있다고 하면, 대부분 첨부터 리스크를 보고하여 미리 대책을 마련했다면 임팩이 크지가 않습니다. 예상된 문제와 예기치 못한 사고는 차원이 다른 것이지요.

제가 팀장이라면 사업부서에 최악의 시나리오를 상정하여 미리 대비하는 시나리오도 마련을 했을 것 같습니다.

그 점이 아쉽네요.

힘없는자의 슬픔