포닥스 프로젝트 리뷰(3) 서비스 가시화를 위한 제품 백로그와 와이어 프레임

  이전 단계에서 솔루션 정의와 대안제까지 조사를 하니 이제는 Develop단계로 기획한 서비스를 실질적으로 보여주는 것이 중요했다. 지금까지는 조사와 발견을 통한 설득이라고 한다면 Develop단계에서는 실제적으로 기술과 디자인을 통해서 서비스를 보여주며 설득해야 하는 단계였다.

  이 단계에서는 IA, 유저 스토리와 백로그, UX Flow Chart, 와이어프레임, 프로토타이핑 등을 사용하여 최대한 기능의 정의와 디자인을 해보려고 노력하였다.

---

1. IA (Infromation Architeture, 정보구조도)

  이제는 많은 기업들이 워터폴이 아닌 애자일 조직으로 바뀌면서 IA(Information Architeture)를 간소화하거나 필요한 사람만 가지고 있는 정도로 중요도가 바뀌었다는 생각을 가지고 있었다. 많은 자료들에서 IA의 형식은 설정하기 나름이라는 말이 많은 만큼 회사에서 필요로 하는 정도로만 만드는 것이 대세일 것이다. 중요도가 바뀌었다곤 하지만 워터폴 방식으로 일하는 기업의 경우에는 이 IA를 통해서 여전히 개발자와 기획자 간 소통이 이루어질 수 있다고 생각한다.
  개인적으로도 애자일 조직이라면 예전처럼 자세한 IA는 불필요하다고 생각을 하였는데, 이번 프로젝트 기획을 하면서 조금 생각이 달라졌다. 특히 신규 서비스를 기획할 때에는 IA가 생각보다 역할이 크다는 생각을 했다. 만일 이 IA가 없다고 가정을 한다면 실제로 와이어 프레임을 만들 때 필요한 요소들을 놓친다던지 혹은 UI 디자인에 너무 초점을 맞춰 서비스의 중요한 부분을 놓칠 수도 있을 것이다. 다른 말로 하면 애자일 조직이던 워터폴 조직이던지 간에 필요하다면 만들고 사용해야 한다는 것이다. 항상 방법론에 대하여 많은 고민을 하지만 나 조차도 이건 좋다, 나쁘다의 이분법적 사고를 한 것 같다.

  그렇기 때문에 IA는 이제는 어떤 소통의 창구라고 하기보다는 하나의 가이드라인 혹은 기준점으로 역할을 할 수 있을 것 같다는 생각이 드다. 앞서 이야기했던 중요도가 바뀐 것이 아닌 역할이 바뀐 것이다. 만일 개발을 하는 도중 갑자기 UI를 바꾸고 기능을 추가하는 도중에 물론 히스토리가 쌓이겠지만 IA의 히스토리를 통해 적어도 프론트의 변화를 가시적으로 볼 수 있고, 또한 서비스에서 중요하게 생각하는 부분을 놓친 것이 없는지 볼 수 있는 중요한 자료가 될 수 있을 것 같았다. 만일 IA를 만들지 않는 조직에 PM으로 있다면, 스스로 IA를 만들어 가지고 있으면서 스스로 서비스의 방향성과 변화를 동시에 동시에 컨트롤할 수 있는 중심을 잡아야 할 때 필요할 수 있을 것이다.

  이번 프로젝트를 진행하면서 디자인이 전혀 없이 IA를 먼저 만들다 보니 생각보다 어려움을 겪었다. 특히 페이지의 모습이 눈에 그려지지 않기 때문에 계속해서 상상을 하며 서비스의 필요한 기능과 서비스에서 엣지로 정한 기능들을 다시 한번 정의하면서 IA를 그려갔다. 또한 나중에 유저스토리 백로그를 작성한 후에 다시 IA로 돌아가 필요한 부분을 추가하고, 불필요한 부분들은 제거하는 작업을 하게 되었다. 이 과정에서 계속해서 돌아오는 작업이 오래 걸릴뿐더러 기획 효율을 떨어지게 하였다.

  하지만 비효율적인 작업에도 불구하고 서비스의 기본적인 기능과 제품의 엣지 기능들을 잡기 위해 노력을 하였다. 개인적으로는 이렇게 제품의 성격과 방향성에 맞게 큰 그림을 고려해 가면서 하나씩 처리하는 것을 좋아하기에 계속해서 작업을 진행하였다. 또한 MVP(Minimal Viable Product)에서만 필요한 IA만 구성한 것이 아니라 MVP 이후에 이 구조에 콘텐츠(Content)를 넣는 작업을 위해 서비스의 전반적인 구조를 짜려고 노력을 하였다. 서비스를 기획, 개발을 하면서 이런 큰 그림을 보지 못하면 결국 다음 것을 찾아 방황을하거나 기획했던 서비스에 추가 기능을 덕지덕지(?) 개발하는 경우를 방지하기 위해서 조금 더 큰 구조를 짜기 위해 노력을 하였다.

 

