세상을 놀라게 하자!

구전문학 프로젝트 관리 본문

Software construction

구전문학 프로젝트 관리

유진호 2009. 4. 9. 01:00

 몇몇 소프트웨어 회사들에서 실제 일어나는 일들 중에 하나가 이런일입니다. 갑자기 고객A가 기능A를 넣어달라고 마케팅 부서에 요청합니다. 그러면  팀장에게 전달되고 팀장은 담당자에게 일을 설명해주고 해달라고 합니다. 담당자는 열심히 일을 해서 팀장에게 검사를 받습니다.

 

 뭐가 잘못되었을까요? 아직 잘 모르시겠습니까? 간단하게 아래의 일들을 하고 있지 않습니다.

  1. 얼마나 큰 일인지 기능에 대한 평가가 되지 않았습니다.
    : 고객의 요구라고 다 해야 되는건 아닙니다. 우선순위를 정해야 합니다. 그리고 얼마나 걸릴지 인력은 얼마나 써야 되는지 평가해야 하는데 그렇게 되지 않았습니다.

  2. 기능의 명세가 기록으로 남지 않았습니다.
    : 이게 무슨 기능인지 기능 A에 대해 어디에도 기록은 안했습니다. 우선 종전 명세서에 추가되어야 되고 그 명세서에 서로 배치되는 것은 없는지 평가를 하지 않고 있습니다. 과연 담당자는 뭐가 뭔지 알고 코딩을 한걸까요?

  3. 어떻게 테스트해야 되는지 기록이 남지 않았습니다.
    : 어찌 보면 가장 중요한 일이라고 봐도 될 것입니다. 기능은 추가되었는데 어떻게 되어야  돌아가는 건가요? 뭐가 바르게 돌아가는 것인가요? 어떻게 확인하지요?

  말로만 모든 의사소통이 남아 있다면 이렇게 됩니다. 담당자 떠나고 나면 이 기능 뭔지 누가 아나요? 매뉴얼 만드려면 담당자 괴롭히면서 해야 합니다. 게다가 이게 어느버전에 들어간건지 관리는 될까요? (이런 식의 업무지시가 많은 곳에는 기록은 '개나 줘붜려'가 됩니다. )

 

