서비스기획, PM스쿨, 인스파이어드 강의

이 책을 이미 알고 계신 분도 있을 겁니다. 서비스기획을 잘 설명한 책이죠. 

책의 저자는 '마티 케이건'으로 PM의 선구자입니다. HP, 넷스케이프, 이베이 등 다양한 기업에서 일을 한 경험을 바탕으로 이 책을 만들었죠. 그래서인지 책에서는 '너무나 진솔한' 단어 선택들도 엿보입니다. 책 5p를 보면 '나는 주어진 업무를 충실하게 수행하면서 주 60시간 보다 적게 일하는 제품 관리자를 많이 보지는 못했다.' 라고 하네요ㅎ

요즘 M이나 Z 세대 입장에서는 '주 52시간'도 너무 많다'고 당연히 40시간 이하로 일하는 게 좋다는 게 다수일 텐데, 서비스 기획 업무를 하려면 '워라벨'은 대놓고 포기하라는 얘기네요 :)

http://www.kookje.co.kr/news2011/asp/newsbody.asp?code=0500&key=20210918.99099005046 

MZ세대가 관심 갖는 책은…돈·일잘러·워라벨

그렇다면, 이렇게 '워라벨'을 포기할 정도로 PM이라는 게 어떤 매력이 있을지도 궁금해졌습니다. 도대체 'PM이 어떤 일을 하기에 이렇게 자신의 삶을 희생하고서도 끊임없이 업무에 종사할 수 있는가?'에 대한 힌트는 책 174~175p에서 찾았어요.

2. 고객의 문제를 공유하라.

이건 제가 일하면서 너무나도 뼈저리게 느끼는 문제에요. 특히 CS로 쇼핑몰에서 1달간 알바를 한 적이 있었고, 모 인터넷 통신 업체에서 CS 교육을 받고 도망간 경험을 통해서 '고객의 문제'를 공유하지 않는게 얼마나 심각한 건지 깨달았죠.

쇼핑몰 알바를 할 때 '현금 입금'을 한 고객이지만, 상품을 받지 못하는 이슈가 있었습니다. 해당 이슈로 CS 전화나 문자를 보내고 해결을 바라셨지만, 제 입장에서는 '이름', '입금액' '입금날짜' 정보만 있었고 계좌번호도 은행도 확인이 어려웠죠. 이게 무슨 '황당한' 소리야 라고 할 지 모르겠지만 교보문고나 카카오 혹은 패스트캠퍼스처럼 '무통장 입금'을 해도 즉시 입금 내역을 문자나 카톡으로 통보해주는 시스템이 없었습니다. 

결과는? CS 담당자에게 전화해서 죽어라 욕설을 해도 3개월 째 상품 배송도 환불도 안되는 상태였죠. 애초에 API를 통해 은행과 전산시스템을 개발하던가, 아니면 해당 서비스를 대리할 업체와 계약을 했으면 됐습니다. 하지만 그렇게 하지 않았고 회사 내 '개발자'에게 얘기 해봤지만 들어주질 않았죠. (아마 BackEnd가 아닌 프론트 엔드 개발자거나 퍼블리셔 였던 거 같습니다.)

https://hithot.tistory.com/entry/%EB%AC%B4%ED%86%B5%EC%9E%A5-%EC%9E%85%EA%B8%88-%EC%9E%90%EB%8F%99-%ED%99%95%EC%9D%B8-SMS-%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EC%95%B1-android-Firebase

무통장 입금 자동 확인 SMS 안드로이드 앱 android & Firebase

이걸 듣고 나서도, 여러분은 '그래서 PM을 왜 하고 싶은건데? 야, 누구나 고객의 목소리를 듣잖아. CS나 CX를 하면 될 걸 왜 PM과 고객의 문제가 상관이 있다는거야?'라고 생각할 수 있어요. 그래서 제가 찾은 건 책 62p입니다. 

3. 어떤 사례에서도 사용자나 고객, 영업을 통해 최선의 솔루션이 나오지 않았다.
- 훌륭한 제품은 비즈니스의 요구를 충족하면서도 사용자 및 고객의 실제 문제 해결을 목표로 디자이너 및 엔지니어와 치열한 협업 과정을 통해 만들어진다.

너무나 매력적이지 않나요? 쇼핑몰에서 근무했을 때, 대표이사가 매일 아침 '우리 쇼핑몰이 성장하기 위해서는 어떤 방법이 필요한가요' 라고 물었습니다. 그래서 제가 CS로서 '무통장 입금에 대해서 자동으로 입금 내역을 통보할 필요가 있습니다. 교보문고처럼요' 라고 답변했지만, 가볍게 씹혔죠.

하지만, 해당 쇼핑몰 대표이사가 PM의 직무에 대해 이해하고 있었다면 좀 달랐겠죠. 개발자와 저, 그리고 기술 책임자를 모아서 CS가 겪고 있는 문제를 들은 후에 어떻게 처리할지를 논의하게 만들었을 겁니다. 아니면 프로그램을 그냥 사서 쓰는 방법도 있었겠죠. 

PM으로서 CS 업무를 해야할 수 있지만, CS와 PM의 결정적인 차이인 '문제 해결' 이 있기에 제게는 PM이 더 매력적인 직무 같아요. 

https://wantoknowtotellthenstudy2.tistory.com/50

모바일 기획자 + 퍼블리셔 (쇼핑 리스트 만들기)

그래서 저는 어설프지만 직접 HTML, CSS, Javascript도 배워가면서 기획하고 설계하고 만들고 있습니다. 문제를 해결하려면 해당 문제에 대해 '전문가'가 되어야 하기 때문이죠. REST API같은 개념을 알게 된 것도 프론트 엔드 개발자 공부를 시작하면서 알게 된거고요. 

