보고서의 버전을 관리하라
파워포인트 블루스 에세이
여러 회사를 다니면서 내가 경험한 바로는 보고서를 요구하는 경영진이나 담당자는 대체적으로 생각이 자주 바뀐다는 것이다. 조금 더 솔직한 표현을 하자면 변덕이 심하다고 하겠다.
그래서 보고서의 내용과 구성이 자주 바뀌게 된다. 보고서 기획 초기에 인터뷰를 통해 들었던 요구사항과는 전혀 다른 얘기를 하는 경우도 간혹 있다.
보고체계가 복잡한 경우도 보고서의 내용수정을 반번하게 하는 원인이다. 여러부서와 여러 직급의 사람들을 모두 만족시키는 보고서는 드물기 때문에 보고서는 항상 수정된다.
위와 같은 이유때문에 크게 골탕을 먹은 적이 있었다. 여러 부서의 임원사무실을 돌면서 보고서의 순회공연을 어렵사리 마치고 문서를 계속 수정, 보완하면서 다시금 경영진과의 최종 리뷰자리를 가지게 되었는데 그 자리에서 갑자기 ‘맨 처음에 보여주었던 버전이 가장 나은것 같다. 그걸로하자’라고 하는 것이 아닌가.
잦은 수정으로 그 보고서의 원형은 이미 하드디스크 내에서 사라지고 난 뒤였다. 물론 나는 기억을 더듬어가며 처음에 만들어 놓은 스토리보드의 잔해를 찾아 오랜작업 끝에 다시 원형을 살릴 수 있었다.
나에게는 웃고 끝나기에는 너무 큰 교훈이었다. 게다가 한번 만들어 놓은 보고서는 언젠가는 또 회자된다. 비슷한 업무를 다년간 하게 되면 반드시 그런일이 생긴다. 예전에 써놓은 보고서에서 내용을 인용하거나 반려되어 묻어둔 보고서가 1년쯤 후에 때를 만나 다시 빛을 보게될 그런일 말이다.
그때부터 보고서의 버전관리를 철저하게 하기 시작했는데 날짜와 버전을 꼭 명기하기 시작했다. 아래와 같이 말이다.
영업전략보고서_20090120_v03.ppt
개인적으로는 하나의 보고서로 ‘v42’까지 기록한바 있었다. 즉, 마흔두번 수정한 보고서 였는데 해당 보고서 폴더에도 마흔두개의 파일이 들어있다. 그 보고서는 18개월만에 통과되었고, 계속해서 후속 보고서가 3개까지 이어지면서 처음 보고서에서 사용했던 자료들도 수년간 계속 이용되었었다. 그 4편의 보고서 시리즈는 3년만에 종료되었고 해당보고서 폴더의 크기는 최종적으로 살펴보니 700메가바이트에 육박하고 있었다.
각 보고서는 20여페이지 내외였는데도 말이다.
한글2007과 ms 오피스 모두 자체적으로 버전관리 옵션을 제공하고 있는데, 의외로 모르시는 분들이 많더군요;; 개인적으로 문서관리라면 ms의 워크스페이스(http://workspace.office.live.com/ )를 추천합니다. ^^
아~ 한번 해봐야겠습니다. ^^ 오피스를 사용하면서 아마 제공하는 기능의 20%도 못쓰지 않았을까 하는 생각이 늘 든답니다. 역시 소금이 님은 구석구석 잘 사용하시는군요 ㅎㅎ
저도 버전은 붙이긴하는데 날짜까지 기입해야 할까요?
참고해야겠네요.
버전을 관리하고 파일이름을 명명하는데 특별한 원칙은 없습니다. 그냥 자기가 편한대로 관리만 잘해주면 되지요. 날짜를 붙이는 이유는 ‘아~ 이게 지난주에 리뷰한 그 버전이었군””하고 알아보는데 목적이 있습니다.
배포할때도 상대방이 버전보다 날짜를 보기도 하죠
그래서 병행한답니다 ^^
v42가 v4.2얘기하시는거죠?
전 중간마무리수준에서 v1.0으로 올리고 여기서 작은거 수정하면 1.1로 진행하는식이거든요.
demitrio님은 어떤식으로 진행하는지 궁금하네요.
버전이름 역시 편리한대로 해주면됩니다. 저는 그냥 수정한 순서대로 계속 순차적으로 번호를 붙여버린답니다. 큰 판올림, 작은 판올림을 구분하지않구요 ^^
저도 얼마 전 진행했던 프로젝트에서 수십개의 같은 내용, 다른 형태의 보고서를 만든 적이 있습니다. 하루에도 몇 번씩 바뀌었던…
아… 정말 힘든 시간이었어요~ ㅜㅜ
아~ 이해됩니다. 정말 저도 그럴때는 미쳐버릴거 같더군요. 그 수많은 파일을 일일히 열어서 특정내용을 찾아 헤메곤 했었죠 … 후우~~
저도 그런 식으로 버전관리를 하고 있습니다. Ver6이 제일 많이 간 거였는데, 그게 총 300페이지가 넘는(첨부문서 빼도 120페이지;;) 물건이라 만들면서도 초난감했죠.
문제는 그게 20분짜리 발표에 쓰여야 하는 자료였다는 겁니다;; 그 프로젝트에 따라붙었던 컨설턴트가 양으로만 승부하는 사람인데다 대표이사랑 친분이 있는 바람에 더 오버를 시키더군요. 발표 10분 전까지 수정사항 이래저래 주문하고(자기는 발표 안 하면서!!). 막판에 많이 싸웠습니다.
그 사람, 그 다음 프로젝트에서는 10분 발표시간에 2천페이지짜리를 들고 오더군요;; 용량이 450메가바이트.
버전관리법을 보니 그 아찔했던 순간이 다시 떠오릅니다;;
양으로 승부하는 사람들…ㅎㅎ ^^ 저도 싫어합니다.
보통 누가 뭘 물어보면 그 안에 다 씌여있다고 대답하곤 했던 분이 생각나네요. 보통 양이 많아지면 내용이 두리뭉실해지고 머리에 남는게 없죠. 그걸 노리는 건지도 몰라요.
저는 영업을 하고 있어서 문서 버전관리를 같은 방법으로 하고 있습니다.
내부 업무는 기획서 등으로 몇가지 안되지만
외부 업무는 사전컨설팅, 견적, 제안, 계약서 등 종류가 많아서
문서별로 버전관리가 반드시 필요합니다.
OOOO 견적서_20090102(ERP).xls – 최초 견적
OOOO 견적서_20090102(ERP)-v2.1.xls – 협상 사항 발생, 이슈정의
OOOO 견적서_20090106(ERP)-방안.xls – 협상 대응 방안 정의 내용
OOOO 견적서_20090109(ERP)-최종.xls – 계약서에 첨부될 내용
OOOO 제안서_20090102(ERP).ppt – 최초제안서
OOOO 제안서_20090106(ERP)-전산실 요구 사항 반영.ppt
– 제안서/요구사항 반영/이슈반영
OOOO 제안서_20090109(ERP).ppt – 최종 제안
(OOOO = 업체명)
이런 예로 활용을 합니다.
v2.1는 금액의 변경이 있을때나 이슈사항이 생겼을 경우에 눈에 띄도록
사용을 하는 것이고 날짜로 분류하는 것이 최선의 방법이라고 생각합니다.
계약/제안 이후에도 이견이 있는 경우들이 있어서 확실히 이렇게 관리를
하면 도움이 되는 경우가 많이 있습니다.
늘 좋은 글 감사합니다.
저하고 비슷하시군요. 아무래도 하나의 이슈에 대해 문서 종류가 많으시니 더더욱 버전관리나 날짜관리가 중요하겠네요
항상 성원해주셔서 감사합니다 ^^
일하다 보면 파일의 명칭이나 문서의 제목을 정하는 것이 참 고민될때가 있더라구요. 한번 저도 위에 내용을 다시 한번 고민을 해보고 개선을 해야겠습니다.^^
ㅎㅎ 네 다들 버전이나 명칭문제로 한번씩들 고민해보셨군요. 좋은 아이디어가 떠오르시면 여기에도 남겨주세요 ^^
계약을 성사하였고 완료 시점에서 문제가 있었습니다.
무상유지보수기간의 문제가 생겼습니다.
계약 당시에 당사와 유지보수를 하지 않을 수도 있기 때문에
계약서에 유지보수에 관한 사항을 제외시켜달라
무상유지보수 6개월을 1년으로 해달라는 계약 요구 조건 중
계약서의 내용만 요구를 들어주기로 하였습니다.
문제는 나중에 담당자는 자기의 요구사항만 생각한다는 것 입니다.
그리고, 인식을 잘못하고 있는지 고의로 그러는 것인지 모르겠지만은
적어도 화일에 진행사항을 정확하게 메모를 해 두지는 못해도 버젼별로
관리를 하고 받은 편지함의 내용을 년도별월별로 나누어서 보관을 해두면
근거를 찾을때 문제가 발생하지 않을 수 있습니다.
문서를 작성하는 것에는 이유가 있는 것이고 그것이 변하는 것 역시
이유가 있습니다.
그래서, 버전 관리가 필요합니다.
나중에 크게 잃지 않을려면 누구에겐가 제안을하고 공급을 하는 사람이라면 반드시 필요합니다.
계약서와 같이 날인을 하지 않은 부분이라도 관리하고 있는 사람의 논리와
근거는 그렇지 않은 경우를 늘 이기는 경우를 많이 봤습니다.
반대로 참담해지는 경우도 많이 경험했습니다.
많은 사람들이 버저 관리의 노하우를 가지고 있네..
그리고 다들 Document Factory의 경험들이 있는 것 같은 느낌이다..ㅎㅎ