2. 유저스토리와 백로그

  사실 유저스토리와 백로그를 구성할 때 가장 많은 고민을 하였고 가장 의문이 많이 들었었다. 먼저 유저 스토리의 설정에 대하여 이야기를 해보자. 사실 잠재고객의 페르소나는 이전 단계에서 설정을 하여서 유저스토리를 만들 때 많은 도움이 되었다. 하지만 문제는 잠재고객이 실제적으로 어떻게 행동하는지에 대한 실질적인 데이터가 없다 보니 유저 스토리를 만들 때 오로지 이미 알고 있는 잠재고객인 연구자들의 행동을 바탕으로 한 가설에 가까운 유저 스토리를 만들었다.

  실무에서는 여러 가지 데이터를 종합하여 페르소나를 만들 뿐만 아니라 고객의 행동을 유추할 수 있는 다양한 데이터를 모아 고객의 행동을 다각적으로 분석할 수 있을 것이다. 하지만 신규 서비스이기도 하고 프로젝트의 시간적 한계 때문에 다양한 데이터가 없이 UX 리서치에서 나온 데이터와 기존의 잠재 고객들의 행동만을 가지고 유저 스토리를 만들려고 시도하니 조금 어려움이 있었다. 뿐만 아니라 기존에 알고 있는 잠재고객의 행동 데이터의 경우에는 오히려 바이어스(Bias)가 있을 가능성이 크고 잘못 알고 있기 때문에 이런 데이터로 만든 유저 스토리는 다른 검증을 거쳐야 한다고 생각했다.

  그래서 우선 유저스토리를 만든 후에 실제 UX 리서치에서 인터뷰를 진행했던 잠재고객에게 물어봐 어떻게 서비스를 이용할지에 대하여 알아보는 과정을 통해 유저 스토리의 검증을 거쳤다. 또한 팀원과 생각을 나누며 유저 스토리를 개선하고 이미 생각해 놓은 기능들을 역으로 이런 유저 스토리가 있지 않을까 하는 가정으로 역으로 만들어 보기도 하였다.

  이렇게 검증을 거친 유저스토리를 바탕으로 백로그를 만들었다. 사실 백로그에 대하여는 개인적인 생각이 정말 많지만 프로젝트를 할 때 나타난 문제를 중심으로 이야기하겠다. 가장 크게 느껴지고 여전히 혼동이 되는 점은 제품 백로그와 기능 백로그의 차이이다. 팀원과도 이 문제에 대하여 많은 이야기를 나누었는데 제품 백로그의 경우는 제품의 전반적인 기능의 분류, 제품의 방향성, 제품 정책 등 큰 그림을 그리고 것들을 말하는 것으로 정의를 내리기로 했다. 그리고 실제적인 개발 스프린트에 들어가서 제품 백로그에서 나온 하나의 아이템을 가지고 그 아이템의 개발 중에 나오는 백로그를 기능 백로그로 정의하고 시작했다.

  그래서 실제적으로 사이드 프로젝트로 이 서비스의 개발을 하지 않지만 적어도 MVP의 기능 위주로 기능 백로그를 만들고 나머지 전체적인 제품에 대한 방향성, 추가 기능들은 제품 백로그로 정리하였다. 이런 백로그를 정리하면서 우선순위를 정하는 것은 PM으로써 당연히 해야 할 일이고 또한 기준을 잡는 것도 PM이라고 생각한다. 개인적으로는 이런 우선순위를 정하는 것도 중요하지만 제품의 성격과 고객의 행동을 분석하여 기능과 제품의 정책을 정하는 것도 PM이 주축이 되어서 기준을 잡아야 한다고 생각을 한다. 

  이번 프로젝트에서는 사실 정책을 정할 필요가 없었지만 주요 기능들에 대한 정책을 고려하여 백로그와 함께 거칠게나마(?) 정리를 하였다. 특히 어뷰징 케이스들의 처리를 중심으로 생각을 했는데, 그 이유는 서비스의 성격 상 잠재 고객에게 신뢰도를 주지 않으면 서비스의 존속에 문제를 얻을 수 있기 때문이었다. 이런 정책을 일반 상식 선에서 정해야 하는 경우가 많은데 이번 프로젝트의 잠재고객 페르소나가 '신뢰도에 목숨을 거는' 사람들이었기 때문에 이 페르소나의 특성에 입각해 정책을 설정하였다. 이렇게 정책을 정할 때에도 데이터나 고객의 행동을 보고 정하는 것이 좋을 것 같다는 생각이 들었다.

