[정책 기획] 서비스 정책서 작성하기

서비스 정책서 작성 시 고려사항

 

강의를 통해 만나는 실무 기획자들에게 서비스 정책서를 작성하는지, 사내에 정리된 서비스 정책 문서가 있는지 묻곤 한다. 놀랍게도 대다수 회사가 정리된 정책서를 가지고 있지 않다. 

기획자가 다수인 규모가 큰 회사조차 정리된 정책서가 없다 보니 서비스를 기획하면서 필요한 정책을 그때그때 작성하고 이 정책들이 파편화된 상태로 존재 및 관리되고 있다고 한다. 그러다 보니 하나의 플랫폼을 다수의 기획자들이 함께 기획을 하고 있는데 서로 다른 정책을 반영하여 기획자는 물론이거니와 사용자와 운영자, CS 담당자들조차도 혼동을 하고 파편화된 상태로 존재하다 보니 중복으로 작성하게 되며 신규 기획자가 입사했는데 정책 문서의 부재로 인수인계나 서비스를 파악하는데 시간이 오래 걸린다.

 

기획자에게 있어 서비스 정책서는 법과 같다. 

 

 

회사에서 CPO나 시니어 기획자의 중요한 역할 중 하나는 사내의 모든 기획자가 기획 시 준수하거나 구성원들이 참고할 수 있는 서비스 정책 문서를 작성하고 이를 지속적으로 관리 및 업데이트하는 것이다.

기획자가 서비스 정책서를 작성해야 한다고 하면 작성해 본 경험이 없다 보니 무엇을 어떻게 작성해야 하는지 묻곤 한다.

서비스 정책 작성 시 고려사항 및 그 순서

서비스 정책서는 불가항력적인 요소를 우선 고려하며 정책을 결정하고 문서로 작성해야 한다.

 

따라서 서비스를 기획하기 위해 참고해야 할 관련 법령을 먼저 검토한다.

한 스타트업이 혁신적인 서비스를 개발하기 위해 관련 법을 개정하거나 제정하는 건 사실상 불가능에 가깝다. 암호화폐로 인해 수많은 사람들이 피해를 봤지만 기존 금융 관련 법으로 규제할 수 없었고 이를 규제하기 위해 특금법이 개정되기까지는 수년이 걸렸으며 해당 법의 개정과 함께 수많은 거래소가 시장에서 사라졌다.

그리고 관련 산업의 생태계나 인프라 등의 외부 환경을 고려해야 한다.

한 스타트업이 상품을 팔기 위해 전자상거래를 기획하는데 CJ대한통운이나 우체국 등의 배송 요금이나 정책이 마음에 들지 않거나, SKT나 KT 등의 통신망이 느리고 장애가 많다며 기존 물류나 통신 인프라를 이용하지 않을 수는 없기 때문이다. 물론 쿠팡과 같이 물류 배송 인프라의 비효율성을 혁신하는 것이 관련 산업에서 소비자들이 느끼는 중요한 페인 포인트(Pain Point)라고 인식하고 이를 개선하고자 노력할 수도 있겠지만 대다수 스타트업이 생태계나 인프라를 혁신하는 것은 어렵기 때문에 기존 생태계와 인프라를 활용할 수밖에 없고 때문에 외부 환경을 고려하며 정책을 만들어야 한다.

또한 벤치마킹 과정에서 경쟁사를 고려해야 한다. 

관련 법령이나 인프라와 같이 경쟁사도 외부 요소이기 때문에 영향을 미치기 어렵기 때문이다. 벤치마킹 과정에서 모든 경쟁사들이 비효율적이지만 그렇게 개발을 한 데에는 보통 그럴 만한 이유가 있다. 물론 외부 환경을 고려할 때와 같이 이 부분이 고객의 페인 포인트라고 인식해 이를 혁신하여 차별성이나 경쟁력의 요소로 가져갈 수도 있겠지만 대다수 경쟁사에서 일하는 동종 업계의 사람들이 바보가 아닌 이상 그럴만한 타당한 이유가 있을 가능성이 크다.

마지막으로 내부 환경 및 리소스를 고려해야 한다. 

내가 주니어 기획자일 때 개발자는 10명도 채 되지 않는 소수인데 나의 기획 실력을 자랑하고 뽐내고 싶었는지 수백 장의 기획서를 작성한 적이 있다. 경영진에서는 내 기획의 방향이나 내용이 마음에 든다며 이렇게 개발을 진행하자고 결정을 했으나 방대한 기획량과 짧은 일정 탓에 몇몇 개발자들은 퇴사를 했고 인력이 오고 나가기를 반복하며 어렵사리 서비스는 오픈했지만 결국 실패했다. 기획자인 내가 내부 환경 및 리소스를 고려하지 않고 기획을 한 잘못이 컸다.

 

 

서비스 정책서 작성하기

 

