[일하다보니...] 정책 템플릿을 수정해서 제안해보았다.

회사에서 정책 템플릿을 처음으로 도입했다.

우리 회사에는 기획자가 없다.

그렇기 때문에 디자이너에게 기획의 역할이 더 무게가 실려 있는 듯하다.

(가끔은 아닌 것 같기도 하고)

 

최근 회사에서는 디자이너와 개발자 그 외 관계자와의 커뮤니케이션 비용을 낮추고, 기록을 위해 정책 템플릿을 도입했다.

원래는 늘 업무 미션을 받아 와이어프레임을 그린 뒤 관계자들과 주고받고, 정책 사항은 피그마에 나열하는 방식을 선택했었다.

그렇게 개발자들은 피그마 화면을 만들면서 개발을 해왔었다.

 

하지만 피그마에 모든 정책을 글로 정리하려고 하다 보니 어지럽기도 했고, 정책이 바뀌게 되면서 개발과 디자인 단에서 수정하게 되는 일도 잦았었다.

(개발자가 원하던 핵심 정책이 없는 경우도 있었고)

생각해 보니 서비스 정책이 나오면서 화면을 동시에 그리는 게 맞나란 생각도 들었다.

 

마침 회사에서 정책 템플릿에 도입에 대한 공감이 이루어졌었고, 공유되었던 영상의 메세지는 좋았다.

텍스트로 먼저 기능에 대해 나열하고 우선순위를 정한다면 더 효율적으로 소통할 수 있다는 것이다.

 

데이먼의 PM 일지

 

영상에서는 에픽 기반 유저 스토리(누가, 무엇을 위해, 어떤 기능을 원한다)를 작성한다.

여기서의 US-1, 2, 3...는 에픽을 달성하기 위해 고객이 볼 수 있는 큰 화면들에 작성된 것으로 보인다.

그렇게 영상 내용을 참고하여 사내에 첫 도입한 정책 템플릿은 아래와 같다.

그리고 사용하면서 어쩐지 불편함이 느껴졌다.

 

 

 

정책서는 어떻게 만들어야 할까?

정책 템플릿을 제안하기 전에 먼저 생각해 봤다.

내가 그전 회사에서는 정책에 대해 고려하면서 디자인했던가? 🙄

생각해 보니 의식하면서 만들진 않았던 것 같다.

 

PO가 걸어 다니는 정책이였으니 나는 그걸 토대로 사용성을 고려해서 서비스를 만들었다.

그 뒤에 PO가 개발팀으로 가서 지시하던 기억이 어렴풋이 났다.

 

서비스 정책까지 고려할 시간은 없었다.

회사가 살아남을 시간도 없어 보였으니 말이다.

그러니 정책에 대해서 다소 추상적으로 알고 있었던 것 같다.

 

그래서 정책에 대해 찾아보니 정책에는 크게 3가지의 개념이 있어보였다.

1. 서비스 정책

2. 개발 정책

3. 운영 정책

 

 

🙄 서비스 정책

서비스 정책이란, 서비스의 개념과 역할, 개략적인 구조가 정의되는 단계

 

프로덕트에 대한 목표, 컨셉, 정체성이라는 생각이 들었다.

프로덕트라는 국가가 있다면 그 국가가 보호되고 돌아가기 위한 법인 듯.

 

우리가 살아가고 있는 법이라는 테두리도 완벽하지 않다.

그러니 향후 발생하는 문제들이 있다면 얼마든지 새로운 법을 제안하고 유연하게 업데이트 해나가는 것이다.

하지만 여기서 중요한 점은 프로덕트의 목표와 컨셉에 맞춰 해당 법을 어떻게 정하고 바꿀 것인지가 주요한 포인트인 것 같다.

(Goal에 맞는 업무를 하자는 백엔드 개발자의 가르침이 있었는데, 이는 뒤에서 작성하겠다.)

 

서비스 정책을 정의할 때는 UI에 대한 논의도 필요 없다.

그저 비즈니스와 시장과 고객의 문제를 해결하기 위한 목표와 전략 수립만이 필요하다.

 

사실 서비스 정책을 정한다는 것, 그리고 상기시킨다는 것 중 가장 쉬운 건 하나인 것 같다.

우리가 이 프로덕트를 왜 만들었지?

이 프로덕트로 어떤 가치를 전달하려고 한 거지?

계속 물음표를 던지는 것이다.

 

 

🙄 개발 정책

