IT컨설턴트의 위상은 이전보다 많이 떨어진 듯하다. 내가 20대, 30대 일 때는 국내 소개되지 않은 각종 방법론, 솔루션 등을 소개하고 수행했으니, 고객사 입장에서는 당연히 선생님 대접을 해 줬고, 그 당시 SI업체도 사업을 벌여나가고 싶으나 경험이 부족하니 배우자는 열의가 강했다.
그러나 40대가 되어서는 컨설팅 회사나, SI업체나, 고객사나 서로 정보와 지식이 섞이고 인력 이동도 빈번하여 큰 차별성이 점차 사라지게 되었고, IT컨설턴트의 위상도 한때의 영광이 된 듯하다.
그래도 무언가 손에 잡히지 않는 것을 구체화하여 산출물로 내어 놓는다거나, 보이지 않는 리스크를 감지하여 이에 대해 의견을 내는 경우, 새로운 것을 빠르게 흡수하고 이를 고객사에 맞게 소개하는 능력은 IT컨설턴트들이 여전히 강점이 있다고 생각한다.
어쩌면 프로젝트를 바라보는 '눈'이 조금은 달라서 일 수도 있다. 내 일이기도 하지만 유체이탈한 것처럼 한 발자국 떨어져서 객관적인 시각으로 보려는 훈련을 나도 모르게 하고 있는 것이 IT컨설턴트기 때문이다.
프로젝트를 할 때 아웃풋 중 시스템 구축에 직접 활용되는 것 이외는 모두 '산출물'이다.
방법론에 정의된 산출물은 계획서나 결과서를 제외하면, 대부분' 정형화된 산출물'이다.
'비정형 산출물'은 주로 보고와 공유를 위해 사용되기 때문에 '보고서' 범주에 넣어도 된다. 어찌 보면 각종 계획서도 프로젝트 참여자들에게 공유되어야 하지만, 결국 '이번 단계에서는 이런 식으로 일을 하겠습니다'의미가 있기 때문에 보고가 무조건 선행되어야 하는 의미에서 보고서에 들어간다.
사람들은 이런 보고서 작업을 상당히 힘들어한다.
첫 번째 이유는 작성이 어렵기 때문이고, 두 번째 이유는 보고와 공유가 두렵기 때문이다.
지금까지 오랜 세월 IT컨설턴트를 하면서 이러한 보고서 작성을 잘하는 사람은 그리 많이 만나보지 못했다. 그렇다고 못하는 건 아니고 평타 정도이다. 기존에 이미 봐 왔던 문서의 수준 정도였으며, 문서의 아름다움은 둘째 문제고 담고 있는 내용도 큰 예리함을 담고 있지 못했다.
IT컨설턴트 한 명의 힘으로 특정 보고서를 날카롭고 예리하게 만들어 내는 것 자체가 어렵긴 하나 간혹 잘 만들어진 문서를 만나면 작성자를 만나고 싶어 진다.
그러면 보고서 작성이 왜 어려울까,
당연히 주제가 어려워서다. 누구도 해결하기 어려운 주제다 보니 보고와 공유가 필요한 것이고, 그것을 해당 컨설턴트가 오너십을 가지고 작성해야 한다. 답이 없는 문제에 답을 내어놓아야 하니 어려운 건 당연하다.
때로는 주제가 명확하지 않을 때가 있다. 이럴 때는 더 난감하다. 뭘 하라고 하는지 감도 오지 않는데 일단 다음 주에 보자고 한다.
사실 이런 요청은 괴롭히려고 하는 것이 아니라 정말 고객도 몰라서 그렇다. 말로 설명하기는 애매한데 그렇다고 그냥 넘어가기에 찜찜한 느낌은 있고, 그럴 때 나 대신 고민 좀 해줬으면 하는 의미를 담고 있다.
이유야 어찌 되었건, 보고서를 맡은 사람은 최선을 다해 작성을 한다.
여기서 갖춰야 할 소양은 '끊임없는 고민'이다.
많은 경우 보고서의 내용이 작성자가 알고 있는 것과 깊이가 다르지 않다. 내가 알고 있는 것이 A부터 Z까지면 이 내용을 고스란히 보고서에 담는다.
이 수준으로 작성해서 보고든 공유를 하게 되면, 이를 보는 사람들은 다른 역할, 다른 경험을 가지고 있기 때문에, 질문을 하게 된다.
보고서 내용이 내가 아는 것의 전부인데 어떻게 질문에 응대를 하겠는가.
그래서 보고서 1장을 작성하기 위해서는 내가 추가로 고민하고 알아낸 정보가 10장이 더 있어야 한다.
다각도로 조사하고, 탐문하고, 분석을 한 다음 내가 이해한 것을 토대로 '전달을 쉽게 할 내용'으로 다시 요약정리한 내용이 보고서에 담겨야 한다.
조사하는 과정에서 많은 back data를 보면서 다양한 사례 연구를 할 수 있고 이는 보고서 설명시 예시로 활용 가능하다.
탐문하는 과정에서 사람들의 의견을 들어보면 현실적으로 도움이 될 만한 토픽들을 뽑아낼 수 있다.
분석을 하는 과정에서는 나만의 인사이트를 통해 사람들이 미쳐 생각하지 못한 해결법을 제시할 수도 있다.
현실에서는 어떤 숙제가 떨어지면, 과거 어디선가 작성된 비슷한 문서를 가지고 와서 조금 손을 보는 경우가 많다.
다른 사람이 만든 보고서를 받아와서 그 틀 안에 내가 알고 있는 내용을 고스란히 적게 되면 있으나 마나 한 형식적인 문서가 된다.
주로 하는 또 하나의 잘못된 습성은 자신이 이해하지 못한 자료를 문서에 집어넣는 것이다.
여러 사람에게 자료를 받아 특정 어젠다를 구성할 수 있는데 이때 각 전문가들이 알아서 잘 작성했겠거니 하고 의심 없이 받는 경우다.
보고서를 작성하는 사람이라면, 그 내용을 반드시 '이해'해야 한다. 아무리 전문가가 작성했다고 해도 이해가지 않으면 물어보고 수정 보완해서 '나부터 납득'하고 그 내용을 포함해야 보고서의 완결성을 가질 수 있다.
내가 문서 만들 때 버릇이 있다.
매번 아예 빈 슬라이드에서 시작한다.
프로젝트할 때마다 매번 등장하는 주제라 하더라도 새로 만든다.
이번 프로젝트만의 특징이 있기 때문이며, 참여하는 사람이 다르기 때문이다.
어젠다를 구상하고 나면, 대부분 시간은 '바닥을 긁는 작업'부터 한다.
최대한 바닥까지 내려가서 훑는다. 이 대상이 어떨 때는 log가 될 때도 있고, 어떨 때는 수많은 다른 산출물이 될 수도 있다. 어딘가 쌓여 있는 프로젝트의 데이터들을 모아 분석을 하고 의미 있는 데이터를 찾아낸다. 그 후 그 영역을 한번 더 집중해서 파고드는데 이때는 주변 연관성도 함께 본다.
시작은 '한번 캐볼까'였으나 이렇게 찾아낸 결과물은 굴비 엮듯이 시사점이 줄줄 나와서 보고서에 다 담기에도 많을 때도 있다.
아무래도 보고서이므로 가독성을 높이기 위한 형태로 작성을 하되, 상세 내용은 다시 별첨자료로 정리한다.
이렇게 작업을 하면, 앞서 언급한 보고서 작성이 어려운 두 번째 이유인 보고와 공유에 대한 두려움도 사라진다.
설명할 때 당사자도 몰랐던 상당히 구체적인 사례, 예외사항, 특별한 고려사항이 툭툭 자연스럽게 나오므로 자료의 신뢰성도 확보되고 집중도 시킬 수 있다. 이미 많은 고민을 했기 때문에 어지간한 질문에 답을 할 수 있을뿐더러, 오히려 내가 추가 질의를 하여 여러 팀들 간 서로 몰랐던 연관 작업의 문제들을 알려줄 수도 있다.
남들보다 시간이 배로 걸리는 작업 같아 보이나, 나의 문서 만드는 속도는 오히려 훨씬 빠르다. 아마도 신입시절부터 단련시켜온 작업 방식이기도 하고, 무엇보다 이 방식은 스스로 얻는 만족감과 성취감이 더 크게 된다. 무엇보다 이 과정은 마치 예술작품 하나를 완성하는 것 마냥 상당히 즐겁다.
이미 오래전부터 프로젝트 내 산출물은 보안 문제로 가지고 나올 수 없다. 하지만 가끔 과거에 고심해서 쓴 산출물 몇 가지가 생각날 때가 있다. 이런 문서들은 모두 내 자식 같아서 아주 가끔은 보고 싶어 진다.
