[SI이야기][산출물] 중간보고서 작성하기

중간보고는 말 그대로 프로젝트 중간에 하는 보고다.

 

프로젝트에 따라 중간보고가 없을 수도 있고, 중간보고가 1회 이상일 수도 있다. 그건 대체로 제안하는 시점에 수행사가 일정/마일스톤을 수립할 때 넣는 순간 정해진다고 볼 수 있다. 참고로 나는 일단 그런 보고라는 걸 다 끔찍하게 생각하기 때문에 1개 이상을 넣지 않는다. 착수보고, 중간보고 1번, 그리고 결과보고, 끝! 그 와중에 프로젝트 기간이 너무 짧으면 그마저도 안하는 편이다. 가장 짧게 해 본 프로젝트(정식 계약을 해서 수행한 경우)는 2개월이었는데 그건 착수보고, 종료보고 두 번이었고 모두 다 서면으로 대체했다. 길게 했던 프로젝트는 착수보고와 종료보고만 하기도 했다. 고객이 특별히 중간보고를 언급하지 않으면 안 해버린다. ^^

 

중간보고를 수행사 측에서 먼저 넣을 필요가 없는 이유에 대해서 이야기를 먼저 해보겠다. (aka. 중간보고를 안 해도 되는 이유) 우선, 중간보고는 프로젝트가 너무 길어서 고객사 윗분들의 관심이 사라지는 게 걱정이 된다거나, 지극히 관심이 많은 고객사 윗분들의 호기심을 해결해 주기 위해서 하는 편이다. 그래서 프로젝트가 너무 짧다면 중간보고를 안 해도 되는 것이다. 착수하고 프로젝트하다 보면 바로 종료보고를 해야 하는 시간이 다가온달까.

 

그리고 중간보고를 제안할 때 제안서에 쓰면 고객은 '제안했던 대로 중간보고 하세요'라고 요구한다. 제안서는 곧 계약서에 준하기 때문에, 중간보고를 고객이 챙기지 않아도 내가 해야 한다고나 할까. 그 형태가 보고인지 서면인지는 달라질 수 있지만, 중간보고서라는 걸 써야 하는 문제는 발생한다. 그리고 그건 언제나 일이고, 고객사 검수 대상에 들어가는 산출물이 된다. 검수 대상이 된다는 건, 신경 쓸 일이 늘어난다는 뜻이다.

 

하지만, 수행사가 제안서에 '중간보고'라는 마일스톤을 넣지 않았고 고객사에서 해야 한다고 (협상 시점에) 이야기하지 않았다면, 정식 산출물에 중간보고서가 들어가는 일이 없다. (얼마나 아름다운 일인가!?) 그러면 수행사는 착수 보고 이후에는 합의한 주/월 정기보고를 수행하고 마지막에 종료보고를 하면 되는 것이다. (혹시 궁금해할까 봐 이야기하면, 착수/종료 보고가 없는 경우는 계약을 하는 사업을 수행하는 거라면 거의 없다고 보면 된다. 하지만 무상/PoC라면 착수보고가 없을 수는 있다. 종료 보고는 언제나 있다.)

 

그럼에도 불구하고 중간보고를 하게 되는 경우가 있는데, 그건 고객사에서 갑자기 요구하는 경우다. 수행사인 나는 제안한 적이 없고, 협상할 때 중간보고를 해야 한다고 고객사에서 이야기한 적도 없는데! 고객이 어느 날 성큼성큼 걸어오면서 중간보고를 해달라고 하는 경우가 있다는 것이다. 그러면 여태 꾸준히 이 블로그에서 글을 읽은 사람이라면 "협상 때 이야기가 없었으니 거절하면 되는 거지!"라고 생각할 수 있는데, 그렇지 않다. '아.. 올 것이 왔구나..'라고 생각하며 "네."라고 대답해야 한다.

 

