개발팀이 일정도 지키게 하면서 동기를 부여하는 방법?
요즘 Hard Code라는 책을 읽고 있는데... 마이크로소프트에서 어떻게 소프트웨어 개발 프로젝트가 이루어지고 있고, 또 문제는 무엇인가에 대해 내부 직원이 쓴 책입니다. 군데군데 회사 내부 용어도 나오는데 꽤나 재미있네요.
내용 중에 개발팀이 일정도 지키게 하면서 동기를 부여하기 위해 저자가 제안하는 방법이 있는데 괜찮은 것 같아서 공유합니다.
우선, 한 번 더 말하겠는데, 기능 완료일을 맞추라고 팀을 닦달하면 팀은 편법으로 날짜를 맞추거나 거짓말을 둘러댄다. 진도를 속이고, 품질을 낮추고, 완성도를 떨어뜨린다. 그게 싫다면 더 나은 방법으로 동기를 부여해야 한다. 나는 다음 세 가지 방법을 적절히 조합해 멋진 효과를 거뒀다.첫째, 가장 기본적으로 일정 예측에 리히터 척도를 적용했다. 기능마다 걸릴 시간을 대략 예측한 후 팀에게 알렸다. 2주짜리 기능에 2주 반이 걸리는 정도는 상관하지 않았다. 그 이상 걸린다면 합당한 이유가 있기 마련이고 팀은 내게 이유를 알려왔다. 합당한 이유가 없다면 지연할 구실도 없이니 동기 부여가 저절로 됐다. 일정이 빡빡하지 않으니 거짓말과 편법도 줄어들었다.
두 번째 방법으로 중간목표 점검일을 정했다. 이 일정 역시 편법을 부추길 위험이 있지만, 팀에게 긴장감을 심어주고 진도를 확인하는 효과가 있었다. 중간목표 점검일은 '팀'이 공식적으로 맞춰야 할 일정이라는 점에서 기능 완료일과는 달랐다. 일정을 맞추려고 팀 전체가 협력했는데, 그 결과 개인적인 부담이 줄면서 편법도 줄었다. 물론 완전히 사라지지는 않았으며, 여기서 마지막 방법이 커다란 효과를 발휘했다.
마지막 방법은 가장 효과적이기도 했다. 나는 팀에게 '반드시 출시할' 기능, 즉 가장 먼저 완성할 기능 목록을 분명히 밝혔다. 나머지는 필요에 따라 쳐낼지도 모른다고 통보했다. 불행하게도 '반드시 출시할' 기능은 구현하는 재미도 없고 자랑할 건더기도 없었다. 그래서 나는 팀에게 재미난 기능을 맡으려면 먼저 핵심 기능을 확실히 끝내라고 말했다. 그러면 포상으로 중요도는 조금 낮지만 더 멋진 기능을 맡기겠노라 약속했다. 이런 식의 동기부여는 긍정적이고, 건설적이며, 효과적이다. 어디서나 늘 통한다.
물론 위의 내용이 제대로 진행되려면 여러가지 사항들이 잘 맞아떨어져야 할테고 일괄적으로 적용하는 것은 불가능할 테지만... 여러분의 팀은 어떤가요? 어떤 식으로 동기부여를 하나요?
댓글
이 글 보고 저도
이 글 보고 저도 질러버렸네요. 출판사에서 하는 트랙백 이벤트 떨어져서 나~~중에 살려고 생각하고 있었는데 결국 결제 완료.ㅋㅋㅋ
하지만 직장인이 아니므로 교양책이나 다름없군요.^^;;
오
"마지막 방법은 가장 효과적이기도 했다. 나는 팀에게 '반드시 출시할' 기능, 즉 가장 먼저 완성할 기능 목록을 분명히 밝혔다."
그러면 반드시 출시할 기능을 먼저 밝히지 않고 프로젝트에 돌입하는 경우도 있다는 말인데...
초큼 무서움....
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.
http://jihwankim.co.nr
여러 프로그램 소스들이 있습니다.
필요하신분은 받아가세요.
---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.
http://jihwankim.co.nr
여러 프로그램 소스들이 있습니다.
필요하신분은 받아가세요.
경험상으로는 대부분
경험상으로는 대부분 그렇던데요.
모든 게 중요하다고 말한다는 -_-
Life with fun...
Life with fun...
제가 알기론
가령 개발팀들에
A, B, A3, C2 기능을 구현하여한다고 내려지면,
개발은 계속 진행되겠지만,
management part 또는 marketing team에서
차후 version에 어떤 기능들이 들어가야 할지 중간에 정하는 경우도 있습니다.
가령, 뭐...
windows mobile 7을 2009년에 발표하기로 했는데,
이것을 미루고,
windows mobile 6.5에 이런이런 feature를 넣어서 2009년 초반에 우선 출시하자... 뭐 이런식으로...
저런건 혼자 알고 있어야 되는건데..
세번째 방법은 프로그램을 하기 좋아하는 사람에게나
통할법 하네요..
요즘은 무책임한 개발자가 너무 많아서요..
저런거에 동기부여가 될지 의심 스럽습니다..
반대로 그런것들이 저에겐 기회겠지만요
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
맞는 말이겠습니다만...
제가 생각하기에는 최우선으로 관리자가 팀원이라는 의식이 모두에게 있어야 한다고 생각합니다.
관리자 스스로도 그렇고, 다른 팀원들도 그렇게 생각해야죠.
우리나라에서 코딩은 이제 끝나고, 관리만 한다면서 좋아하는 프로그래머였던 사람들이 있습니다. 이런 경우 대게 일종의 계급의식이 있는 것 같아요. 같은 회사에서 같은 일을 하지만 마치 타 업체에서 하청주듯 일을 시킵니다.(물론 하청업이 이런 관행이 심하다는 것이지, 하청을 하는 과정이 이래야 한다는 것은 아닙니다.)
심하게 말하면 '너희와 나는 다른 존재다', '아쉬우면 너도 관리자해라' 일까요?
안 그런 관리자도 물론 있습니다. 특히 나이가 역전되고, 코더가 산전수전 다 겪었으면 입장이 바뀌긴 하지요. 하지만 그렇다고 하더라도 코더가 관리자를 무시하는 경우는 없는 것 같습니다. 관리자가 코더를 존중하는 거죠. 일단 이 상황만 보면 이상적이지만 두 사람이 자진적으로 이런 분위기를 만드는 경우는 흔치 않습니다. 그래서 뒤집힌 나이관계와 경험낳은 코더같은 특정요건이 필요하죠.
Hard Code의 저자는 몇가지 방법을 사용해서 개발자들에게 일정에 대해서 지킬 수 있도록 장치를 마련하고, 구체적인 목표를 설정해주었지만 더 큰 부수효과는 자신이 그런 고민을 함으로써 개발자들에게 관리자인 저자 자신도 일을 같이 하고, 끝마치기 위하여 노력하는 동료라는 의식을 심어주는데 성공했다고 생각합니다.
만일 개발자들이 이런 장치들 속에서도 책임을 회피하고, 악용할려면 비록 어려울지라도 방법은 찾을 수 있다고 생각합니다. 관리자는 그런 변화되는 상황을 빠르게 감지하면서, 팀원들에게 귀찮으지 않게 받아들일 수 있는 새로운 제도적 장치를 계속 만들어야 하겠지요. 그리고 받아들일 수 있도록 충분히 설명해야될테고요.
마지막 방법은
악용하는 개발자도 많지 않을까 싶네요...
프로젝트 기간 내내 이것만 하고 말아야지 하는;;;
코드 한줄 덜 짜면 그게 큰 횡재라도 한 줄 아는 사람도 적지 않더군요...
피플웨어에 따르면
피플웨어에 따르면 일정을 전혀 추정하지 않았을 때 가장 개발 속도가 빨랐고, 개발자 자신이 일정을 추정했을 때가 그보다 근소하게 느렸습니다. 그리고 이 둘에 비해 현저하게 느렸던 방법은 팀장이 일정을 추정하고 그 일정을 개발자에게 알려주었을 때였습니다.
마일스톤을 정하는 것 역시 일정을 늦어지게 만드는데 탁월한 효과가 있습니다. 버퍼가 낭비되기 때문이죠. 제약이론에 잘 나오는 이야기입니다.
그래도 세번째 방법은 다른 연구 결과들과 맞아 떨어지는 부분이 있는 것 같습니다. 일 잘하는 사람에게는 돈이 아니라 더 중요한 역할로 보상하라는 말도 있고 말이죠.
Good to Great에 따르면 동기 부여는 별로 고민할 필요가 없다고 합니다. 동기란 것은 사람들 마음 속에 이미 존재하는 것이고 이것을 꺾지 않는 좋은 환경만 만들면 동기 부여 문제는 저절로 사라지는 것이라고 말이죠.
개발자가 일정을
개발자가 일정을 1차로 제출해서 크게 무리가 없다면 그대로 진행이 되고 팀장이 보았을때 자신이 생각한것보다 차이가 크다면 왜 그런지에 대하여 서로 논의해서 1차 구현에 대한 기능을 줄이던지(이때에는 남은 내용들을 2차 일정에 포함시키던지) 아니면 개발자가 일정이 이렇게 되는 합당한 이유를 팀장에게 설득하여 진행하도록 하였을때 상당히 편안한 마음으로 일을 진행할 수 있었습니다.
그리고 일정을 개발자가 직접 산출한것이기 때문에 일정에 대하여는 변명의 여지가 별로 없게 되니 좀더 active 하게 일이 진행될 수 있었던거 같습니다.
그리고 요즘 황농문 교수가 쓴 "몰입 (Think Hard)" 라는 책을 읽고 관련 강의 동영상도 받아서 보았는데 거기에서도 일정에 대한 언급이 있습니다.
우리가 소위 말하는 "똥줄 신드롬"(?) 아라고 해서 일정이 다 되어서 일정에 대한 압박을 받을때 집중도가 급격히 높아지고 구현등의 작업이 상당히 잘 진행되는것을 한번씩 경험해 보았을겁니다. 황농문교수는 이러한것을 좀더 일찍 초기부터 서서히 몰입의 강도를 키워나가면서 평소에도 일정수준 이상의 몰입도에서 일을 진행할 수 있도록 훈련을 해야 한다고 설명합니다.
새로운 내용은 아니지만 remind 차원에서 괸찬은 지적이었다고 생각됩니다.
High Risk & High Return ~
High Risk & High Return ~
개발자가 일정을
개발자가 일정을 잡게 하는 것은... 신뢰가 바탕이 되었을 때 가능하겠죠? 일정은 자기가 잡아 놓고 일정도 못맞추고 계속 delay가 발생하는데 정작 열심히 하지도 않는 경우라면 위의 방법은 소용이 없지요.
신뢰의 문제 크죠.
신뢰의 문제 크죠. 가장 좋은 방법은 사람을 뽑을 때 신뢰할 수 있는 사람을 뽑고 그 이후에는 그냥 믿는 겁니다. 그렇게 되면 꼭 필요한 기능 우선순위는 마케팅 등 직접 사용자의 의견을 들을 수 있는 '믿을 수 있는' 사람들에게 정하라고 하고, 그 우선순위에 따라 일할 수 있습니다. 또, 개발자가 항상 열심히 최선을 다한다고 믿기에, 기능에 따른 릴리즈를 피하고 미리 정해진 기간에 따른 릴리즈를 할 수 있습니다. 즉, xxx 기능을 6개월 후에 릴리즈 될 1.1에 넣는 것이 아니라, 매 6개월마다 제품 릴리즈 하고 다음 릴리즈에는 그때까지 끝마친 모든 기능이 포함시킬 수 있습니다. 결국 중요한 기능은 최단시간에 우선적으로 릴리즈 되죠.
글쎄요. 신뢰가
글쎄요. 신뢰가 바탕이 되어야 하는 것은 맞지만 어떤 다른 대안에 비해서 신뢰가 더 필요한가? 하고 물으면 그 대답은 No인 것 같습니다. "위에서" 일정을 잡는 것이야말로 더 커다란 신뢰를 필요로 하는 것 아닐까요? 신뢰는 항상 필요한 것이지만 작업하는 당사자가 일정을 잡게 하는 것이 가장 최소의 신뢰를 필요로 하는 방법일 겁니다.
네 맞습니다. 이러한
네 맞습니다. 이러한 방법들을 일괄적으로 모든 팀원들에게 적용하기는 무리가 있습니다. 때문에 일정산출 능력이 부족하다고 판단되는 팀원 (아직 신뢰가 쌓이지 않은..) 에 대하여는 또 다른 방법을 사용하고 있습니다. 하지만 결국은 직접 일정을 산출할 능력을 기를수 있도록 하는것이 목표가 됩니다.
그리고 지금 생각해 보니 이러한 방법을 사용할 수 있었던 이유가 말씀하신대로 일정기간 이상 같이 작업해보면서 신뢰가 어느정도 쌓인것이 주요했던거 같네요
안타까운것은 이러한 방법을 1년을 놓고 보면 약 30 ~ 40% 정도의 경우에 한해서 사용되고 그 외에는 외부 일정의 압박으로 잘 지켜지지 않는것이지요... :(
High Risk & High Return ~
High Risk & High Return ~
개개인의 창조적인
개개인의 창조적인 능력을 발휘할 만한 필요 충분한 조건. 기업 윤리에 어긋나지 않는 정당한 근무조건.
이런 것들도 지켜지지 않는 일정은 무의미하다고 봅니다.
온갖 참된 삶은 만남이다 --Martin Buber
저도 마지막 방법.
마지막 방법은 정말 좋은 방법일수도 아닐 수도 있겠네요.
제가 볼때 개발직은 다음과 같습니다.
1. 개발자도 단지 직업중에 하나다. 정시 출퇴근. 안정된 월급날과 직장. 그 이상 그 이하도 아니다.
2. 개발하는 것이 정말 좋다. 나도 정말 특별한 것을 만들어 보고 싶다.
3. 정말 멋진 제품(서비스)를 개발하여 대박한 내보자! 아니면 로또.
1번.
전체 개발자중 50% 이상은 1번에 속한 것 같습니다. 대학도 컴퓨터학과 나왔고, 배운 것이 도둑질이니 개발자로 있다.
오픈소스? 프레임웍? 패러다임? 현재 필요없는데 굳이 배울 필요까지... 관심밖~ 그보다 오늘의 증시나...
2, 3번.
나도 정말 재미있고 멋진 개발을 해보고 싶다. 그러나, 현실은 날코딩, copy&paste, 그나물에 그국밥!
하교 싶은 일을 찾아서 직장을 옮겨볼까! 대학원을 가볼까?. 아~ 이건 아닌데...
----------------------------------------------------------------------------
CODE CRAFT 에서 말하듯 2, 3번 원숭이는 극소수입니다. ^^;
팀원을 전부 2, 3번 원숭이로 충원하지 않는 이상은 당근과 채찍 그리고, 여흥(?)이 필요하겠죠.
우리나라 IT분들의 동기부여는.....
가족인거 같습니다. 당장 유치원, 학교 들어 가는 자녀를 가진분은 암만...더러운 꼴을 격더라도...
가족을 생각해서...꾹 참고 열심히 일하시죠...아님...우리나라에서 집없고 차 없으면...할말 없내요 ㅠ_ㅠ 아 슬픈현실이여
============================
Stay Hungry, Stay Foolish
============================
Stay Hungry, Stay Foolish
IT만 그런게 아니라
전체직장인의 90%정도가 그렇습니다.
근데, 저렇게 책의
근데, 저렇게 책의 본문을 인용하는건 저작권에 위배되진 않나요?
출처를 밝혔으니
출처를 밝혔으니 당연히 위반이 아니지요. 그럼 직접 인용을 하는 모든 학술 논문과 교과서 등이 모두 기존 저술에 대한 저작권 위반을 하고 있게요?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
글쎄요...
학술 논문과 교과서는 저작권법 25조와 28조에 따라 기존 저작물을 이용하는 것입니다.
출처를 명시한다고 해서 누구나 언제든지 직접인용을 할 수 있는 것은 아닙니다.
그런데 `저작권법 제28조'를 어떻게 해석할지가 참으로 모호하기 때문에
공정이용이나 저작권침해냐를 일반인들이 판단하기가 거의 불가능합니다.
한편, `공정이용'을 더 폭넓게 인정하도록 저작권법 개정안이 나왔는데,
(http://www.dt.co.kr/contents.html?article_no=2009070302010251699002
http://likms.assembly.go.kr/bill/jsp/BillDetail.jsp?bill_id=PRC_A0W9L0Y4S0J2V1Q6Z4P6E1L7H8L7P9)
2007년에는 공정이용법안이 통과하지 못했는데, 이번에는 통과가 됐으면 좋겠네요.
--------------------Signature--------------------
Light a candle before cursing the darkness.
Re:
출처 명시는 Academic Integrity와 Plagiarism과 관련된 문제이고 지적재산권 침해는 다른 스토리입니다.
미국의 경우 Fair Use Domain에 속하려면 다음의 4가지 기준을 근거로 판단합니다.
1. the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
2. the nature of the copyrighted work;
3. the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
4. the effect of the use upon the potential market for or value of the copyrighted work.
위 4가지 기준 중에서 보다 많이 충족할 수록 Fair Use일 확률이 높지만 그렇다고 100%는 아닙니다. 그리고 이 중에서 potential market에 대한 영향을 가장 중요하게 평가한다고 들었습니다. 암튼 위 기준으로 보면 이번 인용은 1) 비상업적인 목적이고 2) 인용된 부분이 매우 적고 3) 본 인용으로 인한 인용된 작품의 잠재적인 재정적인/물질적인 피해는 거의 없을거라고 예상할 수 있거나 혹은 긍정적인 맥락 안에서 인용했다는 것을 고려하면 오히려 작품에 대한 홍보 효과가 존재할 수도 있다고 볼수 있기때문에 Fair Use라고 봐야한다고 생각합니다.
한국의 경우는 잘 모르겠는데 아마도 위의 분이 언급한 한국의 공정 이용은 미국의 Fair Use에 상응하는 개념 같아 보이네요.
관리자가 저정도
관리자가 저정도 생각하고 행동한다면 개발자들이 별로 불만이 없겠습니다.
저반대의 관리자를보면...
1. 일정을 반으로 당겨 개발하라고 닥달한다.
(설사 주말야간근무로 그 기간내에 개발했다한들 휴가는거녕 또다른업무를 주거나
일이 없더라도 멍청하게 자리 지키고있게하거나. 심하면 내 보낸다.)
2. 개발의 질이나 효율에는 무관심하다. 오직 관심은 얼마나 야근을 하느냐이다.
(일이 일정대로 진행되고있는 상황이라도.. 야근에 깊은 관심이 있다)
3. 이개발자가 얼마나 많은일을 할 수 있는 능력이있고 얼마나 열심히 하고를 떠나
오직 최저단가를 지불하고 싶어한다.
(특히 하도급일경우.. 재하도급 내려가든말든 전혀 무관심하다)
아마 우리나라 대부분 개발에서 나타나는현상...
제 생각에는...
스케쥴을 악용하는 개발자는 보기 힘든것 같습니다.
관리자가 해야 하는 일은...
1. 전체 일정의 변화가 ( 고무줄 일정) 가능한 없어야 할 것 같구요.
2. 전체 일정중 개발자가 사용하는 세부일정은 매달 Check 해서 지킬 수 있는 일정, 필요한 일정으로 재 조정 및 Item 추가/수정/삭제 를 하도록 하여 개발자 중심의 일정이 되어야 할 것 같습니다. ( 전체 일정내에서 소규모 개발일정은 자유로운게 좋은것 같습니다. )
공염불인 것
공염불인 것 같습니다.
세가지 방법을 위해 두가지 전제조건이 필요하군요.
잘난 개발자.
할 줄 몰라서 허둥대는 관리자.
...
동기부여 그렇게 어렵지 않다고 생각함..
이젠 뭐 일정산출할때 공휴일도 못쉬게 산출해버리고,
저녁에 좀 일찍 퇴근할라면 눈치봐야 되고,
현실은 그러해도 사실 별거없다고 생각함.
야근금지,공휴일 반드시 쉴것. 그리고 잘한것에 대해서는 칭찬해주는것 만한게 없음.
관리자한테 월급을
관리자한테 월급을 평소의 2배로 준 다음 팀원들 야근 수당을
관리자 월급에서 까도록 하면 괜찮은 일정이 나오지 않을까 싶습니다.. -.-
저도 비슷한 생각입니다..
일정 잡는것은 저는 잘 모르겠습니다..
개발자들은 당연히 한없이 늦춰잡으려 할거고 관리자는 후려치려고만 할텐데..
여러가지 언급된 공식같은것이 있다고 하더라도 개발자가 거기에 동의할지가 일단 의문이지만, 대기업이 아닌 이상 결국은 다른 일때문에 인터럽트가 발생했을때의 문제때문에 깔끔하게 정리가 잘 안되거든요. "정말 이거 말고 딴 잡일은 하나도 안해도 되는거죠?" 하고 수십차례 확답을 받아도 결국은 "할사람이 없어서 니가 이것도 같이좀 해줘야겠다 ㅠ.ㅠ" 이런게 나와버리는거고 프로젝트의 데드라인은 결코 이런걸 감안해주지 않지요. 특히 갑을관계라도 끼게 되면..
여튼 일정문제는 그래서 잘 모르겠고..
동기부여라면 어쨌든 합의한 시간에 일을 끝냈을때 무조건 보장되는
꿀맛같은 휴가나 금전적인 보상이 장땡이죠 ㅎㅎ
("재미난 기능"이 "보상?" 허걱... 일 잘하니까 일을 또 맡기는 게 보상이 될수있다니..)
다만 휴가든 금전보상이든 둘다 오너들이 싫어한다는게 문제라면 문제겠네요
이렇게 되면 결국 제자리인가요 ㅎ
--
This is for you new people. I have just one rule :
Everyone fights, no one quits. If you don't do your job, I'll shoot you myself. Do you get me?
--
일정 ㅠ.ㅠ;
일정만 빵꾸만 내는 저는 참보기 부끄러운 글이네요... ㅠ.ㅠ;
----------------------------------------
www.zzizily.com 밥은 먹고 다니냥?
----------------------------------------
밥은 먹고 다니냥?
deuxksy@gmail.com
www.zzizily.com
제가 알고있는 agile프로젝트에서 사용하는 방법과 같은것 같아요
동기부여라는 측면보다는
프로젝트에서의 기간산정와 중간정검을 어떻게 할것인가?
이런 내용의 프로젝트 관리기법이라고 제목을 달아도 될 것같은데요
다른 방법도 있습니다.
1. 프로젝트의 목적과 배경을 정확히 이해시켜서 팀워들의 공감대를 형성한다.
2. 일정은 팀원들의 협의에 의해서 결정한다.(절대 무리한 일정을 푸쉬하지 않는다. 밤새고 코딩하면 품질만 떨어질 뿐이다.)
3. 시험 시나리오를 정확히 세운다.(완성도 떨어지는 일은 나올 수가 없다.)
4. 성과에 대한 '당근'을 준비한다.
댓글 달기