문제 정의서 작성 방법: 주요 팁 및 예시

많은 훌륭한 아이디어는 해결이 필요한 명확한 문제에서 시작됩니다. 제품팀과 디자이너는 해결책을 도출하는 과정으로 직행하고 싶어 하겠지만, 천천히 진행하는 것이 오히려 바람직합니다. “나무를 베는 데 6시간이 주어진다면, 나는 처음 4시간을 도끼를 가는 데 쓰겠다.”라는 속담도 있죠.

바로 해결 모드로 돌입하는 대신, 문제를 다각도에서 이해하는 데 시간을 할애하는 것이 가치 있습니다. 그렇게 하는 효과적인 방법 중 하나는 무엇일까요? 바로 문제 정의서를 작성하는 것입니다. 이 가이드에서는 단계를 분석하고, 실제 예시를 공유하며, FigJam 템플릿이 팀의 시작을 어떻게 도울 수 있는지 집중해서 살펴봅니다.

계속 읽고 아래 내용을 확인해 보세요.

• 좋은 문제 정의서의 특징
• 5단계로 쓰는 방법
• 문제 정의서를 사용해야 하는 경우
• 포함해야 할 주요 컴포넌트
• 문제 정의서 예시 및 바로 사용할 수 있는 템플릿

1단계: 문제 식별하기

문제 정의서를 작성하는 첫 번째 단계는 문제를 포착하고 데이터 수집을 시작하는 것입니다. 지원팀, 생산 라인, 혹은 그 외 어디든 문제가 발생하는 환경으로 들어가 직접 경험해 보세요. 거기서 더 깊은 근본 원인을 가리킬 수 있는 데이터상의 추세나 전체적인 테마를 찾아보세요.

문제를 직접 확인한 후에는, 문제와 가장 가까이 있는 사람들과 이야기하세요. 여기에는 지원팀, 다기능 파트너, 또는 더 많은 맥락을 제공하는 디자인 브리프와 같은 실무 문서를 가진 사람이 포함될 수 있습니다. 그 외에도 고객 피드백과 이해관계자 인터뷰는 문제의 전체 범위를 파악하는 데 도움이 될 수 있습니다.

2단계: 문제를 맥락 속에 배치하기

이제 문제가 고객, 이해관계자, 또는 팀의 수행 능력에 어떤 영향을 미치는지 보여주세요. 의견이 아닌 관찰 가능한 사항에 집중하세요. 명확한 관점은 문제의 우선순위를 정하고 왜 해결해야 하는지 설명하는 데 도움이 됩니다. 제품의 문제가 사용자가 가치를 찾는 데 차질을 빚는다면, 그건 심각한 적신호라 할 수 있습니다. 사용자 리서치를 수행해 본 적이 있다면 이 단계가 익숙하게 느껴질 것입니다.

문제를 맥락에 맞춰 설명하기 위해 다음과 같은 질문을 자문해 보세요.

• 평판, 재정, 또는 물류 측면의 비용을 유발하는가?
• 더 심각한 문제의 표면적인 증상인가?
• 팀이 이전에 이 문제를 해결하려고 시도한 적이 있는가? 무엇이 제대로 되지 않았는가?
• 현재 문제에 대해 확실히 알고 있는 것은 무엇인가?

3단계: 근본 원인 찾기

문제 이면에 있는 "왜"라는 질문을 깊게 파고들어 발원지를 찾으세요. 문제에 대한 초기 가정이 방해가 될 수 있으므로, 문제에 대해 더 많이 알게 됨에 따라 관점을 바꾸는 것을 두려워하지 마세요. 이러한 발견을 중심으로 이해를 재구성하다 보면 근본 원인에 더 가까워질 것입니다.

다음 템플릿들은 근본 원인을 밝혀내고 초기 프레임에 도전하는 데 도움이 될 수 있습니다.

• 5가지 이유. 문제 이면에 존재하는 "이유"를 깊이 탐구하여 근본 원인에 도달하세요.
• 역발상 브레인스토밍 문제를 프레이밍하는 방식을 바꿔 새로운 해결책을 찾으세요.
• DMAIC. 문제를 정의(define), 측정(measure), 분석(analyze), 개선(improve), 제어(control)합니다.
• 마인드맵. 공유 공간에서 원인, 효과, 해결책을 브레인스토밍합니다.

4단계: 이상적인 결과 묘사

문제가 명확해지면, 성공이 어떤 모습일지 정의하세요. 단순히 임시 처방이 아니라 문제가 진정으로 해결되면 무엇이 달라질까요? 단기적인 해결책은 증상을 완화할 수 있지만, 더 깊은 문제는 완전히 해결되지 않는 한 다시 표면화되는 경향이 있습니다.

