누구나 전략 기획 고수가 될 수 있다 - 문제 해결 프로세스 #2

자, 어떠세요, 여러분들이 항상 하시는 업무(또는 과제)들이 모두 ‘문제’와 동일하다고 생각되지 않으신가요? 앞선 예시에서는 현재 상태와 목표 상태를 정량적 수치로만 들었지만, 꼭 정량적으로 나오지 않아도 관계없습니다. 가급적 정량적으로 하는 것이 여러모로 명확하기는 하겠지만요. 

예를 들어, 여러분 회사가 현재는 로컬(국내) 시장에서만 제품•서비스를 판매하고 있는데, 해외 시장으로 확대하고자 한다면, 이 또한 현재와 목표(Should be)간의 GAP이 존재하게 되므로 ‘문제’로 인식할 수 있습니다. 그러나, 실제로 회사에서는 ‘해외 시장 개척 전략’등의 과제명으로 표현하기 때문에 ‘문제 해결’과 연결을 시키지 못한 게 아닌가 생각됩니다.

모든 문제(과제)는 목표상태(Should be)에 어떻게 도달할 것이냐에 대한 물음이며, 그 물음에 대한 답변(전략, 전술 등)을 찾는 것이 바로 ‘문제 해결’이라고 생각하시면 됩니다. 사실 회사 내 업무가 아니더라도 개개인에게도 이러한 문제는 존재합니다. 예를 들어, 여자 친구를 만들고 싶거나 결혼을 하고 싶은데 아직 여자친구가 없다면, 어떻게 해야 여자친구를 사귀고 결혼할 수 있을까에 대한 고민과 자기만의 해결책을 찾는 행위도 같은 문제 해결이라는 것입니다. 

여러분들도 아시겠지만, 이에 대한 솔루션은 정말로 다양합니다. 정답이 있는 건 아니라는 것입니다. 각자의 상황, 주변 환경 등 수없이 많은 인자를 검토하여 자신에게 혹은 문제에 가장 최적의 솔루션을 찾아가야 하는 것이죠. 

① 문제 정의, 상황을 분석하여 문제와 과제(목표 상태)를 명확히 정의해야 합니다. 

이 부분에 대해서는 앞에서 충분히 보충 설명을 해서 그냥 넘어 가겠습니다. 

② 문제의 구조화, 문제를 이슈로 세분하여 분석 구조를 설계합니다. 일반적으로 '로직트리'를 활용합니다.

이슈는 문제를 해결하기 위해 의사결정을 해야 하는 질문입니다. 그래서, 가능한 Yes 혹은 No라고 분명히 대답할 수 있도록 정의해야 합니다. 근본 원인을 밝히기 위해서 가능한 세부적인 단계까지 로직트리를 벌려 나가야 그 해결책을 ‘문제 뒤집기’식(취약 ↔ 강화)이 아닌 구체적인 ‘Action’ 형태로 도출할 수 있습니다.

③ 가설 수립, 개별 이슈에 대한 잠정적인 해결안을 가정해 봅니다.

가설 수립은 새로운 시각과 사실, 경험, 직관 등 여러 통합적인 역량을 바탕으로 수립하는 것이 좋으므로, 가급적 여러 사람이 참여하는 것이 좋습니다. 그리고, 가설은 반드시 검증할 수 있어야 합니다. 또한, 전 단계에서 도출한 이슈에 대한 답변이 이루어져야 합니다. 

l 작업 Framework 또는 자료수집 관리대장 예시

예시와 같이 작성하여, 이를 관리대장으로 계속 사용합니다. 각 담당자가 작업 완료 여부와 최종 산출물 자료명 등을 다른 이들도 한눈에 알 수 있도록 관리합니다. 

여기에서 필자가 가장 중요하게 생각하는 항목이 바로 ‘자료 소스’ 입니다. 실제 자료를 수집하는 방법에 해당되는데요. 여러 가지 방식이 있지만 가장 많이 사용하는 방법이 ‘설문조사’, ‘인터뷰’, ‘자료요청’, ‘자료검색(인터넷)’, ‘자료구매’, ‘현장조사’ 등입니다. 간혹, 우리는 흔히 쉬운 방법을 선택하려는 경향이 많은데요. 가장 최적의 방법을 선택하는 것이 중요합니다. 

