요구 사항 상세화 방법

외주 개발 기획의 시작은 요구 사항을 분석하여 상세화 하는 것에서 시작됩니다. 물론 PM이나 PL이 상세화를 진행할 수도 있지만, 기획자는 고객과 미팅을 통해 어떻게든지 상세화 작업을 하게 됩니다. 그럼 요구 사항 상세화를 잘하는 방법은 무엇인지 궁금하지 않을 수 없습니다.

 

 

 

요구 사항 상세화의 기본은 잘 듣기

 

듣기가 중요한 이용은 상세화이 대상이 요구 사항이기 때문입니다. 그리고 요구 사항은 개발을 원하는 고객이 말하는 것입니다. 그러므로 잘 들어야 합니다.

 

종종 자신의 전문성을 강조, 어필하고 싶은 기획자는 고객의 요구 사항을 듣지 않고, 자신의 말만 하는 회의도 있습니다. 이 경우 요구 사항이 상세화 되는 것이 아닌 기획자의 과거 이야기가 상세화 되게 됩니다.

 

같은 분야의 앱/웹, 시스템이라도 개발은 여러 유형으로 진행되고 완료될 수 있습니다. 금융 시스템이라도 토스와 신한금융그룹이 다르고, 카카오와 SBI의 앱이 다릅니다. 같은 대출 비교 서비스라도 카카오와 토스, 핀다, OK의 앱이 같다고 생각하는 사용자 또한 없습니다.

 

같은 사용자 문제 해결을 지향하는 앱들이라도 세부적으로는 다 다른 기능과 프로세스, 방식 및 조건하에서 개발되어야 하기 때문에 요구 사항을 세부화할 때는 잘 들어야 합니다.

 

잘 듣고, 들은 내용만 잘 정리해도 요구 사항 상세화의 절반은 처리한 것입니다.

 

 

 

들은 후  질문하기

 

요구 사항 상세화 시 기획자가 하는 말은 주장이 아니라 질문이어야 합니다.

 

프로젝트를 하다 보면 때로는 PM이나 PL로 투입될 때도 있고 분석/설계자로도 투입되기도 하지만 PA로 투입되는 경우도 있습니다.

 

이중 기획 PA로 투입되어 작업하는 경우 다른 기획자가 해 놓은 요구 사항 상세화를 바탕으로 기획 업무를 하게 됩니다. 그런데 이때 당황스러운 일을 겪기도 합니다.

 

 

기획자 주관적으로 정리된 요구 사항 문제

 

분명 앞서 작업한 정리 문서에 요구 사항으로 정리된 것에 맞추어 화면 설계를 진행했는데, 고객이 잘못되었다고 지적을 한 것입니다. 특히 강조된 요구 사항 내용을 맞추었는데 고객은 아니라 할 때는 많이 당황하게 됩니다.

 

이유는 고객의 이야기를 정리한 것이 아니라 PM 또는 PL, 분석/설계자로 선행 투입되어 요구 사항 상세화를 진행한 인력이 자신의 주장을 요구 사항 상세화로 적어 놓았던 것입니다.

 

 

질문을 하지 않은 요구 사항 문제

 

기획 PA 투입 시 두 번째로 당황스러운 상황은 계약 후 전달되는 고객의 요구 사항 목록 거의 그대로 있는 자료를 제공받았을 때문입니다. 

 

이 상황은 PM 또는 PL, 분석/설계자 고객의 요구 사항에 대해 질문을 거의 하지 않은 상태입니다.

 

일반적으로 계약 시 요구 사항은 주로 두 가지로 인해 포괄적이게 됩니다.

 

1. 고객이 자신의 요구를 폭넓게 반영하고 싶어 하기 때문
2. 고객이 잘 모르기 때문

 

이런 이유로 초기 고객 요구 사항 그대로 작업하는 경우 개발이 진행될수록 세부 요구사항이 추가되기도 하며, 때로는 개발 내용과 다른 요구가 나오기도 합니다. 그런데 이런 요구가 앞서 요구 사항이 포괄적이었기 때문에 어떻게든지 연결되기에 문제가 됩니다.

 

이커머스 앱을 개발해 달라는 요구만으로 진행되었다면, 일반적인 쇼핑 앱이 될 수도, 라이브커머스 앱이 될 수도, 공동구매 앱이 될 수도, 경매 앱이 될 수도 있습니다. 아니면 쿠팡 같은 앱일 수도, 스마트스토어 같은 앱일 수도, 지마켓 같은 앱일 수도, 롯데온 같은 앱일 수도 있습니다.

 

이에 따라 개발은 달라지게 됩니다. 그리고 기간과 비용이 정한 계약에 기반한 외주 개발의 경우 이 차이는 개발 성패를 좌우하는 중요한 요인이 될 수 있습니다.

 

 

 

요구 사항 상세화 문서 정리

 

잘 듣고 질문하는 것보다 요구 사항 문서 정리의 중요성은 상대적으로 낮습니다.

 

조금 규모가 있는 외주 개발사의 프로젝트의 경우 요구 사항 문서가 자체적으로 존재합니다. 감리 또는 PMO 양식으로 존재하기도 합니다. 

 

그냥 이에 따라 정리하면 됩니다.

 

여기에는 계약 기본 요구 사항 내용에 따라 상세화 과정에서 수용할지 거부할지를 협의한 내용은 물론 수용되는 요구 사항의 구체적 개발 내용이 무엇인지도 정리됩니다. 그리고 넘버링됩니다.

 

이렇게 구체화된 상세 내용은 개발 시작과 진행뿐 아니라 개발 완료 후 요구 사항이 다 반영되었는지 확인하는 용도가 됩니다. 

 

이는 계약 수행의 완료를 확인하는 것입니다. 일반적 도급 계약에서 기간 내 계약 내용이 완료되지 않으면 외주 개발사는 페널티를  받게 됩니다.

 

그러기에 모호한 요구 사항은 문제가 될 소지가 되는 것입니다. 이런 이유로 다수 개발 프로젝트를 진행한 외주 개발사는 요구 사항 상세화에 대해서도 자체적인 표준 문서를 보유하고 있는 것입니다. 

 

투입되는 기획자는 이 문서 양식에 맞추면 됩니다. 크게 고민할 필요가 없습니다.

 

자체적으로 프로젝트를 수주한 경우에는 과거 작업한 문서들을 바탕으로 정리/수정하여 해당 프로젝트에 맞추어 요구 사항을 정리하면 됩니다.

 

요구 사항은 말 그대로 고객의 개발 요구를 정리한 문서를 의미하기에 국제 표준 문서가 있는 것은 아닙니다. 단지 프로젝트의 개발 내용을 파악하고 작업할 수 있고, 개발 후 확인할 수 있으면 됩니다.