• 다른 개발자와 의견 충돌이 있을 때, 단지 의견이 다르다고 해서 감정까지 상할 필요는 없어요. 상대방도 자신의 의견에 대한 충분한 근거가 있을 거에요. 상대방의 주장과 근거를 모두 들어보고, 본인의 주장과 근거를 상대방과 함께 비교해봐요.

• 개발을 하다보면, 정말 많은 경우에는 이미 의견 충돌이 생기는 주제에 대한 해답을 인터넷에서 찾을 수 있어요. 특히 요즘에는 주니어 개발자들, 대학생들까지 양질의 블로그 글을 작성하기 시작하면서 이전보다 비교적 쉽게 원하는 정보를 찾을 수 있어요. 이런 레퍼런스들을 모아서 비교해도 좋아요.

• 그렇다면 레퍼런스까지 없는 상황이라면 어떻게 하면 좋을까요? 제가 실제 기업 면접에서 받은 질문인데요. 이럴 때는 최대한 비즈니스를 먼저 생각해야 하는게 좋다고 생각해요. 비즈니스 요구사항의 충족 측면에서, 의견 충돌로 인해 개발이 지연된다면 꽤나 치명적이라고 생각해요. 우선 비즈니스 관점에서 사고하고, 빠르게 요구사항을 만족한 후 그 이후에 다른 의견을 적용해보고 비교해보는 게 좋다고 생각해요.

개인적인 생각이지만, 하나의 프로젝트를 완성하기 위해선 각자의 역할이 굉장히 중요해요. 기획자는 외부 커뮤니케이션, 프로덕트를 더 발전시킬 수 있는 방법 등을 생각하고, 디자이너는 어떻게 하면 사용자에게 편리하고, 프로덕트에 어울리는 UI를 제공할 수 있을지 고민하고, 만들어 내요. 개발자는 실제 프로덕트를 만들어냄으로써 프로젝트에 기여해요. 이렇게 각자 맡은 역할에 따라 비즈니스 요구사항을 충족하기 위해 노력하게 돼요.

• 기획안에는 나와있는 기능이 주어진 개발 기간 내에 구현하기 어렵다고 판단되는 경우가 있을 수 있어요. 이럴 때는 주저 하지 않고 이야기 해야 해요. 왜냐면 해당 기획안을 기획자가 더 디벨롭하고 있을 수도 있기 때문이에요. 이야기하기를 꺼리거나, 미룬다면 기획안은 더 고도화되고, 개발도 못하게 될 수도 있어요. 단, 이야기 할 때 어떠한 이유 때문에 해당 기능이 구현하기 힘들 것 같은지에 대해 명백하게 이야기해야 해요. 모든 기획자가 개발에 대해 알지 못해요. 따라서 이유를 설명할 때, 개발자가 아닌 그 누구도 이해할 수 있도록하는 본인만의 커뮤니케이션 능력을 키워야해요. 저 같은 경우에는 실생활과 비유하는 방식을 사용해요. 예를 들어, 데이터베이스를 엑셀로 비유하는 것 처럼요!

• 기획안을 보고, 아니면 개발을 진행하면서도 기존 기획안보다 더 낫다고 생각되는 아이디어, 또는 바뀌었으면 하는 부분이 생각날 수 있어요. 이런 경우에도 정말 기본적이지만, 항상 근거를 제시하면 좋아요. 기획자가 왜 기획안을 그렇게 만들었을지 충분히 고민해보고, 그게 어렵다면 먼저 물어보세요. 해당 기획안이 그렇게 만들어진 백그라운드를 알고 나서도 제시하고 싶다면 그때는 편리하게 제시하시면 돼요! 좋은 기획자들은 팀원들이 프로덕트에 의견을 자유롭게 제시하고, 반영하고 싶어하는 모습을 좋아해요.

• 디자이너가 만든 디자인을 보고, 바뀌었으면 하는 화면이 있을 수 있어요. 이런 경우에는 절대 바로 의견을 제시하지 말고, 다른 상황과 마찬가지로 근거를 먼저 제시하는게 좋아요. 디자인된 화면의 거의 모든 부분은 다 의미가 있습니다. 심지어 픽셀 값 까지도요. 분명히 디자인된 의도가 있을 테니, 기획자와 소통할 때와 마찬가지로 의도를 파악한 후 근거와 함께 의견을 제시하면 좋을 것 같아요!

마무리 하며.... 개인적으로 저는 의견 제시, 의견 차이 등으로 생기는 커뮤니케이션에는 모두 근거가 있어야 한다고 생각해요. 정리된 근거 없이 의견만 제시하면, 상대방에게 의도치 않은 상처를 줄 수도 있고, 감정 소모까지도 이어질 수 있어요. 하지만 상대방에게 제시할 수 있는 명확한 근거가 있고, 그 근거를 기반으로 의견을 제시한다면 서로 상처 받을 일을 줄일 수 있다고 믿고 있어요.