훌륭한 제품팀의 세가지 원칙 (덧. 악착같은 마인드)

 

얼마 전에 프로덕트 매니저 (PM)로 일하고 있는 친구를 만났습니다. 

그 친구가 정말 좋은 책이라며, "인스파이드"를 추천해주었습니다. 

인스파이어드는 제품 관리자들이 고객이 사랑하는 기술 제품을 만들기 위해서 구체적으로 어떤 노력(업무)을 하는지를 알려주는 책입니다. 

이 책의 저자는 대부분의 회사에서 진행하는 애자일의 모습은 어떤 의미에서 진정한 애자일이라고 보기 어렵다는 것을 꼬집습니다. 

그런 의미에서 애자일은, 업무 프로세스만이 아니라 제품을 대하는 구성원의 마인드가 중요한 것이 아닐까 싶습니다. 

그러니까, "애자일이란 제품 개선 이터레이션을 린 방식에 맞게 낭비 없이, 빠르게 진행하는 업무 프로세스 그리고 그에 걸맞은 구성원의 *악착같은 마인드"인 것 같습니다.

*악착같이 : 매우 모질고 끈덕지게.

애자일 = 제품 개선 이터레이션 (iteration)을 린 방식(lean method)에 맞게
낭비 없이 진행하는 업무 프로세스 그리고 그에 걸맞는 구성원의 악착같은 마인드 

 

 

워터폴 프로세스 상에서 업무는 보통 

"아이디어 -> 비즈니스 케이스 -> 로드맵 -> 요구사항 -> 디자인 -> 구현 -> 테스트 -> 배포"의 절차를 따라 진행됩니다. 

아이디어는 CEO, 중역들로 부터 출발하는 경우도 있고, 사업 부서에서 아이디어를 제안하기도 합니다. 혹은 고객들 VoC (Voice of Customer)를 통해서 얻기도 합니다. 이렇게 다양한 경로를 통해 수많은 아이디어가 쏟아져 나옵니다. 

수많은 아이디어에 대해서 대부분의 회사는 우선순위를 매기고 로드맵을 짭니다. 그 이유는 1) 가장 중요한 일을 먼저 수행해야 한다고 생각하기 때문에 2) 각 업무가 언제 준비될 수 있을지, 언제 론칭할 수 있을지 예측하고 싶기 때문입니다. 

 

로드맵을 작성하기 위해서는 보통 분기 또는 연간 계획 워크샵과 같은 시간을 마련합니다. 대기업의 경우는 1/4분기 혹은 반년에 한 번씩 CEO 워크숍을 갖고 거기에서 전사의 1년 로드맵을 수립합니다.

우선순위를 매기는 과정에서 비즈니스 케이스 정의를 하게 되는데요, 비즈니스 케이스는 1) 얼마만큼의 매출이나 가치를 만들어내는 것인가 2) 얼마만큼의 비용이나 시간이 필요한 것인가. 이 두 가지를 가늠하여 정의합니다. 

이렇게 1년 로드맵이 수립되면, 각 부서는 이를 맞춰 진격을 개시 합니다. 보통 가장 높은 우선순위의 업무를 차례로 진행합니다. 혹은 적은 공수로 빠르게 할 수 있는 일을 먼저 처리하기도 합니다. 

 

이때 제품관리자 (대게의 legacy 대기업에서는 '기획자'라고 불립니다)는 해당 업무의 이해 관계자 (a.k.a 현업)을 만나서 아이디어를 구체화합니다. 이 과정을 요구사항을 정리한다라고 흔히 묘사합니다. 이러한 요구사항은 사용자 스토리 (User story) 형태이거나, 기능 명세와 같은 양식의 형태입니다. UX 업무 성숙도가 높지 않은 기업의 경우, 사용자 스토리 방식의 요구사항 정리 보다는, 기능 명세와 같은 방식을 주로 취합니다. 기능 명세는 필요한 기능을 정리한 명세서를 말하고 보통 엑셀로 작성합니다.  

 