개발 정책이란, 개발정의서, 개발명세서와 같이 앞서 정의된 서비스 정책을 기반으로 실제 서비스를 개발하기 위한 개발가이드이다.

 

개발 정책은 이름에서도 알다시피 개발자가 어떤 기능이 필요한지, 데이터는 어떻게 가공해서 보여줄 것인지 알 수 있는 가이드이다.

우리 서비스의 목표를 이루기 위해서 '이런 게 필요해요~'와 같은 거라고 봐도 될 것 같다.

 

디자인 - 프론트 - 백엔드가 잘 연결되기 위해선 어떻게 해야 할까?

기능과 기능의 상호 작용과 상관관계를 잘 이해하고 설명해야 한다.

 

디자이너가 기능 동작에 대해 굳이 알아야 하냐고 할 수도 있다.

하지만 실제 기능이 어떻게 되는지를 모르니 연결되지 않은 UI가 나온 적이 있었다.

플랫폼(iOS, Android)을 설정할 때 소셜 로그인 설정하는 컴포넌트가 각각 들어가 있고 가장 먼저 보였으면 좋겠다라는 요구사항을 전달받았었다. 그래서 플랫폼별 소셜 로그인 설정하는 것을 넣었었다. 하지만 알고 보니 소셜 로그인 설정은 플랫폼의 종속이 아니였다.

소셜 로그인 설정이 각 플랫폼 종속이 아니니 다른 방식으로 UI를 표현해야 하는 것이다.

 

뭐가 됐든 지금 회사에서는 정책서를 작성하는 것은 디자이너의 몫이다.

PM을 뽑아서 하든 PO가 하든...개발자가 하던...솔직히 관심 없다.

단지 서비스에 대해 더 깊은 이해를 하고 이해하며 프로덕트를 만들 수 있는 기회를 준다면 좋은 것 같다.

그러니 모르면 최대한 개발자 혹은 구성원들에게 물어보고, 이해하기 핵심 내용만 서술형으로 잘 작성되어야 한다.

 

 

🙄 운영 정책

서비스의 운영을 위해 고려되어야할 다양한 요소를 담아놓은 정책

 

해당 사항은 CS와 운영진이 어떻게 문의에 처리할 것인가에 대한 정의이기 때문에 생략하기로 했다.

 

 

😎 사내 백엔드 개발자분의 강연 아닌 강연

사내에 어떤 백엔드 개발자분께서 'Goal에 맞는 업무 방식' 도입에 대해 이야기를 해주셨다.

내용은 대충 이러하다.

목적을 달성하기 위해서 어떤 기술과 어떤 일들을 해야 할지 어떤 화면이 필요할지도 정해진다.

 

화면으로 이야기할 필요 없다.

어떤 화면이 필요하고, 어떤 컴포넌트에 내용이 필요한지, 그다음에 어떤 액션을 해야 하고 어떤 일이 발생하는지가 필요하다.

 

해당 기능은 어떤 데이터로부터 보여주게 되는지도 정의가 돼야 한다.

어떤 데이터인지 명확하지 않아도 되고, 무엇에 대한 입력 프로세스와 결과만 알면 된다고 했다.

(주어진 입력 데이터에서 원하는 결과값을 예측하는 것을 말하는 것 같다.)

 

해당 내용을 2~3번 이터레이션 하면 백엔드랑 프론트는 저런 데이터를 기준으로 DB 설계를 어느 정도 하고 거기에서 API들이 잘 나와서 돌아갈 수 있을지만 협의하면 시스템을 시작할 수 있는 설계안이 나온 것이고, 그땐 각자의 업무를 하면 된다고 한다.

 

프로덕트 안에서의 각 에픽의 목표도 프로덕트의 목표가 될 수 있다.

Goal이 있어야만 우선순위를 정할 수 있다.

어떤 시스템을 설계한다고 할 때 목표가 뭔지에 대해 물어봐야 한다고 했다.

 

이런 것들이 잘 정해지면 우리만의 헌법이 정해지는 것이다.

그 뒤에는 임원진이 바쁘다는 이유로 결정이 미뤄지는 일 없이 Goal을 기준으로 A, B, C 안이 나온다면 스토리를 가지고 결정하는 시간이 줄여야 한다.

리더가 결정해 줄 때까지 기다려선 안된다고 했다.

(사실 이게 100% 가능할지는 모르겠다. 하지만 안된다면 70%라도 줄여나가는 거다.)

 

 

 

수정한 템플릿을 제안해보았다.

