답변

질문 배경:
프로젝트 시작 시 고객이 과제를 충분히 명확하게 정의하지 않는 경우가 많습니다: 목표는 일반적일 수 있고 세부 사항은 설명되지 않을 수 있습니다. 이는 새로운 방향이나 전통적인 프로세스의 디지털화 시작에 전형적입니다. 분석가는 상충하는 요구 사항과 미래 제품에 대한 분산된 개념에 직면하게 됩니다.

문제:
요구 사항의 불확실성은 설계 오류 위험, 갈등, 일정 지연 및 예산 증가로 이어질 수 있습니다. 병목 현상은 이해관계자 간의 상충과 작업량 판단의 불가능성입니다.

해결책:
분석가는 단계별 요구 사항 파악을 조직해야 합니다:

1. 주요 이해관계자와 인터뷰 및 촉진 세션을 실시하여 명백한 기대뿐만 아니라 숨겨진 기대도 파악합니다.
2. 빠른 피드백을 위해 프로토타입 및 MVP 제작 기술을 사용합니다.
3. 사용자 스토리, 비즈니스 프로세스 다이어그램과 같은 분석 도구와 적용 질문 기법(5 Whys, “성공이란 무엇인가”的 구체화 등)을 사용합니다.
4. 모든 가정을 기록하고 비즈니스와 협의함으로써 불확실성을 줄입니다.

주요 특징:

• 불완전한 요구 사항을 명확히 하기 위한 구조적 접근
• 숨겨진 정보를 수집하기 위한 다양한 기술 사용
• 가정을 문서화하고 협의에 발제하는 것의 필수성

트릭 질문.

암묵적 요구 사항에 필요한 문서는 무엇입니까: 사용자 스토리를 기록하는 것만으로 충분합니까?

사용자 스토리는 유용한 도구지만 요구 사항이 모호할 경우 모든 세부 사항을 드러내지는 않습니다. 화면 프로토타입, 사용 시나리오의 예 및 비즈니스 규칙 표와 같은 추가 아티팩트를 개발해야 합니다.

시작 시 더 중요한 것은 빠르게 결과(MVP)를 얻는 것인가, 아니면 최대한 완전한 요구 사항을 수집하는 것인가?

속도와 완전성의 균형은 상황에 따라 다릅니다. 시작할 때는 최소한의 생존 가능 제품(MVP)이 더 가치가 있으며, 이는 피드백을 제공하고 비전을 신속하게 조정하는 데 도움이 됩니다. 모든 요구 사항을 오랜 시간에 걸쳐 협의하는 것보다 그렇습니다.

고객의 말만으로 결정을 내릴 수 있습니까?

아니요. 고객은 요구 사항을 표현하지만, 기술 세부 사항과 제약을 고려하지 않을 수 있습니다. 분석가는 요구 사항을 프로세스 이해를 통해 유효성을 검증하고, 대안적인 의견을 요청하며, 결과를 분석해야 합니다.

일반적인 오류 및 안티 패턴

• 고객의 말에 대한 맹목적인 신뢰, 프로세스에 대한 상세 분석 없이
• 모호한 요구 사항을 개발 작업으로 직접 전환
• 중간 결과에 대한 피드백 무시

실생활 사례

부정적인 사례: 분석가는 고객의 요구 사항만 기록하고 개발자에게 전달했습니다. 결과적으로 비즈니스의 실제 문제를 해결하지 않는 기능이 구현되었습니다. 장점: 개발이 빠르게 시작됨. 단점: 제품이 사용되지 않았고 많은 수정이 필요했음.

긍정적인 사례: 분석가는 사용자와의 일련의 회의를 진행하고 프로토타입을 구축하며 시나리오를 협의했습니다. 요구 사항이 구체화되었고, MVP는 신속하게 비즈니스에 가치를 가져왔습니다. 장점: 빠른 가치, 긍정적인 피드백, 최소한의 수정. 단점: 요구 사항 수집 단계에서 약간 더 많은 시간이 소요됨.