태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

소프트웨어 프로젝트는 누가 진행하는가?

2008/11/12 15:31 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



안녕하세요. 조성경님. Ray라고 합니다.
블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다.

소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠.
프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠.
물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다.
확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠.
그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다.

그런 이유는 간단합니다. 
그렇게 일을 해왔기 때문에 전문적인 지식을 배울 기회를 별로 보기 어렵고 그러다 보니 후배들에게 별로 가르칠 것이 없는 악순환이 계속 됩니다.
그래서 코딩 기술과 몇가지 Domain 지식만을 가지고 욹어 먹게 되는 경우가 많죠.

이런 기반이 잘되어 있는 회사에 들어가서 몇년 일하는 것만으로도 충분히 배울 수 있으나 그런 회사가 그렇게 많지 않는 것은 안타까운 일입니다.

조성경님이 경험했던 "소스보세요", "서버만들어" 이런 현상은 아주 흔합니다.
회사의 지식이 문서화 되어 있지 않고 소수의 머리속에 있고, 
소프트웨어 프로젝트를 진행하는데 가장 중요한 스펙의 중요성을 잘 모른 것이지요.

이 글에서 말하려고 하는 요지는 소프트웨어 엔지니어라면 단순히 코딩, 요소기술, Domain 지식에 매달리지말고, 소프트웨어 엔지니어로서 갖춰야 할 다양한 지식의 전문가가 되어야 한다는 것입니다.

제 책(소프트웨어 개발의 모든 것)에서도 이에 대한 내용을 상당히 다루고 있습니다.
앞으로 전문가로서 갖춰야 할 지식에 대해서 블로그에 계속 포스팅을 해나갈 겁니다.

감사합니다.


 난 자율따위는 믿지 않는다.
10개월이 걸리는 프로젝트A가 있다고 하자. 프로젝트A를 10개월에 끝낼 수 있는 능력을 실제로 가진 10명을 모아 따로 프로젝트를 진행하게 한다. 조건은 다음과 같다.

>> 어떠한 간섭도 없고 10개월 후 결과물을 보여준다.

10개월 후 제대로 프로젝트를 완료한 사람은 몇명이나 될까? 나는 많아야 한두명이 기대에 충족하는 결과를 내놓을 것이라고 본다. 실력이 모자란 사람은 없지만 자신을 관리할 수 있는 사람은 드물기 때문이다. 개인적인 경험에 의존한 결론이기는 하지만 당분간 이 생각을 바꿀것 같지는 않다.

내 경험과 다른 이들의 증언을 종합해보면 2~3개월 이상의 긴 일정을 툭 던져놓고 신경 끄는 관리자들이 있다. 이런 경우는 십중팔구 실패나 일정지연을 유발한다. 이때 실패는 작업자와 관리자중 누구의 잘못이 더 클까? 내 기준으로는 100% 관리자의 잘못이다. 만약에 이런 실패가 없다면 관리자는 존재 가치가 없다. 모든 조직에 관리자가 있다는 사실 자체가 스스로 뭔가를 알아서 하는게 쉽지 않다는 증거인데도, 이를 무시한다.

첫 회사에서 내가 받은 첫 주문은 "소스 보세요", 두번째 회사에서는 "서버 만들어"였다. 그래서 소스를 보고 고치고, 서버를 만들었다. 이 과정으로인해 나는 몇번의 큰 실수를 한다. 내가 그렇게 해왔으니까 남들도 그렇게 하면 되는 줄 알았고, 그렇게 못하는 남들을 제대로 이해하지도 못했다. 그리고 그렇게 하지 못하는 사람들을 낮게 평가했다. 지금 생각해보면 그냥 부끄러운 과거일뿐이고, 그 사람들에게 진실로 미안한 마음이 든다. 그때는 내가 미숙했다.

다시 프로젝트A를 진행하는 10명으로 돌아가보자. 프로젝트를 성공적으로 끝낼 한두명이 나머지보다 낫다는 점은 두말할 가치가 없다. 그러나 나머지 사람들이 쓸모없는 사람이냐라고 묻는다는 그건 절대 아니다. 단지 그들이 잘 못하는 부분이 들어났을 뿐이다. 좋은 관리자라면 그들을 이끌고 목표를 향해 나갈 줄 알아야하고, 경우에 따라서는 그들이 더 좋은 결과를 만들기도 한다.

왜 이런 구질구질한 얘기를 했냐면 오전에 있었던 엔진쪽 인원에 대한 평판 조회(reference check) 대답때문이다. 평가를 간단히 요약하면 엔진 연구하라고 했는데 1년이 넘도록 제대로된 결과를 만들지 못해서 해고했었다고 한다. 따져 묻고 싶은게 많았는데 그리 친한 사이도 아니라서 더 물고늘어질수는 없었고 잡다한 생각들이 들었다.

1년이 넘도록 결과물을 얻지 못했을 때 관리자는 뭘 했으며, 1년이 넘게 기다려야 했을까?
그 사람이 1년 넘는 기간동안에 진짜로 한 일은 뭘까?

이러한 생각에 대한 내 대답이 바로 이글이다. 계속 해고하면서 자기 스스로 관리가 가능한 스타 플레이어를 채용할 운을 시험해보는 것은 관리자 스스로가 무능하다는 자백과 다를게 없다. 그러니 이거 보세요, 분석하세요, 공부하세요 이런 말은 고만하자.

저작자 표시 비영리 변경 금지

전규현 프로젝트

Trackback Address: http://allofsoftware.net/trackback/12 관련글 쓰기
문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서..

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다. 복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다. 기초..

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다. 보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속..

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다. 2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다. 3. 문제 해결 능력을 키워야 한다...

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다. Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을..

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다. 조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다. 경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하..

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까? 흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이..

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..