프로덕트 오너 #3

6장 개발팀과의 협업을 성과로 이끄는 애자일 전략

확실한 프로젝트 수행법, 스프린트 플래닝

스프린트 플래닝은 하나의 스프린트를 계획하는 회의 이다. 여기서 '스프린트'는 애자일 방식의 조직에서 2주 단위로 나눠 집중 개발하는 것을 말한다. 이런 단기간의 스프린트들이 모여 한 달이 되고, 한 분기가 되고, 한 해가 된다. 스프린트를 올바르게 수행하기 위해 같이 어떤 목표를 달성해야 하는지, 왜 어떤 것이 우선적으로 개발되어야 하는지 등을 설명하고 설득하는 것이 PO의 역할이다.

프로덕트 오너의 저자는 스프린트 플래닝에 들어가기 전 다음과 같이 정리된 문서를 작성하고 공유하길 권한다.

1. 이전 스프린트에 개발 완료한 것
2. 이전 스프린트에서 개발을 완료하지 못한 것
3. 이전 스프린트에 발생한 기술적 이슈 또는 버그
4. 이전 스프린트에 대한 회고
5. 이번 분기의 OKR 달성 상황
6. 이번 스프린트에 개발해야 하는 것

PO는 개발다 및 디자이너의 리소스 등을 감안하여, 최적의 우선순위를 짜도록 해야한다. 한정된 자원과 시간을 활용하여 고객에게 가장 많은 가치를 선보이고, 회사의 발전에도 기여해야 하기 때문이다. 매 스프린트마다 충분히 준비해야 최대한 많은 결과를 얻을 수 있다.

완료일을 언제로 잡는 것이 시기적절한가

개발에 필요한 공수 산정은 개발자와 개발 매니저에게 맡겨라. 하지만 무조건 그들의 의견에 귀 기울여 개발 완료 일자를 정해서는 안된다. PO는 고객에게 선보여야 하거나 회사가 꼭 달성해야 하는 목표를 위해 일정을 최종적으로 조율해야 한다. PO는 일방적으로 ETA를 개발 조직에 강요하거나, 혹은 반대로 개발 조직의 의견에만 의존하여 ETA를 역산정 하는 실수를 범하기 쉽다. PO는 일방적으로 강요하지도, 일방적으로 강요받지도 말아야 한다. 한정된 자원과 시간 내에 최대한 많은 가치를 선보이는 것이 PO의 책임이다.

모든 질문에 대답할 수 있는 소통의 기술

PO는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야한다. 개발자나 디자이너가 궁금해하기도 전에, 최대한 미리 정의를 다해놓고 제공하는 것이 최적화된 협업 방식이라고 생각한다. 팀원이 언젠가는 질문할 것 같은 질문을 미리 예상하고 답을 마련하는 것도 좋은 방법이다.

---

7장 고객 테스트 결과만큼 강력한 데이터는 없다

사용자 테스트 UT로 문제점을 보완하라

프로토타입이 완성되는 동안, PO는 UT를 준비한다. 이때, 대상군을 정의하여 최소 세 명 이상의 대상자를 선정한다. 조건은 테스트하고자 하는 프로덕트에 맞춰 명확하게 정의한 후, 대상자를 섭외해야 한다. 그 후 PO는 테스트 도중 검증해야 할 사항 등을 미리 정리해놓는다.
미리 문서화 해놓는 다면 UT를 진행하는 중에 대상자가 주요 기능을 잘 이해하는지 확인할 수 있다.

PO는 자신이 설정한 가설이 맞는지 1차적으로 확인하기 위해 UT를 최대한 활용해야 한다. 수많은 고객에게 선보이기에 앞서, 몇 명과 UT를 먼저 진행하면 공통적으로 나타나는 문제점들을 효과적으로 알아챌 수 있기 때문이다.

빠른 피드백 공유는 동기부여가 된다

UT를 준비하고 진행하는 과정도 꽤나 고되지만, 최대한 신속하게 결과를 정리해서 개발 조직에 전달하는 것도 중요한 작업이다. 그다음 작업을 진행하기에 앞서 모두가 동일 선상에서 이해할 수 있도록 PO는 기록하고 구두로 설명하는 절차를 빨리 밟아야 한다. 그래야 개발 일정에 차질 없이, 실제 사용자가 만족할 수 있는 수준으로 보완한 후 프로덕트를 선보일 수 있다.

스프린트 기간 중 언제 테스트 하는 것이 효과적인가

PO는 UT가 완료된 이후에도 실제 개발로 이어질 때까지 다양한 요소를 고민해야 한다. 가장 효과적인 방법은 UT를 스프린트 중간인 금요일이나 월요일에 진행하는 것이다. 그러면 UT가 끝나자마자 결과를 정리하여 공유하고, 곧바로 디자이너가 남은 4-5일간 최종본 작업을 할 수 있기 때문이다. 만약, UT결과가 부정적이라 디자인의 많은 변경이 필요하더라도 당황하지 말고 새로운 UT 일정을 계획해야 한다. 하루라도 빨리 선보이려는 자세도 필요하지만, 궁극적으로 고객에게 최상의 경험을 선사할 프로덕트로 개선하는 것이 가장 중요하기 때문이다.

