요구사항은 무엇을 토대로 구체화할 수 있을까요?
제품 요구사항을 정의하는 단계에 대해 궁금한 점이 있어서 질문드립니다.
A라는 새로운 기능을 만들자는 목표가 생겼다고 가정했을 때, 프로젝트화 하기 위해 배경, 목적, 문제 정의 단계가 진행되고, 그다음 요구사항을 정의한다고 알고 있는데요.
궁금한 점은 이 요구사항은 무엇을 토대로 구체화해서 적을 수 있는지 궁금해요.
막연히 A라는 기능을 만들자는 목표만 있을 때, 적을 수 있는 내용이 단순한 내용이 되지 않을까 하는 생각입니다. 아니면, 단순 러프하게 작성 후에 개발자와 논의하여 내용을 구체화하는 걸까요??
데이먼 님은 어떤 방식으로 요구사항을 정의하고, 개발자랑 커뮤니케이션하는지 궁금합니다.
요구사항을 무엇을 토대로 구체화해서 적을 수 있는지에 대한 질문입니다.
온라인에서 요구사항 정의서로 검색해보면 다양한 샘플이 있습니다.
주로 엑셀/스프레드시트 형태로 정리된 샘플인데요.
공개된 문서 대부분이 워터폴 프로세스의 조직에서 작성하는 샘플이라고 볼 수 있습니다.
요구사항을 정의하는 방식은 우리가 대상으로 하는 고객과 내가 일하는 조직의 업무 방식(워터폴 & 애자일)에 따라 다릅니다.
워터폴
명확한 의사결정자가 있고 업무가 기획, 디자인, 개발로 순차적으로 진행되는 워터폴 조직에서는 위 샘플처럼 관련자와의 인터뷰를 통해 요구사항을 정리합니다.
그래서, 프로젝트를 의뢰받아서 고객이 요구하는 제품을 만드는 < SI 기업 >이나 < 에이전시 >에서는 대부분 위의 샘플과 같은 방식으로 요구사항을 정의합니다. 이후에 정리된 내용을 의사결정자(클라이언트)와 확인하고, 스토리보드(화면설계서)를 만들어서 조금 더 구체화된 설계서를 정리한 다음에 결정된 내용을 개발팀에 전달합니다. 그래서 워터폴 방식에서의 요구사항 정의는 기획자가 요구자의 요구사항을 최대한 자세하게 정리하는 것에서부터 시작합니다.
애자일
애자일 조직에서의 요구사항 정리방법은 워터폴과는 완전히 다릅니다.
우리가 200만 명이 이용하는 B2C 서비스를 운영하고 있다고 가정했을 때 우리는 고객의 명확한 요구사항을 알 수가 없습니다. 그래서 가설을 세우고 실험을 하며 고객이 원하는 포인트, 고객이 만족하는 포인트를 찾아 서비스를 지속적으로 개선해나갑니다.
또한, 조직 구조가 기획/디자인/개발이 분리되지 않고 기획 단계에서부터 모든 구성원이 함께 참여하는 것이 특징입니다. 따라서 애자일 조직에서의 요구사항 정의는 가설로부터 시작해나갑니다. 유저스토리 형식으로 고객 입장에서 가설을 세워보는 접근 방식이죠!
그래서, 애자일 조직의 PM은 보통 위와 같은 형태의 유저스토리를 먼저 정리하고, 정리된 내용을 바탕으로 모든 멤버가 참여해 유저스토리를 확인하고 조율해나갑니다.
정리하면,
명확한 클라이언트가 있는 '워터폴 조직'에서는 보통 클라이언트와의 인터뷰를 통해 요구사항을 구체화하고, 이를 바탕으로 화면설계서까지 기획자가 작성합니다. 이후에 디자인, 개발 단계로 이어지게 됩니다.
불특정 다수의 고객을 대상으로 하는 '애자일 조직'에서는 고객의 명확한 요구사항을 알 수 없기에 유저스토리 형태로 가설을 세우고, 제품 팀 멤버들이 모두 모여 유저스토리를 함께 구체화하고 디자인, 개발을 병렬로 이어나가게 됩니다.
글에서는 이해를 돕기 위해 워터폴과 애자일로 비교했지만 고객을 특정할 수 있고 요구사항이 명확한 상황에서는 고객 인터뷰 방식이 효과적이고, 고객을 특정할 수 없고 요구사항을 명확히 파악하기 어려운 상황에서는 유저스토리 방법이 효과적입니다.