이런 '새로운 기능을 구현할 때 말만 남고 문서가 없어 사후 관리가 안되는'것을 '구전(Gujeon : 口傳)'이라고 '어느 나라 말'(?)로 씁니다.  계속 구전을 일삼는 팀은 늘 쳇바퀴를 돌 수밖에 없습니다. 대충해서 문서화나 기록을 남긴 조직은 더 문제입니다. 있는 문서가 더 헷갈리게 하고 차라리 구전질이 낫다는 냉소파들에게 힘을 실어줍니다.

 

 구전파들이 득세하면 이런 일이 벌어집니다. 한번 비교해보세요.

  1. 늘 소프트웨어 개발 조직은 호떡집입니다.
    : 개발 일거리들의 교통정리가 안되니 당연합니다.

  2. 개발팀은 콜센터가 됩니다.
    :필드 엔지니어들이 고객에게 설명해 줄 내용이 없습니다. 그러니 결국 개발자 연락처를 고객에게 넘기고 그래서 문제만 있으면 바로 개발팀을 괴롭힙니다.
  3. 새 출시일 후 1주일 뒤가 새로운 출시일입니다.
    :자신들이 해결한 문제가 뭔지 그리고 어떻게 테스트 해야 하는지 QA조직에서도 모르겠다 하는데 어떻게 하겠습니까.. 현장에 가서 또 깨지는 것입니다. 


     그 외에도 문서를 만드는 자를 색출해서 다 만든 문서에 한자 틀린 것까지 문제삼아 문서는 필요없다는 논리를 피며 감히 문자를 쓴 죄를 물어 왕따와 책임을 묻는 등 별별 기괴한 일들을 많이 봅니다. 각종 개발자 커뮤니티에 올라오는 문제들 중 상당수는 이런 문제들과 유사한가요?


   구전파를 박멸하고 싶으세요? 이제 이런 짓은 그만하고 싶으세요? 이렇게 하십시오.

 

  1. 언제나 문서로 일을 받으세요.
    : 최소한 메일로라도 일을 받으십시오. 말로 설명하고 때우려고 한다면 이렇게 말하세요. "일이 명확하게 되는게 팀장님에게도 득이 되시지 않겠습니까? 제가 정리한 내용이 맞는지 한번 봐 주십시오." 내용이 맞지 않는다면 다시 설명을 해달라고 해서 간단 명료하게 정리하세요.

  2. 우선순위를 매기고 얼마나 자원을 써야 하는지 추산해서 돌려주십시오.
    : 이미 Joel on Software등에 나온 대로 얼마나 시간 자원을 써야 하는지, 우선순위는 어떤지 추산을 해서 알려주어야 합니다. 말도 안되는 자원을 주고 한다면 분명히 말을 해야하지만... 압니다, 힘들죠?
      그래서 이렇게 하시길 권합니다. 자신이 판단한 우선순위와 자원과 위에서 결정한 우선순위와 자원이 진행될 수록 어떻게 되는지를 정리해서 알려주십시오. 이미 Joel on Software에 있는 Excel을 이용한 일정관리의 방법이 이런 방식을 택할 것입니다. 당신의 결정이 더 현실적이라는 것을 보여주고 이것으로 설득을 해야 합니다. 그게 안되는 조직이면 답답한 곳입니다.

  3. WIKI를 구축하세요.
    : 프로젝트를 진행하면서 각종 지식과 노하우가 하나하나 나옵니다. 이것을 모아서 Wiki에 정리해야 합니다. 일명 'Black book'을 만든는 겁니다. 만약 이런 것이 안모이면 늘 새로 일하는 느낌이 될겁니다. '기록문화'를 가진 조직은 이런 것에 대한 대처법이 달라집니다. 흐릿한 먹물이 또렷한 기억보다 낫습니다.


  4. 작업에 대한 기록을 남기세요.
    : Subversion같은 SCM Tool뿐 아니라 Bugzilla같은 버그추적 프로그램을 이용하셔야 합니다. 새로운 일을 모두 버그 추적 시스템에 넣어 놓고 이 일의 양과 자원, 우선순위를 결정하고 그 순서대로 하나하나 처리하는 방식을 사용하십시오. 이때 꼭 '테스트하고 검증하는 방법'에 대해 상세히 적어야 합니다. '무엇했다'만큼이나 '어떻게 검증한다'가 중요합니다.

  5. 상부에 보고할 때 이슈 ID로 대화하세요.
    : 의외로 이게 중요합니다. '그 건'으로 지칭되는 모든 일거리를 이슈 ID로 정리해서 소제목으로 전달/보고해 보십시오. 반드시 최상위권자가 아닌 직속 상관에게 이를 전달해서 상관이 이름을 낼 수 있게 해주는 '센스'도 필요합니다. 그리고 가능하면 자신이 관리하는 할일 목록을 늘 회의 때마다 들고갈 필요가 있지요.

  의외로 이런 구전파는 친일파(?)만큼이나 오랫동안 한국사회가 지식사회로 가는 것을 방해해왔고 우리 소프트웨어 산업이 3D직종이 되어 식민모국이 돈을 벌어가고 자생산업이 나오지 못하게 억압해 왔습니다. 그렇게해야 최대한 많이 착취할 수 있는 구조가 되기 때문입니다.

 그런데 맨날 화만 내면 되나요? 뭔가 행동해야 하지 않을까요? 불행히도 구전파들은 그게 두려워 여러분을 '야근'으로 돌립니다. 만약에 조직이 계속 야근을 하는데 뭔가 개선하려는 시도가 보일 때 마다 더 심한 야근을 하게 계획을 짠다면  거긴 '노예제 사회'일 것입니다. 당신이 충분히 위의 노력들을 해서 뭔가 나아졌는데도 불구하고 억압만 나온다면 나가셔도 됩니다. 이미 당신은 다른 어떤 조직에 가실 만큼 실력을 쌓을 수 있는 '방법'을 알고 계십니다. 의외로 괜찮게 옮기실 수도 있습니다.  노예가 되시렵니까, 시민이 되시렵니까? 왜 예전 노예제 사회에서 노예가 글자 배우는 것을 막았는지 아시겠습니까?


Comments