첫번째 글에 이어서 두번째글

개발자와 기획자 또는 품질관리 조직과의 의사교환은 서로간의 입장 차이가 분명 하기 때문에 어느정도 친하기 전까지는 서로 얼굴 맞대고 이야기 했다가는 얼굴 붉힐 일이 종종 생긴다. 이때는 문서로 의사를 교환하는 것이 좀 더 좋을 것 같은데..

앞의 글에서도 언급 했듯이 문서로 의사 교환하는데 단점은 정확하지 않은 의사전달이 이루어질 가능성이 있다는 것이다. 이럴때 적절한 방법은 이슈관리 솔루션(버그질라 등등)을 사용하는 것이라고 생각 한다. 이전 회사에서 이슈관리 솔루션을 정말 잘 사용하였는데 여러가지 장점이 존재한다. 명확한 의사전달을 도와줄 수 있으며, 덤으로 문서커뮤니케이션의 장점인 검색 및 관리가 용이하다는 장점까지 가져올 수 있다.

두번째는 정확한 커뮤니케이션으로 의사전달 코스트를 줄여 줄 수 있는 이슈관리 솔루션의 활용 되겠다.

그리고 세번째로 앞의 글에서 언급한 문서 커뮤니케이션에 관한 이야기 이다.

앞에서 메일과 같은 문서 커뮤니케이션이 의사전달이 명확하지 않을 수 있다는 단점이 존재 한다고 했는데, 이외에도 메일로 의사를 전달 하는 것에는 몇가지 단점이 존재한다. 먼저 메일은 검색 및 관리가 용이하지 않다. 일회성 특징이 있기 때문에 기록으로써의 가치도 떨어지게 된다. 지금 회사에서는 거의 모든 정리에 위키를 활용한다. 주간업무 정리, 회의 결과 정리, 휴가 일정,투표 와 같은 전혀 다를 것 같은 환경에서도 위키는 그 위력이 뛰어나다. 기록으로써의 가치도 뛰어나며, 검색 및 관리도 용이하다. 메일은 거의 완전한 일회성 의사 교환 및 언제 어느위치에 정리되었음을 공지 하는 용도로만 쓰인다. 개인적으로는 회사 메일 상자를 언제 날려버려도 전혀 불편하지 않을 정도가 좋다고 생각 한다.

그 다음으로 문서화에 대한 이야기 이다.
개발을 하면서 문서화에 대한 중요성은 익히 알고 있다. 참 중요하다. 하지만 서비스 를 개발하는 조직에서 개발 문서화에 들어가는 그 막대한 코스트는 참으로 아깝다. 아깝지만 문서화는 중요하고 그만큼 가치가 있으니까 많은 시간이 들더라도 해야한다? 얼마전까지만 해도 그렇게 생각 했고, 지금도 어느정도 동일한 생각 이지만 약간 다른 것이 한가지가 더 덛붙여 져야 한다고 생각 한다. 문서화가 중요하니까 문서화에 들어가는 코스트는 감수 하여야 하지만, 문서화의 코스트를 줄일 수 있는 최대한의 노력을 하여야 한다는 것이다.

지금 회사에서 회의정리 및 일정, 업무 정리 등에 위키를 사용한다고 했는데, 개발 결과 공유 또는 설계 공유 라는 이름으로 개발 문서도 위키에 정리를 한다. 이때 개발 문서에는 일정 및 스펙, 회의 내용등의 링크를 쉽게 걸 수 있기 때문에 개발문서가 약간 가벼워 진다. 그리고 회의 또는 스텐딩 미팅을 통해서 함께 논의하고 설계해서 화이트보드에 그린 그림을 사진으로 찍어서 개발문서의 설계 다이어그램 등을 대체한다. (설계 문서에 다이어그램 그리면서 얼마나 많은 시간을 들여야 하는지 개발자 분들은 잘 아시리라..) 물론 아주 이쁘지는 않지만 알아볼 만은 하다. 이 정도면 만족.. (하지만 이런 것도 그냥 하라고 해서 되는 것이 아니다. 그림을 쉽게 그리고 회의 없이도 쉽게 논의 할 수 있는 자리를 만들기 위하여, 가능한 모든 벽면에 화이트 보드가 설치되어 있다. 앉아있는 자리에서 가장 가까운 화이트 보드 앞에 모여서서 옹기종기 이야기 하기 쉬운 문화가 쉽게 형성 된다.) 그리고 이렇게 정리된 것은 짧은 시간이라도 결과공유 라는 이름으로 모임을 통해서 설명 하는 자리를 가져야 한다.

개발자가 개발 산출물을 문서화 해야 한다는 압박감에 시달리지 않고, 기획자 또는 PM이 개발 문서가 없어서 전혀 파악이 안된다는 답답 함에서 벗어나는 것이 진정으로 개발 문서화의 목적이라면 이 정도가 아주 훌륭하다고 생각 한다.

문서화를 쉽게 할 수 있도록 하는 노력은 문서 커뮤니케이션의 코스트를 줄이는, 서로서로 편할 수 있는 환경을 만든다는 의미에서 중요하다고 생각 한다.