"이런. 내용까지 써야 해?” 네, 써야 합니다만^^?
어쩌다 보니 서비스 기획자가 되었습니다
이전 글 : “예외케이스, 그게 중요해?" 문제는 늘 뒤늦게 온다.
1. 기획서를 지시서가 아닌 대화의 도구로 만들기 시작했다.
예전 글에서 나는 ‘기획서를 지시서가 아닌 대화의 도구로 만들자.’고 다짐했었다.
내 반쪽짜리 문서를 보고 개발하던 개발자들에게 미안한 마음이 들었고, 단순히 기능을 설명하는 지시서가 아니라, 개발과 대화를 시작할 수 있는 문서를 써보자고 마음먹었다. 그리고 그 다짐은 꽤 많은 변화를 불러왔다.
1) 가장 단순하고 명확한 것부터, 기준
예전엔 ‘노출순 필터’ 같은 기능을 기획할 때, 그저 “필터 선택 시 정렬”이라고만 적어두었다.
어떻게 정렬할지는 개발자가 알아서 판단해주겠지 싶었다. 그땐 정말 내가 ‘기획’이라고 넘겼던 것들이, ‘기준 없는 추상’이었다는 걸 몰랐었다.
그래서 내 문서 안에 ‘조건’과 ‘우선순위’를 직접 써보는 것으로 형태를 바꿔보기로 했다.
최신순 : 서버 기준 Local DateTime으로 저장된 업데이트 시각 기준 내림차순 정렬.
만약, 동일 시각이면 product_id 기준 정렬.
인기순 : 클릭 수 > 찜 수 순으로 우선순위 지정.
이렇게 숫자, 조건, 필드 기반으로 명확하게 문서를 쓰기 시작하자 개발자들의 질문이 하나 둘 줄기 시작했다.
“이건 어떻게 보여주고 싶어요?”
“정렬 기준이 뭐죠?”
그런 질문들이 사라졌고, 그만큼 해석 없이 바로 구현할 수 있었다는 뜻이기도 했다.
‘문서의 완성도’가 실무의 효율로 이어진 순간이었다.
2) 나는 아무것도 모르지만, 기준은 쓸 수 있잖아
사실 그때의 나는, 백엔드도, 구조도, 데이터 모델도 솔~직히 잘 몰랐다.
근데 그저 확신 하나는 있었다. 컴퓨터는 명확한 기준과 조건이 있어야 작동한다는 것 그리고 그 기준은 이미 저장되고 있는 데이터 안에 있다는 것이다.
그래서 문서를 쓸 때 “지금 저장되고 있는 필드 기준으로 조건을 정의해보자”는 원칙을 세웠다. 1/2공대녀로서 나름의 자신감과 확신이 있었다. (지금 생각해보니 좀 건방진거 같은데요?)
“이 조건 하나 더 있어야 할 것 같아요.”
“이건 이쪽에도 영향을 줄 수 있을 것 같아요.”
피드백이 들어오면 굉장히 기뻤던 이유가, 내가 미처 생각 못 한 걸 누군가 짚어주고, 그걸 문서에 고마민해서 채워가는 경험이 생각보다 재밌고 배우는게 많다고 느꼈기 때문이다.
2. 내가 다 하니까, 진짜로 나 혼자 다 하게 되더라.
그런데 어느 순간부터, 문서에 대한 질문이 점점 줄어들기 시작했다.
처음에는 ‘이제 문서 퀄리티가 좋아져서 그런가?’ 하고 긍정적으로 받아들는데 곧 이상하다는 느낌이 들었다.
1) 앨리님, 이건 어딨어요?
질문은 줄었는데, 요구는 점점 늘어나기 시작했다.
문서에 모든 내용을 다 담고 있는 내 모습이 보였고, 그 내용이 빠져 있을 경우, 개발자들이 나에게 직접 코멘트를 달기 시작했다. 그 흐름을 자각하게 된 건, 신규 도메인을 개발하던 중 백엔드 개발자가 내게 질문을 던졌을 때였다.
“이 Status는 terminated랑 deactivated 중 뭘로 할까요?"
“이 기능을 만들면, 연결되는 이벤트들은 어딘지 문서에 나와야 하는 거 아닌가요?”
순간, 머리가 멍해졌다. 이건 기획을 넘어서 개발 설계 수준의 판단까지 나에게 넘어오고 있다는 뜻이었다.
그때 나는 백엔드 개념도 거의 없었고, 여느 주니어처럼 프론트 기획 하나에도 허덕이고 있을 때였다.
이런 질문은 그 자체로 당황스러웠고, 무엇보다 내가 설계한 구조가 아니기 때문에 답을 할 수 없었다.
하나의 ID로 모든 값이 포린키로 연결되어 있을 수도 있고, 아닐 수도 있지 않은가? 그 구조를 내가 단정할 수는 없다. 그건 내가 정의하는 게 아니라, 구조를 가장 잘 아는 개발자가 판단해야 하는 영역이라고 생각했다.
만약 내가 백엔드 기획자이거나 테크니컬 PM으로, 구조 설계 초기부터 논의에 참여했더라면 모르겠지만 그 당시는 그런 체계가 전혀 없던 조직이었고, 나는 그저 필요한 기능을 만들기 위해 API 명세를 참고하고, 데이터를 확인할 수 있는 수준이었다.
2) 도대체 문서의 범위는 어디까지인가?
도대체 문서의 범위는 어디까지여야 할까? 기획자 혹은 프로덕트 매니저의 역할은 어디까지여야 할까?
계속 생각하고 아무리 스스로에게 물어도, 결론은 "이건 지금 내가 정할 수 있는 문제가 아니다." 였다.
그런데 그는 “문서가 명확하지 않다.” 고 말했다.
나는 당황하면 이마를 치는 습관이 있는데, 그 말을 듣자마자 “세상에!” 를 외치며 이마를 찰싹 쳐버렸다.
진짜 왜 그랬을까, 지금 생각해도 웃기다. (ㅎ;;;) 그러고 나서 그 개발자를 데리고 나가서 커피를 마시자고 했다.
대화가 필요했다. 머리가 터질 것 같았고 뭔가 굉장히 잘못 돌아가고 있다는 느낌이 들었기 때문이다.
대화를 해보니, 그의 생각은 단순했다.
"그냥 여기까지도 할 수 있을 줄 알았어요. 문서에 남겨져 있으면 좋을 것 같았고요.”
그리고 뒤에 “어디가 바뀌는지, 정의가 되는 게 맞는 거잖아요.” 고 말했다.
그 말을 듣고 세 가지 생각을 했는데.
1. 맞는 말이야. 문서에 무엇이 바뀌는지 담기고 그걸 정의할 수 있어야지.
2. 그렇다면 모든 게 다 연결된 구조로 설계되어 있다고 전제하고, 문서에 정의해주면 될까?
3. 반대로 개발자가 “이건 여기까지는 연결돼 있지만, 여긴 단절돼 있어서 바뀌지 않아요”라고
정리해주는 것도 가능하지 않을까?
여러 고민이 뒤섞였고, 그때부터 팀원들과 한 명씩 1on1을 하면서 방향을 찾아보기 시작했다.
3. 완벽한 문서보다, 여백이 있는 문서
일단 나부터 바뀌어보기로 했다. 모든 걸 다 담으려는 완벽주의에서 벗어나기를 시작했다.
"긁히지 말자. 긁히지 말자." 스스로 최면을 걸면서 명확한 기준이 필요한 곳엔 최대한 구체적으로 쓰되,
“이건 내가 정해야 할 문제일까?” 싶은 부분은 그냥 물어보고 비워두는 연습을 했다.
필요하다면 문서에 논의가 필요하다고 표기를 해놓고, 애매한 건 애매하다고 쓰면서 그렇게 진짜 협업의 시작점을 찾아가기 시작했다. 물론 각자가 갖는 메인 역할은 분명하지만, 각자의 역할을 잘 수행하기 위해서는 너무 이분법적인 사고보다는 함께 채워가는 여백도 중요하다는 자각했던 것 같다.
4. 함께 만드는 문서를 위해
요즘 나는, 애매하다 싶은 순간엔 자리를 박차고 일어나 담당 개발자에게 뛰어간다.
그러면 개발자는 당황한 눈빛으로 나를 쳐다보며 "또 뭐가 문젠데..?" 라고 물어본다.
“테이블 다 합쳐야 하는데 뭔가 애매하다! 뿌려지는 영역이 많은데 다 찾을 수가 없다. 각자 어떻게 저장되고 있는지 알아야 할 것 같다. 이거 구조적으로 같이 고민해줘!” 그렇게 명확한 SOS를 요청하면 당황의 눈빛 → 정의의 눈빛으로 바뀌며 (끄덕) 고개짓과 함께 슬랙으로 장문의 정리를 보내준다.
너무 멋진 순간이다. (눈물 좔좔, 오열 줄줄)
문서를 쓰는 내가 놓친 부분을 개발자가 채워주고, 그걸 보고 나는 다음 스프린트에 더 나은 구조를 고민하며 기능을 만들 수 있다. 문서에 이 모든 걸 미리 써두지 않았다고 해서, 기획이 부족한 것도, 기획자가 무책임한 것도 아니다.
오히려 정해주지 않는 것이, 더 나은 판단을 위한 시작점이 될 수도 있다는 것을 모두가 알아가고 있는 것 아닐까?
그리고 협업은, 그렇게 서로를 믿고 여백을 채워가는 과정에서 시작되고 있다는 걸 몸으로 느끼고 있다.
겉으로 보이는 성장은 크지 않았을지 몰라도, 속에서는 꽤 많은 변화가 쌓이고 있다는 증거라고 생각한다.
