일할 때에도 애자일하게

 최근에 우리 팀은 여러 번의 내부 미팅을 통해 주문/결제 페이지의 기능을 변경하기로 했다. 개발팀에는 원격 근무하는 외국인 개발자 두 분(H, M)이 계시고 이 분들은 실시간 소통이 어려워서 내부 미팅에 참여하지 못했다. 나는 Product Manager로서, 이 H님과 M님도 변경 사항을 제대로 이해하실 수 있도록 User story와 각 User story에 대응하는 러프한 Wireframe 작성에 몰두했다. 아무리 러프한 Wireframe을 만든다지만, 아이패드로 대충 스케치한 Wireframe으로 두 분을 이해시키지 못할 것 같았다. 그래서 Figma에서 관련 컴포넌트를 직접 만들어 기존에 작업하던 주문 결제 페이지와 이질감이 없도록 구성했다. 컴포넌트를 만드는 데에 시간이 꽤 걸렸지만, 어차피 컴포넌트는 재사용이 되면 될수록 시간을 절약하는 셈이니 괜찮았다.

 이와 관련한 개발팀 내부 미팅이 오늘 오후 7시에 있었다. 회의 전까지 나는 User story와 Wireframe을 만들어야 했다. 회의 세 시간 전, 완성해야 할 9개의 User story 중 7개는 완성해서 Jira의 티켓으로 올렸다. 남은 2개의 User story를 완성하기 전에 하나의 User story에 해당하는 Wireframe만 만들어 이해가 잘 되는지 H님과 M님에게 전달했다. 완성된 7개의 User story의 description도 같이 전달했다.

 그리고 두 분에게 '어떤 User story부터 읽으면 되는지 설명해달라'는 피드백과 '특정한 버튼이 무엇을 의미하는지 설명해달라'는 피드백을 받았다. 두 피드백을 받고 회의 연기를 제안할 수밖에 없었다.. User story를 읽는 순서는 이미 고려하고 있었고 특정한 버튼의 상세 설명도 이미 염두에 두었다. 하지만 완성하지 않은 2개의 User story에 두 분의 피드백이 반영된 내용이 들어가 있었다. 즉, 완성된 7개의 User story보다 완성되지 않은 2개의 User story가 먼저 공유가 되어야 했다. 그런데 그걸 부랴부랴 완성하고 전달하면 제시간에 공유가 불가능했다.

 7개의 User story를 완성하기 전에 미리 하나의 User story와 Wireframe 묶음을 전달하고 대략적인 피드백을 받았다면 오늘처럼 회의 시작이 채 한 시간도 남지 않은 상황에 회의를 내일로 미루는 상황이 발생하지는 않았을 것이다. 만약 이렇게 보다 애자일한 방식으로 작업했다면 회의 4~5시간 전에 모든 User story와 Wireframe의 완성 시간을 계산하고 오늘 미팅이 무리였음을 판단할 수 있었을 것이다.

 비단 오늘 한 작업뿐만 아니라 다른 작업을 할 때도 애자일한 방법을 적용할지 말지를 염두에 두고 있어야겠다. 특히나 내가 최근에 하는 PM의 역할이 팀원 간 커뮤니케이션 로스를 줄이기 위한 업무로 이루어져 있으니 더더욱 알맞은 마인드셋이지 않을까.