웹 서비스 기획 시행착오와 도구 정리 (1)

 

기획 일을 처음 배우던 시절을 돌아보면, 지금이라면 하지 않을 실수를 참 많이 했어요.
그때는 일이 서툴러서이기도 했지만, 도구를 어떻게 쓰는지에 대한 습관이 없었던 탓이 컸습니다.
이번 글은 시작 단계에서 겪은 시행착오와, 거기서 건져 온 도구 사용 습관을 정리한 첫 번째 글입니다.
다음 글에서는 일을 조금 더 해 보고 달라진 점을 이어서 쓸 생각이에요.

 

가장 먼저 부딪힌 문제는 문서 버전이었습니다.
화면 설계 문서를 만들어 메일로 보내고, 피드백을 받아 고치고, 다시 보내다 보면 파일이 계속 늘어납니다.
이름에 "수정", "최종", "진짜최종" 같은 말이 붙기 시작하면 이미 늦은 거예요.

가정해 보겠습니다.
개발자가 어제 받은 파일로 작업을 시작했는데, 저는 오늘 오전에 고친 파일을 따로 갖고 있다고요.
서로 다른 버전을 보고 있었다는 걸 알게 되는 순간은 보통 개발이 상당히 진행된 뒤입니다.
이 일이 한 번 있고 나서는 "최신본은 한 곳에만 둔다"를 원칙으로 삼았습니다.
파일 이름에는 날짜와 버전 번호만 쓰고, 바뀐 내용은 문서 맨 앞 이력 표에 한 줄씩 남깁니다.

이력 표는 복잡하게 만들 필요가 없습니다.
날짜, 바뀐 곳, 바뀐 이유, 작성자 네 칸이면 충분해요.
이 표가 있으면 개발자도 "지난번 파일과 뭐가 달라졌지"를 문서만 보고 확인할 수 있습니다.
처음에는 귀찮아도 한 달만 해 보면 질문 전화가 눈에 띄게 줄어요.

 

회의에서 "그렇게 하죠" 하고 끝난 내용이 일주일 뒤에 "그런 얘기 했었나요"가 되는 경험을 몇 번 했습니다.
서로 기억하는 내용이 다르면 누가 틀렸는지 따지는 일이 되어 버려서 분위기만 나빠져요.
그때부터 회의가 끝나면 결정된 것 몇 줄을 바로 정리해서 공유하는 습관이 생겼습니다.

기록은 거창하지 않아도 됩니다.
무엇을 정했는지, 누가 언제까지 무엇을 하는지, 아직 정하지 못한 건 무엇인지 세 가지만 적어도 큰 도움이 됩니다.
이 기록이 쌓이면 나중에 "왜 이렇게 만들었더라"를 설명할 근거가 됩니다.

가정해 보면, 회의에서 "쿠폰은 가입 직후에 지급하는 걸로 하죠"라고 말이 오갔다고 해 보죠.
저는 가입 완료 시점으로 이해했고, 다른 분은 첫 로그인 시점으로 이해했을 수 있습니다.
회의록에 "쿠폰 지급 시점: 가입 완료 직후"라고 한 줄만 적혀 있어도 그 자리에서 "아니에요, 첫 로그인이요" 하고 바로잡을 수 있어요.
기록은 기억을 대신하는 것보다 오해를 일찍 드러내는 역할을 합니다.

 

의욕이 넘치던 시기에는 좋다는 도구를 다 써 보려고 했어요.
메모는 이 앱에, 할 일은 저 앱에, 화면 구상은 또 다른 도구에, 일정은 달력에 적었습니다.
어느 날 "그 내용 어디에 적었더라" 하고 찾는 데 한참을 쓰고 나서야 문제를 깨달았죠.

그래서 이런 기준을 세웠습니다.
역할이 겹치는 도구는 하나만 남긴다.
새 도구는 한 번에 하나씩, 실제 업무 하나에 적용해 보고 도입 여부를 정한다.
팀이 이미 쓰는 도구가 있으면 내 취향보다 팀 방식을 먼저 따른다.
도구를 늘리는 것보다 쓰는 장소를 줄이는 쪽이 일의 속도를 더 높여 주었습니다.

 

화면 이미지는 고쳤는데 설명 문서는 그대로여서, 두 자료의 내용이 다른 경우도 자주 있었어요.
서비스가 커질수록 이런 불일치가 늘어나고, 나중에는 어느 쪽이 맞는지 아무도 모르게 됩니다.

해결책으로 쓴 방법은 단순합니다.
화면 하나마다 고유한 번호를 붙이고, 설명 문서는 그 번호를 기준으로 작성합니다.
화면을 고칠 때는 해당 번호의 설명을 같이 열어서 고치는 것을 한 세트로 묶었어요.
정책이 바뀌면 영향을 받는 화면 번호를 이력에 함께 적어 두면 추적하기도 수월합니다.

 

그 밖에도 몇 가지 작은 습관이 쌓였습니다.
문서를 보내기 전에 개발자 입장에서 한 번 읽어 본다.
용어는 한 가지로 통일해서 쓴다.
예외 상황, 예를 들어 입력이 비었을 때나 통신이 끊겼을 때의 화면을 빼먹지 않았는지 훑어본다.
일정은 가능하면 작업 단위로 쪼개어 하루 안에 끝나는 크기로 적는다.
하나하나는 사소하지만, 이런 것들이 모여서 문서에 대한 신뢰가 생기더라고요.

혼자 일하는 시간에도 습관이 필요했습니다.
아침에 오늘 끝낼 일 세 가지만 적고, 퇴근 전에 체크하며 내일로 넘길 것을 정리해요.
욕심내서 열 개를 적으면 하나도 끝내지 못한 날로 기억되기 쉬워서 세 개로 줄였습니다.

 

돌이켜 보면 시행착오의 대부분은 실력 문제가 아니라 정리하는 방식의 문제였습니다.
같은 내용이라도 어디에 어떻게 남기느냐에 따라 팀의 시간이 크게 달라져요.

그리고 도구 선택은 일의 규모와 팀의 규모에 따라 달라진다는 점도 배웠어요.
두세 명이 하는 작은 프로젝트에는 가벼운 문서 하나가 맞고, 여러 팀이 얽힌 프로젝트에는 더 엄격한 이력 관리가 필요합니다.
지금 내 상황에 맞는 수준을 고르는 것이 결국 기획자의 판단이에요.

아직 고민이 남은 부분도 있습니다.

문서를 얼마나 자세히 쓰는 게 적당한가, 너무 자세하면 아무도 안 읽고 너무 간단하면 해석이 갈리는데 그 균형이 어렵습니다.
이 이야기는 다음 글에서 이어 보겠습니다.