개발팀을 어떻게 꾸려나가야 할까요?
이곳에 다녀가시는 분들에게 조언을 구할 것이 있어서 이렇게 글을 남깁니다.
프로그래밍 Q&A에 올렸다가 게시판 성격에 맏지 않는것 같아서 자유게시판으로 옮깁니다.
저는 소프트웨어 개발팀에서 일하고 있는 개발자입니다. 이곳에는 대학을 졸업하고 신입으로 들어와서 4년 정도 되었습니다. 회사는 스토리지 SI업체입니다. 한창 성장하던 와중에 중소 SI업체로서의 한계를 인식하고 스토리지 소프트웨어 개발을 시작한지 5년 정도 되었습니다. 제가 입사해서 약 2년 반에 걸쳐 개발을 해서 첫 버전이 출시가 되었고, 현재까지 기능 추가, 안정화 작업을 지속한 상태입니다.
그간 개발팀은 인원의 부침이 있긴 했지만 평균 3~4명 정도가 개발에 참여했었고, 제가 다른 부서와 상의를 해서 스펙을 정하고, 전체적인 설계를 하고, 코어부분에 대한 개발을 담당했었습니다. 그간은 딱히 개발 프로세스라는 것이 정해져 있지 않았고, 개인의 역량에 의존해서 개발을 진행했었습니다. 그러다보니 코드의 오너쉽이 특정 개인 - 저를 포함한 2인 - 에게 집중되어있는 상태입니다. 또한 제품 개발 이외의 지원 - 기술지원, 영업지원 등 - 체계가 잡혀있지 않다보니 사이트에 대한 기술지원도 모두 개발팀에서 했었습니다.
그러다보니 차기 버전 출시 계획도 계속 연기되고, 과중한 업무에 지쳐있기도 하고 개인적으로도 좀 정체되어있기도 하고 그래서 퇴사를 결심하고 마지막으로 경영진 - 경영진이라고 해봐야 대표이사입니다 - 과 담판을 지었습니다. 그래서 얻어낸 것이 시간과 투자입니다.
원래 올해 말로 차기버전 출시가 계획되어있었으나(이미 물리적으로 불가능해진 상태입니다) 이것을 내년 말로 미루고, 개발팀에서 하고 있는 기술지원업무를 다음달까지 기술부로 모두 이관하기로 하고 현재 진행하고 있습니다. 이렇게해서 1년 반이라는 시간을 벌었습니다.
그리고 제품 출시 이후에 시장에서 자사 제품을 가지고 영업을 해본 결과 제품만 완성도있게 나온다면 충분히 가능하다라는 판단을 회사에서 내렸습니다. 그래서 개발팀에서 필요한 만큼 투자와 대우를 하겠다는 약속을 얻어냈습니다.
현재 차기 버전의 요구사항들은 모두 나와있는 상태이고, 전체적인 설계는 미약하나마 제가 진행하다가 중단된 상태 - 기존에 나와있는 어떤 틀에 따라 진행한 것은 아닙니다 - 입니다. 현재 버전을 설치해서 사용하고 있는 사이트가 20여곳이 있고, 이중 일부는 차기 버전이 나오면 필드 테스트를 진행할 수 있는 사이트입니다. 현재 버전은 모두 C로 개발되어 있고, 플랫폼은 AIX, SOLARIS, HP, LINUX, UNIXWARE, WINDOWS 입니다. 앞으로 더 추가해야합니다. 인력구성은 현재 제가 개발팀장을 맡게 될 것이고, 그간 같이 개발을 해왔던 사람 1명과 합류한지 얼마 되지 않은 사람 1명이 있는 상태입니다.
그간 개발과정에서 부족했던 것을 바탕으로 앞으로 어떻게 해야할지 생각해보니 앞으로의 개발과정에서 제일 중요한 것이 개발 프로세스를 확립하는 것이라는 생각을 하고 있습니다. 그래서 이렇게 저렇게 자료를 찾아보다가 TDD(Test Driven Development)라는 것을 보게되었고, 관련해서 Extreme Programming이라는 것을 보게되었고, 그것을 적용하기로 결정하고 관련자료를 찾아보고 책을 읽고 있는 상태입니다. 앞으로 개발자들을 구해야되고, Extreme Programming의 내용과 기존의 개발 프로세스 중에서 적용할 것들을 찾아서 정리하고 앞으로의 개발과정에 적용하는 일을 해야될 것 같습니다.
현재 앞으로의 개발과정을 이끌어갈 모든 권한과 책임은 저에게 주어져있는 상태입니다. 개인적으로 이것이 부담이 된다거나 큰 스트레스로 다가오지는 않습니다. 원체 압박감과 스트레스를 잘 못느끼는 성격이기도 하거니와 개인적으로 아주 좋은 기회라고 생각하기 때문입니다. 하면되지 못할거 뭐있어, 경험은 실패의 기록이라는 것이 평소 일할 때의 생각힙니다.
여기까지가 현재의 상황과 생각하고 있는 것들입니다. 이곳에는 어디서부터 어떻게 시작해야될지 막막해서 조언을 구하고자 글을 올리게 되었습니다. 관련 자료들과 내용들을 탐색하면서 대충의 감은 오긴 하는데 행동으로 옮기자니 어디서부터 어떻게 시작해야될지 막막한 상태입니다. 이곳에 다녀가시는 분들의 고언을 기다립니다.
업무 분장을 하였으면 싶습니다.
글을 읽으면서 파악이 되는 문제점은 대략 다음일 듯 합니다.
- 핵심 개발자 (o)
- 코드의 오너쉽 집중
- 기술지원체계 미비
- 차기 버전 출시 지연
- 과중한 업무 (o)
- 한정된 시간 (1년 반)
- 개발 프로세스 필요
그리고, 현재 상태에서 회사로부터 기대할 수 있는 것은 "지원 약속" 한 가지인 듯하고, 이것은 짐작컨대 "차기 버전 출시 계획"과 밀접히 동전의 앞 뒷면이 될 것으로 생각합니다.
문제점에서, 가장 먼저 눈에 띄는 것은 글을 쓰신 분이 "핵심 개발자"라는 것이고 이미 "과중한 업무"에 지쳐있다는 것입니다. "개발 팀장"의 자리를 맡게 되는 것에 고무가 되어서 "과중한 업무"를 더 늘릴 수 있다는 개연성이 있으므로 주어진 "1년 반"의 시간을 업무를 분장하는 방향으로 쓰시라고 이야기 드리고 싶습니다. 문제점의 중요도와 앞으로 "과중한 업무"를 분담할 사람을 늘리는 것, 그리고 "차기 버전 출시"에 필요한 안정적인 시간을 확보하는 것 그리고 개발팀의 외연을 다지는 순으로 6개월 씩 나누어 보면,
처음 6 개월 - 코드의 오너쉽/개발 프로젝스 정립
중간 6 개월 - 차기 버전 출시 계획
남은 6 개월 - 지술지원 체계 확립
식으로 할 수 있을 듯 합니다.
때로는 새로운 자리("팀장")가 기회가 될 수도 있겠지만 위에 나열된 문제에서는 그 자리가 부수적으로 오히려 업무를 늘릴 수 있고 "핵심 개발자"와 그로 인해 회사에서 신뢰하고 있는 것에 (즉, 차기 버전 출시에 없어서는 안 될 사람이라고 판단하고 있는 것) 악영향이 될 수도 있으니 적절히 업무 분담을 하고 필요한 것을 챙기시는 편이 좋겠습니다.
각각의 사항에 윤곽이 아닌 실제적인 것은, 필요하다면, 다른 글에 첨언하겠습니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Dapper user / Ubuntu KoreanTeam
----
I paint objects as I think them, not as I see them.
atie's minipage
System
저는 대학 졸업하고 이제 2년차된 개발자입니다. 운이 좋아 대기업에 속해 있어 그런지 기술력 있는 해외 업체와 일할 기회가
여럿 있는데 (필립스 S/W, 브로드컴등) 그쪽 개발자들 일하는 것 보면 System이 정말 잘되있더군요.
프로젝트도 짜임새 있게, 일정이 지켜지며 일을 하고, 금요일 퇴근해서 주말은 절대 출근 안합니다.
모두 시스템이 갖추어져 있고, 일정에 맞추어 차근 차근 개발하는 그들의 풍토 덕분이라 생각됩니다.
명분이나마 제가 다니는 회사는 그들의 갑 업체인데, 일하는 거 보면 항상 시간에 쫓겨서 야근하고, 주말 출근하고,
일정에 쫓겨서 땜빵 코드 넣고.. 가끔은 답답할때도 많습니다.
우리 기업도 시스템이 잘 갖추어지고, 일정에 맞게 차근 차근 개발하는 풍토가 생겨야 할텐데요.
전자제품 조립하는 마인드로 S/W 개발 하려니 (밤새 공장 돌려 무조건 조립만 된다식의 마인드)
힘없는 개발자만 몸이 축날 수 밖에요.
heavyman 님은 좋은 System, 좋은 팀장이 되주세요.
끝으로 잡설만 하고 도움이 안되 죄송합니다.
시간 관리, 업무 분담 등등...
제 생각은 그렇습니다... 우선 분야별로 어느정도는 업무의 분담이 필요합니다. 그러나 그 전에 우선 개발자들의 멤버쉽이 ... 흐흠.. 있어야 겠죠 잘 되어 있어야 합니다. 그게 되고 나면 글세 뭐 크게 무리 없이 진행 될 수도 있습니다. 그리고 시간을 엄수할 수 있도록 쳬계적인 시간 관리 계념이 잡혀야 할 듯 싶군요. 그리고 항상 긴장하는 분위기 보다는 개발팀 전체가 유기적으로 움직일 수 잇도록 어느정도는 긴장이 풀리고 상호 교류가 활발할 수 있는 체제가 가추어 져야 한다고 봅니다. 뭐 간단히 정리 하면 그렇다는 거고 사실 개발팀 구성 그런건 잘 모르겠네요...
그리고 개발 프로세스라 하셨는데요 글세요 흐흐흠... 어떤 방식이 좋을까요... 잘 모르겠네요.. 구체적으로 어떤 프로세스를 만다는 것이 좋을런지 후흠... 별로 도움 안 되는 소리만 떠들어서 죄송합니다. 뭐 그래도... 과중한 업문에 시달린 사람들이라면 생기 불어 넣어 주는게 가장 중요할 겁니다. 몸도 몸이지만 정신적인 생기가 들어가야 모든 일을 하는데에 큰 도움이 되고 사람이 활성화 되는 거니까요 으으음.
----
일어나라! 싸워라! 그리고 이겨라!
다만!!! 의미 있는 것에 그 힘을!!!
그 능력과 노력을!!!
사람천사
답변은 되지 않겠습니다만..
생산적인 고민을 하시는 모습이 보기 좋습니다.
매번 문제를 지적하고 성토하는 글은 많이 봅니다만,
heavyman 님처럼 해결 방법을 고민 하시는 분을 볼 수 있어 좋습니다.
쉬운 일은 아니겠지만 힘내시고 꼭 이뤄내십시요.
문제를 인식하고 해결 하려 한다는 건 반은 이미 이루셨다고 생각 됩니다.
꼭 이뤄내시리라 믿습니다.
UP, XP 둘 다
UP, XP 둘 다 공부해보시고 해보고 싶은걸 부분적으로 팀에 적용해보는게 좋을것 같습니다.
이런 일을 추진할땐 이론에 얽매인 완벽주의자가 되는것을 조심하셔야 될 것 같고요.
개발팀과 일정 자체가 상사나 고객에게 블랙박스로 보이지 않도록 눈에 보이는 일정관리와
결과물을 주기적으로 내놓아야 될것같습니다.
저도 팀장이지만 과정과 결과를 놓고 참 고민많이 합니다..
전 과정을 중요시 하지만 결과를 얻기 위해선 현실적 조건이 불충분합니다.
부족한게 많은 저이지만 그나마 팀원들이 절 싫어하진 않는것 같은데
아마 칼퇴근 시키고 주5일을 철저히 지켜줘서 그렇지 않나 싶네요. -_-
애기하다가도 퇴근 시간 5분전이면 말끊고 다음날 합니다.
전 사무실에 혼자 남아서 한두시간 더 하다가 퇴근합니다. 외롭지요. 휴... -_-;
개발팀장...
개발 팀장.. 그거 어려운 건데 맡으셨군요.
저도 부실하지만 한국에 있을 때 중소기업에서 팀장을 맡아서 몇년 고생한 생각이 나네요.
도움이 될지는 모르겠지만, 몇자 적어봅니다.
프로세스를 공부해서 적용하는 것도 중요하지만 무엇보다 중요한 것은 팀웍입니다.
팀원들의 체계적인 업무 분장과 스케줄 관리가 관건이죠.
개발자들은 문서 작성하는걸 젤 싫어하지만, 관리자는 그게 생명입니다.
혼자, 아님 둘이 전담하다시피 하던 일을 여럿이 나누어서 하는건 쉬운게 아닙니다.
무엇보다 각 개발자 혹은 단위팀 별로 적절한 시기에 기일이 명시된 숙제를 내주시고,
계속해서 진행상황을 살펴주시고, 문제점을 파악해주세요.
누가 무슨 문제를 가지고 있나를 알고 방향을 제시해주는 사람이 좋은 팀장입니다.
회사를 위해서도 팀원을 위해서도요.
아마 개발하는 일보다 더 머리가 복잡하고 시간이 많이 소요될겁니다.
하지만, 이렇게 하지 않으면 팀을 꾸려갈 수 없습니다.
팀장은 왠만하면 개발에 참여하는 것보단 딴사람이 개발할 수 있게 만들어주는게 중요합니다.
그 일만으로도 시간이 모자를거예요.
그리고, 공부할게 있으면 같이 공부하세요.
모두가 프로세스를 이해해야 적용이 훨 빠르고 효율적입니다.
적다보니 정작 질문하신 개발 프로세스에 관해선 별로 대답할게 없네요.
무슨 방법론을 택하시든간에 업무에 적용하려면 100% 그대로는 안될거예요.
너무 딱 들어맞게 한다고 생각하지 마시고 좀 여유를 가지세요.
욕심 많이 부려서 이것저것 다 적용하려고 하지 마시고,
일단 하나씩 공부해가면서 하시면 조금씩 효과를 보실 수 있으실거예요.
참, 혹시 문서를 작성할 일이 있으시면(개발문서, 스터디자료) 왠만하면 포맷을 만들어 놓으세요.
약간의 귀찮음이 나중에 무지 편함을 가져옵니다.
vio:
짧은 생각입니다만,
저도 단 2명인 전산팀을 이끌고 있고 ^^...
개발관련한 팀도 이끌어 왔었습니다.
기업내 제품과 관련된 부서들이 대부분 고민은 제품의 기획-조사-개발-품질-지원에 대한 고민으로 들어난다고 봅니다. 그 경로를 잘 다져논 기업이 이익을 더 얻는다고 봅니다.
제품이 출시되어 소비자에게 전달어 사용되어 지는 경과는 대단히 복잡하고 많은 일들이 일어난다고 봅니다. 단순히 좋은 결과물만 잘 만들어 내면 OK는 아니란거죠.
heavyman님은 고민이, 이런 일련의 과정중에 개발에 대한 부분만을 고민하시나 봅니다. 그렇지만 관련된 앞.뒤 단계도 살펴 주시는게 좋지 않을까 합니다. 그런점에서, 개발 잘하기위해 TDD, XP와 같은 개발방법 보단 제품-개발-제조란 대단히 총체적인 과정을 살펴봐야 한다고 생각합니다. 조사-기획-개발-품질-지원이 맞물려야 회사의 이익에 충실한 제품이 되지 않을까요?
(저는 TDD, XP등은 개발/제작의 패러다임이라고 이해하고 있습니다.)
회사 전반의 업무프로세스 정립과 그 이후에 개발팀내의 개발 프로세스를 순차적으로 고민해야 하지 않을까합니다.
예를들어 유지보수를 기술팀으로 이관하시듯 업무 한계 정의, 기획/영업과의 통로, 품질의 정립, 기술지원의 정립을 업무적으로 한계를 그어 놓으신 다음에 개발팀내의 고민을 SW개발 프로세스 및 방법론을 바탕으로 개발팀 업무를 고민하는건 어떨까 합니다.
두서없는 글이었습니다.
--
Go For It, Go For Mad.
http://gtko.springnote.com
본받고 생각할 내용이...
본받고 생각할 만한 내용이 많은거 같습니다. 관리자의 길이란 멀고도 험한 거죠 뭐...
중요한 것은 팀원들이 즐겁게, 그리고 자신의 실력을 최대한 펼칠 수 있는 마춤형 운영이 때로 필요하다는 겁니다. 뭐 제 생각이고, 그렇게 마춰 가는 분들도 많습니다. 글세요... 경영팀의 경영 Know-How를 어디서든 알아다가 여기 적어 볼 수도 있겠죠. 가까이에 경영을 하는 사람이 많으니... 그것도 아주 잘 해 나가고 있는... 붙잡고 물어 보는 것도 좋겠죠 이런 쪽이라면. 하지만 소프트웨어 개발 프로세스에 대해선 저도 드릴 말씀이 없습니다.
다만, 이 스크롤을 읽으면서... 저는 참 생각 할 것이 많다는 느낌을 받게 됩니다 흐흠... 좋은 주제입니다... 중요한 주제이고요. 질문 하시고 의견 구하신 분께는 더없이 중요한 주제가 되겟죠 으음... 앞으로 다른 분들께도 많은 도움이 될 거 같습니다. 이 스크롤이 말이죠.
----
일어나라! 싸워라! 그리고 이겨라!
다만!!! 의미 있는 것에 그 힘을!!!
그 능력과 노력을!!!
사람천사
짧은 주기로 릴리즈 하십시오.
여러 제품의 개발을 맡았던 입장에서 경험을 말씀드리자면 당연히 프로세스 정립 등등 중요하지만 고객과 회사, 개발자 모두가 만족할 수 있는 방법은 짧은 주기의 제품 릴리즈입니다.
TDD나 XP 참고하시면 나오는 얘기지만 실제 개발팀에서는 간과되는 경향이 있어서 노파심에 드리는 말씀입니다.
1년 6개월의 기간이 짧다고 느낄수도 있지만, 고객과 경영 입장에서는 너무 긴 시간입니다. 오랜 기간을 기다리고 기다린 제품이 1년 6개월 전의 사양을 가지고 있다면 바로 개발팀 해체됩니다.
개발팀의 사기도 올라가고 기분좋게 진행할 수 있는 방법은 유지/보수 과정이 정립된 짧은 주기의 개발입니다. 출시를 목표로 하지는 않더라도 2개월 정도에 한 번씩 릴리즈 할 수 있도록 마일스톤을 조정해 보십시오. 전폭적인 지원이 가능하다면 새로운 릴리즈를 개발하는 팀과 유지/보수를 위한 2개의 팀을 운영해 보십시오.
처음 4개월은 팀원 교육과 프로세스 정립에 맞춰 2회 정도의 이터레이션을 실시하고 팀원들과 프로젝트를 평가해 보면 감이 올겁니다. 그 후 고객에게 릴리즈를 목표로 하는 프로젝트를 수행하면 되겠지요.
최소한 6개월에 한 번 정도는 릴리즈해 줘야 고객이 외면하지 않을겁니다.
===========================================================================
Shocky Han
Seoul, Korea.
===========================================================================
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
얼마전에 Dr. Dobb's Journal에 실린 글...
얼마전 Dr. Dobb's Journal에 실린 Quick-kill Project Management라는 글이 실렸었는데요, 좋다 안좋다 의견들이 분분했는데, 제 경험에 비추어 보니 괜찮은 측면이 많아서 번역을 해두었습니다. 한번 읽어보시면 적용할 부분을 찾기 어렵지 않을 겁니다.
http://youlsa.com/2006/07/07/79/
=-=-=-=-=-=-=-=-=
http://youlsa.com
이 책을 보세요
스티브 맥코넬이 지은 '소프트웨어생존전략'을 바이블로 삼으세요 ;)
http://book.naver.com/bookdb/book_detail.php?bid=128468
- I love challenge!!
책을 보시는 방법 밖에 없을 듯...
프로젝트 관리에서 머리털 빠지는 경험이 있어서, 관련 자료를 찾아보았는데... 이상하게도 우리나라의 실무에서 일하는 분들은 이런 얘기를 별로 안하는 것 같네요...
우리 개발자/팀장들이 실력이 없어서 그렇다고는 생각을 안하는데, 아마도 피곤에 지쳐서 누군가에게 자신의 노하우를 알려줄 에너지가 없어서 그렇다고 봅니다... 아니면, 그 정도 수준에 있는 분들은 이런 커뮤니티를 이용하지 않는 경향이 있거나요...
두리뭉실 하지만, 현실에서는 책보다 나은 선택은 없어 보이네요... (물론 뛰어난 프로젝트 관리자 밑에 들어가 전수받는게 가장 좋지만... 여건이 안되니...)
1. 소프트웨어 프로젝트 생존전략, 스티브 맥코넬
2. 프로페셔널 소프트웨어 개발, 스티브 맥코넬
*3. Rapid Development, 스티브 맥코넬
4. 피플웨어, 톰 디마르코, 티모시 리스터
*5. 소프트웨어 요구사항, 칼 위거스
*6. 퍼스널 소프트웨어 프로세스 입문, watt s. humphray
7. Code Complete, 스티브 맥코넬
*8. 마음을 움직이는 프로젝트 관리, 스콧 버쿤
9. 조엘 온 소프트웨어, 조엘 스폴스키
등등...
개인적으로 'Rapid Development'와 '마음을 움직이는 프로젝트 관리', '소프트웨어 요구사항'을 추천합니다. 그나마, 가장 현실에 적용하기 쉬운 테크니컬한 방법들을 많이 제시해 놓았습니다.
건투하시길~
PS. 혹시 프로젝트 진행 관련 커뮤니티/사이트, 알고 계신분~ 알려주십시오~
천지간에 일어나는 모든일은 노력한 만큼 이루어진다. - 한당
퇴사를 하시고, 시스템이 되어 있는 기업으로 가서 배우세요.
정답은 없습니다만, 시스템이 되어 있지 않는 곳에서의 노력은 사실 효과적인 결과를 얻기 힘듭니다. 특히, 최근의 S/W는 혼자 만들어서 상용화 할 수 없을 정도로 방대해지는 경향이 있기 때문에 소규모로 제품을 만들고, 여러 사이트에서 문제 없게 운영되는 경우는 그리 많지 않습니다. 간단한 S/W는 RAD 툴이, 복잡한 S/W는 다수의 개발자들이 투입되어 체계적으로 개발되지 않으면 절대적인 시간 부족으로 인하여 right time에 제품이 출시되는 것이 불가능합니다.
귀사의 규모로 보았을 경우 아무리 많아야 10명 내외의 개발팀이 최대고, 이를 꾸미는 것만 6개월 이상의 시간이 소요되며, 실제 제품이 만들어질 때까지는 1년 이상의 시간이 소요되는데, 회사 입장에서는 적어도 5억원 정도의 투자 (1인 5천만원/년 * 10인)를 감수하고 제품 개발을 준비할 정도의 여력이 있어야 합니다. 그렇게 만들어진 제품이 20억 이상의 가치가 있다고 판단되면 과감한 투자 (ROI, return of investment)도 나쁘지 않으나 과연 지금 하고 있는 일이 그정도의 가치가 있는지 의문입니다.
국내에서 S/W로 20억 정도의 가치라고 한다면 규모나 경비를 최소로 줄여서 10억 정도 가치라고 한다면 최소 10개 정도의 사이트에 적용이 되어야 하는 것으로 판단되는데 이를 관리하는 것만으로도 쉬운 비지니스가 아닐 것으로 판단됩니다. 결국, 본인이 아무리 열심히 하고 매달려도 최종적인 비지니스는 별 도움이 안된다는 것입니다. 물론, 그전처럼 혼자 일당백의 정신으로 싸울 수도 있겠지만, 마찬가지 결과로 힘에 붙이는 결과가 초래될 것으로 예상합니다.
특히, S/W는 시스템에 의해서 만들어지는 것이 바람직하지만, 워낙 "사람"이라는 변수가 강하기 때문에 아무리 인원을 투입해도 그 결과가 좋은 방향으로 흐른다고 장담할 수 없다는데 또 다른 문제가 있습니다. 소프트웨어를 잘 짜는 것과 사람을 다루는 것은 별개의 문제이지만, 결국 공통된 결과를 도달시키는데 비슷한 역할을 합니다. 아무리 좋은 인재도 시스템이 받쳐주지 않으면 결과가 나지 않고, 시스템이 아무리 좋아도 질적으로 문제가 있는 인원으로 구성되면 그 결과는 마찬가지 어려운 문제가 발생할 것이라는 예상입니다.
비관적인 예상이기는 하지만, 왜 반드시 지금 회사인가에 대해서는 정말 심각하게 고민할 필요가 있다고 생각합니다. 만약, 미련이 있으시다면, 최악의 결과를 가정하시고 업무를 진행해야 나중에 큰 후회는 하지 않을 것이라고 생각합니다.
그런 상황들까지 가정하고 진행하는 것이지요 ^^
미소님의 말씀대로 개발 인원은 10명 내외를 생각하고 있고, 회사 입장에서는 5억원 이상의 투자가 더 들어가겠죠. 한명의 사람을 고용하는데 필요한 비용은 인건비의 대략 2배 정도가 들어가니까요. 여기에 필요한 추가 장비들까지 하면 대략 10억원 정도의 투자가 더 되어야 할 겁니다. 그간의 경험들을 바탕으로 회사로서는 투자할 가치가 있다는 판단을 하는 것이고, 제가 판단하기에도 제품만 제대로 나와준다면 투자할 가치는 있다고 판단됩니다. 이에 대한 판단도 회사에 남기로 한것의 한 이유이기도 하구요.
또하나의 이유는 "시스템이 되어 있는 기업으로 가서 배우는 것" vs "시행착오를 겪어가며 그 시스템을 만들어 나가는 것" 사이에서 제 개인에게 어떤 것이 더 좋을 것인가라는 것에서 후자의 손을 들어준 것입니다. 전자의 경우가 고생은 덜하겠지만, 제 개인에게 남는 것은 후자가 더 많을 것이라는 판단을 한 것이지요.
프로젝트가 성공(제품을 개발해서 시장에 안정적으로 진입하는 것까지)할 확률이 실패할 확률보다 많이 높다고 생각하고 있기는 하지만, 실패하더라도 저로서는 엄청나게 소중한 경험들이 될 것이라고 생각하고 있습니다.
개발 프로세스를 포함한 시스템이라는 것에 대해 지금 공부하고 있고, 관련 자료들을 탐색하고 있고, 회사에서 개발하려고 하는 소프트웨어에 어떻게 적용할 수 있을지 연구하고 있습니다. 위에 다른 분들도 많은 좋은 자료들을 추천해 주셨지만 다른 참고할 자료들이 더 있으면 추천해주시기 바랍니다.
현재 개발인원 충원은 제 인맥(어떻게 데려오냐가 문제이긴 하지만, 질이 좋은 인력들은 저의 네트워크에 꽤 있습니다)과 헤드헌팅을 통해서 하고 있는데, 놓치고 있는 부분들이 있을까요?
짧은 소견이겠지만...
제가 볼때에도 성공할 가능성이 희박해 보입니다.
그것은 일단 개발인력구성이 너무 빈약합니다. 팀장님과 그동안 개발에 참여했던 한명 (제가 볼때에는 그분도 전적으로 본 프로젝트의 개발만 하신것 같지 않군요. - 다른 잡스런 일도 같이한듯...) 그리고 신규로 채용할 직원한분인것 같습니다.
제가 이 프로젝트를 볼때에는 적어도 팀장님을 제외하고 3-4명정도가 필요할것 같습니다. 3명은 개발자, 1명은 저급 개발 및 기타지원인력이 되어야 하지 않을까요? 팀장님은 전체적인 설계와 진행을 감독하고, 직원들이 못하는 부분과 시스템인터페이스 부분을 맡아야 성공할수 있을것으로 보입니다. 더구나 3명의 개발자는 아주 커뮤니케이션이 잘되어야 할것으로 추정됩니다. 그쪽 상황을 정확히 알수는 없지만, 저도 현재 6명정도의 개발인력을 이끌고 있습니다. 그런데, 이정도 인력을 만드는데도 거의 1년이 소요되었습니다. 1년사이에 4명을 퇴사시키고 2명을 새로 뽑아서, 훈련을 시켰습니다. 그런데도 아직도 조엘이 제안한기준에는 턱도없는 4-5점에 머무르고 있습니다.
조엘을 비롯한 각종 프로젝트 관리기법이 언급되기는 했지만, 그것은 개발자들이 지시하는 대로 잘 따라줄때 내가 할수 있는 일에 지나지 않습니다. 개발자들이 내가 의도하는 생각대로 따라줄려면 적어도 인원변동없이 2개 이상의 프로젝트를 수행해 봐야 되겠더군요. 정말 상당한 시간과 노력이 필요하다는 것이지요.
지금 제가 볼때에는 팀장님이 거의 모든일을 수행하고, 두명의 개발자는 팀장님이 지시하는 내용을 그저 단위모듈별로 만들어 주는 단순 생산작업만 할 위험성이 높습니다. 결국 팀장님이 모든 짐을 지고 헉헉거리다가가 결국 주저앉을것 같습니다.
그나마 제일 나은 방법은 신규개발은 정지하고, 현재까지의 개발된내용을 3개월에서 6개월정도 걸려서 소오스를 모두 정리하고, 설계문서를 완성하고, 개발자들을 훈련시켜서 문서를 기반으로한 개발을 습득하도록 하고 한명정도 더 선발하여, 바탕을 튼튼히 하고 다시 개발을 재개하는것이라고 생각합니다. 즉 주개발은 팀장님을 제외한 개발자들이 자신의 일로서 생각하고 신나게 일하게 만들어 주고, 팀장님은 조금 멀리 떨어져서 넓은 시야로 바라보고, 개발자들이 못하는것을 도와주는 상황을 만들어야 성공할것 같습니다.
그러나 10명정도의 작은 회사라고 하셨으니, 3개월내지 6개월동안 개발을 하지 않고, 과연 그러한 정리업무에 집중할수 있을런지 심히 걱정이 됩니다. 본인이 하고 싶은것과, 할수 있는 것과는 엄연히 다릅니다. 냉철하게 생각하셔서 판단해보시기 바랍니다.
개발방법론은 물질적, 인원적인 지원에 대한 확신이 섰을때 생각하셔야 하지 않을까 생각합니다.
건승을 빕니다.
ChangHyun Bang
winchild@kldp.org
- 겨울아찌 -
winchild@gmail.com
숙련공에서 마스터로
"쉬운 정답 같은 것은 없다. 도구든, 언어든, 운영체제든, 프레임워크든, 방법론이든 상관없이 최고의 해결방안 같은 것도 없다. 오직 특정한 환경 조건의 집합마다 각 집합에 가장 적절한 시스템들이 있을 뿐이다." - 앤드류 헌트, 데이비스 토머스
XX회사의 프로그래머 P모씨, 그는 경력 5년차의 숙련공이다. 볼것, 못볼것 가리지 않고 봤으며, 해보지 않은 노가다가 없다. 이제는 어떤 노가다라도 아무생각없이 뚝딱뚝딱 해치울 수 있는 경지에 올랐다. 그러든 어느날, 수년간 동고동락하면서 노가다를 했던 사수 M모씨가 진급하면서 "안뇽! 나 이젠 개발 안해" 라는 말을 남기고 관리자의 세계로 차원이동해 버렸다. 혼자 남겨진 P모씨, 3년차와 신입 직원을 데리고 개발을 책임져야 하는 상태다.
고민하던 P모씨가 내린 결론은 개발 프로세스를 정립하는 것이다. 그러나 도무지 어디서부터, 무엇을, 어떻게 시작해야하는지 막막하다. 주위엔 천상 노가다꾼들이라 조언을 해줄 사람도 없다. 결국 why? 라는 물음에 답할 수 없다면, 시작도 할 수 없다는 사실을 깨닫는다. 프로젝트에 가장 잘 아는 사람은 P모씨 자신이며, why? 라는 물음에 답할 수 있는 사람도 P모씨 밖에 없다는 것을 안 것이다. 다행이 P모씨는 답을 할 수 있었다. 이는 몇달전에 일어난 악몽같은 사건에서 시작한다.
몇달전, XX회사의 YY제품은 다수의 플랫폼에 포팅을 진행하면서 안정성을 획득하였다. 출시 및 배포한 이후에 6개월 이상 이상없이 작동중이다. 비록 고객의 잦은 요구사항 변경으로 코드가 조금 꼬인점은 있지만, 더이상 고객은 기능에 대해선 불평하지는 않는다. 그러던중, 윗선에서 C8플랫폼에 제품을 포팅하라는 지시가 떨어진다. C8플랫폼은 다른 플랫폼과 유사한 환경이기 때문에 P모씨는 자신있게 작업에 착수한다. 아뿔사, 컴파일 및 링크 과정부터 문제가 발생한다. 컴파일러, 써드파티 라이브러리, 비지니스 로직까지 문제가 발생하지 않는곳이 없다. 일주일간의 노가다로 컴파일에 성공했지만 이젠 실행시에 프로그램이 죽어버린다. 도무지 원인을 알 수가 없다. 어느 시점에서 메모리를 덮어쓰고, 특정시점이 되어서야 죽는 악명높은 버그가 발생한 것이다. 시간은 흘러 한달이 다되어간다, 잦은 밤샘작업으로 몸은 몸대로 축나고, 고객과 윗선의 신뢰도는 낮아졌으며, 팀원의 사기도 극도로 낮아진 상태다. 고민하던 P모씨는 극단의 결단을 내린다. 각 서브 시스템에대한 단위테스트를 실시하여 하부구조의 무결성을 확보한 이후에 비지니스 로직에 대한 단위테스트를 실시하였다.
결국 총 한달이 걸린 악몽같은 디버깅사건에서 단위테스트를 작성하는데 이틀이 걸렸고, 프로그램이 죽는 이유를 알고 나서 버그를 수정하는데 걸린 시간은 30분에 불과하였다. 이후 P모씨는 모듈을 추가/수정할땐 항상 단위 테스트를 수행 하고, 매일 같이 전체 소스코드의 빌드 및 테스트를 수행하여, 시스템의 무결성을 확보 할것을 맹세하였다. 다른 시스템에 포팅을 하더라도 어느부분에 이상이 있는지 즉시 알 수 있을 것이다.
조엘테스트(http://korean.joelonsoftware.com/Articles/TheJoelTest.html)를 해본 P모씨는 자신의 생각이 맞다는 확신을 할 수 있었다.
1. Source Control(소스 컨트롤)을 사용하십니까?
2. 한번에 빌드를 만들어낼 수 있습니까?
3. daily build(일별 빌드)를 만드십니까?
4. 버그 데이타베이스를 가지고 있습니까?
5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
6. up-to-date(최신) 스케줄을 가지고 있습니까?
7. spec(설계서)를 가지고 있습니까?
8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
10. 테스터들을 고용하고 있습니까?
11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?
P모씨의 팀의 점수는 2-3점에 불과하였다. 조엘에 따르면 세계 표준은 2-3점이라니, 웃고 넘기기엔 서글프다는 생각이 든다. 어쨌든 P모씨는 매너리즘을 떨쳐내고, 어느때보다 활기차게 공부를 한다. 그가 선택한 책음 다음과 같다.
1. Code Complete
2. Refactoring
3. GoF Design Pattern
4. Pattern-Oriented Software Architecture
5. 실용주의 프로그래머
6. 실용주의 프로그래머를 위한 단위 테스트
7. 실용주의 프로그래머를 위한 프로젝트 자동화
8. 서브버전을 이용한 실용적인 버전관리
1-4번은 시간을 두고 점진적으로 공부 및 적용해야 할 것들이지만, 5-8번은 숙련공이라면 누구나 해봤을 노가다를 줄여주는 방법들로 가득차 있으며 즉시 적용가능한 것들이 많았다. 그래도 곧바로 시작하기엔 막연한점이 있었으나 리누스와 에릭 레이몬드의 교훈을 떠올린 P모씨, hellow world 프로젝트를 5-8번으로 적용해본다. 이후엔 계산기 프로그램같이 간단한 프로젝트를 몇가지 시뮬레이션 해본 P모씨가 디자인한 개발 시스템은 다음과 같다.
A. 버젼 관리 시스템(SVN)
B. 이슈 트래커(trac)
- 로드맵/마일스톤/릴리즈 관리
- 티켓(이슈)관리 - 기능의 추가,변경,개선 및 버그수정 등등..
- SVN 브라우징
- 위키
C. 개발 플랫폼
- 유닉스: GCC + gmake + CPPUNIT + shell script + perl + vi
- 윈도: MSYS + MingW + gmake + CPPUNIT + shell script + perl + vi
MSYS + VC++ + gmake + CPPUNIT + shell script + perl + vi
D. C++ Framework
- 코딩 스타일
- 플랫폼 추상화 / Eror Handling / UnicodeString / Memeory Management / Filesystem / Stream / Thread / Logging / Date & Time
마지막으로 P모씨는 개발자 K씨의 하루 일과를 시뮬레이션 해본다.
E. 개발자 K씨의 하루일과
- 메일확인, 전날밤 예약작업으로 걸어논 일일빌드 및 단위테스트가 깨졌다면 메일로 로그파일이 날라올것이다.
- 이슈트래커에 접속하여 로드맵/마일스톤/이슈/SVN의 변경사항을 체크한다.
- 자신에게 할당된 이슈를 처리한다. 아마도 이작업들은 기능추가, 기능변경, 버그수정, 단위테스트, 릴리즈 등
여러가지가 있을것이다.
- 단위테스트 프로그램을 작성하고 자동빌드 및 단위테스트를 수행한다.
- 이상이 없다면 SVN에 commit 하고, 이슈 트래커에 보고한다.
여기까지 진행한 P모씨는 개발 프로세스의 실체가 눈에 보일듯하다. 결국 K씨의 하루일과에서 사용된 각 단위작업을 수행하기위해 처리해야할 절차와 규칙을 기술한 매뉴얼, 그리고 그것들을 자동화해줄 스크립트를 작성한것을 개발 프로세스라고 부를 수 있음을 알았다. what과 how에 대한 답인것이다.
F. 개발프로세스 매뉴얼
- 생략
이제 P모씨는 YY제품에 대해서 지속적인 기능추가와 변경으로 소스코드가 꼬인것과, 전체 프로그램의 속도가 떨어진것을 만회하기 위해 리팩토링을 단행하여 차기버젼을 출시할 생각이다. 설계는 명확한편이고, 개발도중 요구사항 변경은 차차기 버젼으로 미루어 줄것을 저쪽세계의 M모씨로부터 확답을 받은 상태다. 로드맵과 마일스톤 이슈를 이미 작성했으며 실제 구현만 하면 되는 상태다. 비록 P모씨가 디자인한 개발프로세스는 초기버젼이라 조악한 상태이지만 몇달전과 비교했을땐 확실히 개선된 상태다. 그리고 이번 프로젝트가 끝나고 나면 더욱 개선될것을 확신하고 있다.
이상 관을보고 눈물을 흘린후, 심기일전하여 숙련공에서 마스터로의 서원을 세우고 용맹정진을 위한 첫걸음을 시작한 P모씨를 인터뷰한 J기자였습니다. 프로그래밍 세계에서 마스터의 실체가 무엇인지는, 비전문가인 J기자는 잘 모르겠습니다. 하지만 마스터들의 도구는 숙련공의 도구와 분명히 틀립니다. 항상 날카롭게 날이 서있으며, 한번 휘둘러 끝을 냅니다. 마스터들은 도구를 예술적으로 사용할 수 있습니다. 비록 도구를 잘 사용한다고 해서 마스터라고 부를 수 있는것은 아니지만, 숙련공이 마스터가 되기위한 첫걸음임에는 분명해 보입니다.
인터뷰
J기자:
원본인 P모씨가 작성한 글이 조잡하기에 이글도 조악해보입니다. 어떻게 생각하십니까?
P모씨:
이거 모자이크+음성변조 되는거죠? 사실 저, 아는거 개뿔도 없습니다. 본문에 나오는 C8플랫폼에 이가갈려 고민하던중 우연히 같은 고민을 하시는 heavyman님의 글을 본거죠.. 답변을 가장해서 고수님들의 조언을 듣고자 하는 낚시 글입니다. ^^
J기자:
한달간의 디버깅 지옥에서 얻은것이 있다면 무엇입니까?
P모씨:
막바지에 이르자 눈에 다래끼가 나더군요. 그 이후로 조금만 무리하면 다래끼가 재발합니다. 이거 산재맞죠?
J기자:
몇가지 책을 추천하셨는데, 그중에 하나를 꼽으라면 어떤것을 꼽겠습니까?
P모씨:
"실용주의 프로그래머"를 번역한 김창준씨는, 우리나라에서 XP의 전도사 격입니다. 그분이 쓰신 "어떻게 공부할까? 프로그래머를 위한 공부론" 이라는 인터넷 문서를 추천합니다. 좀 오래되긴 했지만 유용합니다.
물론 책으로는 "실용주의 프로그래머"를 추천합니다. 프로그래밍 세계에 실용주의를 전파한 경전이며, 전 기꺼이 교도가 되었습니다. "숙련공에서 마스터로" 이 문구는 이책의 부제이기도 합니다.
J기자:
마지막으로 할 말씀은 없으십니까?
P모씨:
사실 기술문서 보다는 리더쉽 관련 교육이 도움이 됬습니다. 제가 쓴글은 개발(구현)에만 치중한 것이 사실입니다. 가장 중요한 것들이 빠진셈이죠. 문제는 그것이 무엇인지 감이 않 잡힌다는 겁니다. 그것을 가르쳐줄 마스터가 주위에 없습니다. 중세유럽의 장인제도는 apprentice, journeyman, master 로 구성됩니다. 그들은 한 작업장(workshop)에서 수업을 했습니다. 이는 프로그램을 개발하는 사무실에서 그대로 재현됩니다. 문제는 대한민국에서 마스터들은 다들 다른 세계로 차원이동 했다는 겁니다. 부실한 제품이 대량생산되는 주요한 원인중 하나라고 봅니다. 과연 그들은 어디에 있는 건가요?
J기자:
별 내용 없네요? 어쨌든 잘 들었습니다. 수고하셨습니다.
제가 사용하는 방법입니다만..
위에서 언급한 내용들은 주로
1. 프로젝트 관리기법(XP,Agile,CMM,...)
2. 코딩방법( Rafactoring, Pattern,... )
에 맞춰져 있는 것 같습니다.
정말 좋은 내용들로 적혀있고 활용도도 높다고 봅니다.
하지만 위 책들에게 빠진 것이 있습니다. 그것은 사람에
대한 이야기들입니다.
물론 예의 것들이 개발자나, 관리자 그리고 현업의
입장을 무시한 방법론을 적은 것은 아닙니다.
각 분야의 사람들에게 보다 낳은 환경을 제공하기
위한 기법들을 충분히 제공하고 있습니다.
제가 부족하다고 하는 것은
관리자의 마인드와 사람을 중심으로 보는 기법입니다.
뭐 이런것들도 기법이 될 수 있느냐라고 볼 수도
이겠습니다만 몇 해 전부터 부각되고 있는 것이
있습니다.
* 코칭기법
이 바로 그것입니다.
사람은 프로젝트를 통해서 일을 완수하는 것에 목적을
두지 않습니다. 프로젝트를 통해서 성장하고 싶어
합니다. 결과물의 완성을 얻는 성취감은 프로젝트가
클 수록 작아집니다. 특히, 일개 개발자면 성취감은
거의 ZERO에 가깝습니다. 구성원은 과정속에서 새로운
기술과 지식을 습득하고 싶어 합니다.
"코칭기법"은 프로젝트 관리가 아닌 사람을 성장시켜주는
기법입니다. 관리자의 역할, 팀원의 역할이 적혀 있습니다.
예의 정해진 규약과 한정된 시간속에서 관리하는 것이 아닌,
좀더 부드러운 방법으로 도와주거나 동료의식 속에서 일할 수
있도록 해 줍니다.
1. 이런 서로를 위하는 마인드 위에서
2. 예의 관리기법이 적용되어야 한다고 봅니다.
전에 3년간 CMM기반으로 프로젝트를 수행한 적이 있습니다.
거기서 가장 인상적 이었던 것은
1. 교육 ( + PL의 코칭 )
2. pair 작업
3. 동료 검토
4. 팀 검토
5. 보상
이었습니다.
코칭기법하시니...
갑자기 겅호라는 책이 떠오릅니다.
다른책으로는 '선택'이라는 책이 떠오르는군요.
'선택'은 팀관리와는 크게 연관은 없지만 선택이 필요한 일에 직면했을때 도움이 될수 있는 책이라 생각합니다.
poklog at http://poksion.cafe24.com/poklog/
poklog at http://poksion.cafe24.com/poklog/
코칭기법 이라....
저역시 소프트웨어 공학에 관심이 많아서 여기저기 정보를 수집하고 있었습니다.
고기를 좋아하는 님처럼, 저역시 사람이 최고 중요한 요소이지 않나 싶습니다.
요즘에는 좋은 툴들이 너무나 많습니다.
프로젝트 자원 및 일정을 관리해주는 프로젝트 매니져 툴,
복잡한 오브젝트 관계를 직관적으로 표현해주는 여러 다이어 그램들...
디버깅을 위한 로깅툴,
프로세스의 병목현상을 확인할수 있는 프로파일링 툴,
모듈간의 디펜던시를 관리해주는 디펜던시 툴,
코드 버젼을 관리해주는 형상관리 툴,
쉽게 배포해 주는 빌드툴
케이스별 테스트를 지원해주는 테스트 툴,
코드 컨벤션까지 일관시켜 포메팅해주는 코드 포메터
그리고 여러가지 스펙에 맞게 적절하게 구현된 코드 제네레이터 들...
프로젝트가 완료된 후에도 성능측정을 지원하는 스트레스 테스트 툴...
자동화된 도큐먼트 제네레이션 툴....
나열하고 보니 상당히 많은 좋은 툴들이 있군요 ....
하지만, 위의 툴들을 다루기 전에, 왜 이런 툴들이 나오게 되었는지,
그리고 어떻게 진행해 나가야 하는지를 숙고하여야 겠지요.....
이 모든 것을 다 알고 있는 어떤 사람이 프로젝트를 성사시키는데는 한계가 있고,
회사를 발전시키는데는 어려움이 있겠죠
여러 사람과 같이 코웍 할 수 있는 기반이 중요 합니다.
그럼 회사의 입장에서,
위의 모든것을 잘 알고 있는 사람을 채용하는냐?
아니면,
위의 모든것을 함께 습득 하느냐?
99% 는 아래를 선택할 수 밖에 없을 것입니다.
그렇다면 결국, 회사에서 필요한 가장 중요한 자원은 사람 입니다.
바람직한 코칭기법은 무엇일가요?
TP 일까요? 동료검토 일까요? 짝 프로그래밍 일까요?
위의 방법들은 고수가 초보에게 일방향으로 전달하는 주입식 방법입니다.
일정 수준을 끌어올리는데 비용이 많이 들어가는 단점이 있습니다.
그럼에도 불구하고 위와 같은 방법을 써야 겠지요?
그렇다면 비용을 가장적게들이는것은
결국 개인에 대한 논리력, 이해력, 설득력을 살펴봐야 하고
it 기본 지식에 대한 해박한 지식이 있는지를 봐야 겠지요...
쓸데없이 길게 썼네요...
요점은 신뢰할수 있는 좋은사람 뽑아서 성공하시라고 말하고 싶네요.
너무 어렵게 시작하지 말기를 바랍니다...
한2년전에 저도 개발팀장을 맏고 개발을 진행했더랬습니다. 물론 그때 제가 경험이
미천하였던지라 전권을 가지지는 못했구.. 그저 중간관리자 성격이 무척 강했죠..
그때를 회상해보면 몸서리쳐지게 힘들었던 기억밖에는 없네요... ^^
아무런 사전준비없이 투입이 되었던거라서... 그때 팀장을 맡고 계시던분이
갑자기 그만두시는 바람에 그렇게 되어 버렸더랬죠..
서론이 길었네요.. 여하튼 저도 똑같이 heavyman 님처럼 처음부터 방법론을 고쳐보려고 무척이나 노력을
하였더랬습니다. 결국엔 실패를 했습니다.
최근에 다시금 팀장역활을 맡게된 지금에 와서 생각해보면 너무 방법론(도구)에 치우쳤던게 아닌가
싶습니다. 방법론들 많이 나와있지요.. 근데 이것들 따라하기 무척이나 어렵더군요... 해야할 것들도 많고
종류도 많고..
여차여차해서 비슷하게 설계를 진행하였는데, 설계에만 자그만치 4개월이 걸리더군요.. 상세설계가 아닌
개념설계에서.... 이것만으로 지쳐버리더군요 ^^
문서화/방법론 좋지요... 나중을 위해 혹은 개발진행을 위해 무척이나 좋은 습관입니다. 하지만 방법에만 너무
치중하다보니 사람을 지나쳐버린 우를 범하고 말았습니다. 프로젝트를 진행하는 것은 팀장만이 아닌
팀원들이 각 요소요소를 책임지고 하나된 생각을 가지고 진행을 해야 하는데..
이부분을 너무 쉽게 생각해버린 우를 범했습니다. 끝임없이 다그치고 모티브를 제공하고 토론해야하는
사람(팀원)과의 관계를 말입니다.
현재도 위와같은 과오를 물론 범하고 있습니다. 하지만, 방법론을 반드시 따라야 한다는 강박관념에서는
조금 벗어나 있습니다. 개발을 하기 위해 방법론이 필요한 것이지 그이상도 이하도 아니라 생각하고 있습니다.
지금은 그저 의사소통, 자세하게는 일을 맏기고 이에 대한 보고, 문서화, 논의등을 개선하려 하고 있습니다.
방법론 역시 이에 대한 세세한 방법이지만, 아무런 사전 경험없이 진행하다 실패한 우를 조금이나마
벗어나고자 충실한 관리자역활을 배우고 있는 상태입니다. 이렇게 하다 막히는게 있으면 방법론 중에서
그 해결책을 찾을 수 도 있는 경험자가 되어 있지 않을까요?
heavyman님, 우선순위를 사람으로 바꿔서 시작해 보는 것은 어떨런지요?
개발자들의 궁극적 비전은 ?
재미있고도 힘든일을 시작하시는군요
안녕하세요 저는 한국에서 2년간 프로그래머를 했던 사람중 한명입니다.
지금은 일본에서 프로젝트의 한 부분을 맏아 진행중인 프로그래머구요.
경력은 얼마 안되지만 그동안 봐왔던 것을 토대로 한말씀 올리고자 합니다.
한국에서의 프로그래머 생활은 재미있던것도 있었지만 힘든일이 더 많았던가 같습니다.
heavyman님도 프로그래머로서 한 팀장 아래서 근무하신 경험이 있어서 더 잘 아시리라고 생각듭
니다.
일단 머리속에서 한가지 밖에 안떠오르죠.
'팀장이 잘하면 정말 잘되는구나'
부담을 드릴려고 이러는건 절대 아님니다.
잘한다는거..팀원과의 관계가 제일 중요하다고 생각합니다. 물론 한 팀의 리더로서 지식과 자질
이 필요한건 사실입니다.
그러나 팀을 이끄는건 팀장 자신이 아니라 팀원 모두라고 생각합니다.
속담중에 '백지장도 맞들면 낫다'라는 말이 있듯이 팀원이 하나가 되서 같이 움직이면 그만한 효
율이 없죠.
우선 이게 필요할거 같습니다. 같이 모여 의논도 많이하고 사적인 자로도 가끔 마련해서 팀웍을
다지고 그렇게 하다보면 물흐르듯 쭉쭉 뻗어가리라고 생각합니다.
그리고 한가지더 말씀드리자면..
heavyman님은 전세계에서 가장 프로페셔널한 인력(IT관련)은 어디가 많다고 생각하십니까.
저는 당연히 미국이라고 말씀드립니다. 알고계실지도 모르시겟지만요..ㅎ;
미국다음으론? 일본이겠죠. 한국은? 한참 후진입니다..
이런 말씀을 드리는 이유는 원리적으로 바뀌지 않으면 안되겠지만 heavyman님이 나중에 큰 분이 되시길 바라는 마음에
서 올립니다^^
미국은 첫직장부터 '너는 통신쪽만 해','넌 JSP 개발만해' 말하자면 이런식으로 정해줍니다. 사회에 첫발을 딧는 순간
부터 '나는 통신만 하는구나' 이렇게 인식을 시켜주는거죠. 앞으로 이 사람은 일을 그만둘때까지 약 40~50년동안 통신
쪽만 하는사람이 되는것입니다. 이렇게 한사람 한사람이 각자의 전문분야만 하기 때문에 그 분야에서 최고가 될 수 밖
에 없는것이죠.
일본은 그런 미국의 문화를 받아들여서 비슷합니다. 여기에 자기들의 문화를 섞어 일본만의 문화를 만들어냈죠. 미국보
다는 정교하진 않습니다. 하지만 하나의 일에 대해서 '이정도로 철저할 수 있는가'라는 생각이 들정도로 정말 철저합니
다. 예를들어 소스코드에서 의미없는 띄어쓰기가 있으면 일본인들은 그것도 에러라고 보는거죠.
마지막으로 한국은..저도 그렇게 배웠지만...많이 잡스럽습니다. 이것저것 다하는 사람이 잘하는 사람으로 인식되는
사회죠. 우리나라 일부 대기업이나 중기업들중에는 일본의 것을 많이 배운듯한 모습이 보입니다. 분야를 나누어서 그일
만 시키는거죠. 하지만 그냥 따라하기 수준이지 실제 일하다 보면 똑같습니다. 그렇기 때문에 자기 분야가 아닌 곳에
서 고생고생하면 일해야 하는 경우가 많이 생기는 것입니다.
프로그래머로서의 생명을 잠깐 말씀드리면 미국>일본>한국 순입니다. 미국이나 일본은 평생 프로그래머로 일해도 모라
구 하는사람 없습니다. 그러나 한국은? 서른중반까지 프로그램 짜면 '저놈은 발전못하는놈'이라고 찍히는거죠.
이건 문화자체가 바뀌지 않는한 바뀌기는 어렵겠죠. 하지만 나라를 움직이는건 민중의 힘이듯이 아래부터 차근차근 전
문화를 해나가면 언젠가 바뀌지 않을까요.
heavyman님, 알고계시겠지만 일의 진행을 위해서는 각 팀원의 실력을 확인시켜주는게 좋다고 생각합니다. 어설프게 아
는 것은 일에 도움이 전혀 안되기 때문입니다.
각 팀원의 전문분야를 키워주세요~ 한 프로젝트에서 일의 분담보다 팀원 개개인의 역량을 측정해서 가능성을 짚어보고
일에 투입하는거..그후 자기가 맞는 일을 분담해서 해나가면 정말 환상적인 팀이 될거라고 확신합니다.
에고 너무 제 생각의 나열했네요. 아마 제가 나중에 하고싶었던 그런 게 아니었을까 생각해봅니다^^
heavyman님 좋은 팀장으로 성장해주세요~^0^
여기까지 읽어주셔서 감사합니다