처음 기업의 웹페이지 기획을 맡다.
아쉬움만 남는 순간의 연속, 어떻게 주워 담을 수 없을까?
F&B 기업의 배달앱 출시를 마치고 나는 해당 프로젝트에서 빠지게 되었다. 다음으로 나는 어느 기업의 CSR 홈페이지를 메인으로 맡게 되었다. 처음 이야기를 들었을 때, 너무 부담이 되었다. 애초에 나는 혼자서 웹페이지를 기획해 본 적이 없을뿐더러 배달앱에서도 일부를 기획했을 뿐 하나의 전체 프로젝트를 맡는다는 것에 나는 큰 부담감이 느껴졌다.
이 프로젝트가 나에게 온 이유는 애초에 프로젝트 규모가 크지 않다는 것이었다. 그래서 처음에는 기능적인 면 적고 페이지 수도 그렇게 많지 않아서 열심히 해보자라는 생각도 들었다. 하지만, 막상 겪어가며 느낀 것은 역시나 경험 부족은 어쩔 수 없다는 것이었다. 아쉬웠던 포인트를 글로 남겨두고 앞으로 프로젝트에서 아쉬움을 덜어내고자 한다.
1) 적극적으로 물어보고 논의하기
어떤 프로젝트 이 건 기획자가 처음부터 모든 것을 파악하고 이해하기란 어렵다. 이를 위해서는 적극적으로 물어보고 혹은 논의해 결정을 내려야 한다. 이 프로젝트에서 첫 번째 문제는 원타임 URL이었다. 고객사에는 유저들이 참여할 수 있는 프로그램을 운영하고 있어서 신청받는 프로세스가 중요한 이슈였다. 나는 원타임 URL에 대한 이해도가 없었고 그렇다 보니 기획을 하는 데 있어서 급한 불 끄자는 식으로 아는 부분부터 처리하게 되었다. 그리고 나중에 시간이 조금 지나고 이해한 후에 그렇게 어려운 개념이 아니라는 것을 알게 되었다. 그러나 만약 보다 빨리 확인했다면 이번 경험처럼 찜찜하게 프로젝트를 진행하지 않았을거라는 생각이 자주 들었다.
다음으로는 텍스트 에디터였다. 에디터 간 기능 차이가 크지는 않지만 종류가 있고 유로 서비스도 있다는 것을 알게 되었다. 기획으로서 에디터는 에디터로 남겨두면 끝이 아닐까 생각했지만 개발자와 어떤 에디터를 사용할지 논의가 필요했고 유료 서비스를 이용한다면 고객사와도 협의가 필요했다. 사용 에디터에 따라서 입력 폼의 input이 달라지는 만큼 중요한 안건이었다. 원타임 URL과 텍스트 에디터 모두 기본적인 개발 공부를 했던 터라 스스로 찾아보며 해결한 부분도 있었지만 오히려 이렇게 진행하는 것보다는 개발자에게 바로 물어보고 논의하는 것이 좋다고 판단되었다. 논의를 통해 서로의 요구사항에 대한 공감대를 쌓고 팀으로서 결정 안을 만들어 놓는 것이 프로젝트를 진행함에 있어서 더 효율적인 방법임을 깨닫게 되었다.
사실 이 문제의 일정 부분은 내 성격의 기인했다. 나는 참 누구에게 물어보는 것을 어려워한다. 이런 이야기를 하면 그런 성격으로 어떻게 기획자를 하려고 하냐라는 말을 듣는데 어쩌다 보니 기획자가 되었다. 그렇다고 이야기 자체를 어려워하는 것은 아니고 일 이야기를 하면 편하게 할 수 있지만 뭔가 물어보는 것이 특히 어려웠다.
그리고 난 어른을 좀 많이 어려워한다. 이건 누구나 비슷할 수 있긴 하다. 하지만, 회사에서 동년배만 있을 수 없다. 부장, 차장, 과장, 대리, 사원이 있기 마련이고 나이 차가 있을 수밖에 없다. 부장, 차장 개발자와 이야기하면 갑자기 얼어붙으면서 뚝딱거리는데 그 모습을 본 개발자 분들은 오히려 편하게 해 주려고 노력해 주신다. 그래도 오랫동안 이렇게 살아오다 보니 여전히 어렵기에 나에게는 큰 숙제이다.
2) 큰 틀에서 우선순위 결정하기
처음 요구사항 문서로 해야 할 일을 작성한 후에 와이어 프레임 그리고 본격적인 기획 문서를 작성하면서 문서에 매몰되는 내 모습을 보았다. 실상 문서 안에서 내용이 정리되지만 정작 중요한 것은 내 머릿속에서 내용이 정리되고 일의 우선순위가 정리되야 하는 것이었다. 이번 케이스에서 중요한 포인트를 되돌아보자면
- 신청 프로세스
- 관리자 페이지에서 프론트 페이지 제어 기능
이 2가지로 압축할 수 있지만 문서 쓰기 급급했던 나는 시행착오를 자주 겪었다. 홈페이지의 목적성에 맞게 페이지가 구성되는 만큼 홈페이지의 가장 중요한 목적은 무엇인가를 질문을 가장 먼저 던졌어야 하지만 그러지 못했다. 그렇다 보니 고객의 요구사항이 눈에 잘 들어오지 않고 페이지 하나하나 눈앞에만 목표만 쫓아가게 되었다. 이런 이유로 정작 중요한 기능들에 대한 상세 파악이 뒤늦게 이루어졌고 늘 찜찜한 마음으로 프로젝트를 진행할 수밖에 없었다. 큰 프로젝트였다면 큰 실수로 이어질 수 있었지만 다행히 그런 일까지는 벌어지지 않아서 지금 생각해보면 참 미숙했다는 생각이 든다.
3) 프로젝트는 팀으로 운영되는 것
나는 PM이다라는 유튜브 채널에서 PM이 줄 수 있는 가치가 뭔지에 대해 설명해 주었다. 정확히 기억은 안 나지만 고객의 요구사항 혹은 이 프로젝트의 목적을 가장 잘 설명할 수 있다는 것이었다. 그리고 반대로 개발자 및 디자이너도 기획자만큼은 아닐지라도 고객의 요구사항 및 이 프로젝트의 목적을 이해하며 작업을 해야 한다는 것이다. 기획자가 1~10까지 정책을 작성할 수 없을 뿐더러 세세하게 와이어 프레임을 작성할 수도 없다. 이미 고객의 요구사항 파악 혹은 이 프로젝트의 설계만으로도 시간이 부족하기 때문이다. 그렇기 때문에 문서에 쓰여있지 않다고 하더라도 개발자나 디자이너 스스로도 방향성에 맞는 코드 작성과 디자인을 산출물로 스스로 내놔야 한다. 물론 작업자들도 스스로 결정하기 어려운 포인트가 있을 것이기에 기획자와의 논의도 열려있어야 할 것이다.
나는 이런 부분을 놓치고 있었고 모든 것은 문서에 담으려고 했다. 그렇다 보니 정말 시간도 없고 몸은 지쳐가 생각의 여유도 사라졌던 순간이 있었다. 영상을 보고 나서는 스스로 기획자는 만능 잡부가 아니라는 것을 인정하고 요구할 것은 요구해야 한다는 것을 깨달았다. 생각 보면 고객의 요구 사항을 파악해야 한다는 것은 너무나 당연한 이야기고 오히려 기획자가 세세하게 정해버리는 것은 이들의 생각을 차단하는 역효과를 만들어 낼 수 있다는 것을 주의해야 했다. 하지만, 현실에서는 그저 코더나 UI를 그리는 데 그쳐버리는 사람이 존재한다는 것 역시 인정해야 할 수 밖에 없었다.
남은 기간은 이번 아쉬운 포인트들을 최소화해가며 첫 메인 프로젝트를 잘 완수하고 싶다.
