6장. 개발팀과의 협업을 성과로 이끄는 애자일 전략
1. 애자일의 꽃, 스프린트 플래닝
스프린트 플래닝은 말 그대로 하나의 스프린트를 계획하는 회의다.
'단거리 전력 질주'라는 뜻의 스프린트는 애자일 방식의 조직에서 2주 단위로 나눠 집중 개발하는 것을 말한다.
2주마다 성과를 측정하고, 그 다음 2주를 계회하는데 이런 스프린트들이 모여 한 달이 되고, 한 분기가 되고, 한 해가 된다. 그러므로 매 스프린트마다 무엇을 할지 결정하고, 방향성을 올바르게 잡아주는 것이 바로 PO의 역할이며, 이 역할을 얼마나 잘 해내느냐에 따라 조직의 성과는 눈에 띄게 차이가 난다.
그렇다면 이 스프린트 플래닝을 잘하기 위한 방법으로는 무엇이 있을까?
이 책의 저자인 쿠팡의 PO는 다음의 6가지를 스프린트 플래닝 때 한다고 한다.
1. 이전 스프린트에서 개발 완료한 것
2. 이전 스프린트에서 개발을 완료하지 못한 것
3. 이전 스프린트에 발생한 기술적 이슈 또는 버그
4. 이전 스프린트에 대한 회고
5. 이번 분기의 OKR 달성 상황
6. 이번 스프린트에 개발해야 하는 것
2. 모든 질문에 대답할 수 있는 소통의 질문
PO는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야 한다. 개발자나 디자이너가 궁금해하기도 전에, 최대한 미리 정의를 다 해놓고 제공하는 것이 최적화된 협업 방식이라고 저자는 이야기한다.
저자의 생각에 나는 더없이 동의할 수 밖에 없는 것이, 인턴 중에서도 같은 동기분들 중 가장 뛰어났던 사람이 저자의 방식과 동일하게 업무를 수행했다. 단순히 기능을 기획하고, 요구사항을 정의하는 것만으로 끝나는 것이 아닌 기능 정의에 대해 나올 법한 모든 질문들을 미리 다 정리하여 Appendix에서 답을 내놓았고, 정책 방면에서도 어떤 식으로 서비스를 운영할 것인지에 대해 기술해놓았다.
그렇게 기술함으로써 팀원(당시에는 리드장님들)들은 그에 대한 꼬리질문을 할 필요가 없었고, 회의는 매우 간결하고도 효율적으로 마무리될 수 있었다. PM/PO는 팀의 중심이자 팀원들을 설득하는 자리이다. 그렇기 때문에 더더욱 더 많은 것들을 생각해야 하고 고려해놓아야 한다.
이번 인턴을 통해서 나는 다시 한번 더 당시 최종합격했던 스타트업의 CEO가 PM을 지망하던 나에게 요구했던 바를 되새길 수 있었다. 당시 CEO는 내게 이렇게 말했다.
"우리는 대체 불가능한 사람이 되고자 해요. 그리고 PM이라면 모든 방법에 대해 고민을 해보아야 하고, 그 모든 방법들을 끊임없이 그리고 확실히 고민했을 때 방향을 정의할 수가 있어요. 다른 팀원이 A라는 방법이 아니라, B 방법이 더 좋지 않나요? 라고 질문을 했을 때, '아, 그 방법은 생각을 해보지 못했네요.' 라고 대답하는 사람이 아니라 'B 방법도 물론 고려해보았지만, 이러저러한 이유로 A라는 방법이 훨씬 좋습니다. 우리는 A를 해야해요.' 라고 명확히 대답할 수 있는 사람을 원해요. 그럴 자신이 있으신가요?"
말의 토씨 하나까지 틀리지 않고 기억했다고는 할 수 없지만, 스타트업의 CEO가 원하는 바의 의미는 비슷하게 상황을 재구성해봤다. 즉, 그들은 PM/PO라면 프로덕트의 방향성을 설정하기 위해 팀원들보다 훨씬 먼 곳을 바라보고 와야 하며, 모든 상황을 다 분석해보았을 때 나오는 최선의 선택을 할 수 있는 사람이길 바라는 것이다.
PM/PO가 그렇게 모든 것을 고려하고 생각해 주었을 때, 비로소 팀은 낭비 없이 운영될 수 있는 것이다.
7장. 고객 테스트만큼 강력한 데이터는 없다.
UT라고 혹시 아시는가?
Usability Test라고 불리는 이것은 몇몇의 고객을 대상으로 우리가 만든 프로덕트를 어떻게 사용할지 살펴보는 Test이다. 그리고 여기에서 가장 중요한 점은 '사용자가 주요 기능을 잘 이해하는지 확인하기 위함'이므로 사용자에게 어떠한 힌트도 주지 않고 그저 어떻게 사용하는지 지켜보는 것이다.
그리고 이러한 테스트를 하는 목적은 대상자가 처음 접하는 기능 또는 디자인을 어떻게 사용하는지 관찰하기 위함이다. 그러므로 이때 가장 중요하게 지켜야 할 점은 바로 '질문을 통해 특정 행동이나 답변을 유도해서는 안된다' 라는 것이다.
운이 좋게도 이번 인턴 기간 중, 자사에서는 어떤 식으로 Usability Test를 진행하는지 강연하는 사내 교육을 들은 적이 있다. (정말 인턴들에게도 많은 기회를 주려고 했던 회사였던 점이 정말 인상적이라고 생각했다:)) 그때에도, 강연을 진행하시는 분이 쿠팡의 PO와 정말 동일한 말을 했다. 바로 '하나의 버튼에 대해서도 고객들은 다양한 생각을 할 수 있어요. 그러니 그들이 어떤 생각을 하고 있는지 모든 것을 확인해 보는 것이죠.'
예를 들면 이렇다. 고객을 관찰하는 중, 고객이 어떤 버튼을 누르려고 했다고 가정해보자. 그러면 이때, '이 버튼을 누르면 친구에게 선물을 할 수 있어요. 이 기능을 알고 사용하셨나요?' 가 아닌, '이 버튼을 누르려고 하셨는데, 무엇을 할 수 있을거라 예상하시고 누르려고 하셨나요?' 라는 식으로 질문해보는 것이다.
즉, 고객에게 미리 어떠한 정보를 줘서 프레임을 씌우지 않는 것이 UT의 가장 핵심이다. 만일 고객이 아예 버튼을 눈치채지 못했다면, 버튼이 있다는 사실조차 알려주어서는 안된다. 왜 버튼을 찾지 못하였을지를 분석하고, 해당 버튼이 만일 KPI를 충족시키는데 중요한 버튼이라면 PM/PO로서 이를 개선하기 위한 방안을 찾아내야 한다. 왜냐하면 프로덕트를 출시하고 나면 몇 천명이 넘는 고객들이 사용할 텐데, 그 사용자들 한명한명에게 기능을 어떻게 사용하는지 알려줄 수는 없는 노릇이 아닌가.
8장. 프로덕트를 출시하는 최적의 시기
자, 먼저 박수부터 치고 시작해보자.
우리는 드디어 고객의 니즈로부터 시작해서 디자인, 개발을 거쳐 UT까지 진행함으로써 프로덕트의 출시 바로 앞까지 다가왔다. 하지만 이렇게 애지중지, 아이를 기르듯 탄생시킨 우리의 프로덕트를 아무렇게나 선보일 수 있을까?
절대 안된다.
우리의 프로덕트는 단순히 고객에게 보여지는 것으로 끝이 아니다. 맨 첫장에서도 말을 했듯이, 우리는 고객에게 감동을 선사하기 위해 프로덕트를 출시하는 것이다. 그런 중요한 시기를 날치기로 한다는 건 애써 만든 죽을 엎어버리는 것이나 다름이 없다.
또한 프로덕트는 고객의 요구사항을 받아 얼마든지 다시 개선되고 배포되는 일이 많은데, 특별한 주기 없이 필요할 때마다 배포를 하게 되면 버전 관리를 하기도 어려워진다. 무엇보다도 고객에게 충분한 고지를 하지 않은 채 시시때때로 기능이나 디자인이 변경되면 고객 경험을 일관성 있게 유지하기가 힘들다.
그렇다면 적절한 배포 일정을 지키기 위한 원칙은 무엇일까? 저자는 다음의 3가지 원칙을 지키면 도움이 된다고 말한다.
1. 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인할 것
2. 다른 팀과의 협업이 필요한 상황이라면, 최대한 미리 배포 일자를 협의할 것
3. 가급적이면 저녁 늦게 또는 금요일에는 배포하지 않을 것
그 중에서도 마지막 세번째 원칙은 꽤 중요하다고 서술하는데, 이는 배포 일자를 지키겠다는 이유만으로 저녁 늦게 배포할 경우 상태를 확인하고 혹시라도 발생할 문제에 대응할 팀원들이 밤 늦게까지 자리를 지켜야 하기 때문이다. 금요일도 마찬가지로 오후에 배포한 버전에 문제가 생기면, 금요일 저녁은 물론 주말에도 대응할 수도 있기 때문이다. (프로덕트 이전에 사람이 먼저다!)