개발자도 같은 목표를 향해 함께 달리는 구성원입니다
개발자와의 커뮤니케이션이 힘들지 않냐고 물어보는 사람들에게
테크 기반의 스타트업에서 일하다 보니 개발자와 직접적으로 소통할 일이 많다. 마케터일 때도 개발자와 커뮤니케이션할 일이 많았지만, 서비스 기획자, PM 일을 하는 최근에는 개발자들과 소통할 일이 더 많아졌다.
어디 가서 개발자들과 소통하는 일을 많이 한다고 하면, 다들 '개발자들이랑 소통하는 것 힘들지 않아요?', '개발자랑 어떻게 소통해요?' 등등의 질문을 종종 받는다.
아마 비개발 직군의 입장에서 개발자들의 입에서 나오는 개발 용어들이 낯설고, 이들이 하는 말을 완벽히 이해하기 아니, 어림잡아라도 이해하기 어렵기 때문일 것이다. 또 개발자들에게 특정 기능을 구현해달라고 요청했는데, 번번이 거절을 당한 경험이 있어서 일수도 있다. 또 개발자들은 개발 측면에서만 생각한다는 선입견을 갖고 있을 수도 있고.
모른다면 솔직하게 물어보기
결론부터 말하자면, 개발자와의 커뮤니케이션도 다른 비개발 직군과의 커뮤니케이션과 동일하다. 개발자와의 커뮤니케이션에서 특별한 스킬이나 비법을 필요로 하지 않는다는 것이다. 물론 개발 관련 지식이나 용어를 많이 알수록 개발자와 더 쉽게 소통하고, 더 깊은 대화를 나눌 수 있다.
이건 다른 직군과의 소통에서도 마찬가지다. 디자이너와 대화할 때 디자인 용어, 개념을 알 수록 더 풍부하게 대화를 할 수 있고, 마케터와 대화할 때도 마케팅 관련 개념과 지식을 많이 알고 있을수록 더 밀도 높은 대화를 할 수 있다. 문외한이 보기에 개발 지식이 조금 더 진입 장벽이 높아 보일 뿐, 개발 지식이든, 디자인 지식이든, 마케팅 지식이든 해당 지식을 알면 알수록 관련 직군과 소통이 더 쉬워진다.
따라서 개발 지식이 없다고, 개발자와의 대화가 어려울 것이라고 지레짐작할 필요가 없다. 대화를 하다가 특정 개념을 모르겠으면, 제대로 이해를 하지 못했다고 자세하게 설명해달라고 말하면 된다. 물론 시간이 지나도 계속해서 개발 지식이 제자리걸음인 건 문제다. 따라서 개인적으로 개발 지식, 개념, 용어 공부를 하면서 개발 지식을 높여 나가면 더욱 수월하게 개발자와 소통할 수 있다. 코딩을 배울 필요까지는 없다. 비개발자를 위한 IT 지식, 개발 지식 등을 책, 온라인 강의 등으로 공부하는 정도만으로도 충분하다.
대화하다 잘 모르는 부분이 나오면 솔직하게 물어보면 된다배경과 목적을 공유하기
그리고 개발자에게 특정 기능 구현을 요청했다가 거절을 당한 경험이 있는 사람들도 꽤 있을 것 같다. 예를 들면 '이 기능 진짜 잘 될 것 같은데', '이 기능 고객들이 많이 쓸 것 같은데'라고 생각하며, 구현을 요청했지만 여러 이유로 개발자들에게 구현이 안된다는 이야기를 듣고 기획을 접는 상황이다.
이렇게 전달한 기획이 개발자들에게 거절당했다면, 본인이 기획을 어떻게 전달했는지를 먼저 돌아봐야 한다. 구현하고 싶은 기능만 띡 보내지는 않았는지, 꼼꼼한 Use Case에 대한 고려 없이 스케치 정도의 기획만 보내지는 않았는지 다시 생각해 봐야 한다.
개발자들도 똑같이 조직의 목표를 위해 달리는 구성원이다. 따라서 개발자들에게 기능 구현이나 개선을 요청할 때 '왜 이 기능을 개발해야 하는지', '이 기능을 개발하면 고객들에게 어떤 영향을 미치는지', '이 기능을 개발함으로써 우리 조직과 비즈니스에는 어떤 긍정적인 효과가 예상되는지'를 이해하기 쉽게 설명해야 한다.
물론 비즈니스와 고객에 관심이 없는 개발자도 있을 수 있고, 이런 개발자와의 대화는 좀 더 힘들 수도 있다. 그렇다면 이에 대해서 불평할 게 아니라, 왜 비즈니스에 관심이 없는지, 또 자신이 하는 업무가 어떻게 고객들에게 실제로 영향을 미치는지를 잘 설명해서, 소통을 더 쉽게 만들어야 한다.
다른 직군과의 커뮤니케이션을 비교해보면 쉽게 이해할 수 있다. 디자이너에게 무작정 이미지 만들어달라고 하고, 마케터에게 무작정 그냥 이벤트 프로모션 하자고 하면, 이 역시도 거절당할 것이 뻔하다. 개발자라고 특별히 코드만 고려해서 더 까다롭게 굴고 그런 게 아니다.
상세하게 배경과 목적을 공유해야 한다Use Case는 최대한 꼼꼼하게
또 개발을 요청할 때는 스케치나 초안을 보내서 요청하는 게 아니라, Use Case를 꼼꼼히 고려해서 요청해야 한다. 물론 모든 Use Case를 고려할 수는 없어도, 이를 얼마만큼 꼼꼼하게 고려했느냐에 따라서 개발자와의 커뮤니케이션 난이도가 크게 달라진다. Use Case가 모호하고 뭉뚱그려져 있을수록 구현이 어렵다. 따라서 개발자들의 개인 기량에 의존해 구현을 할 수밖에 없다.
예를 들어, 맛집 앱 내에서 지도에 음식점을 마커로 표시하는 기능을 구현하기로 했다고 해보자. 한식은 빨간색, 일식은 초록색, 양식은 파란색으로 표시하기로 하고 이를 개발자에게 구현해달라고 요청하는 건, 거의 카페에서 친구에게 '내 거 초콜릿 음료 빼고 아무거나 시켜줘' 정도의 요청이다.
이 경우에 태국, 베트남 음식점 같은 아시아 음식점은 무슨 색 마커로 표시해야 할까? 카페는 마커를 표시해야 할까 말까? 한식과 양식을 같이 파는 음식점의 경우에는 무슨 색 마커로 표시해야 할까? 등등 고려되지 않은 Use Case가 너무 많다.
따라서 이런 정도의 기획으로 개발자에게 기능 구현을 요청한다면 개발이 안된다는 답변을 듣거나, 개발자의 재량에 의존해 개발을 했기 때문에 원하는 기획이 나오지 않을 것이다. 이렇게 되면 자신이 원하는 대로 기능이 구현이 되지 않았기 때문에, 개발자와의 소통이 어렵다고 생각할 것이고. 문제는 소통에 있는 것이 아니라 기획에 있는데.
이 역시도 다른 직군에 빗대어 생각해보면 이해하기 쉽다. 디자이너에게 토스의 화면을 주고 이렇게 화면을 만들어 달라고 하거나, 마케터에게 광고 링크 하나 보내주면서 이렇게 만들어 달라고 하면 아마 똑같은 반응이 나올 것이다.
Use Case 꼼꼼하게 체크하지 않으면 듣는 입장에서는 이런 표정 짓기 쉽다평소에 스몰톡 많이 하기
그리고 평소에 개발자들과 친밀하게 지내는 것도 소통을 더 쉽게 만들어주는 방법이다. 업무적인 요청, 업무 대화만 해도 일이 굴러갈 수 있다. 아무리 조직에서는 업무적 능력을 통한 관계 형성이 더 중요하다고 해도, 결국 일도 사람이 하는 것이기에 오며 가며 스몰톡 등을 통해 친밀감, 개인적 신뢰를 쌓는다면 더 쉽게 소통할 수 있다.
이왕이면 다홍치마라고 평소에 친밀감을 쌓아둔다면, 요청도 더 쉽게 할 수 있고 거절도 더 편하게 받아들일 수 있다. 이 역시도 다른 직군과 동일하게 해당하는 이야기다.
결국 개발자와의 소통에서 가장 중요한 것은 업무의 근거와 예상 결과, 상세한 기획, 인간적 친밀감이다. 다른 직군들과의 소통에서 필요한 것과 별반 다르지 않다. 하는 일이 다를 뿐, 결국 같은 목표를 향해 달려 나가는 구성원이다.
평소에 스몰톡 많이 하면서 친해지면 분명히 업무에도 도움이 된다