by
Oct 15. 2023
#19 잘 만든 서비스 정책서
2023년 41주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/66
다음 회고 ☞ https://brunch.co.kr/@327roy/68
노트
#1 잘 만든 서비스 정책서
#서비스정책서 #기획
이전 회사부터 서비스 기획 업무를 진행하며 여태 가지고 있는 갈증이 하나 있다. 이는 바로 ‘잘 만든 정책서’에 대한 것. 기획자 커뮤니티 올라온 ‘세균무기’님의 정책서 관련 글이 인상 깊어 이 노트를 작성했다.
우리는 기획자로서 어떤 기획을 하는 데 있어서, 그 산출물이 지켜야 할 규칙, 원칙을 규정하게 된다. 이를 우리는 서비스 정책이라고 부른다. 그래서 서비스 정책서는 제품/서비스에 대한 헌법 역할을 수행하게 된다.
이때 서비스 정책서를 만들 때마다 항상 하는 고민이 있다. 우리는 어느 정도의 정책을 '개발을 위한 스토리보드'에 녹이고, 어느 정도의 정책을 '서비스 정책서'로서 관리하는 것이 효율적일까?
고민의 이유는 서비스 정책서의 독자(개발자, 후임 기획자 등)의 관점으로부터 시작된다. 서비스 정책서를 엄격하고, 꼼꼼하게 작성할수록 정책서의 내용이 비대해지고, 복잡해지기 때문에 아래와 같은 문제가 발생할 수 있기 때문이다.
1. 서비스 정책서 자체의 사용성 하락
2. 프로젝트 수행을 위한 비용 증가
관리하는(확인해야 하는) 문서와 텍스트가 많아지면 결국 정책서의 1) 정책서의 활용 난이도가 올라가고, 2) 정책서 학습을 위한 러닝커브가 발생하며 3) 서비스 정책서를 업데이트하는 것에 대한 관리 포인트가 생기는 것이 원인이다.
ⓒ 세균무기 님우선 위 고민을 안고도 나는 서비스 정책서를 작성하긴 한다. 이때 주로 신경 쓰는 포인트는 세균무기님이 작성한 글(위 사진)처럼 제품에 대한 사용자 생애 주기 관점의 프로세스 단위로 나누는 것이다.
예를 들어, [배너]를 관리하기 위한 정책이라면 1) 이를 위한 데이터 속성 정의, 2) 데이터 처리 플로우, 3) (필요하다면) 운영 정책을 작성하는 것처럼 말이다.
이때 기능 동작을 위한 자세한 로직의 경우 서비스 정책서가 아닌 기획서의 스토리보드로 갈음하게 되는데, 이 때문에 특정 기능에 대한 상세한 내용을 확인할 때는 해당 기능과 관련한 역대 기획서를 모두 뒤져봐야 할 수도 있다는 단점이 있다. 그래서 누구나 필요할 때 꺼내볼 수 있는 기획서와 정책서를 만드는 것이 더욱 어려운 것 같다. (비슷한 예로는 용어 사전, 라이팅 가이드 등)
이 고민에 대한 시니어 기획자분의 조언이 인상 깊어서 남겨놓는다.
”정책서는 기준이 되는 법을 제정한다는 생각으로 접근을 하고, 정책서는 100% 완벽할 수 없기 때문에, 향후 발생하는 이슈에 대해서 관리가 필요하다고 판단되면 정책에 포함, 이외의 것들은 그때그때 설계서에 포함하는 게 맞는 것 같습니다.
일단 '법'이 있으면 기준이 생기고, 애매하다 싶은 건 보통 그런 일이 발생했을 때 법원에서 판결(내부 협의 및 판단) 하잖아요. 그런 이치인 것 같습니다.”
https://germweapon.tistory.com/412
#2 생산성에 대한 고찰
#생산성 #일
요 근래 제품을 위한 사용 가이드 초안을 잡고 있는 것이 있다. 이를 위해 동료 기획자들의 기획서를 분석하며 기획 의도와 산출물을 분석하고 있는데, 한 동료 기획자의 기획서 내 백그라운드 리서치 중 생산성에 대한 내용이 꽤나 인상 깊었다.
그가 인용했던 생산성에 대한 정의가 아주 와닿았는데, '사람들이 살고 있는 환경은 그 어느 때보다도 더 산만하고, 생산성을 유지하는 것은 그만큼 어렵다. 하지만 생산성은 더 많은 일을 하는 것이 아니라, 같은 양의 일을 얼마나 더 효율적으로 하는지를 의미한다. 즉, 불필요한 일을 얼마나 하지 않는지가 중요하다'는 내용이었다.
반대로 말하면 정말 필요한 일만을 하는 것. 그러면 정말 필요하는 일은 무엇이라고 생각할 수 있을까?
기획자의 입장에서는 제품을 위한 기획을 할 때, 진행 중인 일의 프로세스가 뒤로 돌아오지 않고 앞으로 나아가게 하는 일들을 먼저 생각할 수 있다.
예를 들어 수집한 백로그를 그루밍한 후, 이해관계자들과 산출물의 컨셉을 정하는 회의를 가졌다. 이후 이를 구체화하여 이해관계자들과 제작을 위한 리뷰를 가진다고 가정해 보자. 이 상황에서 프로세스가 앞으로 나라간다는 것은 리뷰의 결과가 기능에 대한 아이디에이션으로 돌아가는 것이 아닌, 제품 제작 플래닝을 하는 것으로 진행 단계가 나아가는 것을 말할 수 있다.
나는 이를 '리뷰(회의)를 위한 어젠다가 강력하게 정의되지 않았기 때문인 것'을 원인 중 하나라고 생각한다. 이런 비효율적인 일의 반복이 결국 업무의 생산성을 저하시킨다는 것. 이를 일각에서는 '가짜 일'이라고도 부른다.
혹은 다른 예시로 업무를 위한 업무, 회의를 위한 회의, 보고를 위한 보고자료 작성과 같은 일을 줄이는 것을 말할 수 있을 것이다. 이에 대한 내용은 아래 브렌트 피터슨이라는 분에 대한 글을 읽어보면 좋을 듯하다.
백로그 그루밍이란 애자일 방법론에서 나오는 말 중 하나로, 1) 제품 백로그 항목을 새로 만들거나 정제(세분화), 2) 제품 백로그 항목 추정, 3) 제품 백로그 항목 우선순위 선정하는 과정을 의미한다.
https://www.chosun.com/site/data/html_dir/2016/11/09/2016110900533.html
#3 요즘 하는 일: 제품 사용 가이드 제작
#사용가이드 #리드미
현재 프로젝트와 관련해서 나는 우리가 만드는 제품의 '사용 가이드'를 제작하고 있다. 아직 운영인력이 배정되지도 않았고, 제품을 기획한 기획자가 가이드를 더 몰입해서 쓸 수 있을 것이기 때문에 다른 분들의 기획서를 분석하며 직접 초고를 작성하고 있다.
사실 지금 회사에 있는 기존 제품의 경우 '노션+우피'를 활용해 작성한 사용 가이드를 가지고 있었는데, 나는 1) 검색의 용이성, 2) 직관성이라는 두 가지를 주 이유로 별도 가이드 제작 툴을 사용해서 가이드를 제작 중에 있다.
'노션+우피' 조합의 불편함과 아쉬움이 존재했기 때문에 다른 툴을 사용하는 만큼, 여러 가이드 제작을 위한 툴과 타 서비스의 레퍼런스를 찾아보고 있었는데, 올해부터 꽤 많은 스타트업들이 기존 사용하던 '노션+우피' 조합을 벗어나 ReadMe, Archbee, Gitbook 등의 가이드 문서 제작 툴로 가이드를 이관하는 것을 확인할 수 있었다.
서비스를 리서치하다 보면 이렇게 제품을 보조하는 툴의 이동 현상을 가끔 확인할 수 있는데, 개인적으로는 사용 툴 이동에 대해서 1) 시기에 따라 사용자가 효용성을 느끼는 가치가 바뀌는 것과 2) 유행 이 두 개를 주된 원인으로 보고 있다.
예를 들어 한참 '노션+우피'의 조합이 떠오르던 작년 초에는 누구나 쉽게 만들 수 있는 웹 페이지라는 풍토가 유행했고 현재는 조금씩 바뀌는 것처럼 말이다.
가이드를 직접 제작하면서 느끼는 것은, 제품의 가치를 명확하게 전달할 수 있는 툴을 사용하는 게 좋다는 것. 가이드를 제작하는 것을 기준으로 말하면, 당시 유행하는 제품 보조 툴(위에서는 '가이드 제작 툴')의 유행 이유를 알아두면 좋긴 하지만, 가장 중요한 것은 이 툴을 통해 1) 제품의 가치 전달이 얼마나 쉬운지와 2) 사용자가 얼마나 사용하기 편한지라고 생각한다.
p.s.
사실 이 관점으로 봤을 때 현재 진행 중인 작업 또한 아쉬운 부분이 없는 것은 아니다. 여러 이유로 인해 사용 중인 가이드 툴이 원래는 API 문서 관리에 초점이 맞춰져 있기 때문이다.
이 툴은 API 엔드포인트를 툴과 연결해 API 문서 업데이트 등을 자동화하거나, 사용자가 제품의 API에 대한 콜백을 테스트하는 등의 작업을 더 원활하게 수행할 수 있도록 도와주는 툴이다.
하지만 우리는 현재 사용자가 사용할만한 API가 없기 때문에, 툴의 진가를 현재로서는 완전히 끌어낼 수는 없기 때문이다. 그럼에도 불구하고 제품의 가치를 전달한다는 것을 기준으로 툴을 선택한 것이기 때문에, 툴을 온전히 사용하지 못하는 것에 대한 아쉬움은 나중에 풀 생각이다. (기회가 되면 개발자들에게 이런 방법이 있다는 것을 정리해서 전달할 생각이다.)
뭐든 현재 제작 중인 사용 가이드와 가이드 제작을 위한 규칙을 모쪼록 잘 마무리 지을 수 있길 바라고 있다.
p.s.2
별개로, 가이드 제작 시 가장 고민되는 것이 있다. 가이드의 보이스 앤 톤 등 디테일한 부분도 있지만, 가이드를 사용하는 이유인 '사용자가 필요한 정보를 용이하게 확인'하는 것. 이를 위한 첫 번째 관문이 가이드 페이지에 대한 메뉴 구조도를 정하는 것이 꽤나 어려웠다.
제품이 어느 정도 성숙되어 있다면 메뉴 구조도의 기준을 [사용자 여정(내지 사용자 시나리오)]으로 잡았을 것 같은데, 제품의 성숙도가 높지 않기 때문에 현재는 메뉴 구조도의 위계를 [대메뉴 > 주요 기능(사용자 행동 단위)]로 잡고 만들고 있다. 언젠가 가이드 페이지가 늘어나게 되면 소메뉴로 그룹핑을 한 번 더 할 듯.
#4 간만에 클럽하우스
#클럽하우스 #기획자 #프로덕트매니저 #퍼즐러
간만에 기획자들의 클럽하우스에 참여했다. (월요일 밤 10시에 진행됨)
클럽하우스의 주제는 저번 주간 회고에도 작성했던 ‘에어비앤비가 PM직무를 없앤 것, 그리고 디자이너가 PM대신 비즈니스를 리드해야 하는지’에 대한 것과 관련되어 있다. 결국엔 직무별 역할의 고착화에 대한 내용.
만담에서 지배적인 내용으로 다루어진 것은 결국 현재 우리나라의 개발조직(기획, 디자인, 개발)의 가장 큰 문제가 직무와 방법론에 너무 매몰되어 있다는 것 같다는 내용이다. 어느 정도 연차가 쌓이거나, 내공이 깊은 시니어분들과 얘기를 하다 보면 자연스레 생각하게 되는 문제 중 하나라고 생각한다.
이번 만담에서 시니어분께서 한 말 중 기억에 남는 것은 10년 전 정도만 해도 개발 조직의 가장 큰 문제가 '역할의 모호함과 방법론/프로세스의 낙후됨’이었다는데, 빠르게 현대화 시키다 보니 오히려 독이 되어 버린 것이 아닌지에 대한 내용이었다.
공감되었던 것은 역할과 프로세스를 정하는 이유는 서로 협업을 더욱 잘 하고, 업무의 효율을 올리기 위해서라는 것. 하지만 역할과 방법론에 매몰되다 보니 ‘나는 기획자인데 이 업무를 내가 왜 하는 거지? 이것은 디자이너가 하는 일 아닌가?’와 같이 씬에서 보편적인 방법론과 역할에 매몰된다는 것이었다. 역할과 프로세스를 나눈 본래의 의미가 희미해진 채로 말이다.
나 또한 제일 동의하는 내용은(재직 중인 회사도 추구하는 방향은) 직면한 문제를 해결할 수 있는 가장 적합한 사람이 그 문제를 해결하면 된다는 것이다.
특히나 기획자나 프로덕트 매니저는 ‘제품을 잘 만들고 키우기 위한 사람’이기 때문이다.
#5 사내 개발자 컨퍼런스 후기
#컨퍼런스 #개발자
이번 주에 사내에서 개발자 컨퍼런스를 진행했다. 프로덕트 디자이너와 프론트엔드 개발자들이 조직의 업무 프로세스 효율 향상을 위해 만든 결과물에 대한 사례 공유를 중점으로 진행된 컨퍼런스다.
간략하게 인상 깊었던 말에 대해서 남겨둔다.
1. Form follows function
- 프로덕트 디자이너가 발표의 운을 뗄 때 인용한 말이었다.
- 미국의 유명 건축가 '루이스 설리번'이 했던 말로 '형태는 기능을 따른다.'는 뜻인데, 이 원칙은 기본적으로 어떤 물체나 구조의 형태는 그것의 기능에 의해 결정되어야 한다는 것을 의미하고 있다.
- 자사에서 제공 중인 제품의 경우 피그마로 만든 스타일 가이드를 가지고 있는데, 이 스타일 가이드의 근간을 이루는 철학으로 사용하고 있다고 한다.
2. 디자인 패턴
- 디자인 패턴은 1) 제품 디자인과 UX의 디자인 일관성을 유지하고 2) 화면 설계의 효율을 올리기 위해 만든다.
- 예를 들어, '사용자 확인을 받은 후 데이터를 수정하는 프로세스'가 기획에 들어간다고 했을 때, 미리 만들어 둔 디자인 패턴을 사용해서 UXI의 일관성을 유지할 수 있다.
- 따라서 디자인 패턴은 1) 예시와 2) 원칙Principle로 구성되어 있다. 예시는 중국 Ant Group의 Ant Design을 참고하면 될 듯.
3. 기능 조직과 목적 조직, 그리고 성과
- 사내에서 기능 단위로 모여있던 조직이 목적 형태의 조직으로 바뀌는 중이다.
- 이번 컨퍼런스에서 관련 내용을 일부 다뤘는데 인상 깊었던 것은 OKR의 핵심결과(KR)를 기준으로, 각 KR을 담당하는 스쿼드를 구성한 것. 스쿼드는 KR을 달성하기 위한 직군들로 골고루 구성되어 있고, 이렇게 구성된 스쿼드는 각자의 목적(KR)을 달성하기 위해 스프린트를 돌린다.
- 개인적으로 생각하는 발생 가능한 문제는 목적 조직의 타깃이 '만들어 내야 하는 성과(KR)'로 설정된 것이다. 하나의 조직 내에서 존재하는 성과는 다른 성과와 연관성 혹은 의존성을 띌 수 있기 때문이다. 예를 들어 조직의 KR이 '사용자 000명 확보'와 'MAU 000명 증가'라고 했을 때, 사용자가 확보되는 것과 MAU가 증가하는 것에는 연관성이 발생할 수밖에 없다.
- 이로 인해 파생될 수 있는 문제는 스쿼드 간의 리소스 배분 문제가 있지 않을까.
- 그럼에도 불구하고 인상 깊었던 것은, 이러한 가능성을 열어두고 조직을 개편하고 도전하는 것에 대한 실험 정신이었다. 잘 되었으면 하는 바람이다.
#6 이외 자잘한 생각들
#생각 #노트
1. 시스템화
- 시스템화의 이유는 반복되는 업무에 대한 패턴을 찾아내고, 이를 규격화 함으로써 비슷한 상황에 대한 대응 효율성을 높이는 것이라고 생각한다. (시스템을 개발한다는 의미가 아니다.)
- 시스템화를 하는 것은 업무의 효율성을 증대시키기 위해서 필요한 과정이지만, 시스템화를 위해 규격화된 내용들이 어려워질수록 사용자들이 제대로 사용하기 위한 학습이 필요해진다.
- 사람의 행동에는 관성이 존재하기 때문에, 시스템을 따르는 것에 대한 익숙함이 궤도에 오르기 전까지 지속적인 관심을 유도하기 위한 촉진이 없으면 원래 하던 대로 돌아가게 된다.
- 그래서 느끼는 것은 시스템화를 제대로 하기 위해 필요한 것으로는 구성원들이 내재화를 할 수 있을 정도의 동기 부여(공감대 형성) 일 듯하다.
2. 그룹핑
- 항상 어려운 것은 그룹핑이라는 생각을 한다. 그룹핑의 과정은 어떤 것을 개념화하고, 그 개념화한 것들을 공통점으로 묶어 다시 한번 개념화하는 것으로 이루어지는데, 그렇기 때문에 어렵다.
- 이 그룹핑을 개념화의 일종으로 봤을 때 결국 이 그룹핑의 과정은 세상을 살아가는 사람들이 모두 하게 되는 것이다. 우리가 일상생활에서 그릇, 포크, 수저, 국자 등을 '주방용품'으로 분류해서 함께 보관하는 것부터 서비스를 이용하는 사용자로부터 관리할 아이디, 비밀번호, 이메일, 전화번호 등의 데이터를 '회원정보'로 분류하는 것까지 모든 것이 그룹핑의 과정이다.
- 그룹핑과 관련해서 다른 사람의 인상 깊은 고민을 스크래핑해둔 것이 있는데, 이를 다시 읽어봤다. 어떤 프로덕트 디자이너의 아토믹 디자인 패턴 실행에 대한 여정을 담은 글이다. 아래 사진은 디자인의 컴포넌트들에 아토믹 방법론을 적용한다고 했을 때, 이를 Meocules로 그룹핑할 것인지, Organisms로 그룹핑할 것인지에 대한 고민이다.
ⓒ velog.io/@teo