개인적으로는 이런 백로그에 우선순위를 정하고 기능의 정책을 정하는 것에 재미를 느낀다. 이런 우선순위와 정책을 정하는 것에는 여러 상황에 대한 정확한 판단과 이해관계자들의 입장을 이해하고 밸런스를 맞추는 것이 중요하다고 생각을 한다. PM으로서는 이런 백로그를 관리하는 것이 성향상 맞기 때문에 가장 기대하고 있는 직무 중 하나라고 할 수 있다.

 

3. Flow chart 그리고 와이어프레임 + 스토리보드

  물론 Flow Chart의 경우에는 개발자들이 만드는 경우가 있지만 PM이 이해하고 있는 것이 좋기 때문에 적어도 서비스의 MVP 기능으로 잡은 회원 가입, 프로필 구성에 대하여 간단히 만들어 보는 작업을 하였다. 그리고 Flow Chart를 만든 또 다른 이유는 와이어프레임을 그릴 때 최소 기본이 되는 기본 골자를 정하기 위해서였다. 와이어프레임을 IA, Flow chart 등 참고 자료가 없다 보면 UI 디자인에 현혹(?)되어 길을 잃어버릴 수 있기 때문이다.

이런 부분에서 UI 디자이너와 함께 와이어프레임을 PM이 같이 제작을 해야 한다고 생각을 한다. 많은 회사들에게 이 부분을 나누는 경우가 있을 것이다. 그 이유는 PM은 PM대로 할 일이 있고 또한 UI 디자이너는 디자이너대로 일이 있기 때문에 둘의 시간을 같이 내는 것은 비효율적이라고 생각하기 때문일 것이다. 그러나 개인적으로는 수정에 수정을 거듭하는 과정을 거치기보다는 시간이 조금 들더라도 같이 디자인과 제품의 성격을 고려할 수 있는 작업을 PM과 디자이너가 같이 해야 한다고 생각을 한다.

  그리고 이런 공동의 작업에서 와이어프레임을 가지고 각각의 기능을 정의하고 성격을 정하는 것은 PM이 주축이 되지만 개발자가 같이 공동으로 작업을 해야 한다고 생각을 한다. 물론 모두가 바쁘다. 하지만 이런 공동작업이 일반화가 된다면 느리지만 효과적이고 강력한 제품이 나올 것이라고 개인적으로 생각한다.

---

이제 프로젝트가 마무리되었고 마지막 발표도 끝이 났다. 앞으로 이 프로젝트를 포트폴리오화 시켜 좋은 곳에서 지금까지 생각한 것을 증명하고 또한 고치고 배우기 위해서 일할 수 있는 밑거름이 되었으면 좋겠다. 

 

제가 공부하고, 이해해본 PM에 관련된 내용을 포스팅으로 남깁니다.
잘못된 생각이나 혹은, 이견, 참고자료 등은 댓글로 남겨주세요.
감사합니다