4주차) 02 - 01 - 규제

규제와 서비스 기획자

 

규제샌드박스

• 사업자가 신기술을 활용한 새로운 제품과 서비스를 일정 조건 하에서 시장에 우선 출시해 시험, 검증할 수 있도록 현행 규제의 전부나 일부를 적용하지 않는 것을 말하며 그 과정에서 수집된 데이터를 토대로 합리적으로 규제를 개선하는 제도이다.
• 위 사진은 샌드박스 신청과 승인 플로우이다.

서비스 약관과 정책서

• 새로운 서비스를 만들거나 기존 서비스의 새로운 기능을 만들 때 새로운 서비스인 경우 신규 약관과 개인정보 동의서를 신규로 만들어야 하고 기존 서비스의 신규 기능을 만들기 위해서도 역시 기존 약관과 개인정보동의서에 대한 추가 또는 변경이 일어날 수 있다.
• 서비스 기획자가 세세하게 알 수 없기 때문에 사내 법무팀이 있으면 기획 전부터 이러한 법 부분에 대한 법무 가이드라인이 있는지를 확인해야 한다.
• 어떤 목적으로 어떤 서비스를 할 것이고 이에 대한 고객의 어떤 정보를 어떻게 수집해서 어디에 활용된다라는고객 정보의 흐름에 따라서 정리한 문서를 바탕으로 법무팀과 커뮤니케이션할 수 있다.
• 중요한 점은 내가 서비스하고 만들려고 하는 해당 정책의 법률의 근거까지 확인을 꼭 해봐야한다.
• 제휴사가 늘어나거나 법이 바뀌거나 다루는 업무가 늘어나면 바뀐 만큼 약관도 업데이트를 해줘야 한다.

회원 정책 정책서 작성

• 정책서는 서비스의 용어와 기본 운영정책을 정의한 프로젝트 산출물로 해당 정책서를 통해서 서비스의 용어를 통일하고 비즈니스에 대한 방향성을 이해할 수 있다.
• 정책 정의를 위해서는 서비스의 비지니스 구조와 운영 프로세스가 먼저 확정되어야 하기 때문에 관련된 담당자들과 어떤 프로세스로 운영할지 커뮤니케이션을 통해 서비스 방향과 전략이 포함되어 있어야 한다.
• 각각의 모듈이나 기능 별로 정책을 만들어서 관리를 하는 게 좋다.

요구사항 정의서 PRD(Product Requirement Document)

• 신규 서비스(기능 포함) 업데이트 및 기존 서비스의 변경 등 서비스의 변화를 가져오기 위해 변경 요구사항을 정의하는 것
• 외부 요구사항과 내부 요구사항으로 나뉘게 된다.
• 내부 요구사항은 개발팀 내부에서 정의한 이야기, 외부 요구사항은 주로 서비스를 운영하는 운영팀이나 새로운 상품을 만들어야 하는 사업개발팀에서 문의가 많이 들어온다.
• 도입 배경 및 목적 - 문제가 무엇이며 이를 통해 어떤 개선을 원하는지
• 타깃 고객 - 해당 문제를 겪고 있는 타겟 고객이 누구인지
• 기대효과 - 이를 통해 예상되는 효과
• 고객 기준의 Flow-Chart - 변경 이후 고객은 서비스를 어떻게 사용할 수 있을지
• 기능 정의 - 실제로 문제를 해결하기 위한 방안 UI를 제안하면 안 된다.
• 요구사항 정의서 작성 순서
  • 요구사항 정의 -> 초안 작성 -> 협업 논의(법무, 재무, 디자인, 개발 등) -> 초안 수정 -> 개발 조율(UI설계, 개발일정 등)