요구사항이 수립되고 나면 UX팀 (사용자 경험 디자인 팀, 시각 디자인팀, 인터렉션 디자인 팀 등)이 디자인을 진행합니다. 요구사항과 디자인, 경우에 따라서 퍼블리싱까지 완료되면 이것은 개발자에게 전달됩니다. 개발자가 개발을 뚝딱뚝딱 하면 지난한 QA와, UAT를 거쳐 배포가 되면, 이 업무는 끝이 나게 됩니다. 

 

제품 관리자가 없는 조직의 경우, 업무가 끝남과 동시에 제품이 방치될 확률이 높습니다. 보통 규모가 있는 구축 업무는 TF를 꾸려서 진행하는데요, TF는 임시 조직이기 때문에 언젠가는 해산이 되기 마련이기 때문입니다. 

하지만, 애자일팀에서는 프로덕트 매니저가 미니 CEO로서, 제품의 시작과 끝을 계속해서 관리합니다. 자식을 키우는 부모처럼 말이죠. 제품이 방치되지 않고 개선을 지속하는 과정에서 적극적이고 악착같은 이터레이션이 일어납니다. 

 

저자는 관련해서 세 가지 중요한 핵심 원칙을 소개했습니다. 

 

1. 위험은 마지막보다는 초기에 대응한다. 

뛰어난 제품 팀은 구현을 결정하기 전에 위험을 먼저 발견하고 대응합니다. 워터폴 조직에서는 워크숍을 하고 로드맵을 수립하고 요구사항도 다 정의한 상태에서 구현이 들어갑니다. 구현 단계에서 기술 검토가 들어가게 되죠. "이거 이거 할 거야"라고 로드맵 다 세워놨는데, 이런 일정으로, 이런 요건은 개발이 어렵다는 피드백이 나오는 경우가 많을 수밖에 없습니다. 그러면 일정에 맞게 제품 스펙  및 기능을 억지로 수정하게 되고, 그 과정에서 사용자 경험을 타협하게 되면 이상한 UX가 탄생할 수밖에 없습니다. 

하지만 뛰어난 제품 팀은 실현 가능성 위험을 사전에 점검합니다. 

- 실현 가능성 위험 (feasiblity risk) : 우리 엔지니어가 보유한 시간/역량/기술로 필요한 것들을 만들어낼 수 있는가? 

 

이외에 가치 위험 (value risk) : 고객이 과연 이 제품을 구매할 것인가? 

사용성 위험(usability risk) : 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가? 

사업 유효성 위험 (business viability risk) : 이 솔루션이 영업/마케팅/재무/법무 등 우리 사업의 다양한 측면을 고려했을 때 제대로 효과를 발휘할 수 있는가? 

를 검토합니다. 

 

2. 제품은 순차적인 방식보다는 함께 협업하며 정의되고 설계된다. 

워터폴 조직은 위에서 언급한 바와 같이 기획자가 요구사항을 정의하고, 디자이너가 그 요구사항에 맞는 화면을 디자인하고, 그 후 개발자가 그것을 구현합니다. 각 담당자는 그 "요구사항"에 갇혀 업무를 수행하게 되죠. 하지만 훌륭한 제품 팀은 제품 관리자, 디자이너, 개발자가 함께 붙어서 활발히 의견을 주고받으며 솔루션을 만들어 냅니다.

 

3. 기능을 구현하는 것이 아니라 문제를 해결한다. 

전통적인 제품 로드맵은 생산량에 대한 것 이었습니다. 제품이 배포되는 것 = 프로젝트의 끝. 이렇게 론칭하고 나면 장땡인 경우가 많았죠. 제품이 배포되고 나면 그들은 본인들의 생산량을 달성한 것이기 때문에, 이 제품들은 방치되어 버립니다. 하지만 훌륭한 제품 팀에게는 "구현하는 것"이 중요하지 않습니다. 무언가를 만들어내는 것보다, 만들어낸 솔루션이 정말로, 과연! 근원적인 문제를 해결했는가에 관심이 많습니다. 바로 사업적인 성과에 대한 것입니다.