A
약 75초
경험 중심 1인칭 답변
졸업 프로젝트에서 팀원들이 '우리 서비스를 개선하자'는 막연한 방향으로만 이야기하다가 3주가 지나도 무엇을 만들지 결정이 안 됐던 경험이 있습니다. 저는 '지금 어떤 사용자가 어떤 상황에서 무엇을 불편해하는가'라는 문장으로 문제를 좁히자고 제안했습니다. 팀이 각자 가정을 하나씩 적고 가장 많이 겹치는 고통 지점을 찾는 방식으로 좁혀나갔습니다. 그렇게 나온 문제 정의 한 문장이 이후 기능 우선순위와 제외 기준의 기준점이 됐습니다.
문제를 구조화하는 것은 해결책을 찾는 것보다 더 중요한 작업이라는 걸 그 경험에서 배웠고, 좁고 명확한 문제 정의가 팀 전체의 방향을 맞추는 가장 빠른 방법이었습니다. 앞으로도 문제를 구조화할 때 '어떤 사용자가 어떤 상황에서 무엇을 불편해하는가'라는 문장으로 좁히는 방식을 유지하겠습니다.
문제를 구조화하는 것은 해결책을 찾는 것보다 더 중요한 작업입니다. 좁고 명확한 문제 정의 한 문장이 팀 전체의 방향을 맞추는 가장 빠른 도구가 됩니다.
이 결의 특징
문제를 좁히는 과정이 3주를 거쳐 구체화됐습니다. 막연한 '서비스 개선'에서 출발해 '어떤 사용자가 어떤 상황에서 무엇을 불편해하는지' 문장으로 재정의한 흔적이 있습니다. 팀원들이 각자 가정한 고통지점을 겹쳐보며 수렴한 방식도 보입니다.
이 결이 통하는 자리
문제 구조화 자체가 다음 결정의 기준점이 되는 조직에서 살아 있을 때 통합니다. 기능 우선순위와 제외 기준이 문제 정의로부터 일관성 있게 도출되는 환경이라면, 이런 과정을 거친 결정자는 신뢰받을 가능성이 높습니다.