서비스 정책서는 고객의 회원 가입에서부터 회원 탈퇴까지 서비스를 기획하는데 필요한 정책을 정리한 문서이다. 때문에 해당 도메인에서 서비스 정책을 수차례 작성해 본 경험이 없다면 시니어 기획자라 하더라도 서비스에 필요한 모든 서비스 정책을 정리하고 작성하는 것은 매우 힘들고 어려운 일이다.

 

서비스 정책서는 회원 가입에서부터 탈퇴까지 기획에 필요한 정책을 정리한 문서이다.

 

서비스 정책을 작성하기 위해서는 모두가 관련 도메인 및 법령 전문가가 아니기 때문에 시장조사 및 벤치마킹 과정에서 경쟁사의 이용약관 및 개인정보 처리방침, 서비스 정책 등을 읽으며 관련 법령을 모두 뽑아내고 해당 법령을 살펴봐야 한다.

나의 경우에도 이직을 하면서 새로운 도메인이나 서비스를 기획하게 되면 경쟁사를 벤치마킹하며 위 과정을 똑같이 거친다. 경쟁사 서비스를 벤치마킹하기 위해 회원가입을 하는 과정에서 가장 먼저 보게 되는 것이 이용약관이나 개인정보 처리방침 등의 서비스 약관인데, 특히 개인정보 처리방침을 읽게 되면 해당 서비스를 운영하기 위해서 수집하는 개인정보나 제휴사, 솔루션 등을 확인할 수 있다. 그리고 경쟁사 서비스를 이용하면서 접하게 되는 모든 법 조문 등은 직접 해당 조문을 찾아봐야 한다.

 

또한 IT 관련 법이 개정되었다는 기사나 소식을 들으면 해당 내용을 반드시 찾아봐야 한다.

전 세계가 AI 주도권을 놓고 치열한 경쟁을 하고 있는 상황에서 AI 발전을 위해서는 빅데이터의 활용이 중요하다. 하지만 개인정보 보호를 위해 제정된 기존 법령으로는 데이터의 활용이 어려워 빅데이터의 이용을 활성화하기 위해 2020년 1월에 통칭 데이터 3법이라는 개인정보 보호법, 정보통신망법, 신용정보법 개정안이 국회를 통과하였고 이 법령 개정으로 인해 수많은 금융기관과 IT기업들이 마이데이터 사업을 추진할 수 있었다. 금융 서비스 기획자가 해당 법령이 개정되었다는 사실조차 모르거나 이해하지 못했다면 경쟁사에 비해 마이데이터 사업 준비나 진출이 늦을 수밖에 없을 것이다.
구독 결제 서비스가 늘어나며 구독 경제를 통한 소비자 피해 사례가 늘어나자 2021년 8월, 여신전문금융업법 시행령이 개정되며 무료 이용 제공 후 유료 전환 시 7일 전 사전 통지를 하고, 해지 시 사용 일 수에 따라 환불을 해야 한다는 등 소비자를 보호하기 위한 여러 규제가 시행되었다. 당시 구독 결제 서비스를 기획하던 나의 경우에도 시행일자 전에 이를 반영하기 위해 개정 내용을 살펴보고 서비스에 반영했는데, 기획자가 해당 개정 사실을 모르고 있었다면 어떻게 될까?

때문에 기획자는 새로운 서비스 아이템을 찾거나 관련 법령을 준수하기 위해서라도 IT 관련 법의 제정 및 개정 소식에 관심을 가져야 한다.
나의 경우, 브라우저 즐겨찾기에 ‘찾기쉬운 생활법령정보, 국세법령정보시스템, 개인정보 포털’등이 최상단에 고정되어 있을 정도로 빈번하게 관련 법령 정보를 찾아본다.

 

기획 시 관련 법령을 찾기 위해 가장 자주 방문하는 찾기쉬운 생활법령정보 사이트

 

처음 정책서를 작성한다면, 회원가입에서부터 회원탈퇴까지 필요한 모든 정책을 한 번에 작성하는 것은 어렵고 오랜 시간이 걸릴 수밖에 없다. 그렇다고 프로젝트를 진행하는데 갑작스레 정책서가 필요하다며 이를 작성하기 위해 많은 시간을 소비한다면 회사와 동료들에게 그 피해가 고스란히 돌아갈 수 있다.

때문에 경험이 많거나 관련 템플릿을 가지고 있을 시니어 기획자가 빠르게 작성하는 것이고, 주니어 기획자라면 한 번에 작성할 수 없기 때문에 프로젝트를 진행하며 필요한 정책을 기획서 작성 전후에 틈틈이 작성하고 다수의 프로젝트를 진행하며 그 문서를 지속적으로 관리하고 업데이트해 나가야 한다. 이런 과정을 반복하다 보면 어느 순간 완성된 정책서 템플릿을 소유하게 될 것이고 대다수 서비스들이 동일한 정책을 적용하는 경우가 많아 조금씩 수정해서 사용하면 된다. 그렇게 반복해서 정책서를 작성하는 연습을 하게 되면 신규 서비스를 기획하더라도 템플릿을 활용해 정책서를 작성하는데 며칠 걸리지 않을 것이다.

 

