2007/08/01 23:32
미완성문서관리.
며칠 전에 이야기한 마인드 매니저를 이용한 문서관계관리 실험에 적당히 포함되는 이야기입니다. 문서 하나를 만들면 문서를 완성한 상태로 유지되는 시간은 그리 길지 않습니다. 여러 가지 이유로 문서는 반드시 수정되어야 합니다. 잠깐 프로그래머와 나눈 이야기의 결과만으로도 많은 것들이 변할 수 있는데, 이것들을 기록해 두지 않으면 며칠 못 가서 문서는 완전히 쓸모 없는 딴 세상 소리를 지껄이게 되고 맙니다. 무슨 이야기를 하건, 무슨 변경사항이 있건 간에 문서에 기록을 남겨야 합니다. ... 다들 알고 있지만 생각처럼 잘 되지는 않습니다. 이야기를 나눈 직후에 파일을 열어 문서를 수정할 수 있을 정도로 문서 작성의 고수라면 게임 회사에서 기획서나 정리하며 박봉에 시달리지도 않을 겁니다.
워드프로세서에는 참 다양한 기능이 있습니다. 문서에 메모를 첨부하거나, 이전 버전과 현재 작업 버전을 비교해 변경된 부분에만 밑줄을 그어뒀다가 검토자가 변경사항을 승인해야만 문서에 실제로 반영되는 기능을 사용할 수도 있습니다. - 일단 MS워드에선 그렇습니다. - 하지만 어째서인지 이 기능을 제대로 활용하는 경우를 몇번 못 봤습니다. 이 기능을 아는 사람들은 기능을 유용하게 사용하곤 하지만, 작업자 중에 한명이라도 이 기능에 익숙하지 않은 사람이 있다면 분명 이렇게 말할 겁니다. '이거 이상해. 서식 적용도 안했는데 빨간 밑줄이 그어져.'
며칠 전에 이야기한 문서관계관리에서 중요하게 생각한 점은 웬만하면 기존 작업자들을 괴롭히지 말아야 한다는 것입니다. 물론, 회사 내의 어떤 부서들처럼 강력한 문서관리 정책을 작업자들에게 제시해서 목차와 수정사항까지 깔끔하게 정리된 문서를 받아볼 수도 있겠지만, 그 정도 문서작업에 투입됐을 인적 자원을 생각하면 감탄 이전에 눈물이 앞을 가립니다. 마치 민방위에 처음 나가서 받아온 안내 책자를 볼 때와 비슷한 느낌입니다. 작업자들에게 강력한 문서관리 정책을 지키도록 하는 것도 중요하지만, 일단은 작업자들이 웬만하면 작업 방식을 그대로 유지한 채로 정리만 할 수 있으면 좋겠습니다.
일단, 이런식으로 문서 파일을 정리하고 있습니다. 카테고리와 파일은 아무렇게나 배치해도 상관 없기 때문에 필요한 아무 장소에 새로운 카테고리를 추가하거나, 설명을 붙일 수 있습니다. 파일은 다들 svn에서 체크아웃해 똑같은 디렉토리 구조로 다운받아서 들고 있어서 워드 아이콘을 누르면 바로 문서를 구경하거나 편집할 수 있습니다. 사실, 문서를 이렇게 논리적인 구조로 관리하기 시작하면 물리적인 구조에 신경을 덜 쓰게 되고, 나중에 물리적인 구조에 신경써야 하는 시점이 됐을 때 꽤 고달프게 될 수도 있습니다. 일단 정리가 잘 된 것 같아 보였지만, 위에서 이야기한대로, 문서에 수정을 가하기 시작하면 어떨까요.
문서를 수정해야 하는 상황은 정말 자주 일어납니다. 며칠 전에 읽었던 게임 개발 서적에서는 수정사항이 발생했을 때 빡세게 정성을 들여 문서를 다시 수정해 놓을 것을 권장합니다. 문제를 찾을 수 없는 훌륭한 방법인데, 쉽지는 않습니다. 다음 프로젝트에서는 꼭 그렇게 할 수 있기를 바라지만, 일단 지금의 문제를 수습하는데 초점을 맞춰 보겠습니다. 문서의 수정사항은 여러 가지 경로를 통해 나타나는데, 이것들은 원래 문서와 잘 통합되지 않습니다. 휘갈겨 적은 노트, 포스트잇, 다른 사람에게 날아온 메일이나 메신저 메시지들. 바로바로 문서에 통합하기에는 수고가 많이 들고, 그대로 쌓아두자니 답답합니다만, 제 아이디어는 이렇습니다. 변경사항을 당장 문서에 반영할 수 없다면, 일단 그냥 날아온대로 쌓아두자는 겁니다.
쌓아 둔 수정사항은 또 다른 문서파일이 될 수도 있고, 아웃룩 메모나, 메일이 될 수도 있습니다. 아니면 해외에서 날아온 수정이나 확인사항이 가득히 적힌 엑셀 파일일 수도 있지요. 이것들을 깔끔하게 통합할만한 관리 솔루션을 본적이 없기 때문에, 마인드 매니저에서는 이것들을 원래 문서 뒤에 서브 토픽으로 그냥 붙여둡니다. 원래 '문서.doc'를 참조하려는 사람들은 뒤에 붙어있는 파일을 함께 읽어야 합니다.
그대로 언제까지 놔둘 수는 없습니다. 예전에 저런 식으로 원래 문서의 수정 없이 계속해서 수정사항을 쌓아버린 사례 하나를 오래 전에 사용하던 공유디렉토리에서 발견했는데, 정말 대단했습니다. '수정사항', '또 다른 수정사항', '최신 수정사항', '오늘자 수정사항' ...... 연구해볼 만한 사례입니다만, 저런식으로 일이 처리된 걸 보면 신기하기 짝이 없습니다. 당연히, 작업 중간에 작성된 저 모든 문서들이 '잘못된 사례 분석' 이외에는 아무런 용도로도 사용될 수 없었습니다. 절대 저렇게 해선 안되고, 저 상태로 방치해서도 안됩니다.
그러면, 시간이 났을 때 '문서.doc'를 작성한 담당자가 문서 뒤에 서브토픽으로 달려 있는 내용들을 원래 문서에 병합해야 합니다. 물론 이것도 귀찮긴 하지만, 그때그때 병합하지 않는 정도로도 꽤 타협할만 하다고 생각합니다. 단, 병합이 끝났다고 해서 바로 서브 토픽을 지워버릴 필요는 없을 것 같습니다. 병합이 완료되었다는 표시를 해두고, 서브토픽들이 모두 병합될 때까지 잠시 그대로 놔둡니다. 아니면 기간을 정해놓고 그 기간이 지난 병합이 완료된 서브토픽만을 선택적으로 지울 수도 있겠죠.
만족할만한 깔끔한 방법은 아닙니다만, 일단 당장의 상황을 수습하기에는 적당하다고 생각합니다. 문서가 자기 역할을 다하기 위해서는 개발 상황에 따른 변경사항의 철저한 업데이트만큼 훌륭한 방법은 없습니다 ... 만, 그걸 실천하기 너무너무너무너무 힘들다면 이런 방법도 고려해볼 '수'는 있습니다. :(
워드프로세서에는 참 다양한 기능이 있습니다. 문서에 메모를 첨부하거나, 이전 버전과 현재 작업 버전을 비교해 변경된 부분에만 밑줄을 그어뒀다가 검토자가 변경사항을 승인해야만 문서에 실제로 반영되는 기능을 사용할 수도 있습니다. - 일단 MS워드에선 그렇습니다. - 하지만 어째서인지 이 기능을 제대로 활용하는 경우를 몇번 못 봤습니다. 이 기능을 아는 사람들은 기능을 유용하게 사용하곤 하지만, 작업자 중에 한명이라도 이 기능에 익숙하지 않은 사람이 있다면 분명 이렇게 말할 겁니다. '이거 이상해. 서식 적용도 안했는데 빨간 밑줄이 그어져.'
며칠 전에 이야기한 문서관계관리에서 중요하게 생각한 점은 웬만하면 기존 작업자들을 괴롭히지 말아야 한다는 것입니다. 물론, 회사 내의 어떤 부서들처럼 강력한 문서관리 정책을 작업자들에게 제시해서 목차와 수정사항까지 깔끔하게 정리된 문서를 받아볼 수도 있겠지만, 그 정도 문서작업에 투입됐을 인적 자원을 생각하면 감탄 이전에 눈물이 앞을 가립니다. 마치 민방위에 처음 나가서 받아온 안내 책자를 볼 때와 비슷한 느낌입니다. 작업자들에게 강력한 문서관리 정책을 지키도록 하는 것도 중요하지만, 일단은 작업자들이 웬만하면 작업 방식을 그대로 유지한 채로 정리만 할 수 있으면 좋겠습니다.
일단, 이런식으로 문서 파일을 정리하고 있습니다. 카테고리와 파일은 아무렇게나 배치해도 상관 없기 때문에 필요한 아무 장소에 새로운 카테고리를 추가하거나, 설명을 붙일 수 있습니다. 파일은 다들 svn에서 체크아웃해 똑같은 디렉토리 구조로 다운받아서 들고 있어서 워드 아이콘을 누르면 바로 문서를 구경하거나 편집할 수 있습니다. 사실, 문서를 이렇게 논리적인 구조로 관리하기 시작하면 물리적인 구조에 신경을 덜 쓰게 되고, 나중에 물리적인 구조에 신경써야 하는 시점이 됐을 때 꽤 고달프게 될 수도 있습니다. 일단 정리가 잘 된 것 같아 보였지만, 위에서 이야기한대로, 문서에 수정을 가하기 시작하면 어떨까요.
문서를 수정해야 하는 상황은 정말 자주 일어납니다. 며칠 전에 읽었던 게임 개발 서적에서는 수정사항이 발생했을 때 빡세게 정성을 들여 문서를 다시 수정해 놓을 것을 권장합니다. 문제를 찾을 수 없는 훌륭한 방법인데, 쉽지는 않습니다. 다음 프로젝트에서는 꼭 그렇게 할 수 있기를 바라지만, 일단 지금의 문제를 수습하는데 초점을 맞춰 보겠습니다. 문서의 수정사항은 여러 가지 경로를 통해 나타나는데, 이것들은 원래 문서와 잘 통합되지 않습니다. 휘갈겨 적은 노트, 포스트잇, 다른 사람에게 날아온 메일이나 메신저 메시지들. 바로바로 문서에 통합하기에는 수고가 많이 들고, 그대로 쌓아두자니 답답합니다만, 제 아이디어는 이렇습니다. 변경사항을 당장 문서에 반영할 수 없다면, 일단 그냥 날아온대로 쌓아두자는 겁니다.
쌓아 둔 수정사항은 또 다른 문서파일이 될 수도 있고, 아웃룩 메모나, 메일이 될 수도 있습니다. 아니면 해외에서 날아온 수정이나 확인사항이 가득히 적힌 엑셀 파일일 수도 있지요. 이것들을 깔끔하게 통합할만한 관리 솔루션을 본적이 없기 때문에, 마인드 매니저에서는 이것들을 원래 문서 뒤에 서브 토픽으로 그냥 붙여둡니다. 원래 '문서.doc'를 참조하려는 사람들은 뒤에 붙어있는 파일을 함께 읽어야 합니다.
그대로 언제까지 놔둘 수는 없습니다. 예전에 저런 식으로 원래 문서의 수정 없이 계속해서 수정사항을 쌓아버린 사례 하나를 오래 전에 사용하던 공유디렉토리에서 발견했는데, 정말 대단했습니다. '수정사항', '또 다른 수정사항', '최신 수정사항', '오늘자 수정사항' ...... 연구해볼 만한 사례입니다만, 저런식으로 일이 처리된 걸 보면 신기하기 짝이 없습니다. 당연히, 작업 중간에 작성된 저 모든 문서들이 '잘못된 사례 분석' 이외에는 아무런 용도로도 사용될 수 없었습니다. 절대 저렇게 해선 안되고, 저 상태로 방치해서도 안됩니다.
그러면, 시간이 났을 때 '문서.doc'를 작성한 담당자가 문서 뒤에 서브토픽으로 달려 있는 내용들을 원래 문서에 병합해야 합니다. 물론 이것도 귀찮긴 하지만, 그때그때 병합하지 않는 정도로도 꽤 타협할만 하다고 생각합니다. 단, 병합이 끝났다고 해서 바로 서브 토픽을 지워버릴 필요는 없을 것 같습니다. 병합이 완료되었다는 표시를 해두고, 서브토픽들이 모두 병합될 때까지 잠시 그대로 놔둡니다. 아니면 기간을 정해놓고 그 기간이 지난 병합이 완료된 서브토픽만을 선택적으로 지울 수도 있겠죠.
만족할만한 깔끔한 방법은 아닙니다만, 일단 당장의 상황을 수습하기에는 적당하다고 생각합니다. 문서가 자기 역할을 다하기 위해서는 개발 상황에 따른 변경사항의 철저한 업데이트만큼 훌륭한 방법은 없습니다 ... 만, 그걸 실천하기 너무너무너무너무 힘들다면 이런 방법도 고려해볼 '수'는 있습니다. :(
