이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서비스 요구사항을 분석할 때 이해관계자가 말하는 것과 실제로 원하는 것이 다를 수 있다는 것을 수업에서 배웠습니다. 수업 서비스 기획 과제에서 요구사항을 인터뷰로 먼저 수집했는데, 사용자가 '더 빠른 검색'을 원한다고 했지만 실제로는 잘못된 결과가 자주 나오는 것이 문제였습니다. 표면 요청과 실제 필요를 구분하기 위해 '왜'를 3번 질문하는 방법을 활용했습니다. 또한 기존 화면 흐름을 분석해 사용자가 어디서 멈추는지를 함께 확인했습니다. 요구사항 분석에서 정밀함과 속도의 거래가 생기는데, 초기에는 핵심 사용자 몇 명의 인터뷰로 먼저 방향을 잡는 것이 효과적이라고 생각합니다. 분석이 끝나면 주요 요구를 우선순위별로 정리해 이해관계자와 공유하는 것도 중요합니다.
서비스 요구사항을 분석할 때 제가 또 한 건 기능과 비기능 요구를 나누고 우선순위를 매기는 것입니다. 시스템이 무엇을 해야 하는지(기능)와 성능·보안·가용성(비기능)을 섞으면 범위가 흐려졌습니다. 그래서 둘을 분리한 뒤, 반드시 필요한 것과 있으면 좋은 것을 MoSCoW로 가렸습니다. 또 이해관계자 인터뷰와 현행 프로세스 관찰, 기존 문서 검토를 함께 썼습니다. 표면 요청(Want)과 근본 필요(Need)가 달라, 둘을 구분하는 게 출발이었습니다.
충돌하는 요구를 다 담으려다 범위가 과잉됐습니다. 그래서 분류와 우선순위로 범위를 잡는 게 핵심이었습니다.
요구사항 분석에서 제가 의식한 건 범위를 잠그는 것입니다. 충돌하는 요구를 다 포함하다 보면, 범위가 끝없이 늘어났습니다(Scope Creep). 그래서 책임자가 최종 요구사항을 서면으로 확인하는 Sign-off 절차로 범위를 잠갔습니다. 또 정밀과 속도 사이에서, 초기엔 핵심 사용자 몇 명의 인터뷰로 방향을 먼저 잡고, 정밀화는 나중에 했습니다. 처음부터 다 정밀하게 하려면 너무 느렸기 때문입니다.
다 담으려다 출시가 무한정 밀리는 것보다, 범위를 잠그고 시작하는 게 나았습니다. 그래서 우선순위로 좁히고, 서면으로 확정하는 게 핵심이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 서비스기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.