요구사항으로부터 만들기/개선하기

위 내용은 현재 진행중인 프로젝트인데 나는 이 요구사항과 함께 Figma Make로 내가 생각하는 사용자 흐름을 공유했다.

따로 이 내용을 전달하는 회의를 하지 않았는데 최대한 Figma Make에 지금이 아니더라도 할 수 있는 최대한의 내용을 넣어두었다.

프로젝트를 만들 때 로드맵을 구성할 때 두가지가 있다고 생각한다.

1. 지금 할 수 있는 최소한의 것만 만들자.
2. 만들고 싶은 것의 최종 모습을 공유하고 이 중에 이번에 할 것을 선택하자.

나는 보통 2번을 선택한다. 미래에 어떤 것을 만들지 최대한 생각해보고 그 중에 지금 할 수 없는 것들은 미리 뒤로 미룬다. 그리고 남은 것들 중 최소 요구사항에 맞는 것들만 고른다.

이번에 추가 요구사항에도 적지 않았지만 검색같은 것들이 지금 할 수 없는 것이었다. 기획를 만들 시간도 마음도 안들어서 그냥 같이 해줄 사람들을 먼저 모으고 그 다음에 내 생각을 말한 다음 자율적으로 논의해서 결정해달라고 했다. 

단, 다음 전제를 깔아두었다.

• 만드는 분들이 생각해봤을 때 이 기능 자체가 불필요하다고 생각이 들면 폐기해도 괜찮다.
• 만드는 분들이 생각해봤을 때 이 기능의 최소 요구사항이 너무 높다면 알려달라.
• 추가 요구사항은 현재 내가 생각한 것에 불과하니, 논의 후에 더 좋은 내용이 있다면 최소 요구사항을 해치지 않는 한 무엇이든 괜찮다. 나의 허락을 받는 등의 행위는 불필요하다.
• 내가 중간에 진행 방향에 개입하는 것은 간섭이라 생각한다. 정말 필요할 때만 불러달라.
  • 내가 어디까지 개입할 수 있는지 경계를 명확히 알려달라고 했고, 요구사항 확인 외에 아무것도 안하기로 했다.
• 만드는 분들 중 한분을 의사 결정자 (유사 PM)으로 지정해달라.

이 프로젝트는 다음 구성원이 진행중이다.

• 디자이너 1명
• UI 개발 2명
• API  개발 1명

PM으로 선정된 분은 UI 개발자인데, 처음에는 내가 생각한 것보다 더 기능을 축소해서 나가고 싶다고 나에게 물었다. 어느정도 타당한 의견이었지만, 작업하는 팀원분들과 최소 요구사항을 가지고 논의를 한 이후에는 오히려 기능을 더 추가해 주셨다. 나로서는 더 좋은 상황이었다.

적어도 최소 요구사항은 지켜질 것이고 추가적인 무언가도 만들어질 것이기 때문이다.

추가 기능으로는 앱에서 만든 리스트를 웹으로 공유할 수 있도록 하는 것이다.

나는 처음부터 있으면 좋겠다고 생각했지만 일부러 어디에도 말하지는 않았다. 다만 그 전에 여러 레퍼런스를 보여드리고 만들기 전에 한번씩 눌러보시면 좋겠다고 했었다.

그리고 서로 사용자에 대한 고민을 이어갔다. 예전이었으면 기획서에 뭔가 적혀있을 때 귀찮아할법한 내용인데 만드는 사람끼리 이렇게 해보면 어떨까 저렇게 해보면 어떨까 하면서 오히려 더 손이 가는 방법을 선택해주었다. 이 프로젝트가 시작될 때만 하더라도 개발하기 쉬운 방향으로 선택한다고 천명했으나, 실제로 논의하다보니 ‘사용자들이 이러면 더 잘 쓸 것 같아요’ 라고 해주셔서 다행이었다.

그동안은 누군가 하자고 하면 설득하고, 개별적으로 논의하고, 또 묶어서 공유하고 공지하는 식으로 일했다면 (적어도 내 눈에는 그랬다) 지금은 아주 다르다.

나는 관여하지 않겠다고 자주 이야기하고 있는데 알아서 만드는 분들의 의사소통 채널을 만들고 그 안에서 치열하게 논의하시는 것 같다. 그리고 중간중간 고민이 있을 때 잘 공유해주신다.

그리고 나는 항상 이렇게 말씀드린다. ‘사용자 입장에서 괜찮다는 생각이 들면 그 결정을 그대로 이어가도 괜찮습니다.’ 

이제는 어느정도 다 정리가 된 것인지 딱히 물어보시는 것도 없고 이것저것 잘 해주시는 것 같다.

과감한 선택들을 해주시는게 있는데 나는 불편해 하는 사람이 있는지 확인해주는 정도의 역할을 하고 내 일을 하고 있다.

개발자는 개발만, 디자이너는 디자인만하는 상황에서 조금 벗어난 것 같아 좋으면서도 여러가지 생각이 든다. 이 상황이라면 기획자는 무엇을 해야할까? 하고. PM은 무엇을 해야할까?

보통 작은 규모의 팀이면 기획자가 PM의 역할을 할 것 같다.

중간에서 각 말단에 있는 사람들의 의사소통 창구로 있는게 맞지는 않는 것 같다. 만약 이견이 나오면 그건 그거대로 다시 소통을 해줘야하니까. 

나는 기본적으로는 ’UI 기획‘은 UI개발자와 디자이너가 해도 괜찮다는 생각을 하고있는데, 서비스 기획이라면 그냥 이정도의 요구사항과 기준을 세우고 이를 토대로 다른 사람들이 이야기하면서 진행할 수 있도록 뒤에서 밀어주면 되지 않나 싶다.

전통적인 상황이라면 나는 기획자도 PM도 아닌 사람이지만, 내 생각에는 기획자/PM이 해야할 일을 하고 있는게 아닌가 생각중이다. 

‘사용자는 좋아하는 음식점 리스트를 만들고 싶어할 것이다.’ 가설을 세웠고, 검증을 위한 준비를 한 것으로 어느정도 할 일을 마무리 한 것 같다. 다음으로는 출시하고 사용자의 의견을 살펴보고, 다음 단계를 고민하면 될 것 같다.

추가

중간에 약간 문제가 있던 부분이 있었다. 실제 구현에 동상이몽을 하는 경우였다. 작업자간 유저스토리만 가지고 이야기하는 경우 구현에 있어 목적은 같으나 서로 다른 생각을 하는 상황이 있었다.

금세 이야기해서 맞출 수 있긴 했는데 회의하거나 논의한 다음에 결정사항을 잘 남겨놓는게 좋겠다.