즐겁게 문제를 해결하는 나만의 커뮤니케이션 방식

 

많은 이해관계자들과 모여 발견된 문제에 대해 토론을 하다보면 갑자기 새로운 문제가 뜨거운 감자가 되는 경우가 있다. 우리가 모인 이유는 발견된 문제를 해결하기 위함인데 어차피 하는 김에 아직 발견되지 않은 문제들까지 찾아내고 덧붙이며 더 좋은 경험이라고 포장되기도 한다. 얼마든지 이야기를 꺼내고 대화할 수 있다는 건 건전한 조직문화를 가졌다는 반증이기도 하기 때문에 좋은 현상이라고 생각한다. 문제는 이 다음부터이다. 우리가 가진 한정적인 자원(썩 내키지 않지만 자원에 인재도 포함해본다)을 고려했을 때 우리가 아이디어를 내고 아직 아무도 경험하지 못하거나 리포팅 되지 않은 문제들을 개선하냐 마냐는 완전히 다른 차원의 이야기가 된다. 그래서 한다, 안한다에 대한 결정은 온전히 실행(execution) 단계에서 진두지휘 할 수 있는 사람이 의사결정을 해야 한다. 더 정확하게 말하면 그 의사결정을 할 수 있도록 임파워먼트가 충분해야 한다는 의미이다. 

 

그리고 그 의사결정에서 PO는 동료의 의견을 충분히 들어야 하는데, 여기서부터 개인의 역량 차이로 나타난다. 누군가는 밀어붙이기 식으로 통보하거나, 누군가는 음흉하게 다른 일정에 슬쩍 끼워넣기도 한다. 또 누군가는 체념하듯 위에서 시켰다고 상위 레벨의 기획 자체를 탓한다.  이게 꼭 나쁘다가 아니라 이것도 하나의 방식일 수는 있다. 하지만 모두가 동의하고 함께 시작한 일은 더 효율적이고 즐겁게 끝난다. 여기서 즐겁게가 상당히 중요한데, 일이 즐겁다는 양이나 질로만 결정되는 것은 아니다. 그리고 그 즐거움이란 건 모두가 다른 부분에서 느낀다. 어떤 이는 소확행 하면서, 어떤 이는 일을 많이 하면서, 어떤 이는 빨리 퇴근하면서 즐겁다고 느끼기도 한다. 그래서 조직은 우리는 어떤 부분에서 일의 즐거움을 느끼는 사람을 선호하는지 알리고, 그런 사람들이 모이게끔 해야 한다. 그래야 우리가 하는 일을 즐겁게 계획하고 실행하고 뿌듯하게 바라볼 수 있기 때문이다. 내가 속한 조직은 '즐겁다'가 모두가 각자 자기 영역에서 프로답게 일을 하고 관리/감독이 아닌 자신이 주체가 되어 스스로 의사결정하고 우리가 목표한 바를 이루기 위해 몰입하는 데에서 즐거움을 느낀다. 그래서 나는 위와 같은 상황에서 문제를 들고 찾아가 함께 일하는 (이 일이 시작되면 실제로 이용자들에게 딜리버리 하기 위해 고민과 구현을 할) 동료들에게 문제를 꺼내놓는다. 

 

'A라는 문제가 있어요. 어떤 거냐면요...'

 

어떤 이는 그 뒤에 이렇게 해보면 어때요? 라는 제안을 요구하기도 하는데 나는 내가 생각한 해결책은 되도록 꺼내놓지 않는다. PO는 아이디어를 모으고 더 좋은 결론에 도달할 수 있게 촉진제 역할을 해야 하는데 좋든 나쁘든 나의 생각을 먼저 꺼내는게 반대로 다른 이들의 순간적인 고민을 막아버리기 때문이다. 쉽게 생각할 수 있는 방식도 함께 해나갈 동료들이 쉽게 꺼낼 수 있게 해주고, 그런 분위기일때 우린 치열하게 토론할 수 있다는 믿음 때문일 수도 있다. 혹자는 애초에 솔루션을 제안하는 것도 좋다고 하는데 반대로 나는 반박하고 주거니 받거니 하면서 멘탈이 나가는 사람도 제법 봤다. 우리는 거절 당했을 때 아쉽고 상처 받으니 말이다. 거절하지 않으면 된다고 하는데 생각보다 우린 무수히 많은 거절할 상황들을 만난다. 

 

아이디어가 나오기 시작하면 나는 다시 이전의 미팅들을 답습하며 빠르게 몇가지 질문들을 던진다. 이전의 미팅에서 내가 얻은 결론과 팀으로서 우리가 내리는 결정이 얼마나 일치하는지 알고 싶어서이다. 굉장히 많은 부분에서 다른 결정을 하게 되고 대부분 팀이 내리는 결정대로 진행한다. 반박하지만 결국 나는 수긍한다. 여기에서 중요한 부분은 나는 동료를 신뢰하기 때문이다. 보통 저 부분에서 저렇게 하면 개발자들은 자기 편한대로만 해 라거나 마이크로 매니징과 관련된 사례들을 꺼내놓기도 하는데, 나는 그렇게까지 사람을 관리하는 능력이 출중하지도 못한 뿐더러 내 시간을 신뢰하지 못하는 동료를 관리하는 데에 쓰고 싶지 않다. 프로에게 프로다움을 요구하는 것이 문제일까? 

 

어쨋든 이렇게 모인 아이디어는 대부분 매우 훌륭하고 구현 가능하며, 계획보다 빠르게 출시된다.

얼마전의 나는 이 부분부터 고민이 많았다.

이렇게 모인 아이디어에 대해 이전 미팅에 참여했던 사람들과 어떻게 이야기 하는게 좋을까?

우리도 우리 딴에 고민하고 아이디어 냈는데 왜 이렇게 범위가 줄었지? 라던가 이럴거면 왜 모여서 이야기 했어 라는 말을 듣는게 내게도 상처가 되지만 내가 또 그에 대해 답변을 하려면 엄청난 시간을 써야 하기 때문이기도 하다. 결국 거절하는 상황이 부채가 되어 미래에 생겼기 때문이다. 

 

그래서 내가 택한 방식은 초반에 거절할 수도 있다는 여운을 항상 남긴다. 발견되지 않았던 이슈는 덧붙여질때 좋은 의견인데 우리가 가진 시간 상 가능성은 조금 더 보고 말씀드리겠다 라던가 백로그에 넣자고 한다. 결국 언젠가는 그 일도 한다. 나의 제품을 함께 만드는 팀원들과는 항상 점검기간이란 걸 갖는데 이 점검기간은 아이디어 중에 아쉬웠던 것들을 담는다거나 QA를 하며 나왔지만 구현하지 못한 것들, 오류가 나는 것들을 업데이트 하는 시간이다. 기술적인 부채가 될 것이든 함께 하는 동료들에 대한 감정 부채이든 해소해야 즐겁더라