기획자와 개발자, 어서 친해지길 바라

지난 포스팅에서 개발자와 대화하고 싶은 비 개발자를 위한 참고서에 대한 글을 작성했습니다. 이번 포스팅에서는 개발자와 기획자 간 원활한 커뮤니케이션을 위해 저희 팀 내에서 초기 사용했던 방법이 현재는 어떻게 바뀌었는지 사례를 통해 보여드리겠습니다.

주의! 이 방법은 주로 슬로워크 1팀 기획자인 저와 개발자들이 사용하는 방식으로, 회사별로 팀별로 방법이 다를 수 있습니다. 가장 좋은 방법은 팀 내에서 서로 많은 대화를 해보는 것입니다.

1. 기획자와 개발자의 시간은 다르게 간다.

“이거 금방 되죠?” vs “이거 오래 걸려요”

초기에 기획자로서 흔히 했던 실수는, 개발자에게 정확한 기간이나 요건을 설명하지 않고 금방 될 것이라 추측한 것입니다. ‘금방’, ‘오래'와 같은 단어는 주관적입니다. 내가 생각하는 금방은 하루지만 상대방이 생각하는 금방은 3일일 수 있습니다. “이거 금방 되죠?"와 같은 질문을 받은 개발자는 당연히 금방 되지 않으니 오래 걸린다고 답할 수밖에 없습니다. 그러다 보니 서로 갈등과 오해가 생기게 됩니다. 기획자는 ‘분명 이전 프로젝트에서는 금방 해주었던 것 같은데, 왜 오래 걸린다는 거지’ 혼자 생각하고, 개발자는 ‘지금 요건에서 그 기능은 금방 추가할 수가 없는데 왜 금방 된다는 거지’ 하며 답답해 합니다.

시간에 대해 설명할 때는 구체적인 언급이 필요합니다. 모호하고 주관적 단어 대신 구체적인 단어를 선택해야 합니다.

“이런 기능 요건이 추가되었는데, 3일 안에 가능할까요?”

“이 기능은 지난 프로젝트에서 사용했지만, 이번 프로젝트 개발 구조와 달라 수정이 필요할 것 같아서 3일은 어렵고 5일이 소요될 것 같아요.”

위와 같이 서로 구체적인 기간을 언급하고, 그 이유를 설명해야 불필요한 오해의 소지를 줄일 수 있습니다. 또한, 고객에게 일정을 설명할 때도 정확한 기간을 언급해주는 것이 신뢰의 기본입니다.

2. 개발자와 기획자의 서로 다른 언어

이해관계자와 수많은 커뮤니케이션 vs 프로그래밍 언어로 컴퓨터와 커뮤니케이션

기획자는 여러 이해관계자와 다양한 수준의 커뮤니케이션을 합니다. 이를 통해 일을 정리하고 상대방을 설득하며, 개발자에게도 설명합니다. 즉 기획자가 하는 모든 일은 다른 사람들에게 상대방의 생각을 올바르게 커뮤니케이션해주는 과정에 있습니다. 개발자는 해당 내용을 결과물로 보여주기 위해 일반인이 이해하기 힘든 프로그래밍 코드를 작성하고, 컴퓨터와 대화를 주고 받습니다. 기획안을 오랫동안 설명하였는데 나의 기획과 다른 개발 결과물이 나오는 일도 있고, 반대로 기획자가 가져온 그대로 개발하였는데 번복하는 상황이 생기기도 합니다.

서로가 대화하는 대상이 다름을 인지하는 것이 가장 중요합니다.

기획자는 자신뿐만 아니라 상대방의 생각도, 고객의 요구도 반영해야 합니다. 개발자는 그러한 결과물을 구현해주기 위해 컴퓨터와 끊임없이 대화하고 수정합니다. 그렇기 때문에 서로의 커뮤니케이션 대상자가 다름을 이해할 때 서로 불필요한 오해를 줄일 수 있습니다. 특히 개발언어는 정량적 측정이 어렵기 때문에 정확한 기간을 말하기 힘들 때가 있습니다.

커뮤니케이션 대상자는 다르지만 하나의 결과물을 위해 함께 협업해야 한다는 점을 기억하세요.

3. 개발자와 기획자의 논리적인 대화를 위한 3단계

“이 기능 간단하죠? 전에 한 거랑 같은데.” vs “이거 달라요, 여기엔 안 돼요.”

기획과 개발은 서로 함께 하나의 목표를 위해 달려가는 협업과정입니다. 그 과정에서 서로가 생각하는 바가 다르기도 하고 머릿속에 있는 것을 말로만 설명해서는 이해하기가 어렵습니다. 막바지에 이르러 서로 다른 결과물을 가지고 볼 수도 있습니다. 따라서 대화 전에 아래와 같은 사전 기획서 혹은 간단한 문서를 통해 대화하면 조금 더 논리적이고 오해가 적은  커뮤니케이션을 할 수 있습니다.

1) 자신의 생각을 정리한다

2) 생각을 구체적으로 손으로 그리거나 툴을 이용해 누구나 이해할 수 있게 그린다

3) 1:1로 직접 보고 대화한다

<실제 1팀에서 기획자와 개발자 간에 대화를 위해 작성한 페이퍼프로토타입, ppt 문서>

슬로워크 1팀에서 기획자는 주로 moqups.com과 ppt를 사용합니다. 와이어프레임을 그려 디자이너와 개발자에게 전달하고 내부 세미나를 합니다. 또 역으로 개발자가 기획자에게 관리자 화면이나 기획안 수정 및 요청을 할 때가 있습니다. 주로 직접 그려서 주거나 엑셀 표에 작성해서 전달합니다. 또 가까운 공간에 서로 함께 일하기 때문에 끊임없이 이야기하면서 커뮤니케이션 능력을 서로 업그레이드시키고 있습니다. 특히 제가 개인적으로 선호하는 방식은, 개발자에게 먼저 묻고 일정과 협의를 진행하는 것입니다. 그렇게 되면 일정이나 서로 개발범위에 따른 오해의 소지가 반 이상 줄어들고, 서로 존중하는 프로젝트가 진행됩니다. 개인적으로 짐작하거나 말을 걸기 두려워 지레짐작하다 보면 프로젝트는 산으로 가기 십상입니다. 최근 1팀의 대화는 이렇습니다.

“ A와 B를 통해서 C가 나오도록 해주세요, 10일간의 일정에 가능할까요? “

“네, A와 B를 OO코드로 C가 나오도록 구현할게요. 일정은 10일이면 가능할 것 같아요. ”

4. 마무리

‘우리는 모두 한 배를 타고 있다.’ 서로의 언어에 관심을 가지는 것이 시작입니다.

사실 커뮤니케이션 방법에 정답은 없습니다. 우리 팀에서 잘 맞고, 우리 팀원들과 적합한 커뮤니케이션 방식을 찾아가는 것 또한 업무의 일환이라고 생각합니다. 다만 서로에 대한 배려와 이해하고자 하는 마음 그리고 조금 더 구체적으로 서로의 업무를 설명하는 것이 신뢰를 위한 첫 걸음입니다.