보고서를 쓰는 일은 언제나 험난하다.
직장인이라면 누구나 보고서의 작성과 책임자에 대한 보고가 매우 큰 부담으로 작용하는 업무 중 하나일 것이다. 더군다나 빈번하게 보고서를 작성하는 담당자가 아닌 경우에는 익숙지 않은 절차에 많은 시행착오를 겪기도 한다.
가끔씩 보고서를 검토하다 보면 형식이나 내용이 너무나 본인 중심으로 전개하곤 해서 그 맥락에 놀라는 경우가 많다. 특히 기술적인 업무보고서의 경우 더욱더 그런 상황을 많이 접하게 된다.
심지어 같은 본부 예하 팀으로써 비슷한 업무를 담당하는 경우에도 업무에 따라서 어려움과 난해함을 느끼곤 한다.
나의 경우 IT를 전공하고 소프트웨어 개발팀에서 오랫동안 근무했지만, 네트워크에서 다루는 업무는 낯선 경우가 많아 별도의 기술 매뉴얼을 참고해야만 하는 경우도 있다. 이런 상황이라면 전문용어가 다수 포함되는 보고서를 접했을 때 상위 관리직의 경영진이라면 어떤 느낌을 받게 될지 두말할 필요도 없을 것이다.
그렇다면 보고서를 잘 만들려면 어떻게 해야 할까.
어떤 부분에 주안점을 두어야 할까.
많은 직장인들이 고민하고 있는 것이 바로 이 부분이지 싶다.
일반적으로 우리가 알고 있는 잘 쓴 보고서는 그 목적과 근거가 명확하고, 구조적이면서 논리적이되 이왕이면 가독성도 우수하면 더더욱 좋다고 한다. 사실상 이런 정의 자체가 해석의 여지가 커서 단정 짓기가 쉽지 않다.
이것을 다르게 쉽게 풀어서 표현하면 무엇일까?
결국은 보고를 받는 의사결정권자가 이해하기 쉽게 그의 관점에서 작성하는 것이 가장 중요하다. 이 말은 어쩌면 뚜렷한 정답이 없다는 말과도 맞먹을 수 있다.
두 번째는 질문이 불필요하도록 충분히 정보를 전달하는 것이다. 이 또한 보고서를 보는 입장에 따라 달라질 수 있다.
하지만 이 두 가지가 보장만 된다면 충분히 훌륭한 보고서가 될 수 있다. 그런데 실상은 말처럼 쉬운 것이 아니다.
보고서라는 제한된 공간과 보고 과정에서의 임기응변 등 많은 준비가 필요하고, 자칫 그 과정에서의 한순간의 실수로 그동안의 노력이 물거품이 될 수도 있기 때문이다.
혹자는 대면 보고 시 그 시간대 까지도 고려를 해서 집중력이 떨어지는 시간대를 선호하기도 한다.
하지만 서면 보고를 선호하는 의사결정권자 라면 앞서 언급한 두 가지만 만족이 된다면 충분한 효과를 누릴 수 있으니 참고할 만하다.
현재 진행 중인 사업 추진 건은 사업비가 많지 않아 보고서 위주로 진행이 되었다.
따라서 사업에 대한 이해와 보고서의 내용이 매우 중요한 상황이었지만 적어도 공식적인 대면 보고의 부담감은 없었다.
보고서 작성을 자처한 담당 팀원의 보고서를 검토했을 때 깔끔하고 일목요연한 느낌을 받았다.
그동안은 주로 기술엔지니어와 함께 업무를 진행한 나로서는 이런 보고서가 작성되리라고는 생각조차 하기 어려웠다. 그리고 보니 팀 변경 이후 팀원들의 인력구성이 기술엔지니어만이 아닌 소위 문과 출신의 인력이 있다는 것을 새삼 알게 되었다.
"PoC(Proof of Concept:실제로 기대한 성능·효과·기능이 나오는지를 확인하는 과정)를 통해 업무 사용자들이 만족하고 우리 조직에 꼭 필요하다는 의견이 지배적인 만큼 사업 진행이 필요하다고 어필했습니다.
무엇보다 업무 특성상 빠른 시간에 접목을 시켜야 하는 특수성이 있다는 부분도 강조를 했습니다."
신속한 솔루션 도입이 필요하니 지루한 재보고 요구를 하지 말라는 취지로 보고서를 작성한 것이라는 점을 강조하며 우쭐대는 듯 얘기했다.
그도 그럴 것이 어쩌면 현재 시점에서 가장 좋은 방법일 수 있고 나 또한 효과적인 전략이라고 생각되었다.