왜냐? 그냥 고객사 프로젝트 팀 누군가가 보고를 하고 싶거나, 고객사 윗 분 누군가가 보고하라고 했기 때문에 하게 되는 것이기 때문이다. 여기서 성실한 고객이거나 욕심 많은 고객은 필요한 내용(자료)만 주면 자기가 하겠다고 하는 경우도 있지만, 대체로는 '보고 해 줘. 보고서 초안 나오면 공유해 주고.' 하면서 사라진다. 

 

안타깝게도. 그런 경우에 해야 하는 게 수행사의 팔자다.

 

그렇다고 오해는 말자. 고객이 아무 때나 와서 '보고 해 줘'라고 하지 않는다. 엄연히 일정 계획을 갖고 일해왔기 때문에 '언제', '왜', '무엇'을 보고할지는 대체로 분명하다. 새로운 스토리라인이 있는 경우도 거의 없다. 착수보고와 마찬가지로 대체로 정해진 스토리라인을 구성해서 보고하는 편이다. 그냥 '어차피 했을 거야...'라고 생각하면서 여태 작성해 온 산출물을 주섬주섬 꺼내서 정리하기 시작하면 된다.

---

중간보고가 뭐길래?

 

중간보고는 SI프로젝트에서는 분석 단계와 설계 단계가 모두 끝났을 때 진행하게 되어있다. 그렇기 때문에 중간보고의 내용은 생각보다 간단하다. 분석 단계와 설계 단계에서 진행했던 내용을 요약해서 보고하고 남은 일정에 대한 보고를 진행하면 된다. 아주 간단!

 

목차를 잡는다면 이런 느낌일 것 같다.

 

Ⅰ. 프로젝트 진행 경과

Ⅱ. (분석 단계 내용)

Ⅲ. (설계 단계 내용)

Ⅳ. 향후 추진 일정

 

Ⅰ 프로젝트 진행 경과는 전체 일정표를 넣고 현재 어디까지 진행을 했는지를 명시해 주는 게 포인트다. '분석/설계 단계를 끝냈습니다'가 그림으로 잘 보이면 된다. 분석/설계에 진행했던 타스크를 쭉 정리해 주면 뒤에 설명할 내용에 대한 간단한 마중 장표가 되기도 한다. '아, 분석/설계 단계에는 이런 일들을 했구나. 뒤에 그 내용을 설명하겠구나.'라는 설명이 된다고나 할까.

 

Ⅱ 부터 목차 제목을 괄호 안에 넣은 이유는 간단하다. 실제 목차에 '분석 결과'라는 식으로 쓰지 않기 때문이다. 만약 분석이 은행 업무에 대한 내용이라면 'OO업무 현황' 이라던가, 'OO업무 개선 방안' 등 그 업무에 맞게 써야 한다. 그 안에 들어가는 내용은 분석 단계에 수행했던 내용의 요약이 들어가면 된다. 시스템 사용량이라면 사용량 통계, 사용 현황이라면 그런 내용, 고객 인터뷰 내용이라면 그 요약 내용과 그 시사점이 나오는 형태인 거다.

 

설계도 마찬가지로 그 시사점을 반영해서 설계된 시스템의 내용을 그려주면 된다. 설계한 대상이 하드웨어, 소프트웨어, 데이터 등 뭐든 해당되는 내용은 잘 정리해서 넣어주면 된다. 단, 보고를 받는 대상이 현업이라면 IT중심의 내용은 없어도 되고 비즈니스 중심의 내용을 넣어야 하고, 보고를 받는 대상이 IT라면 현업의 이야기를 넣고 IT 이야기도 충실히 넣어야 한다. 대체로 금융사 IT는 현업이 어떤 일을 하는지, 어떤 문제가 있는지를 잘 모르기 때문에 대체로 큰 교육/이해의 계기로 삼는 편이다.(가끔은 현업끼리도 교육의 계기로 삼기도 한다.) 그리고 놀랍게도 현업의 이야기는 설계 결과의 무논리를 받침 해주기도 한다. '현업이 해달래요'만큼 막강한 논리가 없다고나 할까. IT는 납득이 안되더라도 결국 자기가 이해하지 못하는 세상의 이야기를 그냥 받아들인다. ^^

 

