서비스 기획자의 기록 | '7년차 기획자의 커뮤니케이션'을 신입 기획자 관점에서 리뷰해보자

https://yozm.wishket.com/magazine/detail/2274/

7년차 기획자의 커뮤니케이션 실제 사례 | 요즘IT

 

 

 

한 커뮤니티에서 7년차 기획자의 커뮤니케이션 실제 사례라는 제목의 아티클을 읽게 되었다. 글은 디자이너와의 소통, 프론트엔드, 백엔드 이렇게 세 갈래로 구성되어 각 직군과의 업무 중에 있었던 문제 해결 에피소드를 담고 있다. 읽으면서 내가 사이드 프로젝트에서 일을 하면서 느낀 점들, 인사이트와 비슷하다는 생각이 들어 많이 공감이 되었다 !

​

그 글을 리뷰하면서 내 이야기를 덧대고자 글을 쓴다.

​

​

​

1. 디자이너: 기획의도를 잘 전달하기

디자이너분들이 와이어프레임을 작업하실 때 자주 나오는 얘기 중에 하나가 "이건 기획의도가 뭐예요?"였다.

​

디자이너와의 원활한 소통을 위해서는 기획의도를 잘 전달하는 게 중요하다고 느꼈다. 디자이너분들은 시안을 정말 많이 만들고 계속 계속 수정을 한다. 따라서 명확한 방향성이 주어지지 않고 밑도 끝도 없는 자율성이 부여될 경우에는 기획자가 생각한 것과 다른 디자인이 나올 뿐만 아니라, 작업이 딜레이 되는 일이 발생한다. 이런 일이 발생하지 않으려면 디자이너분들이 작업에 들어가기 전에 기획안을 같이 보면서 이해 안 되는 점, ux 관점에서 보완이 필요한 점, 디자인 톤앤매너 등에 대한 디테일한 리뷰를 해야 한다.

​

우리 프로젝트에서 나는 최종 기획안을 전달한 뒤에도 디자이너 회의에 가능한 꼭 참석해서, 기획의도가 제대로 얼라인되었는지 확인했다. 기획안 리뷰를 같이 진행했음에도 막상 작업에 들어가면 디자이너분들 눈에 수정해야 할 부분, 디테일에 대한 궁금증이 생긴다. 그래서 회의에서 같이 얘기하면서 UX 관점에서 더 괜찮은 방향으로 기획안을 손볼 수도 있다.

​

그런데 이런 일이 이미 발생했고 디자이너가 고충을 겪고 있다면? 이때 기획자로서 디자인 진행 현황을 파악하여 우선순위에 따른 결단력이 필요하다. 디자이너 분들이 여러 시안을 두고 너무 고민을 오래 하셨다. 기획 단계부터 골칫덩어리이던 특정 그래픽에 대해서 이런 건 오히려 디자이너분들이 잘 표현해 주실 것 같다는 생각으로 디테일이 부족한 채 디자이너분들에게 넘겨드렸기 때문이다. (당시 디자이너분들도 동의를 하셨지만, 이제 생각해 보면 기획자의 잘못이다) 결국 더 딜레이 되는 걸 기다릴 수 없어, 각 상태에 대한 디테일을 기획자인 내가 결정했다. 이후 디자이너분들도 더 필요한 곳에 자원을 집중할 수 있었다. 처음부터 엣지 케이스 상태에서의 노출을 결정해 드렸으면 좋았을 텐데. 기획자의 여러 상태, 순방향/역방향을 고려한 기획이 중요하다는 걸 이 경험을 통해 생생히 깨달았다.

 

​

2. 프론트엔드: 디자인 시안과 기획서를 동시에 보는 고충을 해결하기

프론트 쪽에서 “최종 시안이 뭐예요? 지금 있는 게 최종 기획안인가요?”라고 문의한 적이 있었다.

​

