기획자의 요구사항 분석이 가지는 근본적 문제점

서비스 개발 프로젝트에 투입된 기획자는 먼저 고객의 요구사항을 파악하고 분석하는 일을 합니다. 이를 토대로 기획 설계를 하여 작업을 규정하고 WBS(개발 작업 및 일정)를 작성하게 됩니다. 그런데 대부분은 요구사항 분석의 근본적 문제로 시작부터 난관에 부딪치게 됩니다.

 

 

요구사항의 주체는 누구인가?

프로젝트에 들어가면 고객은 경험 많은 기획자가 알아서 요구사항을 정리해 주기를 바라기도 합니다. 과거 비슷한 프로젝트를 많이 해 보았기에 더 잘 알 것이라 생각하기도 합니다.

 

그러나 기획의 특성상 과거를 기반으로 개발이라는 미래 결과를 도출한다는 것은 어폐가 있습니다. 과거를 기반으로 개발을 할 것이면 기획자보다는 해당 분야 경력자가 더 유용할 것입니다. 기획은 과거와 단절된 미래 불확실성 하의 성과를 도출하기 위해 진행되는 것이기 때문입니다.

 

또한 알아서 요구사항을 정리해 달라는 말은 애플 스토어에 가서 구매를 하려 하는 사람이 아이폰을 구매할지, 아이패드를 구매할지, 맥북을 구매할지 모르겠으니 스토어 매니저에게 알아서 선택해 달라고 말과 같습니다. 문제는 서비스 개발 과정이 이 보다 더 복잡하다는 것입니다. 

 

결국 요구사항은 고객이 외주 개발사에 어떤 서비스를 만들어 달라는 것입니다. 이 시작은 서비스 사업 기획 및 서비스 기획을 바탕으로 이루어져야 합니다. 여기서 서비스 사업 기획과 서비스 기획 내용은 보안 사항입니다.

 

서비스 개발 전 이 내용을 경쟁 서비스가 알게 된다면 개발 기간 동안 준비를 할 것이어서 해당 서비스는 개발되어 봤자 실패를 하게 될 것입니다.

 

솔직히 서비스 사업 기획과 서비스 기획이 공개되었다면 그 프로젝트는 중단하는 게 비용과 성과 측면에서 더 나은 결정입니다.

 

이 말인즉 근본적인 요구사항의 주체는 고객이며, 이 요구사항이 개발에 적합한지를 파악하여 부족한 부분을 고객과 협의하여 채워 넣는 분석의 주체는 기획자가 되는 것입니다. 결국 요구사항 자체가 부실한 경우 아무리 분석을 해도 질 높은 요구사항 정리가 될 수 없다는 것을 의미합니다.

 

이는 미래 성과 기획에서 현재 파악되는 성과 영향 변수가 부실한 경우 아무리 기획력이 뛰어나도 제대로 된 기획을 할 수 없는 것과 같습니다. 

 

AI(인공지능)의 경우도 아무리 뛰어난 알고리즘이라도 학습 데이터가 부실하면 바보 AI가 되는 것과 같은 이치라 할 수 있습니다.  

 

 

왜 요구사항을 분석하는 것인가?

그러므로 기획자의 요구사항 분석은 요구사항에 개발을 위한 요소들이 제대로 정리되어 있는가와 현재의 개발 도구와 투입 개발자 특성/역량과 적합한가를 파악하기 위한 것이라 할 수 있습니다.

 

만약 개발을 위한 요소들이 제대로 정리되어 있지 않다면 고객과 이야기하여 요구사항 내용을 보충해야 합니다. 대부분의 내용은 서비스 의도와 정책, 목적한 서비스 기능, CI/BI 등에 나타나게 됩니다.

 

개발 도구와 투입 개발자 특성/역량에 따라 같은 결과라도 개발이 쉬울 수도 어려울 수도 있습니다. 이에 대한 조정이 필요합니다. 때로는 고객의 서비스 사업 계획에 따라 꼭 필요한 개발 방식이라면 개발자를 변경 또는 추가 투입해야 할 수도 있습니다. 

 

 

알아야 면장을 한다

그러므로 고객이 해당 서비스에 대해 모른다면 요구사항이 분석이 제대로 이루어지기 어려워집니다.

 

최소 수년간 서비스를 운영해 왔던 고객도 자신의 서비스에 대해 잘 모르는 경우가 있습니다. 직접 서비스를 기획, 개발, 운영한 것이 아닌 직무 변경으로 그냥 이전 운영을 했던 직원의 일을 인수받아 똑같이 해왔을 경우도 있기 때문입니다. 이 경우 서비스 운영 내용은 알지만 서비스에 대한 내용은 잘 모르게 됩니다.

 

외주 개발의 기획자는 고객과 미팅을 통해 개발 목표 서비스 대상을 구체화하고 개발 과정 중 변수를 개발 도구와 개발자에 대입하여 서비스 개발을 계획하게 됩니다. 이는 입력 변수가 함수를 거쳐 결괏값이 되는 것과 비슷한 과정입니다.

 

결국 입력 변수가 잘못되면 결괏값은 어떤 상황에서도 잘못된다는 것을 의미합니다. 그리고 이 변수의 결정 주체는 고객입니다.

 

때로는 서비스 개발이 진행되는 과정에서 지금까지 개발 내용을 뒤집을 고객의 말도 안 되는 추가 요구나, 기존 요구사항을 바꾸거나 심지어 협의 완료된 요구사항을 부정하는 일 때문에 개발이 지연되는 일이 생기기도 합니다.

 

이런 일들은 고객 스스로가 어떤 서비스를 개발해야 할지 모르기 때문에 발생합니다. 이때 아무리 뛰어난, 역량이 높은 기획자가 투입된다고 해도 그 프로젝트는 실패합니다.

 

스포츠에서 뛰어난 성과를 보인 선수가 팀을 옮긴 후 성적이 떨어지는 일이 있습니다. 그리고 다시 팀을 옮긴 후 엄청난 퍼포먼스를 보이기도 합니다.

 

어떤 뛰어난 기획자도 서비스 내용을 모르는 고객과 성과를 내기는 쉽지 않습니다. 그렇다고 전부 개발 자체가 실패한다는 것은 아닙니다. 그냥 결과 퀄리티의 문제로 나타날 수도 있습니다.