brunch

You can make anything
by writing

C.S.Lewis

부하직원은 결코 한 번에 원하는 것을 가져올 수 없다

옛날 중국 황제가 유명한 화가에게 자신이 아끼는 고양이를 그려달라는 주문을 했다. 7년이 지나도록 그림이 완성되지 않자 황제는 화가를 불러들여 크게 화를 냈고 화가는 황제 앞에서 바로 고양이를 그려냈다. 그림이 마음에 든 황제가 그림 값을 묻자 화가는 엄청난 금액을 요구했다. 단숨에 그린 그림에 높은 값을 부른 이유를 묻는 황제에게 화가가 대답했다. “폐하, 저는 지금까지 7년 동안 고양이를 그려왔습니다.”


화가는 황제가 지시한 날부터 7년 동안 고양이를 그려왔지만, 부하직원은 검토자가 보고서 작성을 지시한 날부터 지금까지 한 장도 쓰지 않았거나, 썼다 할지라도 전혀 다른 내용을 써놨을 것이 분명하다. 만약 데드라인이 없다면 전혀 보고서를 작성하지 않았을 것이고, 데드라인이 있다면 6년과 360일을 다른 일로 보내다가 데드라인이 있기 며칠 전에나 겨우 보고서에 쓸 자료를 찾을 것이다.


이런 상황은 검토자에게 검토에 필요한 시간을 뺏는다. 일주일 후에 대표이사에게 보고할 보고서 작성을 부하직원에게 지시했는데 보고일 바로 전날에나 돼서야 초안을 들고 오면 기가 막힌다. 그나마 오탈자나 잡고 근거 한두 개만 바꾸는 정도면 안심이지만 전혀 다른 주제를 적어오거나 문제에 대한 접근 자체가 잘못되거나 엉뚱한 결론을 내려오면 시간은 없고 당장 뭘 어찌할 수도 없는 절망적인 상황에 빠진다. 이쯤이면 방법이 없다. 같이 밤새면서 서너 시간마다 리뷰하는 수밖에. 그런데 이런 일을 사전에 막을 수는 없을까?


보통 검토자는 작성자에게 상위 조직에 언제 보고해야 하는지를 얘기한다. 그러면 작성자는 그 상위 조직 보고일을 데드라인으로 생각하기 때문에 검토자 검토일을 데드라인으로 고려하지 않는다. 따라서 최종 보고 데드라인을 알려주지 않고 최종 검토 데드라인만 알려주는 방법이 있다. 만약 작성자가 최종 보고일을 알고 있다면 중간 검토일을 미리 정한다. 최종 보고일이 7일 후라면 중간 검토일은 2일, 4일, 6일이 된다. 


여기서 중요한 것이 있다. 중간 검토 때에 문서의 모든 내용을 작성토록 해서 한 번에 검토하는데 이것은 잘못된 방법이다. 3번의 검토 기회가 있다면 첫 번째 검토 때는 보고서 작성 시나리오만을 검토해야 한다. 보고서를 어떤 논리로 작성할 것인지, 보고서의 전개는 어떻게 할 것인지, 분량을 얼마로 할 것인지, 누가 어떤 부분을 쓸 것인지, 언제까지 얼마큼 쓸 것인지 등을 먼저 검토한다. 두 번째 검토 때는 보고서의 제목에서부터 결론을 내리기 전까지만 작성해서 검토하는 것이 효율적이다. 만약 앞의 논리가 잘못되어 바꾼다면 결론까지 작성한 노력이 쓸모없게 되고 시간만 뺏긴 결과를 낳기 때문이다. 마지막 검토 때는 전체 내용을 하나씩 확인하고 결론에 이른 과정을 되짚어보는 것이 좋다. 서식이나 오탈자도 이때 확인한다.


김철수 씀. 2016.12.3

vitaminq42@gmail.com


<팀장을 위한 보고서 검토 기술> 

http://www.yes24.com/24/Goods/67720961?Acode=101


매거진의 이전글 보고서 작성자는 결코 오탈자를 발견할 수 없다.
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari