제품이 자꾸 내 생각과 다르게 만들어지는 이유

안녕하세요! 김명관 입니다.

 

예전에 프로젝트를 진행하다보면 '이 기능이 왜 이렇게 만들어졌지? 내가 생각한 건 이게 아닌데..' 하는 상황이 자주 있었습니다. 또 '이 부분은 기획대로 만들어지지 않았는데?' 라고 느끼는 부분들도 있었어요. 지금은 이런 경우들이 굉장히 줄어들었습니다. 예전에는 왜 제품이 내 생각과 다르게 만들어지는 일이 많았을까요? 그리고 지금은 왜 그렇지 않을까요?

 

제품이 내 생각대로 만들어지지 않았던 경험들과 그것을 어떻게 방지할 수 있었는지 제 경험을 공유해 보겠습니다.

---

오해와 추측

모두 동일한 기획 내용을 기준으로 제품을 만들어 가는데 그 결과물이 내 생각과 달랐던 가장 큰 원인은 제 경험에 비추어 볼 땐 오해와 추측이었습니다. 동일한 기획을 읽고 누군가는 A를, 누군가는 B를, 누군가는 C를 생각하고 있었던거죠. 심지어 '왜 내 생각과는 다르게 만들어진거지?' 라고 생각했던 '제 생각' 마저도 기획자의 의도와는 달랐지만 저는 그것이 맞다고 오해했던 거였죠. 기획의 가장 명확한 의도는 그것을 작성한 기획자만 알고 있습니다.

 

기획자라고 해서 완벽한 기획을 작성할 수 있는 것은 아닙니다. QA라면 알고있을 테스팅 원칙인 "완벽한 테스트는 존재하지 않는다." 와 마찬가지로 "완벽한 기획은 존재하지 않는다." 라고 생각합니다. 아무리 정성들여 쓴 기획이라도 모든 유저플로우와 제약사항, 모순들을 커버할 수는 없을거에요. 그리고 이 상황에서 기획을 오해해서 생긴 기획의 모순이나 공백은 각자 멋대로 추측하게 됩니다. 

 

 

예를들어 프로필 사진을 크롭하는 기능을 만든다면 대표적으로 두가지 방식을 생각하게 될겁니다.

1. 왼쪽처럼 사진이 고정되고 크롭 영역이 움직이는 방식

2. 오른쪽처럼 사진이 움직이고 크롭 영역이 고정되는 방식

이런 상세한 방식에 대해 논의하지 않고 "이 방식일 것이다." 라고 오해하고 사진 크롭의 방식을 추측하게 되는거죠. 그렇게 각자 기획을 다른 방식으로 이해한 채로 작업이 시작됩니다. 작업이 완료되고 나서야 '아 이게 아니었네..' 하고 진상을 파악하기 위해 대화를 시작합니다. 그 결과 어느 한쪽은 작업을 다시해야 합니다.

---

받아들이는 자세

'나에게 당연한 방식이 남들에게는 당연한것이 아닐 수도 있다' 는 것을 받아들여야 합니다. '이런 방식을 말씀하신거겠지.' '이렇게 개발 되겠지.' 와 같이 추측하며 당연히 ~하게 될거야 라는 생각을 하지 않아야 합니다. 논의되지 않은 여러가지 문제에 대해서는 질문과 대화를 통해 명확한 결론을 얻어내고 작업을 해야 합니다. 그래서 팀원들은 서로 언제나 대화를 시작하고 논제를 끌어낼 준비가 되어있을 만큼 친해야 합니다. 

 

[명확한 결론]을 얻어내는 과정에서 다른 사람들도 오해를 하고 있었다거나 기획 시 고려되지 않았던 케이스들이 꽤나 많다는 것을 알게 되실겁니다. 이렇게 논의가 필요한 많은 세부 사항들을 모두 각자의 견해대로 '추측'해서 만들고 있었기 때문에 결과물이 모두에게 만족스럽지 못했던거죠. 팀원들끼리 많이 질문하고, 많이 대화해야 합니다.

개인적인 TMI이지만 저는 질문을 할 때 제가 QA라는 것이 꽤 신경이 쓰입니다. 저는 숨은 의도 없이 그냥 궁금한 것에 대해 질문을 한건데, 듣는 사람들은 '이걸 수정하라는 얘긴가?' 라고 받아들일 수도 있다는 괜한 걱정이요. 
(사실 괜한 걱정이 아닐 수도 있는게 몇몇 분들은 제가 질문을 하면 변명을 하시기도 합니다..😥) 
몇 차례 이런 고민에 대해 1on1 미팅에서 얘기해 보았고 이젠 질문을 할때 명확하게 그냥 질문인지, 개선 의견인지 표시해 드리고 있어요. QA의 질문이 구성원들에게 괜한 오해나 불안함을 드린다면 그 답변도 제가 원하는 방향이 아니었던 적이 많았으니까요. 질문의 의도가 명확하지 않으면 서로 시간과 감정을 낭비할 수 있습니다.