프론트엔드분들은 디자인 시안과 기획서를 같이 보면서 개발해야 한다. 그러니 시안과 기획서의 맵핑이 중요하다. 우리는 피그마에서 디자인 시안 바로 옆에 화면설계서를 두고 있기 때문에 맵핑을 많이 걱정할 필요는 없었다. 그래도 최종 시안이 완성되면 기획-디자인 회의를 통해 데이터 노출에 대한 표현과 동작 시점 등을 리뷰해야 한다. 디자이너분들의 실수로 시안에서 사소한 기능들이 누락되기도 하기 때문이다.

​

또한 시안 변경사항에 맞춰 기획안도 업데이트해야 한다. 디자인 시안이 수정을 거듭하면서 자잘한 기획사 항도 바뀌기 때문이다. 최종 시안 옆에 화면설계서를 다시 작성해야 한다. 이 역시 나중에 프론트 측에서 구현에 이슈가 발생하지 않도록 리뷰해야 한다.

 

​

3. 백엔드: 구조적으로 접근하기

백엔드 개발자분께 받았던 철렁했던 슬랙 메시지"비즈니스 로직이 이게 맞나요? 섹션과 태그가 겹치는데요. 헷갈려서 질문드립니다."

​

개발 도중 기획서에 없던 스펙이 추가되어 추가 공수가 발생한 백엔드 개발자의 고충 부분이 충분히 이해가 된다. 우리 팀 역시도 백엔드에 서비스할 범위를 넘겨줄 때 추후 db 설계를 다시 해야 하거나 플로우를 다시 짜는 등의 고충이 발생하지 않도록 작업하는 걸 중요하게 생각했다. 그럼에도 불구하고 커뮤니케이션이 부족으로 invisible하게 처리하는 컬럼이 추가로 발생하게 되었지만, 공수가 크게 드는 일은 아니었다. 여하튼 그러한 이슈를 처리하면서, 역시 커뮤니케이션이 가장 중요하다는 생각이 더 커졌다.

​

글을 통해 추후에 발생 가능한 확장 기능에 대해서도 언지를 주는 게 중요하다는 걸 배웠다. 그래야 개발자가 확정 기능과 가변 기능을 분리해서 아키텍처 설계와 모듈 단위의 작업을 할 수 있기 때문이다.

​

또한 추가 기능 발생 시 그 기능이 왜 필요한지를 충분히 납득이 가게끔 설명하는 센스가 필요하다. 우리의 경우 재입고 노티를 열심히 기획했다가 여건상 처리가 어려워서 빠지게 되었는데, 그 과정에서 추후 모바일에 넣을 기능이라고 설명하며 개발자들과 적절하게 소통했었다. 또 푸시 노티의 경우 플로우가 바뀌었는데, 이건 다행히 개발자가 개발에 들어가기 전 디자이너와의 회의에서 ux를 고려하여 바뀌게 되었다. 이렇게 바뀌게 된 히스토리는 특히나 중요하게 표시하여 헷갈리지 않도록 하였다.

​

마치며

기획자의 손길은 작업 구석구석에 닿는다. 기획안 작성은 끝이 아니라 시작이며, 여러 직군과의 회의, 조율, 우선순위 결정, 법률과 정책 검토, QA 등등.. 이렇게 다양한 업무를 잘 수행하기 위해서 역시 가장 중요한 건 커뮤니케이션임이 분명하다.

어떤 사람들은 이런 직무 특성 때문에 기획자를 잡부라고 부르기도 한다. 그러나 프로젝트에서 일하면서 나는, 기획자를 '일이 잘 되게 만드는 사람'이라는 정의를 내렸다. 서비스의 탄생과 원활한 운영이 되게 하기 위해서 많은 제반 사항을 핸들링할 수 있는 사람. 꼭 필요한 일이라고 생각한다.

​

7년차 기획자의 글을 리뷰하다 보니 디자이너, 개발자와의 소통에 있어서 내 인사이트와 깨달음이 바람직한(?) 길로 가고 있다는 것을 느꼈다. 일견 뿌듯하기도 했다. 그러나 개발자와의 소통에 있어서 아직 부족한 점이 많다는 걸 느꼈다. 글쓴이와 같이 개발자와의 소통에 필요한 용어들과 기술적인 백그라운드를 이해하기 위해 인풋을 게을리하지 말아야겠다.