사실 현재 회사에서는 기능에 대한 정의보다는 화면에 버튼이 있어야 한다던지, 화면에 들어가야 할 사항들을 빼곡히 적혀 있는 요구사항 명세서였다.

하지만 이렇게 모든 것을 작성하는 문서라면 보는 사람도 그렇고 작성하는 사람도 언젠가 큰 피로도가 올 것임을 예상한다.

그랬기에 기존 정책서에서의 불편사항을 토대로 개선되었으면 하는 건 크게 7가지 정도였다.

 

 

1. 백엔드 개발자가 말했던대로 서비스와 에픽의 목표 정의가 잘 됐으면 좋겠다.

지금까지는 에픽의 정확한 목표보다는 정의만 존재했다. 서비스와 에픽의 목표가 잘 정의돼서 기능 정의까지 잘 됐으면 좋겠다.

 

 

2. 큰 Flow를 볼 수 있었으면 좋겠다.

각 표에 화면에 필요한 요소들만 작성이 되면서 큰 흐름을 볼 수 없었다.

화면이 이어지는 플로우 그리고 그 안에 들어가는 기능이나 필수 요소들에 대해 나열될 수 있다면 더 빠르게 이해할 수 있을 것 같았다.

 

 

3. 해당 기능 혹은 정책에 대해 잘 아는 사람이 있다면 디자인과 개발 파트별로 담당자를 잘 알 수 있었으면 좋겠다.

물론 모든 기능이 빼곡히 다 적혀 있다면 좋겠지만, 이해가 안 가는 사항이 있다면 물어볼 사람이 누구인지 바로 떠오르지 않는다면 이것도 비효율이라는 생각이 들었다.

담당자를 한번 명시함으로써 담당자도 검토할 의무와 책임을 부여해야 하는 것이다.

 

 

4. 기능에 대한 우선순위가 명확해졌으면 좋겠다.

화면 상세 설명이 섞여 있다 보니 어떤 기능이 우선으로 필요한지 알 수 없었다.

그리고 화면 상세 설명 보다 기능 우선순위와 동작에 대한 설명이 있다면 화면에서도 어떻게 보여줄지 정해질 수 있을 것 같았다.

하지만 이는 템플릿에 녹여내진 못했다.

어떤 기능이 우선으로 필요한지에 대해 상단에 적어야 할지 고민이다.

 

 

5. 수정이 될 때의 히스토리는 페이지 안에서 작성됐으면 좋겠다.

화면에서 작은 요소가 수정이 될 때마다 v1.0, v1.1, v1.2, v1.3... 이런 식으로 버전이 계속 올라가는 방식을 취했었다.

하지만 이는 언젠가 v1.9.1, v1.2.9...로 라벨의 순서도 많아질 것으로 보였다.

그렇기 때문에 큰 업데이트만 v1.0, v.2.0, v3.0으로 달기로 하고 나머지는 페이지 안에서 바뀐 사항, 날짜, 담당자의 이름만 적는 것으로 바꾸었다.

 

 

 

6. 한 화면에서의 엣지케이스는 한 표 안에서 작성됐으면 좋겠다.

기존의 정책서에서의 가장 큰 불편함 중 하나였다.

US-01과 US-08, US-10은 사실 같은 화면이다.
흐름대로 표를 작성하다 보니 한 화면에 대한 요구사항이 끊기고, 정작 봐야 할 내용을 보기엔 피로도가 높아졌다.

그랬기에 한 화면에 대한 엣지케이스는 전부 한 표 안에서 확인할 수 있는 방안으로 바꾸었다.

 

7. 세세한 정의가 많아질 수록 나중에 유지보수가 어려울 것 같다.

모든 기능과 요구사항에 대해 나열해서 적었다.

글이 많아질수록 봐야 할 정보는 넘쳐나고, 중요한 핵심 내용을 놓치게 된다.

우리가 쓰는 방식은 보통 외주를 맡길 때 쓰는 방식이고, MVP를 출시해서 빠르게 바뀌게 되는 경우에 적합한 문서는 아닌 것 같다.

정책서에는 서비스 정책, 기능 정책, 필수 화면 지시사항 몇 가지 정도로만 작성되고 세세한 건 피그마에서 관리되어야 한다고 생각한다.

하지만 이는 기존의 방식을 아예 뒤엎는 것이 되어버리기 때문이다.

일단 지금은 화면이 없는 상태에서는 요구 사항을 전부 적고, 화면이 이미 나와있는 상태에서는 전부 적지 않는 방식으로 해보는게 나을 것 같다.

 

 