---

이정표 만들기

하지만 많은 대화를 했다고 해서 완벽히 기획 의도와 맞는, 내 생각과 일치하는 제품이 만들어 지는 것은 아닙니다. 대화를 통해서도 여전히 해소되지 않은 일부분의 일부분은 계속해서 다릅니다. 여전히 내 생각도 다른사람들과 다릅니다. 이것 또한 받아들이고 내 생각대로 만들어지지 않은 이유보다 어떻게 그 생각을 일치시킬지 생각해 보아야 합니다. 많은 대화를 하면 할수록 그 안에서 잊어버리는 것 또한 많아집니다. 1~10까지의 대화를 나누었고 누군가는 1~5까지만 기억할수도 있고, 누군가는 6~10까지만 기억할 수도 있습니다. 아니면 1, 3, 5, 7, 9나 2, 4, 6, 8, 10만을 기억할 수도 있습니다. 대화를 하는 것 만으로는 서로의 오해와 추측이 완전히 해소되지 않습니다. 따라서 서로의 생각을 보여줄 공간이 필요합니다.

 

모두가 참여할 수 있는 문서를 만들고 거기서 우리가 나눈 대화에 대해 내가 생각하는 결론을 적어두고 팀원들에게 이야기 합니다. '앞으로 이것이 우리의 이정표니까 이대로 만들어 주시면 됩니다. 그런데 혹시나 이 이정표가 틀렸다면 확인하고 수정해주세요!' 제가 생각했던 방향도 어처구니 없을정도로 기획을 오해하고 있었다는 경험 덕분에 제가 생각한 대로 만들어지지 않았을때 '엥 왜 내생각대로 안만들어졌지?' 같은 건방진 생각은 하지 않게 되었습니다. 그래서 서로의 생각을 체크할 때 그 체크 대상은 '나' 역시 포함되어야 합니다. 제 생각도 팀원들에게 확인받는 것이죠.

---

One team, One sound

사람들은 원래 생각도 다르고 취향도 다르고 대부분의 것들이 다릅니다. 평소에는 그런것들을 배려하며 살고있죠. 이사람이 주말에 산에 가는지, 바다에 가는지, 집에서 쉬는지 알 필요도 없고 여기로 가라, 저기로 가라 할 수도 없습니다. 이런 배려에 익숙해서인지 개입이 필요할때도 필요 이상으로 남을 배려하고 있는게 아닌가 생각도 됩니다.

 

팀 프로젝트는 하나의 목표를 두고 서로 다른 방식으로 어떻게든 도달하면 되는 것이 아닌 것 같습니다. 하나의 목표에 도달하기 위해 한 배에 타서 서로를 살펴주고 다같이 노를 저어가야 조금이라도 빠르고 완벽하게 도착할 수 있겠죠. 그래서 다같이 한 배에 탑승하고 있는지가 중요합니다.

 

팀원들이 모두 하나의 목표를 보고 있는 것이 맞는지, 목표를 위한 내 생각과 우리의 생각이 같은지, 서로 같은 내용을 파악했고 이해했는지 확실히 체크해 가면서 나아가야 합니다. 그러기 위해서 때로는 질리도록 얘기하는 것도 필요합니다. 그리고 그 대화를 통해 나온 결과를 기록하고 확인 받으세요.

 

서로의 생각을 계속 확인하고 이해를 모으면 '이게 왜 이렇게 된거지?' 같은 상황을 덜 마주칠 수 있을거에요.

---

 마무리

이 글을 쓰고보니 시작할 때의 의도와 마무리 하고서의 의도가 많이 달라진 것 같습니다. 제 개인적인 경험을 쓰려고 했는데 다 쓰고 읽어보니 건방지게 '이것이 정답이다!' 라는 식으로 써버렸네요.. 당연히 이것이 정답은 아닙니다. 서로의 생각이 달라서 많이 혼란스럽고 고생했던 시절이 있었고 '원래 그런것이다' 라고 받아들이면서 개선할 수 있는 방법도 찾게 되더라구요. 제 경험을 바탕으로 혹시나 똑같은 고민을 하고 계신 분이 있다면 이 글이 도움이 되었으면 하는 바람으로 작성해 보았습니다.

 

감사합니다!