서비스 기획자에게 중요한 역량이 무엇이라고 생각하십니까 🧐
데이터 분석 능력, 개발 지식, 사용자 요구 분석, 이슈 해결 능력 등등...
서비스 기획자가 갖춰야 할 역량은 너무나도 다양하지만
결국 기획의 시작과 끝은 문서 작성이다.
현재 팀에 PM직으로 합류하고, 당연하게도 기능명세서를 적게 되었는데
양식에 대한 고민이 이만저만이 아니었다
그냥 말하는 감자였던 내가...
기능명세서를 쓰기까지 고민했던 부분들을 공유하고자 한다
1. 기획 문서란?
서비스 기획자 또는 PM이 작성해야 하는 문서가 기능명세서만 있는 것은 아니다. 기능 기획과 개발 프로세스 전반을 다루는 PRD 문서부터, 메뉴구조도(IA), 플로우 차트, 정책 정의서 등등 문서 종류는 매우 많다.
메뉴 구조도 (IA)
테스크 플로우
정보구조도
와이어프레임
화면정의서
개발 플로우차트
유저플로우
기능명세서
서비스 이용정책
그렇다면, 이렇게 많은 기획 문서를 매번 다 작성하는가? 당연히 그건 아니지만, 때에 따라 필요한 문서를 골라 써야 하기 때문에 모든 문서의 개념을 다 알고 있는 것이 중요하다. 플로우가 중요한 기능이라면 테스크 플로우를, 정책이 중요한 기능이라면 이용정책 정의서를, UI 디자인이 중요하면 화면정의서를 먼저 쓰는 등 개발하고자 하는 기능을 여러 사람들에게 잘 설명하고 설득할 수 있도록 문서를 작성하는게 가장 중요하다.
기획 문서는 기획자, 개발자, 디자이너, 마케터 등 모든 팀들의 협업에서 중심이 되는 문서이다. 생각보다, 같은 기능을 같은 회의에서 논의했다 하더라도, 서로가 다르게 이해하고 동의하고 있는 경우가 많다.
👩🏻💼 : (A를 생각하며) 저희 ~~ 기능 이렇게 하는거 맞죠?
🧑🏻💼: (B를 생각하며) 네! 그렇게 진행할게요!
------------ 개발 후 ------------------
👩🏻💼 : 그때 A로 개발하신다고 하셨는데 왜 B가 됐나요?
🧑🏻💼: B라고 하신거 아니었어요?
이런 일이 없을 거라 생각하지만, 종종 있다. 이런 헤프닝을 막기 위해서는, 모두가 동의한 부분에 대해 기획 문서를 빠르게 작성하고, 정해지지 않은 부분이 무엇인지, 정해진 기능의 개발은 어떻게 진행하면 되는지 정확하게 작성해야 한다.
2. 기능명세서, 어떻게 적는가?
이번 포스팅에서는 기획 문서 중에서도 기능명세서에 대해 적어보고자 한다. 개발 과정에서 가장 중요한 문서라 생각하기 때문이다.
(*나는 소규모 스타트업에서 일하고 있고, 주니어 기획자라 경험이 부족하기 때문에 다른 분들의 의견은 다를 수 있다)
팀에 합류하고 난 뒤, UI 제작과 개발이 80% 정도 완료된 상태에서 기능명세서를 작성하게 되었다.
기능명세서를 완료하고 개발을 진행하는게 당연한 절차이지만, 스타트업은 때론 역기획을 하기도 한다 (물론 그러면 안된다.)
그때 사용하고 있던 기능명세서 양식은 이랬다. 화면 설계서에서 해당 화면에 연관된 기능을 '관련 기능 명세서' 페이지로 연결하여 작성했다. 토글로 뎁스를 표현한 부분이나, 동일한 기능의 명세를 한번만 적으면, 같은 기능을 사용하는 다른 화면을 쉽게 연결할 수 있다는 점은 편리한 부분이었다. 또, 기능이 수정되면 하나의 기능명세만 수정하더라도, 이어진 화면에서 모두 수정된다는게 장점이었다.
그러나, 화면 설계에서 페이지 소개나 주요 기능, 참고 사항 등을 작성하고, 비슷한 정보를 기능명세에서 또 작성하는게 불필요하다고 느껴졌다. 관련 기능 명세서를 연결하거나 생성하는 과정도 여러번 해보니 비효율적이라는 생각이 들었다. 또한 기능명세서를 읽으려면 '관련 기능 명세서'를 클릭하고, 페이지를 한번 더 클릭해야 했다. 여러 기능을 담고 있는 화면의 경우, 화면의 어떤 부분이 어떤 기능을 담당하는지 표시하기가 어려웠고, 비슷한 기능이 화면 별로 조금씩 다르게 구현되는 기능의 경우에도 표현이 어려웠다.
무엇보다도, 기능명세서가 한눈에 들어오지 않는다는 단점이 제일 컸다.
이 부분이 기능명세서를 작성하는 나도, 개발을 하는 개발자들도 귀찮을 것이라 생각이 들어 양식을 뜯어 고치기로 했다!
덧붙여 말하자면, 기능명세서는 하나의 기능에 대해 매.우.매.우. 자세하게, 처음 보는 사람이더라도 이해할 수 있도록 적는 것이 중요하다.
데이터의 디폴트 값이 뭔지, 데이터가 없다면 어떻게 표현할건지, 사용자가 작성하는 텍스트가 있다면 몇글자까지 적을 수 있는지, 각각의 버튼이 어떤 기능을 하는지, 날짜나 지역은 어떤 식으로 표기하는지 등등 공식을 정할 수 없을 정도로 적어야 할 내용이 천차만별이다 ㅎ.
3. 새로운 기능명세서 양식은!
먼저, 화면 섹션 별로 표를 구분했다. 우리 앱은 5개의 탭이 있고, 그 외의 로그인이나 섹션을 나눠 적어야 할만한 화면들을 분류했다.
그리고 화면에서 이동되는 페이지의 뎁스를 나누고, 화면별로 넘버링하여 피그마에서도 쉽게 확인할 수 있도록 했다. 1번 페이지의 다음 뎁스는 1.1 그다음은 1.1.1, 1.1.2로 나눴고, 피그마에서의 화면 넘버와 동일하게 표기했다. 해당 넘버링에 따라 기능명세도 작성했다. 또한 기획, 디자인, 개발 상태를 나누어 각 기능이 어디까지 구현되었는지 표시하도록 했다!
해당 양식으로 바꾸고 나니, 기능명세가 한눈에 들어와서 보기가 편했다.
특히, 기능명세를 작성하는 기획자보다 기능명세서를 보고 개발하는 개발자들이 보기 편한게 더 중요했는데 이부분에 있어 만족도는 꽤 높았다. (아마? ㅎ)
피그마와 넘버링을 동기화시켜두니, 화면을 확인하기도 편했다!
그치만, 기획서에 최종이란 없다. ㅋㅋㅋㅋㅋ ㅋㅋㅋㅋㅋㅋ
기능과 기획은 늘 수정되고, 새로운 기능을 개발하게 되기 때문에......
기획자에게 기능명세서를 비롯한 기획 문서를 어떻게 '잘' 적을지는 평생 고민거리일 듯 싶다!
완벽한 기능명세서를 적을 수 있는 그날까지
to be continue....
'IT' 카테고리의 다른 글
| 디지털 인사이트 275호 서평 | IT 전문 큐레이션 매거진 추천 (8) | 2024.10.28 |
|---|