---

8장 프로덕트를 출시하는 최적의 시기

배포 일정을 정할 때 플랫폼을 고려하라

배포란, 개발이 완료 된 후 QA라고 불리는 품질 또는 기능 테스트를 거친 뒤, 온전한 상태라고 판정되면 고객이 사용할 수 있도록 적용하는 것을 뜻한다. 모든 개발의 마무리는 배포이며, 신규 프로덕트일 경우 배포 일자가 론칭 또는 공개 일자라고 통용되기도 한다.

하지만, 배포를 아무 때나 하게 된다면 동시다발적으로 여러 팀이 배포를 시도하면서 기술적 문제가 발생할 가능성이 크고, 버전 관리도 하기 어려워진다. 따라서 배포 주기를 일정하게 정립하여 관리하는 것이 효과적이다. 혹시라도 스프린트 도중에 기존 프로덕트에 문제가 발생할 경우 신속히 고쳐야 한다. 이때, 급하게 수정하여 안정화된 버전을 배포하는 것을 핫픽스라고 부른다. 이때 배포 일정과 무관하게 수정된 버전을 적용해야 하는 경우 고객 경험에 지대한 영향을 미치는 사안이라면 곧바로 수정하는 것이 좋다.

배포일 정을 정할 때 적용되는 플랫폼도 고려하도록 해야한다. PC의 경우 대부분 웹 서비스 형태이기 때문에 인터넷 브라우저를 통해 접속 및 사용이 가능해서 배포 일정이 상대적으로 자유롭다. 하지만, 안드로이드나 iOS의 경우 상황이 다르다. 비교적 안드로이드는 새로운 버전을 배포하면 거의 바로 구글 플레이에서 다운로드 또는 업데이트가 가능하다. 그러나 iOS는 새로운 버전을 배포하기 위해 애플의 검토가 필요하다. 이에, 안드로이드와 iOS의 배포 일정은 다를 수밖에 없다.

PO는 단순히 고객에게 빨리 선보이고 싶은 마음에 배포 일정을 무작위로 정하지 않도록한다. 다음과 같은 원칙을 지키면 도움이 된다.

- 개발 조직이 정한 배포 일정이나 절차가 있는지 먼저 확인한다.
- 다른 팀과의 협업이 필요한 상황이라면, 최대한 미리 배포 일자를 협의 한다.
- 가급적이면 저녁 늦게 또는 금요일에는 배포하지 않는다.

PO는 기능이 배포될 때까지 고려해야 할 것들이 많다. 각 플랫폼에 따른 일정, 혹시라도 발생할 문제에 대한 대응 태세, 사전 고지 등 다양한 요소들을 준비해야 한다.

A/B 테스트를 통해 트래픽 분산하기

A/B 테스트 플랫폼이 있으면 트래픽을 분산 시킬 수 있다. 통상적으로 다음과 같이 트래픽을 분산시킨다.

A그룹 : 신규 디자인 또는 기능에 노출되지 않는 이용자
B그룹 : 신규 디자인 또는 기능에 노출되는 이용자

새로운 디자인이나 기능을 배포한 다음 , 곧바로 모든 사용자에게 보여주는 건 위험하다. 수많은 고객이 사용하는 서비스라면 특히 100% 적용에 뒤따르는 위험 요소가 과도하기 때문에 점진적으로 노출 빈도를 늘려가면서 여러 수치를 확인하고, 안정적으로 적용할 필요가 있다.

내부 직원도 고객이다

PO는 일반 고객은 물론 내부 고객을 상대할 수 있다. 내부 고객에는 PO가 책임지는 프로덕트를 사용하는 회사 내부 팀, 외주 업체, 고객센터 직원, 배송 인원 등이 포함된다. 일반 고객에게는 연락을 취하기 상당히 어렵지만 내부 고객은 연락을 취하기가 상대적으로 수월하다. 메일을 보내거나, 담당자에게 부탁해 소집하여 설명할 수 있다. 이러한 이점을 이용하여 내부 고객용 프로덕트를 만들어 배포할 수 도 있다.

---

프로덕트 오너를 읽으며, 실무적인 내용을 담고 있어서 실제 기업의 PO가 어떻게 일을 하는지, 기획을 하는지 생각해 볼 수 있었다. 동시에 '주니어 PO' 가 될 수 있을까?라는 생각을 많이 하게 되었다. PO는 고객은 물론 회사 사정에도 밝아야 한다. 디자인, 개발 팀의 업무들에 대해 디테일하지는 않더라도 일의 난이도, 소요 시간, 팀 간의 이해관계를 인지하며 말하고 행동해야 한다. 과연 '주니어'가 미묘하고도 섬세한 사정들을 이해하고 행동할 수 있을까. 배우면 배울수록 어렵고도 매력적인 직업이라는 생각이 들었다.