[SI이야기][산출물] 종료보고서 작성하기

<DALL-E로 생성한 이미지>

 

프로젝트는 끝나면 무조건 종료보고를 하게 되어있다. 프로젝트의 규모와 상관없이, 컨설팅, PoC, Pilot, MVP 등 고객과 합의를 해서 일정 기간 무언가를 했다면 다른 건 다 안 해도 종료보고는 하게 되어있다. (착수보고를 안 해도, 중간보고를 안 해도, 종료보고는 한다.)

 

놀랍게도 이 '종료보고'라는 아이는 착수보고, 중간보고와는 완전히 다른 양상을 띤다. 목적도 다르고, 의무감도 다르고, 고객사도 수행사도 접근하는 각도가 놀라운 존재가 이 종료보고다. 아무리 정직한 고객을 만나도, 아무리 정직한 수행사여도 종료보고 앞에서만큼은 무력해지기 마련이다.

 

무슨 이야기인지 하나씩 설명해 보겠다.

---

우선, 종료보고는 양사가 합의하고 한 일에 대해서 마무리하는 보고다. '끝났습니다~'하는 보고. 그렇기 때문에 수행사가 고객 PM에게 하는 보고라고 생각하면 안 된다. 이 보고는, 고객 PM이 보고하고 싶은 윗사람의 끝까지 올라갈 보고서를 만들어주는 일을 하는 거다. 그리고 그 보고서에 들어간 내용의 사실이든 거짓이든 그 모든 것을 수행사의 입으로 하는 것이 그 취지라고 하겠다.

 

종료보고서에 뭘 쓰길래?라는 의아함이 생길 수 있으니 하나하나 설명해 보겠다.

 

우선 큰 목차는 이렇다.

 

Ⅰ. 프로젝트 배경 및 목적

Ⅱ. 프로젝트 수행 내용

Ⅲ. 고도화 방안/로드맵

 

Ⅰ. 프로젝트 배경 및 목적에서는 그냥 전체적인 배경을 설명해 주면 된다. 왜 이 프로젝트를 했는지, 이 프로젝트의 목적이 뭐였는지를 다시 상기하는 것이다. 물론 이 목표를 달성하지 못했는데 적으려고 하면 적지 않은 현타와 자괴감이 들만한 장표지만, 계획대로 착착 진행된 프로젝트라면 아주 수월한 장표다. 그냥 프로젝트 중에 만들었던 자료를 슥슥 붙여 넣으면 끝이니 말이다. 착수보고, 중간보고 적극 활용하면 수월하게 작성할 수 있는 영역이다.

 

Ⅱ. 프로젝트 수행 내용 역시 아주 쉬운 영역이다. 그냥 짧으면 짧은 기간 동안, 길다면 긴 기간 동안 뭘 했는지 결과중심으로 적으면 된다. 고생한 이야기, 여담, 맨땅에 헤딩한 이야기 등 이런 건 다 없애고 결과만 딱딱 짚어내면 된다. 총 몇 개의 과제, 몇 개의 영역이 있었고, 몇 개의 화면을 개발했고, 무엇을 달성했고 등을 설명하면 된다. 그래서 전체적으로는 이 프로젝트를 나는 PM으로서 잘 수행했고, 다 완수했다는 근거자료를 만드는 것이다. (고객사 사인이나 회의록을 넣으라는 뜻이 아니다.)

 

여기까진 아주 쉬운 장표다. 종료보고의 고뇌는 여기에는 하나도 없다. 아마 종료보고를 쉽게 생각하는 사람들은 다 그렇게 생각할 것이다. '무슨 일을 했는지 쓰는 건데 뭐가 어려워?'라고 말이다. 여기서 조금 어려워봤자, 완성된 결과를 직접 시연해야 하는 상황이 있는 정도라고나 할까. 시연이 있으면 리허설도 해야 하고, 적절한 예시도 찾아야 하는... 괴로움이 다소 존재한다. 그래도 정상적으로 개발이 마무리되어 오픈한 시스템이라면 어렵지 않을 것이다.

 

이제 어려운 영역을 이야기해 보겠다. Ⅲ. 고도화 방안/로드맵 영역이다. 이 목차를 잡지도 않고 끝내는 프로젝트도 있으리라 생각한다. 특정 고객은 요구하지 않기도 하기 때문이다. '우리 고객은 그런 거 요구 안 하던데?'라고 생각하거나 '저런 걸 왜 해'라고 생각한다면... 프로젝트 수행 경험이 있는데 '저런 거 해본 적 없는데'라는 생각을 하고 있다면, 유감이라고 말해주고 싶다.

 