Ⅳ 는 향후 추진 일정을 다시 넣어준다. 대신 Ⅰ과의 차이는 Ⅰ 에서 넣었던 예쁜 일정 그림을 넣는 게 아니라 남은 일에 대한 구체적인 이야기를 하는 게 포인트다. 보고 받는 사람들에게 '분석/설계에 나왔던 내용은 앞으로 개발/테스트 기간을 거쳐 언제 오픈하는 일정으로 진행될 예정입니다'를 알 수 있게 하는 것이다. 당연한 이야기를 하는 것 같이 보일 수 있지만, 긴 프로젝트를 하는 경우는 일정이 변경이 되는 경우도 많아서 새로 변경된 일정을 공유하는 의미도 있다. 그리고 남은 단계의 세부 마일스톤을 알려줌으로써 '개발된 내용을 테스트를 해볼 수 있는 시점은 언제입니다'를 공유할 수 있는 데에 큰 의의가 있다. 그러면 윗분들은 '그럼 그때 다시 보러 오면 되겠군.'하고 돌아간다.

---

중간보고는 착수보고와 마찬가지로 기대효과를 넣지 않는다. 중간보고의 중요성은 이 프로젝트가 제대로 굴러가고 있다는 것을 모두에게 알려주는 것이라고 봐야 한다. 그리고 혹시나 분석/설계 단계에 진행한 내용들이 윗사람들의 생각과 너무 달라서 개발을 잘못하는 위험을 사전에 방지하기 위함이기도 하다. 보고를 받으러 오는 사람들이 '그렇군요. 알았어요. 안녕' 하고 사라지진 않는다. 자기 의견을 넣기도 하고, 자기에게 중요한 게 뭔지 언급도 하고, 분석/설계에 없는 기능을 추가해 달라고 하기도 한다. (여기서 협상 회의록을 꺼내드는 일은 하면 안 된다. 이야기는 듣되, 무조건 수용을 할 필요도 없다. 그냥 듣고 '검토하겠다'라는 수준으로 대답을 하면 된다. 방어적으로 들리지 않게 말투를 주의하는 게 포인트다. 이런 말투에 귀신같은 사람들은 방어적인 말투를 한 방에 눈치를 챈다. 그런 PM으로 비치면 아주 귀찮아진다. 신중한 말투로, 충분히 검토해서 반영할 것 같은, 신뢰를 주는 멘트를 해야 한다. 그렇다고 무조건적인 수용으로 보여서도 안된다. 물론, 아주 단순한 거라면 '반영하겠습니다'라고 대답하면 된다 ^^)

 

중간보고는 사실 기반으로 정리해서 보고하면 된다. 아름답게 포장할 것도 없다. 프로젝트가 지연이 있고, 이슈도 많다면 어디까지 보고할 지에 대해서 고객 PM과 협의가 필요할 수는 있다. 하지만 여기서 중요한 건, 이슈가 되는 내용이 드러나지 않게 보고하는 것이지, 거짓말을 하는 것은 아니다. 이슈를 숨기면서 허위보고를 하라는 것도 아니다, 어떤 문제가 있다면(지연은 티가 나게 되어있다) 이야기하고 챙기고 있다고 대답해도 충분할 수가 있다. 참고로 지연이 심각해서 허위보고니 수습이니 걱정해야 하는 수준이면 고객사에서 중간보고 하라고 하지도 않는다. 그렇게까지 용감한 고객사는 아직 만나보지 못했다. 대체로 그런 경우 고객은 중간보고를 미룬다. ^^

 

2024.04.02 01:21