경우에 따라 프로세스 맵을 만들어 기존 안전장치가 목표 달성에 어떻게 도움이 될 수 있는지 검토할 수 있습니다. "더 나은 상태"가 어떤 모습인지 시각화하면 목표를 구체화하고 다음 단계의 해결책을 안내하는 데 도움이 됩니다.

5단계: 해결책 제안 및 이점 개요 설명하기

하나 이상의 잠재적 해결책을 개괄적으로 설명하여 문제 정의서를 마무리하세요. 팀이나 이해관계자에게 앞으로 나아갈 명확한 경로 몇 가지를 제시하면, 합의를 촉발하고 더 스마트한 아이디어를 도출하는 데 도움이 될 수 있습니다. 각 해결책에 대해 시간, 비용, 또는 팀의 노력과 관련된 이점과 트레이드오프를 강조하세요.

사고를 검증하기 위해:

• 제안된 해결책이 단순한 증상이 아닌 문제에 대한 팀원들의 이해를 반영하고 있는지 팀원들에게 물어보세요.
• 두 가지 이상의 해결책을 탐구하세요. 일부 해결책은 병행하여 작동할 수 있습니다.
• 해결책이 제공하는 즉각적인 이점과 장기적인 이점을 모두 강조하세요.
• 위험 요소, 사각지대, 또는 의도치 않은 부작용을 찾으세요.
• 주공정법을 사용하여 작업을 과제와 의존 관계로 나누세요.

문제 정의서는 왜 중요한가요?

문제 정의서는 팀이 직면한 과제에 대한 세부 정보를 공유하는 데 도움이 됩니다. 해결책부터 서둘러 찾는 대신, 문제 정의서를 작성하면 과제를 되돌아보고 대응을 계획할 수 있습니다.

문제 정의서는 팀이 변경할 필요가 있는 요소에 집중할 수 있도록 높은 수준의 관점을 제공합니다. 매니저들은 또한 팀이 해결책을 마련하는 동안 감독하기 위해 이러한 하향식 관점을 활용합니다.

문제 정의서 예시 1: 지원 티켓 대기 시간

중견 SaaS 기업의 지원 매니저라고 상상해 보세요. 목표는 모든 지원 요청에 몇 시간 내로 응답하는 것이지만, 팀은 기대치를 충족하는 데 어려움을 겪고 있습니다. 다음과 같이 문제 정의서의 요소를 분석하는 것으로 시작하세요.

• 격차. 고객들이 지원 응답을 받기 위해 오랜 시간을 기다리고 있습니다.
• 방향.이 문제는 몇 달 전에 시작되어 꾸준히 악화되었습니다.
• 영향.고객 만족도가 떨어지고 있고, 팀은 번아웃을 느끼고 있습니다.
• 중요성. 지원은 유지율과 제품 경험에 핵심적인 역할을 합니다.

이제 세부 내용을 파악했으므로, 이를 문제 정의서 형식으로 만들 수 있습니다.

1. 문제 파악. 지원 티켓 처리 시간이 깁니다. 지난 몇 달간 시간이 어떻게 늘어났는지 추적하고 일관적이지 않은 대기 시간에 대해 고객과 대화하여 데이터를 수집하세요.
2. 맥락에 맞추어 보기. 기다리다가 불만을 느낀 고객들이 경쟁사로 이탈할 수 있습니다. 처음에는 계절에 따른 수요 증가라고 간주했지만, 대기 시간이 줄어들지 않아 평판 및 금전적 문제를 일으킬 수 있습니다.
3. 근본 원인 찾기. 처음에는 수요가 증가했다고 가정했습니다. 지원 티켓 수는 일정하게 유지되었지만, 사소한 문제를 해결하도록 설계된 AI 지원의 티켓 수가 줄어들었습니다. 이러한 AI 지원 부족으로 인해 팀의 여력이 부족해졌습니다.
4. 이상적인 결과 묘사하기. AI 지원이 더 고급 질의를 처리할 수 있어야 합니다. 이러한 방식으로, 서비스팀은 AI가 처리하기에 너무 어려운 티켓에만 온전히 집중할 수 있습니다.
5. 해결책 제안하기. 개발자를 배정하여 AI를 개편할 수도 있으며, 티켓을 처리할 새로운 솔루션에 투자할 수도 있습니다. 또한 고객과의 직접적인 접촉에 더 집중하도록 지원 상담원의 업무 흐름을 재작업하는 것도 고려할 수 있습니다.

문제 정의서 예시 2: 신규 기능 개발

업무 흐름 인사이트 플랫폼을 제공하는 기술 회사의 프로젝트 매니저가 되었다고 상상해 보세요. 경영진은 해결된 각 문제에 대한 비용 절감을 추산하는 기능을 추가하고 싶어 하지만, 당신은 이를 구축할 리소스가 있는지 확신할 수 없습니다.