이 영역은 구축한 이 시스템의 발전 방향이나 향후 과제를 이야기하는 자리다. 이 목차를 넣어달라고 하는 고객이 있다면 이 프로젝트를 성공시켜서 고도화 프로젝트 예산을 받고 싶은 고객이다. 다음 프로젝트를 해야 하는 걸 당연히 알고 있지만 자기가 계획을 하기 싫고, 할 수도 없는 경우에 요구하는 영역이다. 보통 고객 PM이 다가와서 '우리 이 시스템을 오픈했는데, 고도화해야 하잖아요... 앞으로 계속 확장해야 하는데... 그런 내용을 넣어주시면 좋겠어요'라고 너무 쉽게 말하고 사라진다. 뭘 더 할지, 예산 범위도 없고, 그냥 좋은 말 해달라는 이야기다. 그리고 수행사는 프로젝트를 미친 듯이 달려서 이제 쉬고 싶은 마음만 있는데 그 요구를 듣고 한숨을 쉬면서 다시 컴퓨터 앞에 앉아서 머리를 쥐어짜게 된다.

 

그렇다. 이 목차는 고객사 윗사람이 '그래, 이 시스템 잘 만들었어. 고생했어. 그래서 이제 뭐 할 거야?'라고 물어볼걸 대비해서 작성하는 영역이다. 윗사람이 '오, 자네는 계획이 있군'하면서 돌아갈 수 있도록 말이다. 그리고 보고를 지금 해버려서 다음 보고를 최소화하고 '그래 진행해'라는 긍정적인 시그널을 받아내기 위해 하는 일이다. 구축 결과 보고만 하고 말면, 다음 사업을 준비하고 발주하는 데에 시간이 엄청 많이 들기 때문에 한방에 해결하고 싶은 고객의 욕심이랄까.

 

근데 이게 '정직함'과 어떤 관련이 있냐? 이건 개인적인 생각이지만... 종료보고를 쓰면 대체로 후속 과제로 고객사에서 생각하는 일들, 확장하는 업무들이 상당히 무리라고 생각이 들 때가 많았기 때문이다. 프로젝트를 하면서 무리이기 때문에 요구사항 단계에서 잘라내 버린 것들이 있는데 그걸 후속과제로 넣는 상황이 비일비재하달까... 그런데 그걸 뻔히 알면서 달리 생각나는 게 없고, 새로운 니즈를 발굴할 시간도 없고, 설령 물어봐서 받는다고 해서 그게 더 현실적이라는 보장이 없어서 그 무리한 요건들을 다 넣어버리게 된다. "(이번에는 기술적으로 한계가 있어서 못했지만) 다음 프로젝트에서는 이런 기능을 추가해서 업무를 확장하겠습니다"라고 보고서를 써야 한달까... (실제로 그런 보고서를 써서 그다음 프로젝트에서 주워 담는 상황이 발생하기도 했었다... 안 좋은 기억... 다행히 주워 담았다... 고민할 시간이 있었던 덕분에...)

 

그래서 혹시 종료보고서를 준비하는 사람이 있다면, 이야기해주고 싶은 것은, 굳이 새로운 자료를 만들기 위해 시간을 들이고 고생할 필요가 없다는 것이다.(기존에 만든 거 잘 갖다 붙이면 된다.) 그리고 철수를 위해 해야 하는 마지막 일이니 개인적인 양심의 가책이 느껴지는 말을 해야 할 수도 있지만 철판 깔고 해 버리라는 것이다. (그렇다고 허위보고를 하면 안 된다. 미래의 이야기는 꿈일 수 있지만, 수행한 내용은 거짓이어선 안된다. 네버. 절대. 안됨.)

 

참고로 '종료보고'를 생략하는 경우도 있는데 그래도 '종료보고서'가 생략되진 않는다. 서면으로 고객사에게 주면 고객 PM이 직접 자기가 가공해서 자기 윗사람에게 보고 하는 형태로 진행하기도 한다. 이런 경우는 이 시스템 구축의 기대효과와 향후 과제들을 수행사는 모르게 하고 싶을 경우에 고객 PM이 취하는 형태다. 하지만 대체로, 고객 PM은 자기가 보고하기 싫어서 대신 시킬 겸 + 수행사에게 직접 보고할 기회를 주기 위해서 진행한다고 보면 좋을 것 같다. 이게 왜 수행사에게 기회냐... 물어보신다면... 그건 수행사에서 종료보고를 할 때 수행사 임원들이 초대되는 경우들이 많기 때문이다. 양사 임원들이 만날 기회를 만들기 매우 어려운데, 프로젝트 종료보고만큼 우호적이고 화목한 분위기의 미팅은 구하기 힘들다고나 할까. 그리고 착수할 때 고객사 임원과 종료할 때 임원이 다를 수도 있기 때문에, 그런 정보를 업데이트하고 그 영업 네트워크를 계속 가져가기 위해 중요하기도 하다. 수행사 PM 한 명이 모두 앞에서 종료보고 한번 함으로써 많은 이해관계자들의 숙제를 수월하게 해주는 셈이다. (물론, 모든 종료보고가 양사 임원이 오진 않는다. 그런 레벨의 프로젝트가 그렇다는 뜻이다.)

 

그래도 이랬든 저랬든. 종료보고를 하면 프로젝트는 끝난다! 수고하셨습니다!

 

2024.08.13 23:21