앱/웹 개발 시 요구 사항 파악 업무 정리

고객사가 요구하는 앱 또는 웹 사이트 개발 요구사항은 이미 계약 시점 합의된 사항입니다. 이로 인해 요구 사항을 개발 계약의 내용 또는 개발의 범위라고 할 수 있습니다. 문제는 계약 상 요구사항 내용만으로 개발자나 디자이너가 작업을 하기에는 부족하다는 데 있습니다.

 

 

요구사항 구체화

앱/웹 개발에 투입되는 기획자가 하는 요구사항 관련 작업은 완전히 새로운 요구사항을 정리하는 것은 아닙니다. 계약 시 합의된 개발 목적물 관련 요구 사항을 구체화하는 작업을 하게 됩니다.

 

계약 시 합의된 앱 또는 웹 사이트 개발 관련 요구 사항은 다소 포괄적인 경우가 대부분입니다. 즉 계약 상 정리 된 요구사항을 개발자와 디자이너가 작업할 수 있게 구체화하여 정리하는 작업을 하는 것입니다. 

 

이때 새로운 계약의 범위를 넘어서는 새로운 요구사항이 나오기도 하고, 계약 기간과 투입 인력/예산을 가지고 어려운 개발 요구 사항이 나올 수도 있습니다. 이 경우는 PM과 개발사에 확인 후 정리를 해야 합니다. 

 

 

요구사항 변화 대처

때로는 고객사 내부 의견 조율이 되지 않아 요구사항의 디테일이 개발 작업 중 자꾸 변할 때도 있습니다. 문제는 이런 구체적 요구사항의 변화가 단순한 변화가 아닌 지금까지 개발하고나 디자인한 작업 내용을 뒤집어야 해야 하는 상황을 만들 수도 있다는 것입니다.  

 

비전문가인 고객 직원들은 단지 몇 글자 변경 또는 화면 변경 수준으로 이해하고 이렇게 주장을 합니다. 그러나 이를 구현하는 작업은 수많은 서로 다른 코드와 디자인 요소의 상호 작용과 밸런스에 의해 보이는 것일 수 있습니다. 이 경우는 하나의 변경이 전체 시스템의 안정성을 저하시키기도 하고, 디자인 밸런스를 무너뜨리기도 합니다.

 

기획자의 요구사항 구체화 작업은 이런 요인들을 고려해야 합니다. 그래서 때로는 개발자와 디자이너와 협력이 필요하게 되기도 합니다.

 

그리고 사전 계약 된 범위를 벗어나는 요구사항 내용이 있는 경우 PM과 개발사 영업에 알려 의사 결정을 추가로 받아야 합니다.

 

이는 투입된 기획자뿐 아니라 개발자와 디자이너의 계약 기간에 영향을 줄 수 있는 사항입니다. 단순한 말 한마디가 확정된 개발 요구 사항이 되는 경우 개발 기간과 예산을 변화시킬 수 있습니다.   

 

 

계약 후 개발 전 요구 사항 정리

고객과 요구사항 미팅을 하다 보면 화면 하나하나에 대한 내용을 요구하는 경우가 있습니다. 때로는 고객이 아니라 기획 PL 요구사항 구체화 단계에서 화면 구성과 디자인을 요구하는 경우도 있습니다.

 

그러나 이는 개발 관련 계약이 화면 수정인 경우가 아니라면 요구 사항 시기에 협의할 내용이 아닙니다. 어차피 개발이 진행되고 화면 디자인이 나오면 하나하나 협의를 하게 될 것입니다. 아직 보고 협의할 디자인도 나오지 않은 상태에서 기획자가 문서에 적은 내용으로 화면을 확정하려는 이런 방식은 불필요한 회의 시간만을 늘릴 뿐입니다. 결국 뒤에 또 할 의미 없는 협의를 하고 있는 것입니다.

 

그렇다면 계약 후 개발이 시작되기 전 요구 사항 정리는 어떻게 해야 될까요? 

 

먼저 계약 내용을 기반으로 초안을 작성합니다. 그리고 여기서 나온 내용을 구체화하는 방식으로 요구 사항 구체화를 진행해야 합니다.

 

기능을 중심으로 한 신규 앱/웹 개발이 목적인 계약이라면 고객사가 원하는 기능 개발의 구체적 내용이 정리되어야 합니다.

 

기존 앱/웹이 있고 화면 업그레이드와 이에 따른 보완 계약이라면 기존 앱/웹 화면에서 고객이 수정/보완하려는 부분을 체크하면서 요구 사항을 정리할 수 있습니다. 이때 조건은 최대한 기존 개발된 시스템을 건들지 않는다는 것입니다. 만약 고객이 요구하는 화면 수정/보완 내용이 기존 시스템의 전반적은 재 개발이 필요한 사항이라면 계약의 범위를 벗어나게 됩니다.

 

그러기에 화면을 가지고 하는 요구 사항 협의의 대부분은 디자인 변경에 그쳐야 하는 경우가 많습니다. 전면적 프런트엔드 개발이 필요한 경우는 결국 백엔드 개발로 이어지게 되는 케이스가 많습니다. 앱/웹 화면으로 보이는 서비스는 프런트엔드와 백엔드 상호작용의 결과이기 때문입니다.

 

그러므로 기획자는 직접 개발이나 디자인을 하지는 못하더라도 최소한 어떤 영향이 생길지는 파악할 수 있는 역량은 있어야 합니다.