기획자와 (효과적으로)
협업하는 방법
데이터 분석가의 R&R
경험상 사내 모든 팀과 협업이 필요했던 것 같다.
개발, 기획, 디자인은 두말할 필요 없고 데이터 적재 관련으로 법무팀까지도 협업이 필요했으니 말이다. 그중 서비스를 기획하는 부서와의 협업이 업무 대부분을 차지한다고 해도 과언이 아닐 만큼 밀접한 구도를 가지고 있다.
그렇다면 어떠한 협업을 보통 (혹은 궁극적으로) 하게 될까? 서비스 기획의 업무 프로세스는 서비스에 필요할 것 같은 기능을 고안하고, 어떤 식(디자인적)으로 그려낼지, 어떤 사용자들에게 필요하고 어떤 식으로 풀어져 나갈지에 대한 고민을 해서 실질적인 기능 개발 전까지의 모든 작업을 수행하는 업무라고 생각한다. (개발 자체는 개발자가 하는 것이니 그 전까지만) 의식의 흐름대로의 업무 프로세스는 아래와 같다.
필요성
이런 기능이 필요하겠다
구체성
이런 식으로 필요하겠다
완성도
그 서비스가 어떤 식으로 고객에게 와 닿았는가 (=잘 쓰던가?)
대략적인 플로우는 이런 식인데, 다음 기획에는 더 괜찮은 안들이 나올 수 있게 하기 위해서 보통 해당 기능이 배포되고, 기획의도대로 사용자들이 잘 사용하였는지 사용성이 나쁘지는 않았었는지에 대한 후 분석이 일반적으로 이루어진다. 망한 기획에 대해서 데이터에 의거하여 롤백해도 괜찮다는 실험적인 마인드라면 상관없지만, 전 글에서 언급했듯 자기가 기획한 기능에 대해 고나리질 하는 시선을 그저 그렇게 곱게만 보기는 힘들어하는 것 같다. 이러한 상황에서 양방 해피한 앤딩을 가져올 수 있는 안은 크게 다르지 않았다.
최초 기획할 때부터, '그냥 필요할 것 같아서 쓰는 기획서'를 쓰지 않으면 된다. 모든 것을 데이터로 증명하고 시작할 수는 없겠지만 꽤 생각보다 많은 부분들은 사전에 데이터로 어느 정도 확인이 되고 (=유실 포인트 확인이 된다는 말), 가끔은 변경 시 어떤 결과물이 나올지도 시뮬레이팅이 되는 경우도 있다. 예를 들어 무척이나 구닥다리 디자인에 UI 구조를 가진 특정 퍼널의 이탈률이 엄청나게 낮다면, 해당 화면을 이쁘게 만들어보고 싶은 창작욕구가 뿜어져 나온다는 이유만으로 그 페이지를 개선 시도를 안 하는 게 좋다는 말이다. 잘해봐야 본전인데, 뭣하려 하냐는 말이다. 절대 하지 말자는 아니지만 우선순위상 조금 밀린다는 말이다. 기능적으로 충실하기 때문에 화면이 좀 구닥다리여도 사용성에 불편을 느끼지 않는 서비스들도 존재한다. (e.g. HTS, MTS) 다만 개선을 필요치 않는 화면을 실적을 채우기 위함인지, 뭔가 해야 할 것 같아서인지, 남들이 하니까 여서 인지는 모르겠지만 사용자가 필요해서 라는 이유가 아닌 다른 이유로 기획서의 첫 삽을 뜨는 경우가 종종 있어왔다.
해서 그간 접해왔던 협업 기획팀과의 업무 프로세스 내에서의 분석가로의 요구사항은, 필요할 것 같은 기능이 존재할지도 모르는 뭐 그렇고 그런 화면에 대해서 고민을 시작할 시점부터 공유해달라 였다. 어차피 진짜 데이터 하나도 안 들여다보고 그냥 이쁘게만 딱딱 만드는 기획자는 없다고 봐야 한다. 데이터를 어차피 사전에 확인해보고 필요성에 의거해서 기획을 하게 되니, 그때부터 같이 논의를 하자고 했다.
어떤 세그먼트는 이 화면에서 불편함을 겪고 있지만 대부분의 사용자들은 잘 사용하고 있는 것 같아서 UI적으로 큰 개선이 필요한 것 같지는 않다. 하지만 소수의 불편함을 겪는 사람들이 있으니 차라리 UT(User test)를 통해서 그들에게 물어보는 편이 무작정 기획하는 것보다는 효율적일 수도 있다.
와 같은 큰 방향성에 대해서는 사전에 논의가 되면, 뒤 따르는 작업에 대한 실패비용의 최소화도 노려볼 수 있게 된다.
그렇다면, 기획자가 묻는 대부분의 질문에 대한 답변을 하기 위해서는 분석가는 어떤 준비를 하면 될까?
말로는 쉽지만, 실제로는 무척이나 어려운 것인데, 모든 (혹은 대부분) 질문에 대답을 할 수 있는 인프라를 갖추면 된다. 분석가가 다루는 (=필요한) 인프라라고 하면 아무래도 데이터베이스 일 것이다. 그 형태가 RDB든 Non-SQL이든 그걸 말하는 것이 아니라, 어떤 식으로든 사용자의 현재의 행동과 과거의 기록이 남아 미래를 예측할 수 있는 로그가 담겨 있는 그 무언가를 말하는 것이다. 물론 클래식한 DB의 형태일 수도 있고, 3rd Party tool 일 수도 있다. (요즘 나오는 툴들 좋은 것들 정말 많더라, SDK 하나만 심어도 막 다 해주던데..)
모든 답변에 대답할 자세와 생각으로 태깅(Tagging)을 준비하는 것은 아니지만, 사용자의 일거수일투족을 일단은 (진짜 다 따면 정말 QA도 너무너무 너무 힘들고, 무엇보다 과부하가 걸린다) 다 딴다는 생각으로 태깅을 하곤 했다. 스크롤이 됐든, 노출 위치에 따른 위치 값이든, 이미지의 크기가 됐든, 버튼의 색깔이 됐든 사용자가 결정을 하기까지 기여한 서비스의 모든 면모와 변수들을 담아두려고 한다. 그것들이 모여서 데이터가 되고 무엇이 필요한지에 대한 현안을 (어느 정도는) 내놓을 수 있는 인프라가 된다고 생각한다.
업무를 하면 할수록 분석가의 R&R이 좋게 말하면 슈퍼맨 나쁘게 말하면 잡부의 형태로 변모하고 있는 것 같다. 제플린으로 화면을 그리는 업무를 빼고는 기획자와 협업하고 실제로 코딩을 하는 부분을 제외하고는 개발자와 협업하고 태블릿으로 아이콘을 직접 그리는 업무를 빼고는 디자이너와도 협업을 해야 하다 보니, 꽤 많은 부분에서 서포트를 해야 한다. 슈퍼맨은 아닌데 그렇다고 잡부는 아니니까 슈퍼 잡부 정도로 해두자.
