섣부른 해결 대신 치열한 정의를
컨설턴트의 핵심 역량, '해결'보다 중요한 '문제 정의'에 대하여
"배가 아프다"는 고객에게 진통제만 건네고 있지는 않나요?
컨설턴트의 핵심 역량, '해결'보다 중요한 '문제 정의'에 대하여
컨설턴트에게 '문제'란 무엇일까요? 어찌 보면 문제는 컨설턴트가 고객에게 필요한 유일한 이유이기도 합니다. 고객은 자신들이 가진 문제를 해결하기 위해 우리를 부르고, 우리는 그 부름에 응답해 성심성의껏 해결책을 제시합니다.
하지만 여기서 중요한 갈림길이 나타납니다. '무엇을 문제로 볼 것인가'에 대한 시각 차이입니다.
어떤 컨설턴트는 고객이 말하는 불편함 하나하나를 모두 문제로 규정하고, 그것을 해결하는 데 자신의 역할을 한정 짓습니다. 반면, 어떤 컨설턴트는 고객의 입에서 나온 불만이 아니라, 실제로 그 문제를 일으키는 '원인'을 제거하는 것이 자신의 진짜 역할이라고 믿습니다.
저는 컨설턴트라면 마땅히 후자에 자신의 업(業)을 맞춰야 한다고 생각합니다.
의사와 컨설턴트의 공통점
이해를 돕기 위해 병원을 찾은 환자를 떠올려 봅시다. "선생님, 밥만 먹으면 속이 더부룩하고 배가 살살 아파요."라고 호소하는 환자가 있습니다. 이때 의사는 어떻게 반응해야 할까요?
단지 배가 아프다는 증상에 맞춰 소화제나 진통제를 처방해 주는 것으로 의사의 역할이 끝나는 것일까요? 사실 '배가 아프니 통증을 없애는 약을 먹는다'는 해결책은, 굳이 의사가 아니어도 누구나 제안할 수 있는 1차원적인 처방입니다. 환자 스스로도 약국에서 해결할 수 있는 일이죠.
"진정한 의사라면 문진, 촉진, 정밀 검사 등 다양한 수단을 동원해 통증의 근본적인 원인을 찾아낼 것입니다. 단순한 소화불량이 아니라 몸 안에 심각한 질병이 숨어 있을 수도 있고, 혹은 과도한 스트레스가 원인일 수도 있기 때문입니다."
컨설턴트 역시 마찬가지입니다. 고객의 문제를 해결한다는 것은 고객이 나열하는 요구사항(Requirements)을 기계적으로 들어주는 것을 의미하지 않습니다.
고객이 해결하고자 하는 현상, 혹은 도달하고자 하는 목표가 있습니다. '진짜 문제'는 그 맥락 안에 숨어 있습니다. 따라서 '문제 정의 역량(Problem Definition)'은 컨설턴트가 반드시 갖춰야 할 핵심 무기입니다. 이 역량이 부족하면, 남이 정의해 둔 표면적인 문제를 받아 적고 해결책을 조립하는 수동적인 역할에 머무를 수밖에 없습니다.
'무엇(What)'을 정의하는 사람 vs '어떻게(How)'를 구현하는 사람
특히 IT 시스템 구축 프로젝트 현장에서 이 차이는 극명하게 드러납니다. 여기서 컨설턴트와 개발자의 역할은 명확히 구분되어야 합니다.
컨설턴트: 문제를 새롭게 정의하고, 이를 해결하기 위한 최적의 방안(To-be Image)을 설계합니다.
개발자: 설계된 방안을 바탕으로 실제 구현(Implementation) 가능한 기술적 해법을 찾아 실현합니다.
안타깝게도 현장에서는 이 역할 분담을 혼동하는 경우를 종종 목격합니다. 문제 정의 과정을 소홀히 한 채 곧바로 해결책부터 찾으려 들거나, 치열한 고민 없이 과거의 경험을 답습하여 기계적으로 스펙(Spec)을 맞추는 데만 급급한 컨설턴트들이 적지 않습니다.
이는 스스로 컨설턴트라는 직업의 존재 의미를 퇴색시키는 일입니다. 개발자의 영역을 침범하는 것이 아니라, 컨설턴트 본연의 가치를 잃어버리는 것이니까요.
해결은 그 다음입니다
컨설턴트는 숨겨진 문제를 발굴해내는 사람이어야 합니다. 그 문제가 피상적이거나 일차원적이어서는 안 됩니다.
우리가 찾아내야 할 것은 '근본적이고 해결할 가치가 있는 진짜 문제'입니다. 해결책을 만드는 것은, 그 문제를 정확히 정의한 바로 그 다음 단계의 일입니다.
#컨설턴트 #문제해결 #컨설팅 #문제정의 #비즈니스인사이트 #일하는태도 #직장인 #기획자 #PM #IT컨설턴트 #성장
