구전(Gujeon)

http://worldawesome.tistory.com/5

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

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

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

2. 기능의 명세가 기록으로 남지 않았습니다.
: 이게 무슨 기능인지 기능 A에 대해 어디에도 기록은 안했습니다. 우선 종전 명세서에 추가되어야 되고 그 명세서에 서로 배치되는 것은 없는지 평가를 하지 않고 있습니다. 과연 담당자는 뭐가 뭔지 알고 코딩을 한걸까요?
3. 어떻게 테스트해야 되는지 기록이 남지 않았습니다.
: 어찌 보면 가장 중요한 일이라고 봐도 될 것입니다. 기능은 추가되었는데 어떻게 되어야 돌아가는 건가요? 뭐가 바르게 돌아가는 것인가요? 어떻게 확인하지요?

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

이런 '새로운 기능을 구현할 때 말만 남고 문서가 없어 사후 관리가 안되는'것을 표준 한국어로 '구전(Gujeon 口傳)'이라고 합니다. ( 영어로 word of mouth. ) 계속 구전을 일삼는 팀은 늘 쳇바퀴를 돌 수밖에 없습니다. 대충해서 문서화나 기록을 남긴 조직은 더 문제입니다. 있는 문서가 더 헷갈리게 하고 차라리 구전이 낫다라는 생각에 힘을 실어줍니다.

구전파들이 득세하면 이런 일이 벌어집니다.

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

2. 개발팀은 콜센터가 됩니다.
:필드 엔지니어들이 고객에게 설명해 줄 내용이 없습니다. 그러니 결국 개발자 연락처를 고객에게 넘기고 그래서 문제만 있으면 바로 개발팀을 괴롭힙니다.

3. 새 출시일 후 1주일 뒤가 새로운 출시일입니다.
:자신들이 해결한 문제가 뭔지 그리고 어떻게 테스트 해야 하는지 QA조직에서도 모르겠다 하는데 어떻게 하겠습니까.. 현장에 가서 또 깨지는 것입니다.

그 외에도 문서를 만드는 자를 색출해서 감히 문자를 쓴 죄를 물어 왕따를 만들고 책임을 몰아버리는 등 별별 기괴한 일들을 많이 봅니다. 각종 개발자 커뮤니티에 올라오는 인간관계의 문제들 중 상당수는 여기서 시작합니다.

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

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

2. 우선순위를 매기고 얼마나 자원을 써야 하는지 추산해서 돌려주십시오.
: 이미 Joel on Software등에 나온 대로 얼마나 시간 자원을 써야 하는지, 우선순위는 어떤지 추산을 해서 알려주어야 합니다. 말도 안되는 자원을 주고 한다면 분명히 말을 해야하지만... 압니다, 힘들죠?

그래서 이렇게 하시길 권합니다. 자신이 판단한 우선순위와 자원과 위에서 결정한 우선순위와 자원이 진행될 수록 어떻게 되는지를 정리해서 알려주십시오. (Joel on Software에 있는 방법이 제일 좋았습니다.) 당신의 결정이 더 현실적이라는 것을 보여주고 이것으로 설득을 해야 합니다. 그게 안되는 조직이면 답답한 곳입니다.

3. WIKI를 구축하세요.
: 기능 명세, 규율, 각종 정보들이 한곳에 모여있어야만 합니다. 그리고 이것은 자주 수정되고 늘 새로운 것이어야 합니다. 이것을 잘 활용할 수 있는 방법은 바로 Wiki입니다. 이제 WIKI가 나온지 너무 오래되서 더 말하기도 힘들지만 쓰는 사람들만 쓰는 것 같습니다. 미디어위키나 Trac이나 Moni Wiki등 많은 프로그램들이 비교적 설치하기 쉽게 되어 있습니다. 그게 싫다면 스프링노트 같이 위키를 서비스 해주는 것을 이용해볼만 합니다. (Google docs도 공유하면 의외로 쓸만합니다. ) 하지만 가장 좋은 것은 작은 PC에 가상 PC설정하고 그 위에 위키같은 정보 집중 Tool을 설치하는 것입니다.

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

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

의외로 구전파는 노론벽파만큼이나 오랫동안 한국사회가 지식사회로 가는 것을 방해해왔고 우리 소프트웨어 산업이 3D직종이 되어 식민모국이 돈을 벌어가고 자생산업이 나오지 못하게 억압해 왔습니다.

이들을 이기는 방법은 한가지, '똑바로 해서 된다'라는 것을 보여주어야 합니다. 욕하고 비방하고 아무 소용 없습니다.절대 구전파 동료들에게 분노를 표현한다든가 그들을 낮춰보지 마십시오. 그럴수록 더 그들의 방식을 고집하게 됩니다. 남 말고 내가 먼저 '되는 방법'을 가지고 보여주면 됩니다. 내가 먼저 메일이든 버그 트랙킹 툴이든 쓰고 정리해 주면 됩니다.

어떤 식으로든 집단을 바꾸는데 3명만 있으면 된다는 집단 심리학자들의 말은 헛된 이야기가 아닐 수 있습니다. 3명만 당신 편을 만드시면 됩니다.

p.s: Blog에 마구잡이로 적은 글을 조금 정리해서 올립니다.