퍼블리 읽어주는 청년 206 협업을 잘 하는 것은 직장생활을 하는 모든 사람에게 필요한 기술입니다. 협업을 잘 하려는 대상이 되는 동료를 잘 이해해야 합니다. 동료의 역할과 상황에 대해 관심을 가

퍼블리 읽어주는 청년 206 협업을 잘 하는 것은 직장생활을 하는 모든 사람에게 필요한 기술입니다. 협업을 잘 하려는 대상이 되는 동료를 잘 이해해야 합니다. 동료의 역할과 상황에 대해 관심을 가지고 있어야 이해를 할 수 있습니다. 협업은 내가 하고 싶은 것을 일방적으로 요구하는 것이 아니라 동료와 뜻을 맞춰 함께 나아가는 것이기 때문입니다. 오늘은 협업을 위해 동료를 이해하는 따뜻한 울림이 있는 노하우 콘텐츠를 소개합니다 :) 다름을 충돌로 만들지 않는 서비스 기획자의 노하우 저자 Olivia 내가 협업자의 영역에 대해 모른다는 점을 인정해야 의견 차이를 갈등이 아닌 다름으로 수용할 수 있게 되더라고요. 개발자, 디자이너, 기획자가 협업하는 과정에서 서로의 입장 차이로 의견 충돌이 생기는 건 당연하다. 각자 다르기에 협업자와 공통적으로 가져가야 할 목표와 방향성을 항상 강조한다. 기분이 태도가 되지 않아야 하고, 다른 의견을 경청하고, 존중하며 서로 신뢰해야 한다. 디자이너는 기획에서 설계한 내용을 사용자가 최적의 경험을 할 수 있도록 디자인하는 전문가입니다. 디자이너 입장에서는 기획자의 피드백을 간섭이라고 느낄 가능성도 있기 때문에 조심스럽게 대처할 필요가 있습니다. 이런 경우, 바로 수정 요청하는 것이 아니라 왜 디자인을 그렇게 했을지 먼저 고민해보고, 그 방향으로 했을 때의 장점을 우선 생각해보면 좋습니다. 디자이너는 사용자에게 최적의 경험을 제공하는 방향으로 디자인하는 사람입니다. 기획서대로 하지 않은 이유가 분명 있을 거예요. 디자이너의 의견을 들어본 후 납득할 수 있는 이유가 있고, 더 나은 방향으로 도출된 결과물이라면 그대로 진행해도 됩니다. 반대로 기획자가 생각한 방안이 더 나은 결과물이라는 생각이 든다면 디자이너를 설득해야 합니다. 설득할 때는 데이터 기반의 정량적인 근거를 토대로 이야기하는 게 가장 좋고, 그렇지 못할 때는 사용자의 의견이나 입장에서 납득이 되는 정성적인 방법으로 설득하는 게 좋습니다. 개발 상황이 정확히 어떤지, 왜 안 되는지 확인해야 합니다. 개발 구조가 간단한지 아닌지 확인을 해야 업무의 범위를 알 수 있고, 그에 따라 빨리 처리할 수 있는 일인지를 파악할 수 있으니까요. 상황을 파악한 후에는 최선의 방법을 제안해야겠죠. 중요도와 우선순위를 파악해서 해당 리소스로 어떻게 업무를 진행해야 사용자와 서비스에 가장 좋을지 판단하는 게 우리 기획자의 역할이니까요. 사용자 입장에서 서비스 이용에 치명적인 단점으로 느껴진다면 빠르게 개선해서 더 큰 문제가 되기 전에 개발자를 설득해야 했습니다. 저는 이때 왜 해야 하고, 목표는 무엇이고, 결과가 어떻게 될 것인지 명확하게 제시하면서 개발자가 정말 중요한 업무를 하고 있다는 사실을 상기시켰습니다. 사실 기획자 입장에서는 명확하게 말하지 않아도 개발자가 중요성을 알고 있다고 넘겨짚으며 작업의 내용만을 전달하기 쉽습니다. 서로 일정을 조율할 여지가 있는 경우, 기획자가 먼저 사업적으로 시기에 맞는 일정, 개발자의 리소스 등을 고려하여 굵직한 일정을 계획합니다. 개발자 입장에서 일정을 가늠하기 어려운 작업도 존재하고, 중간에 이슈가 생기는 경우도 많아 세부 일정을 처음부터 조율하기 어려울 수 있기 때문입니다. 그보다 일주일 혹은 매일 스크럼을 진행하며 서로의 진행 상황을 알 수 있도록 미리 체크하는 편이 더 효율적입니다. 협업을 진행할 때, 협업자의 성향에 따라 커뮤니케이션 방법이 달라져야 한다고 생각합니다. 그래서 저는 협업자가 어떤 성향인지 파악하기 위해서 먼저 함께 일했었던 기획자분에게 협업자에 관해 물어보기도 하는데요. 그럴 수 없는 경우에는 협업 전에 간단한 스몰톡을 나누며 서로의 긴장을 풀고, 업무를 시작합니다. 이마저 어렵다면 처음에는 일단 부딪히는 수밖에 없는데요. 협업자는 업무를 하면서 도움을 주고받는 관계입니다. 서로에 대한 존중과 배려가 우선된다면 서로 맞춰나가며 커뮤니케이션을 쉽게 풀 수 있습니다.