🐷 해당 내용으로 개선한 템플릿을 제안하였다.

물론 일부 템플릿에 담아내지 못한 것들도 있긴 했다.

화면 요구 사항을 다 적지 않는다든지 기능 우선순위를 명확하게 알 수 있도록 하는 것들 말이다.

하지만 우선 개선할 수 있는 사항들 먼저 공유하였고, 개발 리드 분과 동료 디자이너의 피드백을 토대로 아래의 템플릿이 1차 마무리되었다.

템플릿 개선사항 피드백

1. 개발 논의 및 협의, 히스토리는 변경 사항이 있는지 파악이 쉬웠으면 좋겠기에 다른 페이지로 이동하지 않고 최상단에 위치했으면 좋겠다고 하셨다. (다만 내용이 길어질 수 있으니 토글로 확인했으면 좋겠다고)

2. 담당자에 대한 명시는 각 화면의 항목마다 붙지는 않기 때문에 표 최 상단에 디자이너와 개발 담당자를 태그 하는 것으로 수정하자고 하였다. (그리고 바뀐 담당자에 관해서는 페이지 안에 적어두는 것으로 합의하였다.)

3. 원래는 서비스 전체에 대한 필독 문서를 상단에 배치하였었는데, 이는 프로덕트 상위 개념의 필독 문서로 옮기고 기능과 에픽에 대한 정책 문서에서는 확인이 굳이 필요하지 않을 것 같다고 하였다.

 

 

정책서 템플릿 v1.1 구성 소개

1. 히스토리 : 누가, 언제, 어떤 내용을 위해 작성되었는지 기록한다.

2. 정책 문서 : 서비스 안에 기능 혹은 에픽이 있다면 그 에픽과 기능에 대한 서비스 정책을 기록한다. (ex. 만약 과금이라면 그 안에 플랜 업그레이드, 플랜 다운그레이드, 환불 관련 정책들이 있을 것이다.)

3. 유저 Flow : 기능과 에픽이 흘러가는 흐름에 대해 작성한다. 플로우는 사용자 시나리오를 중심으로 데이터의 흐름이 정의되어야 하며 이는 모든 요소를 한눈에 파악할 수 있어야 한다.

4. 기능 명세 : 기능에 대한 목표, 개발 논의 내용, 목차, 화면에 들어가는 기능과 요구 사항들과 담당자, 엣지케이스들을 확인 할 수 있다.

 

 

 

우리에게 맞는 방식을 찾아가기

사실 처음엔 그냥 적당한 템플릿 찾아서 제안할까 생각했다.
하지만 이미 개발팀에선 이 방식이 편하다고 생각했으니 반영한 것 같았고 전부 바꾸기엔 많은 합의가 필요해 보였다.

내가 바라는 건 단지 독자들이 쉽게 읽었으면 좋겠다였다.
예전에 한 임원분께서 우리 회사는 애자일이 맞지 않는 것 같다고 하는 걸 보면 어느 회사에서 맞는 방식이 우리에겐 맞지 않을 수 있는 것 같다. 관객은 내부에 있으니 정답을 외부에서 찾을 필욘 없을 것도 같다.

사실 템플릿은 껍데기에 불과하다.
결국 내가 핵심 내용을 누락하지 않았는지, 오해의 소지가 없게 잘 작성했는지는 작성자의 몫이기도 하니깐.
그리고 더 좋은 서비스로 발전하기 위해 히스토리도 분명 필요하다.

 

아직 완벽하지 않다는 건 안다.

하지만 불편 사항이 조금씩 개선되고, 우리만의 룰이 생긴다면 좀 더 효율적으로 변할 수도 있을 것 같다.

그런 의미에서 시간이 지난다는 건 아쉽기도 하지만, 뭐가 됐든 변화를 기대하는 현재의 마음이 있으니 시간이 흐른다는 건 좋은 것 같기도.

 

참고한 글
└ 제품 팀에서 Notion, Axure, Figma로 기획/디자인하기! (노션, 액슈어, 피그마) : https://youtu.be/O6ZGURXQjQs?si=8z4fcF_1yhYrtAhZ
└ 기획자가 알아야 할 정책 설계 가이드 : 회원 정책 (템플릿 제공) : https://publy.co/content/6943?fr=library-done
└ [웹기획가이드] 서비스 정책? 개발정책? 운영정책? : https://www.datachef.co.kr/post_webplanning/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=5643839&t=board