서비스/프로덕트가 태어나고 운영되는 일반적인 프로세스
<서비스 기획자로 영역 확장하기> 04
서비스 기획자의 일을 살펴보기 전에 먼저
하나의 서비스 혹은 프로덕트가 태어나고 운영되는 업무 프로세스를 살펴볼게요.
(이 글에서 서비스 혹은 프로덕트라는 단어의 차이가 있지 않아 이하 서비스라고 적겠습니다).
B2C 서비스 회사의 프로세스를 기반으로 설명해 보겠습니다.
일반적인 상황에서 각 프로세스마다의 고유한 결과물이 기대되는지 여부를 기준으로 정리하였습니다.
현실의 다양한 상황에서는, 서비스나 추진 과제의 속성마다 더 세부적인 단계가 필요하기도 하고 어떤 단계는 없어도 되기도 합니다.
이번 글에서는 프로세스에 집중하여 설명하지만,
각 프로세스에서 기획자가 해야 하는 구체적인 업무는 별도로 시간을 내어 정리해볼 예정이에요.
서비스 전략
해결해야 할 문제나 비즈니스 기회가 포착되어 서비스를 만들거나 개선하여야 한다면
서비스 전략을 세우는 것부터 시작할 수 있습니다.
상황이나 사안에 따라 서비스 전략이라 부를 만한 별도의 프로세스를 거칠 수도 있고, 아닐 수도 있습니다. 별도의 프로세스가 없더라도 서비스의 전략을 세우고 생각해보는 것은 중요합니다.
여기서 서비스 전략은 해당 서비스의 목적을 설정하거나, 혹은 비즈니스 목적에 따라 서비스에서 전개해 나갈 방향성을 정의하는 일을 의미합니다. 그것을 위해 어떤 범위로 어떻게 실행해야 하는지도 수립합니다.
서비스 전략에 대해서 좀 더 이야기해볼게요. 전략 기획이라는 부서가 있죠. 여기서 쓰인 서비스 전략이라는 일은 전략 기획의 일과는 다른 일을 의미합니다.
전략은 군사학에서부터 유래한 단어라고 하는데, 보통 경영에서 쓰이는 단어입니다.
전략의 [사전적 정의](https://terms.naver.com/entry.nhn?docId=1139480&cid=40942&categoryId=31738)는 목적에 대한 적절한 결과를 달성할 수 있도록 계획, 조직, 그리고 수행하는 방책을 의미합니다. 그런 방책을 서비스 관점에서 전개하는 것을 서비스 전략이라고 할 수 있습니다.
전략 기획 부서에서 회사의 비즈니스 전략을 수립하지만 그 이외에 서비스 측면에서의 전략을 수립하는 것이 중요한 이유는 목적(가치)을 설정하고, 그를 이루기 위해 서비스가 가져야 할 방향성, 이하 다양한 기획마다 필요한 결정의 기준을 만든다는 점입니다.
이런 서비스 전략은 모든 과제마다 새로 수립하지는 않습니다. 새로운 서비스를 론칭하거나, 새로운 비즈니스 모델을 적용하거나, 서비스의 방향 전환이 필요할 때 진행하지요.
하지만 세부 기능을 구현할 때에도, 상위 서비스 전략과 방향을 맞추거나, 혹은 기능들을 연합하여 하위 전략을 세울 수 있기 때문에, 거창하게 보이는 전략 프로세스를 거치지 않더라도 서비스 전략이라는 부분을 고민해 볼 필요가 있습니다.
서비스 기획
기획의 사전적 정의는 어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것입니다.
그렇다면 서비스에 있어서 기획이란,
서비스 목적과 방향성에 맞게 성과를 낼 수 있도록 가장 적합하게 서비스를 설계하고 구현하는 계획을 세우는 것입니다. 즉 무엇을 어떻게 할 것인지 현실화할 수 있도록 구체적으로 정하는 일로써 무언가를 새로 만들거나 개선할 때 반드시 거쳐야 하는 업무입니다.
서비스 전략을 먼저 수립하게 되는 프로젝트도, 외부의 요구 사항에 따라 진행되는 프로젝트라 외부의 전략을 수용하는 경우에도, 기획 단계를 거치면서 구체적인 요구 사항이나 정책, 범위를 정하게 되죠.
서비스 기획 단계에서는 요구사항 정의서나 정책서 등이 대표적인 산출물입니다.
조직의 일하는 방식에 따라 산출물의 형식에는 차이가 있을 수 있습니다.
UI 설계
서비스 기획 단계에서 요구조건이 정의되고 정책이 정해졌다면 그에 따라 UI(User Interface) 설계를 하게 됩니다. 실제 사용자들이 인터랙션 하게 될 인터페이스를 정의하는 일이죠.
인터페이스 정의의 대부분은 화면을 정의하고 설계하는 일입니다(전체가 아닌 이유: 인터랙션 하는 요소에 대한 정의이기 때문에 화면 이외의 요소도 설계에 포함되게 됩니다).
따라서 이후 디자인 프로세스에 직접적인 영향을 주는 단계입니다. 개발 단계에서는 주로 클라이언트나 Front-End 개발자들이 이 정의 문서를 토대로 구현을 하게 됩니다. 그리고 QA(품질 검증) 단계에서 TC(Test-case) 목록을 작성할 때에도 그 기준이 됩니다.
디자인
인터페이스나 인터랙션에 대한 디자인을 하고 구현할 수 있도록 가이드를 만드는 프로세스입니다.
대부분 UI 설계를 토대로 디자인을 하게 되지만, 디자인을 거치면서 더 좋은 인터랙션을 반영하여 반대로 UI 설계에 영향을 주기도 합니다. 혹은 디자인 자체 과제로 진행되는 경우 UI 설계와 관계없이 디자인 프로세스부터 진행되는 경우도 있습니다.
디자인 단계의 산출물은 디자인 가이드입니다. 클라이언트 개발자들이나 Front-End 개발자들이 디자인 가이드에 맞춰 구현합니다. 동작에 대한 구현은 UI 설계서에 맞춰 진행하고 화면을 구성하는 것은 디자인 가이드에 맞춰 구현하게 됩니다.
개발
여기서는 개발 하위의 구체적인 프로세스는 중요하지 않아 하나의 프로세스로 표시했습니다. 실제로 동작되도록 구현하는 일이죠.
테스트
QA(품질 검증) 단계입니다.
개발된 산출물을 가지고 기획된 내용이 의도에 맞는지, 놓친 부분은 없는지, 기획된 내용에 따라 잘 구현이 되었는지 테스트를 진행하고 수정합니다.
위에 TC(Test-case) 목록을 작성한다는 언급이 나왔는데요, 중요한 부분을 놓치지 않거나, 혹은 기본 품질 검증에 대한 일관성을 맞추기 위해 테스트할 경우들의 목록을 만들어 놓는 것을 말합니다.
테스트가 반드시 TC로만 진행되지는 않습니다. 의도에 맞는지 테스트해보는 부분은 개발로 구현된 내용이 기획 의도에 맞는지 확인해 보는 부분도 있지만, 사용자에 빙의하여 산출물을 사용해봄으로써 원래 해결하려고 했던 문제가 의도에 맞게 해소되는지 테스트해보는 내용도 포함됩니다. 즉 구현해보니 사용자가 정말로 그 방법으로 문제가 해결되는지 테스트를 해보는 거죠.
출시와 운영
준비해온 서비스가 고객을 만나게 됩니다!
경우에 따라 정식 출시 이전에 베타 서비스로 먼저 시작하거나, A/B 테스트를 거칠 수도 있습니다.
데이터 분석/ VoC 분석
출시/운영되는 서비스가 의도했던 대로 고객이 잘 사용하고 있는지 확인하는 프로세스입니다.
정량적으로 데이터를 확인하거나 정성적으로 VoC 등을 확인해볼 수 있습니다. 시장에서 반응이 오는지 알 수 있겠죠? 놓쳤던 부분이나 부족한 부분을 알게 될 수도 있고, 전혀 다른, 새로운 인사이트를 얻을 수도 있지요.
이 결과들에서 인사이트를 잘 도출해야 이후의 방향에 옳은 결정을 할 수 있습니다.
다시 앞으로
잘 구현해서 사용자를 만난 것이 끝은 아닙니다.
이제 이 프로세스가 계속 순환하게 됩니다.
고객과 시장의 반응에 따라 서비스 전략을 수정하거나, 기획을 수정하거나, 인터페이스나 인터랙션을 개선할 수 있습니다.
이 순환이 계속되는 것이 서비스/프로덕트가 운영되는 기본 프로세스입니다.
이후 내용 스포일러
이 일반적인 프로세스에서 서비스 기획자는 어떤 일과 역할을 할까요?
‘기획자’라고 ‘기획'이라는 단어가 들어간 업무만 하지는 않습니다.
다음 내용을 기대해 주세요!
