[Publy] 제품문화 - 인스파이어드 : 감동을 전하는 IT제품은 어떻게 만들어지는가?

제품 문화좋은 제품팀 Vs. 나쁜 제품팀 / 혁신을 잃는 10가지 이유 / 속도를 잃는 10가지 이유 / 강력한 제품 문화 구축하기publy.co

💬제품팀이 가져야할 문화

이 아티클에서 제품문화에 대한 내용으로 좋은팀vs나쁜팀, 혁신을 잃는 10가지 이유, 속도를 잃는 10가지 이유, 강력한 제품 문화 구축하기 4가지로 이야기하고 있다.

많은 부분에서 공감이 갔는데 내가 생각했을 때 중요한 점은 이렇다.

제품의 아이데이션 그러니까 시작 단계에서 부터 모든 이해관계자가 참여해야 한다.

핵심 기능 위주 개발과 빠른 실행 그리고 실패를 두려워 하지 않는 마인드.

각 구성원들간의 신뢰(일정)

기획단계에서 제품 개발의 의미, 요구사항, 목적을 공유하고 각 포지션에 맞는 아이데이션이 필요하다. 단순히 기획자가 모든 내용을 만들어서 던져주기만 하는 것이 아니다. 대부분의 기업들에서 기획은 기획자가, 디자인은 디자이너가, 개발은 개발자가.. 라는 공식이 굳어져 있다. 물론 각자가 해야할 일이 명확하게 있지만, 초기단계에서 적극적으로 참여하는 것과 아닌 것의 차이는 엄청나다.

특히 내가 겪은 개발자는 기획 문서를 진작에 보내줘도 전혀 검토하지 않고 외형 작업물(디자인)이 나오면 그떄서야 개발을 진행하는 사람이 있다. 그리고 개발하면서 발생하는 문제에 대해 다시 사람들을 모아 의견을 묻고 결정한다. 답답할 노릇이다. 문서만으로 개발 시나리오가 충분히 예상 가능하고 초기 개발 단계에서 발생할 수있는 문제를 빨리 캐치하여 공유하는 것도 개발자의 능력이다.

빠른 계획과 실행만이 답이다. 1일 동안 해야할 고민사항을 2일, 3일 한다고 크게 달라지지 않는다. 일단 만들고 고객들에게 뿌려본 후 내외부 반응(데이터 및 Voc)에 따라 변경하거나 폐기 후 다시 실행해야 한다. 아무리 많은 고민을 하고 런칭해도 고객들의 반응을 예측하기란 사실상 불가능하다. 실패의 경험은 곧 성공을 위한 밑거름이다.

각 구성원들 간의 신뢰. 가장 중요하지 않을까? 적어도 자기가 뱉은 말에 대해서는 책임을 져야 한다. 본인이 정한 일정은 밤을 새든, 주말 근무를 하든 어떻게든 지켜야 한다. 본인이 제시한 약속을 지키지 않는 것은 같이 일해서는 안 되는 사람이라고 생각한다.

물론 일정은 늘어날 수 있다. 앞서 이야기 했듯이 미리 본인의 영역을 분성하여 초기 문제점을 파악하여 해결 한 후 실행 하는 중에 지속적인 소통을 통해 문제를 해결해 나가야 한다. 나의 경험상 신뢰가 없는 사람은 데드라인에 닥치면 그제서야 문제점을 공유하고 해결방법을 제시하는 것이 아니라 오히려 알려 달라고 한다. 이렇게 되니 이후 다른 업무를 하더라도 신뢰가 0인 상태에서 시작하기에 크게 기대도 하지 않게 된다.

결국 프로젝트의 성공확률은 낮아지고 데드라인까지 달성해야할 제품의 퀄리티는 점점 낮아지고 명확하게 끝나는 것이 아닌 2차, 3차 개발로 넘어가게 된다. 이 경우 100% 프로젝트가 완벽하게 완성되지 않는다.

처음부터 다 함께 모여 필수 기능을 빠른 시간에 완성할 수 있는 방법을 찾고 런칭한 후 문제점을 발견하여 지속적인 개선이 이루어 져야 한다. 고객에게 완벽한 제품을 제공할 수는 없다. 하지만 당장 필요한 것을 앞으로 지속해 나가야할 제품의 철학에 맞게 개발하는 것이 중요하지 않을까?

일하면서 느끼는 점은 실력이 1순위가 아니라는 것이다. 커뮤니케이션, 신뢰 그 다음이 실력이다. 사실 앞 2개를 잘 하는 사람이 실력도 좋다. 커뮤케이션도 안되고 타인에게 신뢰도 못 받는 사람치고 일 잘 하는 사람은 없다. 아니 다른 사람이 그렇게 느끼지 않는다.

#퍼블리뷰 #3일차