게다가 PM은 그 권한과 책임 때문이 아니라, 직무상 '리더'가 될 수밖에 없습니다. 제품의 기초를 설계하고 UX/UI 디자이너들과 디자인에 관해서 논의하며, 개발자들과 어떤 기능을 담고 어느정도 성능으로 언제까지 개발할지를 협의하고, 마케터들과 어떤 마케팅으로 제품을 홍보할지 등등... 해야하는 업무의 범위가 정말 넓습니다.

그렇기 때문에 '아는 만큼' 말할 수 있고, '아는 만큼' 인정받고, '정확하게 문제를 짚어내는 만큼' 업무가 수월하겠죠. 특히 책 369p의 '강력한 제품 문화 구축하기'를 보면

능력과 다양성의 문화 - 팀은 서로 다른 능력과 배경이 혁신적인 솔루션을 창출한다고 인식한다.

비즈니스와 고객에 능숙한 팀의 문화 - 개발자를 포함한 팀은 비즈니스의 요구와 제약사항에 대해 깊이 이해하고, 사용자와 고객에 대해 잘 알고 있어야 한다.

'PM'이 얼마나 힘든 일인지 잘 말해줍니다. 

서로 다른 능력을 갖고 있는 사람들이 모여 '비즈니스의 요구와 제약사항'에 대해 깊이 이해한다는 건, 내가 소속한 회사가 AI를 통해 사용자의 '수학 실력'을 파악하고 적절한 문제를 제공하는 QANDA일 경우 AI의 제약사항이나 제품 개발에 어떤 문제가 있는지 등은 '어느 정도' 파악하고 있어야 한다는 말이죠.

물론 내가 AI를 직접 개발할 필요는 없지만 '어떤 개발자'와 '어떤 내용'에 대해 이야기하고, '어떤 성능 제약사항' 이 있는지는 스스로 공부해야죠. 

그런 태도가 있어야 '책임감'을 가진 '리더'로서 '신뢰'를 받을 수 있으며 '트렌드'의 '변화'를 계속해서 따라갈 수 있는 '인적가치'가 충분한 PM이 될 수 있다고 생각합니다.  

그렇다고 해서, '학습'이 PM의 중요한 직무는 아니죠. PM의 주요 직무 중 하나는 '프로젝트를 관리'하는 건데 이건 방법론이 참 많아요. 모든 방법론이 모든 회사에 적용되는 건 아닌 만큼 '가려서' 들을 필요가 있는데, '서비스기획'의 대표적인 방법론 2개로 소개해보죠.

첫번째는 '워터폴' 입니다. 

 

마치 폭포수처럼 '위'에서 '아래'로 계속해서 쏟아지는 개발 방법이죠. 비즈니스 요구에 의해 '디자인'하고 '개발'하고 테스트해서 제품을 시장에 내놓는 건데 보통 규모가 큰 기업에서 쓰는 방법입니다. 이 방법은 '미리 모든 걸 계획'하고 진행하기 때문에 계획이 상황을 적절히 예측해서 잘 만들어졌고, 상황 변화가 크게 없다면 매우 좋은 방법이죠. 물론, '예측'이 틀렸거나 '예측'할 수 없는 상황이 만들어진다면? 답이 없죠.

두 번째는 '애자일' 입니다.

이건 '스프린트'와 같이 얘기하는데, '전력 질주'처럼 딱 5일 동안 '계획' '디자인' '개발' '검수'까지 한마디로 '매우 빡세게' 하는 겁니다. 이런 '스프린트'를 적용해서 '작게' '자주' 제품을 지속적으로 발전시키는 방법론이 '애자일'인거고요.

아까 '쇼핑몰'을 예로 들어보면, 워터폴의 경우에는 대표이사가 직원들을 모읍니다. 그리고 '문제'를 말하게 하고, 그 이후에 계획을 세웁니다. ~한 문제가 있고 ~한 디자인으로 ~한 해결방법이 있으니 '기획'을 하죠. 그리고 기획한 순서대로 '기획' -> '디자인' -> '개발' -> QA 팀이 업무를 다 끝낸 후에 제품 개선이 이루어집니다. 당연히 일정이 늦어지겠죠?

애자일은 그냥 '기획', '디자인', '개발', 'QA'가 한자리에 모입니다. 그리고 시간을 정해놓고 문제에 대해 자유롭게 아이디어를 얘기하고 그에 대해 '비판'하죠. '투표'를 통해 어떤 해결방안을 선택하면 바로 '프로토 타입'을 만듭니다. 

Axure 같은 '프로토타이핑 툴'을 활용해서 기능을 구현해 볼 수도 있고, 아니면 

손 그림을 통해서 '대략적인' 논의를 해볼 수도 있는거죠. 

어디까지나 '시간'과 '인력'이 허용하는 한에 따라서 유연하게 제품을 개발-디자인-검증하는 거니까, '워터폴'처럼 계획한 대로 그대로 움직이는 것과는 다릅니다. 대표적인 사례로 KB 은행이 시도하는 '애자일'이 있겠네요. 

http://www.khrd.co.kr/m/view.php?idx=5052882&mcode=m146r0hk 

KB국민은행 , 애자일 중심으로 혁신적인 조직역량 강화

장황하게 말했지만 애자일 vs 워터폴 은 '팀이 권한과 책임'을 갖고 업무를 주도적으로 진행하느냐, 아니면 '기획'한 대로 '주어진 업무'를 수행하느냐 인것 같습니다.

저는 '애자일'이 마음에 드네요 :)

서비스 기획이 무척 힘든 일이지만, 그만큼 매력적인 일인 거 같아서 저도 꼭 '서비스기획자'가 되고 싶습니다. 

'이 글은 소정의 대가를 받고 작성되었습니다.' :)