문제를 정확히 파악하는 것은 해결 과정의 첫 단계이자 가장 중요한 요소다. 이는 문제 해결사가 갖춰야 할 기본 소양이지만, 다른 기본기와 마찬가지로 때때로 소홀히 되기 쉽다. 특히 개발자들은 코딩을 할 때면 문제 파악에 주의를 기울이지만, 다른 영역의 문제에 직면할 때는 그러지 못하는 경우가 많다. 나 역시 이런 실수를 범하곤 한다. 최근 몇 달간 문제 상황을 "정확하게" 인식하는 것의 중요성을 재확인하는 경험을 여러 번 했는데, 그중 한 가지를 공유하고자 한다.
나는 동료와 정기적으로 1:1 미팅을 진행한다. 최근 한 미팅에서 동료가 요즘 팀 전반적으로 능동성이 떨어지는 것 같아 개선 방안이 고민이라고 말했다. 이 얘기를 듣고 나는 먼저 각 팀원의 능동성에 대해 어떻게 느끼는지, 구체적으로 어떤 사례들이 있었는지 함께 이야기를 나눠보았다.
구체적인 사례들을 하나씩 되짚어가며 회고한 결과, 우리는 전혀 다른 결론에 도달했다. 팀 전반의 문제가 아니라 특정 팀원의 능동성만이 문제였던 것이다. 더욱이, 대부분의 팀원은 처음 생각과는 달리 상당히 능동적인 모습을 보이고 있었다. 결국, 능동성이 부족한 한 팀원과만 깊이 있는 대화를 나누면 되는, 오히려 희망적인 상황임을 알게 되었다.
만약 문제 상황을 정확히 파악하지 않았다면, 팀의 능동성 전반을 개선하기 위해 운영 방식을 변경하는 등 불필요하거나 비효율적인 방향으로 접근했을 것이다. 이처럼 문제 상황을 어떻게 인식하느냐에 따라 해결 방향이 아주 달라질 수 있다. 더 간단한 해결책을 두고 복잡한 방법을 시도하거나, 심지어는 실제 문제와 무관한 것을 해결하려 들 수도 있다.
엉뚱한 문제를 해결하려는 시도는 들으면 우스울 수 있지만, 실제로는 정도의 차이만 있을 뿐 흔히 일어나는 일이다. 나 역시 방심하면 같은 실수를 범하곤 한다. 그래서 나는 문제 해결에 착수하기 전에 최대한 실제 사례들을 수집하려고 노력한다. 여기서 중요한 것은 막연한 느낌이나 추상적인 판단이 아닌, 구체적인 사실을 파악하는 것이다. 예를 들어, "요즘 서비스 배포가 느린 것 같다"는 느낌보다는 "서비스별 실제 배포 소요 시간"을 측정하고 "배포가 오래 걸리는 서비스"를 파악해야 한다. "요즘 문의가 많다"는 느낌보다는 "서비스별 문의가 주에 몇 번씩 인입되는지"를 파악해야 한다.
물론 항상 정확한 사실을 파악하기는 쉽지 않다. 그러나 사실 파악에 들인 노력만큼 더 나은 문제 해결 방안을 도출할 가능성이 높아진다. 항상 기본에 충실하자.