• 격차. 수익 계산기를 구축하라는 요청을 받았지만, 팀에 리소스가 부족합니다.
• 방향.기능 요청이 들어왔을 때 문제가 시작되었습니다.
• 영향.지연될 경우 경쟁사가 유리해지는 상황이 발생할 수 있습니다.
• 중요성. 이 기능은 차별화와 성장을 이끌어낼 수 있습니다.

이 정보를 바탕으로 이를 문제 정의서로 작성할 수 있습니다.

1. 문제 파악. 팀에 새로운 기능을 디자인하고 구현할 리소스가 없습니다. 이와 같은 도구에 대해 작업해 본 이해관계자 및 직원과 인터뷰하는 것으로 시작하세요. 이들이 이 기능을 추가하는 데 수반되는 문제와 해결책을 설명해 줄 수 있습니다.
2. 맥락 파악. 이 기능을 구현하지 않으면 경쟁사에 경쟁 우위를 내어주고, 수익 계산기에 관심 있는 고객들을 제품에서 이탈하게 만들 수 있습니다.
3. 근본 원인 찾기. 팀은 현재 ROI 계산기에 사용할 필수 메트릭을 추적하고 있지 않습니다. 또한 팀은 그 도구를 처음부터 구축할 만한 충분한 경험이 없습니다.
4. 이상적인 결과 묘사하기. 개발자가 플랫폼에 계산기를 추가합니다. 이 기능은 도구에 관심 있는 신규 고객을 유치하고 기존 고객이 전환하도록 돕습니다.
5. 해결책 제안. 개발자들은 기능의 프레임워크에 대해 더 배우고 ROI 중심 지표를 추적하는 기능을 추가합니다. 거기서부터 몇 달 안에 플랫폼에 이 기능을 추가하기 위한 프로젝트 로드맵을 만들 수 있습니다.

문제 정의서를 사용해야 하는 경우

문제 정의서는 과제에 대한 더 깊은 이해나 팀 합의가 필요할 때 언제든 유용합니다. 특히 다음과 같은 경우 도움이 됩니다.

• 프로젝트 제안서 다듬기. 매니저는 프로젝트 제안서를 작성하여 사용자 문제를 해결합니다. 문제 정의서는 이러한 제안서를 알리고, 그 목표, 요금제 및 접근 방식을 형성합니다.
• 신규 기능 개발. 많은 스타트업은 장기적인 문제를 해결하는 일을 비즈니스 모델로 삼아 사업을 구축합니다. 문제 정의서는 회사의 미션과 핵심 제품 디자인을 명확히 하는 데 도움이 됩니다.
• 장기적 이점 강조. 문제 정의서는 문제 해결의 영향을 구조화하며, 이는 이해관계자와 리소스 확보에 결정적인 역할을 합니다.
• 팀 간 협업. 공유된 문제는 공유된 목적으로 이어집니다.
• UX 개선. UX 팀은 문제 정의서를 사용하여 문제점을 드러내고, 의도가 반영된 디자인을 수행합니다.

문제 정의서의 구성 요소는 무엇인가요?

대부분의 문제 정의서에는 다음과 같은 핵심 부분들이 포함됩니다.

• 격차(Gap): 작동하지 않는 것과 해결되어야 할 것
• 방향(Orientation): 문제가 언제, 어디에서 나타나는지에 대한 설명
• 영향(Impact): 고객, 팀, 또는 비즈니스에 미치는 결과
• 중요성(Importance): 문제 해결이 중요한 이유

문제 정의서 템플릿

문제 정의서를 직접 작성할 준비가 되셨습니까? 아래의 문제 정의서 템플릿을 사용해 보세요.

팀의 의견을 하나로 모아 문제를 더 빠르게 해결하세요

문제 정의서는 팀에게 명확한 공동의 목표를 제시하여 아무도 궤도에서 벗어나지 않게 합니다. FigJam은 참여를 유도하는 맞춤형 인터페이스를 사용하여 모든 기여자가 호흡을 맞추는 데 도움을 줍니다. 자세한 방법은 다음과 같습니다.

• 데이터 사일로를 방지하고 FigJam의 전략 기획 도구를 사용하여 의사결정 역량을 저해하지 않으면서 모든 의견을 수렴하세요.
• FigJam의 다이어그램 도구로 최고의 아이디어에 생명을 불어넣고 계획을 실행에 옮기는 방법을 보여주세요.
• 차질 없이 프로젝트를 계속 진행하세요. Figma의 디자인 핸드오프 도구는 주요 이해관계자 간의 열린 소통을 통해 프로젝트를 성공적으로 완수하도록 돕습니다.