당신이 개발자와 소통하기 어려운 진짜 이유(下)
화성에서 온 프로덕트 디자이너, 금성에서 온 개발자
이 글은 "당신이 개발자와 소통하기 어려운 진짜 이유(上)"의 하(下) 편이다.
전편에 이어서 개발자와 프로덕트 디자이너의 일하기 방식이 어떻게 다른지 살펴보고, 그 간극을 채울 수 있는 방법을 함께 알아보고자 한다.
일이 제대로 이루어졌는지
판단하는 데 드는 시간이 다르다.
프로덕트 디자이너와 개발자가 서로를 이해하지 못하는 데는, 결과물의 질을 판단하는 데 걸리는 시간에 차이가 있기 때문이기도 하다. 이런 사소한 차이가 상대방에게 우유부단하고 확답을 주지 않는다는 인상을 줄 수 있다.
프로덕트 디자이너가 기획을 할 때
만약 여러분이 이번 스프린트에서 A라는 피쳐를 기획했다고 해 보자. 함께 일하는 동료들에게 디자인 자문을 구하고, 우리 팀이 하는 일과 거의 관련이 없는 옆 챕터의 팀원들에게 기획에 대한 피드백을 듣고 반영했다. CEO와도 논의를 잘 끝냈다. 마침내 우리 사무실에 있는 모든 사람들이 A 기획에 대해 좋은 반응을 보이게 되었다. 이제 이 기획은 완성되었을까?
당연히, 다들 예측했겠지만, 전혀 그렇지 않다.
A 피쳐가 "완성되었다"는 것은, 시장에서 의미 있는 반응이 있기 전까지는 섣불리 판단하기 어렵다. 시장의 반응을 판단하기까지는 짧게는 며칠, 몇 주, 길게는 몇 달이 걸릴 수 있다. 모수가 많을수록 검증하는 데 드는 시간은 적게 걸릴 테지만, 어쨌거나 좋은 피쳐인지 아닌지를 정의하기 위해서는 회사 내부의 판단보다는 외부의 판단이 중요한 척도가 된다. 프로덕트 디자이너가 "이 기능을 넣기만 하면 성공할 겁니다", 라거나 "사람들이 원하는 기능은 이것이에요!"라고 자신 있게 말하기 어려운 근본적인 이유가 바로 이것이다.
그런데 이렇게 이야기하면 확실한 답을 원하는 개발자의 입장에서는, 뭔가 우유부단하고 정해지지 않은 느낌을 받을 때가 있다. 본인이 이 개발을 왜 해야 하는지 설득되지 않는 것이다. 프로덕트 디자이너 입장에서도 확실하지 않은 것을 설득해야 하므로 어쩐지 말투가 주눅 들게 된다. 이런 행동이 개발자에게 신뢰를 덜 주는 요인으로 작용한다.
"그래서 이게 중요한 거예요, 아니에요?... 제가 이걸 왜 해야 해요?"
"으음... 확실하진 않아요. 하지만..."
다행히, 많은 좋은 개발자들은 기획이 본인들이 바라는 만큼 완벽하지 않는다는 것을 이해하고 있다. 개인적인 경험으로는 시니어 개발자일수록 이를 잘 이해하는 편이었다. 반면 가능한 만큼의 설명은 꼭 제공되어야 한다.
시장의 평가를 받기 전까지는, 기획은 완성된 것이 아니다.개발자가 개발을 할 때
반면 개발자가 어떤 것이 "개발이 되었다"라고 판단하는 데에는, 이것이 되느냐, 안 되느냐, 얼마나 걸리느냐가 1차적인 고려사항이다. 코드를 작성해서 원하는 대로 기능이 작동을 하면 개발이 된 것이고, 그렇지 않으면 개발이 덜 된 것이다. 어떤 기능이 제대로 만들어졌는지 판단하기 위해서, 개발자들은 즉시 실제 개발을 시도하면서 확인해볼 수 있다. 짧게는 수 시간, 길게는 며칠이 걸릴 수 있지만 판단의 주체는 개발을 진행한 개발자와 그의 동료들이므로 이를 판단하는 데 기획자들보다는 시간이 적게 걸린다.
개발자에게 있어서도 물론 질적으로 좋은 코드를 만드는 것은 중요하다. 하지만 좋은 코드를 만드는 것의 전제는 일단 "작동하는 코드를 만드는 것"이다. 이것은 작동하는가, 작동하지 않는가, 라거나 이것은 기한 안에 만들 수 있는가, 와 같은 질문은 개발자에게 당연하다. 이 질문이 선행하고서야 "이 코드는 깔끔한가?"와 같은 질적인 질문을 할 수 있다.
좋은 디자이너라면 이 기능을 왜 추가해야 하는지에 대해 개발자가 이해할 수 있도록 최대한 예상 가능하게 설명할 수 있어야 한다. 이를 위해서 개발자에게 사용자 데이터와 가설을 가져가는 것이 좋은 방법이다. 좋은 개발자라면 시장에서 이 기능이 먹힐지 아직까지는 추측과 가설에 불과하다는 것을 감안하고, 디자이너의 설명의 논리적으로 모호한 지점을 공유하며 함께 가설을 검증하기 위해 달려 나갈 수 있을 것이다.
결과물의 질을 판단하는 데 걸리는 시간이 다르다.컨텍스트를 전달하지 않고
하향식으로 기능을 요청할 때 반감이 든다.
오늘날의 개발자는 지시대로 묵묵히 개발만 하는 사람들이 아니다. 좋은 개발자라면 우리가 이 기능을 왜 개발해야 하는지, 제안된 기능보다 기술적으로 더 좋은 기능을 어떻게 만들 수 있는지 본인의 기술적인 전문성을 가지고 기획자들을 설득하고 적극적으로 의견을 공유한다.
개발자를 쥐어짜는 기획자
내가 만났던 많은 개발자들은 핸드오프 시에 전달받은 기획 내용을 납득할 수 없는 상황에서 동기부여가 크게 떨어진다고 말했다. 특히 기획자로부터 요구사항이 일방적으로 전달되는 일이 잦을수록 개발자를 존중하지 않는다고 느꼈으며, 사내 문화에 대해 부정적으로 생각하게 되었다고 한다.
무작정 "해줘"형 핸드오프 / 이건 애자일도 워터폴도 아니다.만약 여러분의 스타트업이 애자일을 지향하는 집단이라면, 이런 일방적인 의사소통은 애자일이 아니라는 점을 분명히 알아 둬야 한다. 본인의 팀을 애자일 조직으로 소개하면서도, 하향식 의사소통을 선호하는 프로덕트 디자이너 또는 PM과 PO가 있다. 이런 사람들은 스프린트에 관계없이 마음대로 요청사항을 바꾸고 싶기 때문에 애자일이라는 단어를 오용하고 악용하는 것이 아닌지 스스로 생각해 보면 좋겠다. 내가 관찰한 바로 이런 악의적인 기획자들은 다음과 같은 문장으로 개발자들을 찍어 누르곤 했다.
"갑작스럽지만 어쩔 수가 없어요, 최근에 결정이 나서요. 어마어마하게 중요한 기능이에요."
"급한 일이 생겨서 무조건 이번 주 안에 빨리 처리해야 해요."
처음에는 호의로 밤을 새워서라도 몇 번 이런 일을 처리해줄 수 있을지도 모른다. 하지만 계속해서 해 주다 보면, 기획자들은 요청사항 변경을 아무렇지도 않게 생각한다. 특히 이런 하향식 의사전달의 특징은 컨텍스트를 공유하지 않는다는 것이다. 그들이 개발자에게 컨텍스트를 공유하지 않는 이유는 다음과 같다.
(1) 개발자에게 컨텍스트를 전달했을 때의 이점을 이해하지 못한다.
(2) 개발자와 컨텍스트를 공유하면 말이 길어지고 골치 아파진다고 생각한다.
맥락을 공유하지 않는 기획자
또, 질문의 앞뒤 맥락은 전달하지 않고 원하는 질문만 툭툭 던지는 기획자도 있다. 예를 들면 이렇게 본인이 궁금한 것만 맥락 없이 단순하게 질문하는 경우다.
"OO 님, 혹시 … 이거 개발돼요?"
기존에 이야기가 되었던 내용에 대해 추가 질문을 하는 경우라면 전혀 문제가 되지 않는다. 하지만 처음 듣는 새로운 기능에 대해 이런 질문을 듣게 되면, 개발자는 앞으로 어떤 임의적인 업데이트 요청이 일어날 것만 같은 불안감이 엄습한다.
쏟아지는 무논리 요청사항 앞에 무력감을 느끼는 개발자.바쁜 개발자를 방해하고 싶지 않아서 요점만 짧게 질문했다고 변명하지 않았으면 좋겠다. 사전에 어떤 논의가 진행되었는지 알지 못하는 개발자 입장에선 심각한 정보 비대칭을 느낄 수밖에 없다. 맥락을 모르는 상태에서 되고 안 되고의 결정을 내리기도 어렵다. 개발자는 같이 일하는 동료지, 되는지 안 되는지 허락해주는 기계가 아니다. “어떻게”를 고민하는 개발자 입장에서는 곤란한 질문이 아닐 수 없고, 심지어는 화도 날 수 있다.
팀 구조적으로, 사용성 개선에 대한 안건은 대부분 기획자들이 먼저 먼저 제안하는 경우가 많다. 중요한 내용은 프로덕트 디자이너들끼리 논의하고, 궁금한 것만 개발자에게 물어보는 일방적인 태도는 정보 비대칭과 오해를 유발하기 너무나도 쉽다.
개발자와 함께 기획하는 기획자
어떤 데이터를 보고 안건이 나왔는지, 기능 업데이트에 대한 얘기가 왜 나왔는지, 어떻게 이런 결정을 내리게 되었는지, 마감일은 왜 이렇게 정해졌는지에 대한 컨텍스트가 공유된다면 개발자가 기능 구현을 고민하는 데 드는 시간을 줄일 수 있다. 또 개발자 입장에서 갑작스럽게 들이닥치는 "이거 돼요, 안 돼요?" 질문이 아닌 "현재 이러이러한 이슈가 있는데요~"로 시작하는 질문을 한다면 개발-디자인 간의 간극을 좁힐 수 있을 것이다. 다음 문장을 한 번 읊어보면 좋겠다.
"지금까지 분석한 사용자 데이터를 보니~"
"그래서 이런 이슈 때문에 A 기능에 대한 중요도가 높아질 수 있을 것 같아요~"
"그래서 이렇게 결론이 나게 된 이유는요~"
"마감일은 왜 이렇게 정해졌냐면요~"
만약 이 문장들에 대해 개발자에서 설명할 수 없다면, 자신이 옳은 커뮤니케이션 또는 옳은 기획을 하고 있는 게 맞는지 스스로 한 번쯤 돌아보는 것이 도움이 될 수 있을 것이다.
마치며.
서로의 단점을 보완하는 것이 아름다운 개발자와 기획자의 관계가 아닐까?개발자를 대하는 올바른 태도
경험적으로 개발자들이 궁금해하는 것은 항상 다음 두 가지였고, 이를 바탕으로 커뮤니케이션했을 때 개발자들 스스로 존중받는 느낌을 받을 수 있었다는 피드백을 받곤 했다. 여러분이 좋은 기획자가 되고 싶다면, 다음 두 명제를 마음속에 콕 박아 두고 필요할 때 유용하게 사용할 수 있으면 좋겠다.
[1] 이 기능을 만들자는 이야기가 왜 나왔는가?(컨텍스트 공유)
[2] 이 기능을 만들면 서비스가 어떻게 좋아지는가?(데이터와 가설)
개발자는 기획자와 다른 교육을 받은 전문가들이다. 분명 개발자들은 우리가 생각하는 것과 다른 가치를 중요하게 여길 때가 많다. 하지만 그 가치는 디자이너가 중요하게 생각하는 것들 만큼 중요하다. 그래서 우리가 서로 상호 보완적인 관계이지 않을까? 서로 못 보는 지점을 봐주는 것, 그것이 팀워크니까.
