오늘도 기획자가 왜 안되냐고 했다 1편
하지만 전 토니 스타크가 아닙니다...
서비스기획자에 입문하거나 주니어 시절을 보내다 보면 가장 많이 듣게 되는 단어는 대부분
"안된다" 또는 "어렵다"라고 볼 수 있다
이는 서비스의 특징과 개발구조를 명확하게 파악하기 이전에 기획을 진행한 경우 발생할 수 있는데, 문제는 이를 알아차리는 시기가 대부분 개발자와 소통을 시작할 때라 많은 기획자가, 그리고 내가 어려움을 겪고 있었다.
표지만 봐도 구매욕구가 샘솟는다그렇기에, 위와 같은 상황이 많이 펼쳐질 텐데, 이를 기획자를 꿈꾸거나 나와 같은 주니어들이 현명하진 않더라도 실패하진 않도록 내가 겪었던 시행착오와 여러 사례들로 해결 방법을 작성하고자 한다.
1. 이 서비스처럼 만들어주세요.
??? : 하...하지만 저희는 구글이 아닙니다...기획 초기 서비스를 밴치마킹, 역기획을 하며 핵심기능을 기획하고 설계하는 경우가 많다.
그렇다 보니 다른 서비스에서 이미 구현된 기능을 요청하는 경우도 자주 있는데, 그 과정에서 당시 나의 시니어는 다음과 같이 말하기도 했다.
그 서비스가 그렇게 만들었다면 우리도 만들 수 있다.
이는 지금 와서 생각해도 틀린 말은 아니다.
간단히 생각해도 같은 모바일 앱을 만드는데 다른 앱에서 구현한 기능이 우리 앱에 안된다는건 납득하기 어려울 수 있다. 실제로 구현이 가능했기에 개발하여 서비스 중이고, 이는 우리가 개발하는 앱이라고 다르지는 않을 것이니 말이다.
하지만 이는 상황에 따라 반은 맞고 반은 틀릴 수 도 있다.
보통 서비스기획을 다른 분야 사람들에게 소개할 때 나는 건축에 빗대어 설명하는 경우가 많은데, 같은 건물도 어떻게 시공하냐에 따라 구조가 달라진다는건 모두 알고 있을 것이다.
예를 들어, 우리 서비스는 3층까지 쌓을 건물이여서 별도로 엘레베이터를 염두하지 않은채로 건물을 지어나갔다. 그러다, 엘레베이터를 갑자기 추가를 하자고 결정 나더라도 엘레베이터를 배치할 공간, 이를 동작하도록 구성하는 설비가 갖춰지지 않은 건물에 엘레베이터를 추가하긴 힘들 것이다.
이를 기획에 대입하면 건물은 서비스, 엘레베이터는 기능이라 볼 수 있다.
엘레베이터가 있는 건물도 많고, 사용화된 매우 일반적인 설비이지만 아무 건물에나 추가할 수 없는 것 처럼, 서비스에도 구조에 따라 추가할 수 없는 기능이 있다는건 언제든 염두해야한다.
방법에 따라 다른 결과가 생기는 건 우리 모두 알고있다물론 개발은 건축보다 유동적이며 적용도 비교적 원활하지만, 기존 설계된 API, 개발 구조 등, 쉽사리 방향을 틀 수 없는 사항도 있음도 틀림없다.
이를 예방하기 위해서는 정확한 서비스의 구조를 파악하고 올바른 요청을 진행함이 현명한 기획자라 할 수 있다.
2. 일주일 안에 만들어주세요!
*이러시면 안됩니다기획자 입장에서는 정말 간단해 보이는 사항들이 여럿 있다.
가령 “채팅앱에서 상대가 채팅을 보내면 알림이 오게 해 주세요” 라던지
하지만 서비스를 기획해본 적 없는 완전 신입이나 경험이 많지 않은 주니어는 한 번씩 간과하는 것이 있는데, 그것은 서비스를 기획할 때, 그 어떤 것도 자동으로 만들어지지 않는다는 것이다.
위처럼 메시지를 하나 보내는데도 많은 준비와 구성이 필요하다.
기본적으로 메시지를 보내면 어떤 기준(전회번호, 유저넘버, 아이디 등)으로 수신인을 특정하고 메시지를 수신시킬지, 한 번에 전송 가능한 메시지의 크기는 어떻게 한정할지 등 간단히 ’ 보낸다 ‘라는 짧은 동작에도 많은 고려할 점이 필요하다.
이보다 더 더 깊게 들어가 보자
그렇다면 이제 서비스의 정책과 개발 구조에 대해 연관하여 서비스를 설계해야 한다.
예를 들어, 우리 서비스의 정책이 익명 메시지를 지원하는가, 한 번에 여러 명에게 보낼 수 있는가 등부터, 모바일 PC 등 멀티 플랫폼을 제공하도록 개발하는 가 등 케이스는 ’ 메시지를 보낸다 ‘라는 짧은 요청사항에 비해 비대해지고 복잡해진다.
이런 상황을 인지하고 일정을 조율하고 협의를 진행해야 하지만, 간단하다고 판단 후 라이브 배포일을 지정한다면 많이 고단한 상황에 직면할 것이다.
마치며
적어도 나와 같은 실수를 하는 사람들에게 도움이 되는 글이길 바라며 다음에 2편으로 돌아오겠다.
