실제로 먹히는 문서화 하기
문서화의 이점을 몰라서 문서화를 안 하는 조직은 없다. 이상적인 문서화의 결과물이란 모두가 반기는 그런 것이다. 문서화가 잘 된 조직에서는 필요한 정보를 누구나 어디서든 쉽게 찾아볼 수 있고, 커뮤니케이션의 맥락을 재빠르게 확인하고 논의에 참여할 수 있고, 인수인계의 비용을 크게 줄일 수 있다.
하지만 정작 문서화를 하려 들면 왜 문서화를 지금까지 우리 조직이 안/못했는지에 대한 이유만 절절하게 깨닫고 곧 손을 놔버리는 경우가 많다. 문서화를 안/못하거나, 중간에 관두게 되는 이유는 대체로 다음과 같다.
문서화를 따로 할 사람이 없다.
문서를 쓰다가 별로 공유할 내용이 아닌 것 같아서/대단한 내용이 아닌 것 같아서 관둔다.
기껏 열심히 문서를 쓴 후에 업데이트를 할 짬이 없어서 정보가 충돌한다.
적당히 다른 데에 기록해둔 정보를 조직의 문서로 옮기지 않는다.
이것저것 쓰려다 보니 너무 문서가 많아져서 관리가 어렵다.
문서화를 위한 문서화를 해야 할 것 같다.
노션이든, 컨플루언스든, 피그마든, 자체 사내 위키든 문서가 쓸데없는 짐이 아니라 보물이자 조직 업무의 핵심으로 자리잡기 위해선 문서화의 이점을 확실히 이해하고 모두가 ‘그래, 문서화 제대로 좀 해 보자’라는 마음을 먹는 데에서부터 시작해야 한다. 다만 마음만 먹는다고 모든 일이 마법처럼 이루어지는 것은 아니므로 문서화라는 어젠다를 꾸준히 끌고 갈 사람이 필요하다. 보통 그 역할을 각 스쿼드/프로젝트의 PM이나 PO가 담당하게 된다. 오늘의 글은 그래서 내가 PM으로 어떻게 꾸준히 이 주제를 다루고 있는지에 대한 경험담이자 현재진행형인 고민이다.
백문이 불여일견
문서화의 효능을 체감하게 하고 싶다면, 일단 문서화를 해 보는 게 가장 좋다. 어떤 형태든 문서화라는 게 이뤄지지 않은 조직은 없다. 다만 문서화의 실제 효능을 낮게 체감하고 있는 조직이라면 지금 작성하고 있는 문서가 위의 문서화를 안/못하는 이유 중 하나에 걸려서 표류하고 있는 상태일 가능성이 높다. 이럴 때엔 자신이 관찰한, 있어야 하는데 없는 문서나 제대로 정비가 되어야 하는데 아직 되어 있지 않은 문서의 토픽을 하나 잡아 실제로 문서화를 진행하자. 프로덕트 조직이라면 다음 토픽 중 하나를 시도해 볼 수 있을 것이다. (이 토픽들이 모두 지금 문서로 커버되고 있고 체계화되어 있다면 문서화가 잘 되고 있는 조직이다. 축하한다! 그대로만 하면 된다!)
프로덕트 중 특정 피처의 스펙 문서(특정 피처로 한정하는 것은 전체 피처에 대한 스펙 문서를 작성하다보면 진이 빠지기 쉽고 피처별로 잘라 정리하는 게 체감 효용도 크기 때문이다)
팀/조직의 프로덕트 랭귀지
프로덕트의 플로우 차트 or 구조도
프로덕트의 화면 리스트
프로덕트의 이벤트 로그 리스트
어떤 종류의 문서가 있으면 좋겠는지 동료들에게 의견을 듣고, 가장 필요로 하는 문서의 작성을 손댈수록 이롭다. 문서화를 제대로 하면 좋다! 는 말을 백 번 듣는 것보다 실제로 필요한 문서가 생기고, 이 문서를 참고하고 업데이트해가며 업무를 진행하는 경험을 공유하면 문서화에 대한 공감대를 형성하고 이후 문서화에 필요한 협조 역시 손쉽게 구할 수 있다.
물리적, 심리적 진입장벽 낮추기
실제로 팀/스쿼드 멤버들의 업무 스코프에 밀접하게 도움이 되는 문서를 일단 작성한 후에는 이 문서가 계속해서 살아있는 문서가 될 수 있도록 조금씩 멤버들이 직접 문서를 만지는 경험치를 쌓아야 한다. 문서화가 익숙하지 않은 초기에는 PM이나 PO가 팔을 걷어붙이고 이리저리 뛰어들어 정리할 수 있겠지만, PM과 PO도 문서화에만 시간을 쓸 순 없기 때문에 언젠가는 결국 모두가 조금씩 해야 하는 일이다. 그러니 문서화를 업무 루틴에 정착시키면서 팀 안에 문서화는 아무나 언제든 해도 괜찮다는 확신을 주어야 한다. 작은 비용으로 손쉽게 팀원이 문서에 내용을 보탤 수 있는 구체적인 루트를 마련하자.
예를 들면, 개발 스펙을 정리한 문서의 DB 테이블을 만들 때 예시 문서를 덩그러니 던져 두는 것보다 필터로도 사용할 수 있는 여러 정보값을 기입하도록 정보 필드를 파두고 본문 내용 역시 미리 세팅된 질문에 답하는 것처럼 자연스럽게 채울 수 있는 템플릿을 제공하는 것이 좋다. 팀의 미팅 로그를 정리할 때도 마찬가지다. 누구나 회의록을 작성할 수 있게 하려면, 음슴체로만 흘려 쓰더라도 어떤 유의미한 정보를 남기는 것이 좋은지 템플릿을 통해 가이드라인을 주면 된다.
실제로 손쉽게 문서화에 보탬이 될 수 있는 방법을 제공하는 게 물리적으로 진입장벽을 낮추는 일에 해당한다면, 팀원의 의견과 아이디어가 문서에 체계적으로 기록되고 다른 팀원에게 공유되는 경험을 제공하는 것은 심리적으로 진입장벽을 낮추는 일에 해당한다. 크고 작게 이뤄지는 논의의 결과를 문서에 정리했다면, 다음에 관련된 이야기가 나올 때 논의의 결과가 정리된 문서 링크를 들고 오자. 당시 우리는 이런 맥락으로 이렇게 이야기했다는 기록을 다시 살펴보고 그 기록을 기반으로 논의를 이어나가는 경험을 꾸준히 하다 보면 논의의 기준이 문서가 되고, 문서에 서로의 이야기를 적기 위해 더 집중하게 된다. 이 과정에서 스스로가 기여한 내용이 문서를 통해 일종의 팀/조직 내 ‘오피셜’이 되는 셈이다. 결과로 남는 문서와 친근해지는 계기가 되기에 충분하다.
안전망 두기
아무리 이래저래 장치를 두고 문서화를 독려해도 하루아침에 업무 습관이 바뀌진 않는다. 그건 당연하다. 번쩍거리는 최강의 문서가 어느 날 난데없이 등장해 모두의 문제를 해결해버리는 건 전혀 좋은 문서화가 아니다. 모두가 조금씩 보태가면서, 꾸준히 살피고 꾸준히 참고하는 문서와 그 문서를 다루는 팀원이 있어야 조직에 도움이 되는 문서화라고 할 수 있다. 그렇게 될 때까지, 과도기에서는 조직 내 정보의 체계화를 책임지는 PM과 PO가 반드시 안전망 역할을 해야 한다.
일단 추가해 주시면 제가 보고 보탤게요.
일단 어떻게든 써주시면 제가 알맞게 손볼게요.
일단 던져주시면 적절한 곳에 배치하고 분류하겠습니다.
이렇게 정리해서 넣어봤는데, 어떠세요?
와 같이 ‘일단’ ‘뭐라도’ 하면 함께 할 사람, 함께 볼 사람으로 문서화 과정을 함께해야 한다는 뜻이다. 소프트 스킬을 통한 서포트가 필요하다. 동시에, 자신의 업무 루틴에서도 주기적으로 문서를 체계화하고 낡은 정보는 제외하고 새로운 정보는 추가하는 시간을 두는 것이 좋다. 문서화는 모두가 함께해야만 의미있는 과정이다. 하지만, 그 중에서도 문서화를 주도하며 꾸준히 신경쓰는 사람은 반드시 있어야 한다. PM/PO는 팀원이 겁없이 문서화에 뛰어들 수 있도록 독려하는 안전망이 되어야 한다.
해 보자
문서화가 업무 프로세스에 제대로 자리잡지 않아 불편한 부분이 있다면 PM, PO가 먼저 드라이브를 걸고 나서야 한다. 일단 뭔가 하지 않으면 아무것도 바뀌지 않는다. 불변의 진리.
