이거 해주세요!
프로덕트를 만들다 보면 개발팀이나 디자인팀에 요청할 것들이 발생한다. 이런 경우 각 팀에 이런 기능을 개발해달라, 저런 화면을 디자인해달라고 요청하곤 한다. 이런 요청사항은 요구사항이라는 형태로 정리되지 않으면 “어떻게 해달라는 건데요? 기획안을 주세요”라는 반문을 듣기 십상이다. 각 팀에서 요구하는 요구사항이란 무엇일까?
요구사항
프로덕트를 만들기 위해 문서를 만들다 보면, 요구사항 정의라는 것을 작성하게 된다. 말 그대로 개발 및 디자인팀에 요구하는 사항들을 기재한 문서다. 어떤 기능인지, 왜 만들어야 하는지, 어떤 목표를 추구하고자 만드는 것인지를 포함해야 한다. 다만 요구사항은 너무 자세하게 작성하면 개발자와 디자이너의 전문 영역을 침해하고 되고, 너무 러프하게 작성하면 의견의 전달이 제대로 이루어지지 않는다.
요청이나 의견 제시가 문제가 되는 이유
간단한 요청 사항이나 프로덕트에 대한 의견을 제시하는 것은 자유롭다. 다만 그것이 실제 프로덕트에 반영이 되거나 되지 않는 것은 다른 문제다. 간단한 요청과 의견 제시라 하더라도 이를 프로젝트에 반영하기 위해서는 일정 조정, 리소스 배분 등의 일이 필요하다. 그리고 바꾸거나 새로 만드는 것은 생각보다 그리 간단하지 않다. 리소스를 투입한 만큼 사용자가 충분히 활용하고 만족할만한 가치의 것인지, 기존에 만들어 놓은 것들과 충돌이 이루어지지는 않는지, 새로 만든 것이 잘 작동하는지 생각할 것과 테스트해보아야 할 것들이 많다.
또한 이런 경우 으레 단순하게 표현되는 경우들이 많다. 이를테면 “빨간색이 별로네요”, “버튼이 여기 있는 게 어색해요. 여기로 옮겨주세요”, “이렇게 하면 팝업이 떴으면 좋겠어요”, “글자 크기가 좀 더 컸으면 좋겠어요”와 같다. 이렇게 요청이나 의견을 받게 되면 “왜 또 바꾸라는 거야?”, “왜 처음부터 이런 생각을 하지 못했지?”, “그래서 명확하게 어떨 때 동작하게 하라는 거야?”라는 불만과 의구심만 커지게 된다.
그래서 요구사항이 필요해요
기획자는 이렇게 요청하거나 의견을 제시하는 데 그치면 안 된다. 요청이나 의견을 요구사항으로 명확하게 바꾸어 제시해야 한다. 요구사항이라 함은 명확한 근거와 배경을 토대로 어떠한 것이 있어야 한다는 것 표현이다. 또한 고객의 관점에서 생각해야 한다. 고객의 관점에서 바라보아 “사용자의 사용 환경이나 반응하는 부분이 예측했던 부분들과 벗어나 있기 때문에”, “고객 피드백은 이러하기 때문에”가 있어야 하며, “A 환경에서는 B라는 부분을 고객이 할 수 있어야 한다”처럼 표현되어야 한다.
이를테면 “고객이 결제할 때 결제 수단을 선택하지 못하는 어려움이 있기 때문에(왜, 어떤 배경으로 인해) 최초 결제 화면에 진입하였을 때(조건, 어떤 환경일 때 동작) 결제 수단(무엇, 어떤 기능인지)을 선택할 수 있어야 합니다”와 같이 명시되어야 한다. 여기에 더해 “이 기능을 통해 결제를 완료하는 비율을 0% 증대할 것으로 기대”와 같이 달성하고자 하는 목표가 추가되면 금상첨화이다.
이렇게 요구사항을 정리하고 나서 리뷰를 통해 요구사항에 대한 설명을 진행하고, 보완되거나 수정할 부분을 정립하며 일정을 조율해야 한다. 이 과정을 통해 우선순위에 대한 논의, 리소스 배분에 대한 논의가 이루어진다. 이러한 과정을 통해서 결정된 사항과 일정은 단순하게 요청하거나 의견 제시했을 때와 달리 효율적이고 효과적으로 디자인과 개발이 진행된다.
결론
단순 요청이나 의견 제시보다 요구 사항을 제시하는 것은 당연한 역할이며 기획자의 전문성이라고 생각한다. 너무 러프하지 않게 작성함으로써 주어진 일정 내 우선순위와 적절한 리소스 배분을 할 수 있고 이를 통해 프로덕트의 일정을 관리할 수 있다.
너무 자세하게 작성하지 않음으로써 때로는 기획자가 생각하는 것보다 훨씬 효과적인 방법들이 디자이너와 개발자로부터 도출되기도 한다. 별거 아닌 것 같지만, 가장 필요한 작업이 요구사항을 정의하는 것이라 생각한다.
원문: June의 브런치
이 필자의 다른 글 보기