반면, 정책서를 작성하는 데는 며칠이면 충분하겠지만 이 정책서를 가지고 유관 부서나 담당자와 협의하고 확정하는 데에는 꽤 오랜 시간이 필요할 수 있다.   

 

서비스 정책을 확정하지 않고 기획서를 그려 디자인 및 개발 중에 기획서를 수차례 수정하는 실수는 하지 않기를 바란다.

 

 

서비스 정책 확정 및 공유하기

 

서비스 정책서에 포함된 내용 중 일부는 경영진이나 비즈니스팀과 협의가 필요하거나 그들의 요구사항일 것이다.

때문에 최초 정책서를 작성하거나 해당 정책이 새롭게 추가되는 내용이라면 그 초안을 가지고 유관 부서나 담당자, 필요한 경우 경영진에게 공유하고 합의에 이를 때까지 피드백 및 수정을 반복하게 된다.

 

정책서를 수차례 작성하다 보면 정책서를 작성하는 데는 며칠 걸리지 않는데 이 협의를 하는 과정이 꽤 오래 걸린다.

한 번은 정책서 초안을 작성하는데 일주일 밖에 걸리지 않았는데 유관 부서들이 많다 보니 협의하고 확정하는데 까지 한 달이 걸렸다. 그렇게 한 달이 걸렸음에도 불구하고 몇몇 사안은 끝까지 합의가 이루어지지 않아 결국 경영진이 최종 결정을 했다. 프로젝트가 너무 지연되는 것을 막고 그 정책으로 인해 발생할지 모를 문제에 대한 책임을 경영진에게 전가하기 위해서다. 보통 이렇게 끝까지 협의가 이루어지지 않는 경우는 프로젝트의 일정이나 비용에 큰 영향이 가는 의사결정이거나 불법적인 결정일 가능성이 크기 때문이다.

그리고 이렇게 확정된 정책서를 유관 부서 및 담당자, 프로덕트팀에 공유하게 된다.

이렇게 힘든 과정을 거치며 정책서를 작성하고 협의하는 이유는 기획서나 목업을 작성하거나 디자인 및 개발을 하는 과정에서 정책의 변경이나 수정을 최소화하기 위해서다. 정책 수준의 변경이 아니더라도 기획과 디자인, 개발 과정에서 이런저런 이유로 수많은 변경과 수정을 하게 된다. 그런데 단순한 기능이나 디자인의 변경은 그리 많은 시간이 소요되지 않을 수도 있지만 보통 정책의 변경은 프로세스와 같이 여러 페이지나 기능에 영향을 미치는 큰 변경일 가능성이 크다.

프로덕트팀에서 업무에 따라 소요되는 시간을 단순 비교하기는 어렵지만 하나의 기능을 구현하기 위해 기획자가 1시간을 소요하였다면 디자이너는 2시간이 소요되고 개발자는 4시간이 소요된다. 그런데 기획자나 디자이너는 보통 1~2명인데 반해 개발자는 다수이기 때문에 4시간 x N명이라고 가정하면 기획자가 정책서를 작성하고 이를 협의하여 확정하는 것이 얼마나 중요한지 알 수 있다. 때문에 한번 작성되어 확정된 정책서는 제품 개발이 완료되기 전까지 최대한 변경되지 않도록 하는 것이 기획자에게 중요한 역할이고 프로덕트 매니저로서 프로덕트팀으로부터 신뢰를 쌓을 수 있는 중요한 역량이다.

 

너무 중요하기 때문에 다시 한번 강조하자면, 서비스 정책서는 기획자에게 법과 같은 문서다.

특히 다수의 기획자가 한 플랫폼을 기획하고 있다면, CPO나 시니어 기획자는 서비스 기획자 모두가 참고하고 준수하며 기획을 할 수 있도록 서비스 정책서를 만들고 이를 공유 및 관리해야 한다. 신규 서비스나 기능 기획 시 기존 정책서에 필요한 정책이 없는 경우에는 담당 기획자가 정책 초안을 작성하고 유관 부서의 협의를 거쳐 CPO나 시니어 기획자 또는 전체 기획자 그룹에 검토를 받아 서비스 정책서에 추가하는 과정을 거치며 전사 정책서를 업데이트 및 관리해 나가야 한다. 그리고 개발자와 디자이너가 소스코드 및 디자인 결과물을 공개 및 공유하며 함께 성장하듯이 이런 문서들이 외부로 공개 및 공유되어 기획자들도 함께 성장할 수 있는 문화가 확산되었으면 하는 바람이다.

 

 

세균무기가 알려주는 서비스 기획의 모든 것 | 세균무기 - 교보문고