주니어 프로덕트 디자이너가 일하는 방법
느리더라도 꾸준히 성장하고 싶다.
어느덧 프로덕트 디자이너로 일을 시작한 지 1년이 지나가고 있다. 현재는 프로젝트 매니저와 프로덕트 매니저의 경계의 일을 하면서 어떻게 하면 정해진 시간 안에 효율적이게 일을 하며 함께 성장할 수 있을지 고민하며 일한 방식을 회고해보았다.
첫 번째, 모든 해결은 질문에서부터
아마 입사 후 가장 많이 했던 것이 질문일 것 같다. 실무와 비슷한 프로젝트를 했었다 해도 실전은 완전히 달랐다. 백앤드, 프런트 앤드가 무엇을 하는지도 몰랐을 시절... 입사 한 달 후 온전히 혼자 프로젝트를 진행했어야 했다. 클라이언트와 의사소통은 어떻게 하는지, 개발자와 소통은 어떻게 해야 하는지 모든 것이 막막했을 때 틈만 나면 관련 부서분들께 질문했었다. 기존 프로젝트들을 살피면서 눈치껏 일을 진행하다가도 애매한 것이 있을 때면 무조건 물어봤다.
단, 우선 시도해보고 질문하자. 그리고 쉬운 단어로 질문하자.
고민했던 문제의 대부분은 직접 시도해보고 기존 프로젝트를 확인해보면 해결되었기 때문에 일단 혼자 해보고 안된다면 질문 리스트를 만들어서 한 번에 물어보았다. 질문 리스트를 만들 때에는 쉬운 단어를 사용하려고 노력했다. 이유는 기획업무의 경우 전후관계를 파악해야 답을 할 수 있는 경우가 많기 때문에 해당 프로젝트에 참여하지 않아도 이해할 수 있도록 해야 했고 그러려면 우선 내가 완벽히 이해해야 했다.
아무튼 질문하지 않고 혼자 판단하면 괜찮겠지 하고 넘어갔던 것이 더 큰일이 되어 돌아올 수 있으니 할까 말까 할 때는 무조건 질문하기!
두 번째, 친한 개발자 동료 만들기 그리고 함께 기획하기
IT업계의 PM업무는 개발지식이 정말 필수인데 책을 읽는다 해도 사실 이해가 잘 되지 않는 경우가 많다. 그래서 친한 개발자 동료를 꼭 만들어 두기를 추천한다. 이유는 자투리 시간에 궁금했던 개발 용어나 기획할 때 개발적으로 어떤 게 더 쉬운지 질문하면서 함께 기획하다 보면 책을 읽는 것보다 훨씬 많은 것을 그리고 빠르게 배울 수 있다.
'이렇게 하는 게 좋을 것 같은데 개발적으로 괜찮을까요? 더 좋은 방법이 있으면 알려주세요!'라고 질문하면 '해당 부분에서는 00 이렇게 개발이 될 것 같아요. 근데 00 이런 방식으로 개발하면 더 쉽고 빠르게 갈 수 있는데 어떤가요?'라는 피드백을 주고받으면서 도메인 지식을 비롯하여 개발자들이 어떻게 사고하는지 직간접적으로 알 수 있었다.
이후에 새로운 프로젝트를 기획할 때는 고려해야 할 개발적인 부분에 대한 도움을 받을 수 있었다.
(+개발 지식을 아는 만큼 기획할 수 있는 범위도 넓어지더라!)
마지막으로 무조건 정리하고 기록하기
여러 개의 프로젝트를 진행하다 보면 외부, 내부 할 것 없이 미팅 지옥에 빠지게 된다. 특히 클라이언트 잡인지라 커뮤니케이션의 오류를 최소화하는 것이 가장 중요한데 미팅 때 서로 합의된 내용을 구두로만 전달할 경우 이후에 기획이 갈아 엎어지는 대참사가 일어나기도 한다. 그래서 항상 미팅이 끝난 후 주요 내용을 정리해서 전달하고 확인했다는 말을 꼭 받고 내부에 공유한다.
사실 기획과 디자인과 매니징까지 동시에 하면서 매번 기록한 것을 정리하는 것이 힘들기는 하지만 하다 보면 일의 우선순위 파악과 이전 프로젝트의 히스토리까지 한눈에 확인이 가능하기 때문에 만약 누군가가 중간에 프로젝트에 투입이 되더라도 빠르게 적응할 수 있도록 하기 위함도 있다. 내가 조금만 더 힘들면 함께하는 동료들은 조금 더 편하게 일할 수 있다!
앞으로 내가 생각하는 나의 모습은!
사실 아직도 나의 업무가 프로덕트 디자인이라고 딱 잘라 이야기할 수는 없지만 일을 하면서 앞으로 내가 되고 싶은 모습은 개발 도메인 지식과 더불어 커뮤니케이션하기 편한 사람이 되고 싶다. 여러 개의 서비스를 만들면서 느끼는 것은 정보전달의 오류가 생기지 않도록 하는 것, 함께 프로젝트를 진행하는 팀원의 업무가 꼬였을 때는 정리해주는 것, 더불어 함께 만들어 나가는 것이라 생각한다.
올바른 Management는 혼자 결정하고 진행하는 것이 아니라 파트너로서 함께 만들어가는 것이라는 생각이 든다.