하나를 검증하기 위해서 여러 가지 방식을 동시에 수행하기도 합니다. 예를 들어, 인터뷰의 경우 사실과 다른 경우가 많은데요. 이런 경우, 자료 요청이나 자료 검색 등을 통해 가급적 사실 여부를 확인하거나 증빙을 함께 수집하는 것이 좋습니다. 

두 번째는 ‘작업 계획서(일정표)’입니다. 이 작업의 경우, 여러 사람이 작업하고 또 윗분들에게 정기적으로 보고해야 하는 경우에 반드시 작성해야 합니다. 그러나, 한두 명이 하는 작업일 경우에는 저는 개인적으로 이 계획서를 작성하는 것을 권하지는 않습니다. 이미 앞에서 자료수집 관리대장에 담당자와 기한이 나와 있기므로, 그 정도로 충분하다고 생각합니다. 이 작업계획서는 우리가 평소에도 많이 작성해 보셨을 것 같아 상세한 예시는 생략하겠습니다. 

가급적 주 단위로 주요 Task 별로 일정을 막대 그래프로 해당하는 주 만큼 표시하게 되면 한 눈에 일정을 잘 확인할 수 있을 겁니다.

인터뷰 질문지가 작성이 완료되면 인터뷰 날짜까지 기다리지 말고, 인터뷰 대상(예시 상 품질팀)에 미리 전달하여 사전에 질문 내용을 충분히 숙지해 올 수 있도록 해야 합니다. 그리고, 필요한 경우, 증빙자료를 제출해 줄 것을 사전에 공지해야 합니다. 그리고 중요한 것은 인터뷰하고 난 후입니다. 인터뷰가 끝나면 반드시 그 날 인터뷰 결과서를 작성하는 것이 좋습니다. 필요한 경우, 사전에 인터뷰 대상자의 양해를 얻어 인터뷰를 녹음하는 것도 좋은 방법이겠습니다. 

앞서 몇 번 언급하였지만, 인터뷰를 뒷받침할 수 있는 자료를 함께 받는 것도 중요합니다. 즉, 인터뷰 시에 인터뷰 대상자가 하는 말 중에 사실이 아닌 추정이나 자기 생각이 들어가 있는지를 잘 구분하여야 합니다. 예를 들어, “사실 저희에게 보안 가이드가 있지만, 대부분 개발자가 보안 가이드에 대해 알지 못할 겁니다. 저희가 한 번도 교육을 한 적이 없었으니까요.”라고 인터뷰했지만, 시간이 허락하는 한도 내에서 이게 사실 인지를 확인해 봐야 합니다. 

보안 가이드가 있다고 했으니, 실체가 있는지 자료를 요청해야 합니다. 그리고, 실제로 개발자들이 보안 가이드에 대해 모르는지 설문결과를 확인해 봐야 한다는 것이죠. 즉, Cross 체크를 할 필요가 있다는 것입니다. 그러나, 실제 현장에서 인터뷰에 너무 의존하다 보면 실제가 아닌 데이터로 분석해서 잘못된 솔루션을 제시하는 경우를 많이 접하게 됩니다. 이 부분은 항상 주의해야 합니다. 

오늘은 ‘문제’에 대한 보충설명과 문제 해결 프로세스 중 두 번째 단계인 ‘자료 수집’에 대해 설명을 드렸습니다. 개인의 일이나 회사 일에서 우리가 항상 접하는 것이 ‘문제’입니다. 물론, 과제라고 생각해도 무방합니다. 여기에서 제가 소개해 드린 절차의 주의사항들을 잘 숙지하셔서 실제로 여러분 업무에 적용해 보시기를 권합니다.

백 번 읽는 것보다는 실제 여러분 업무에 한 번 적용해 보는 것이 훨씬 기억에 남고 도움이 됩니다. 다음 편에서는 이어서 ‘분석’, ‘솔루션 도출’ 단계에 대해 설명해 드리겠습니다.