[독후감] 조직을 성공으로 이끄는 프로덕트 오너

이동한·2021년 1월 12일
0

책을읽고나서

목록 보기
1/1

이 책을 읽은 이유

개인적으로 항상 관심이 있었고 도전해보고 싶었던 역활이 Product Owner(PO)였습니다.

왜 하필이면 PO에 관심이 있었냐고요? 약간은 긴 이야기가 될수 있지만 다음과 같은 이유 때문이였습니다.

제가 QA Engineer로 사회생활을 시작하고 얼마 안되었을 때에는 항상 지식에 대한 갈망이 있어서 시간이 있을 때마다 이런 저런 책을 읽고 공부하려고 더욱 더 노력했었습니다. 그 때에 보던 소프트웨어 공학 원서에 자주 나오고 제 머리속에 남았던 단어가 Stakeholder 입니다. 이 단어를 번역한다면 이해당사자가 제일 적절할 것입니다. QA의 모든 판단의 기준은 Stakeholder으로 해야 한다 정도의 문장이였을 것입니다.

Stakeholder를 잘 표현해준 이미지를 찾아왔습니다. 일반적인 정의를 그림으로 표현한 것입니다.

(그림 출처: https://commons.wikimedia.org/wiki/File:Stakeholder_(en).svg)

업무를 하면서 판단이 필요할 때마다 이 관련된 분들 모두에게 의견을 물어본다는 것이 과연 가능할까요?? 불가능합니다.

제품 개발을 진행하려고 하면 어떠한 방향성이 결정이 되어야지만 업무가 가능합니다. 동전의 양면을 모두 선택할 수 없듯이 어떠한 것은 취하고 어떠한 것은 버려야 합니다.

모든 사람의 생각과 의견을 완벽히 대신 할수는 없겠지만 최대한 객관적이고 효율적인 판단을 내리고 방향성을 만들어 나가는 역활이 프로덕트 오너라고 저는 생각합니다.

이 책이 출간되고 나서 알려지는 것을 보고 한번쯤 읽어봐야지 읽어봐야지 하고 미루다가 인터넷 서점에서 다른 공부를 위해서 책을 구매하는 장바구니에 같이 담았습니다. 그런데 정작 공부를 위해서 산 책은 바로 지금도 제 옆에 독서대에 펼쳐서 올라가 있는데 아직 30%정도 밖에 보지 못했습니다. 공부를 하다가 답답할 때에 "조직을 성공으로 이끄는 프로덕트 오너"를 읽었고 이제 다 읽었네요.

한번 보고 나면 책장으로 들어가서 나오지 않는 책이 있는데 이 책은 다시 한번 읽어볼 것 같습니다.

간략한 독후감

쿠팡에서의 프로덕트 오너가 어떻게 일하는지도 책으로 일부분이라도 알게 되어서 좋았습니다. 어떠한 내용을 글로 옮겨서 설명한다는 것이 매우 어려운 일이라는 것을 다양한 문서들을 작성하면서 느꼈는데 재미가 있는 실사례를 들어서 설명해나가시는 문장력이 먼저 부러웠습니다.

이 책의 독자에 대해서 제 나름대로 생각해보면 IT개발 경험이 없으신 분들이 이해하시기는 조금 어려움이 있을 것 같습니다. 아무래도 IT 개발을 리딩해나가는 역활이 프로덕트 오너이다 보니 개발하는 과정에서 다양한 용어와 상황에 대해서 나옵니다. 이런 것들에 대해서 이해하시는 데에 어려움이 있을 수도 있다고 예상됩니다.
개발 경험이 있으신 분들도 회사별로 개발 프로세스가 다르다 보니 자신의 경험과 다르기 때문에 이해하기 어려운 부분이 분명히 있을 것입니다. 저 또한 일부분 이해하기 힘든 부분이 있어서 읽으면서 어떤 내용인지 고민하면서 읽었던 부분이 있었습니다.

책의 내용중에 제가 좋았던 일부분을 여기에 정리하고 제 생각을 적어보겠지만 저작권 위반이 될 위험이 있기 때문에 아주 일부만 적어보려고 합니다. 혹시라도 저작권 위반이라고 말씀해주시면 바로 해당 내용은 삭제 하겠습니다.

(24page) 제1장 "PO는 중심에 있다"의 일부

"그래, 명심해. PO는 중심에 있어. 모두가 보고 있단 말이지. 절대로 감정을 공개적으로 보이지 마."
그가 마지막으로 던진 그 말은 순간적으로 뇌리에 박혔다. 감정을 보이지 말라니.

"사람은 감정의 동물이다." 그래서, 개인적으로는 서로를 이해한다는 것이 상대방의 감정을 이해하는 것이라고 생각했습니다. 내 입장에서만 이야기 하면 서로 영원한 평행선을 긋고 서로 만날수 없는 이야기만 하기 때문에 같이 업무를 할때에 끊임 없는 감정소모와 다툼이 있다고 생각했었습니다. 저는 합의하거나 동의하는 방향을 정하기가 어렵기 때문에 서로의 입장에서 생각해보는 것이 필요하다고 생각했었습니다.

하지만, PO라면 제품을 책임지는 사람이기 때문에 결정을 항상 해야 하고 결정은 항상 치우치지 않아야 할 것입니다. 이것을 위해서 "자신의 감정을 공개적으로 보이지 말아야 한다.".
책임자로서 감정보다는 합리성을 기반으로 하는 최선을 다하는 문제를 해결해나가는 과정이 중요하지. "아! 감정은 독이 될 수 있겠구나."라는 생각이 들었었습니다.

(72page) 제2장의 "서비스는 하나라도 사용자 유형은 다양하다"의 일부

PO가 범하기 쉬운 실수 중 하나는 프로덕트를 만드는 사람의 관점에서 고객을 바라보는 것이다. 그렇게 하면 무의식적으로 PO 자신이 만들고 싶어하는 방향으로 데이터를 해석하고 결정해버릴 수 있다. PO는 절대로 자신의 직관이나 바람에 의한 결정을 내려서는 안 된다. 고객을 분류하는 방식을 완벽하게 터득할 때까지, 자신이 책임지는 프로덕트를 수도 없이 많이 사용해보는 것이 좋다.

아주 예전에 제가 다니던 직장의 부서장님께서 저에게 그런 말씀을 하신 적이 있었습니다.
"이대리, 왜 자네는 그렇게 항상 보고서를 부정적인 경우를 강조해서 작성하는거야? 다양한 경우의 수가 있으면 이대리가 생각하는 의견을 가장 먼저 이야기 해야 해. 그게 프로야. 부정적인 경우도 빼서는 안되지만 부정적인 경우만 강조하면 자네의 강점이 보고서에서 보이지 않아."
제가 지금도 가끔 연락드리고 찾아뵙는 상사분이십니다. 현재는 그 회사의 CIO의 자리에 있으시고요.정말 감사하고 감사한 분이죠. 제가 아무래도 Software QA로 일을 하다보니 부정적인 경우에 대해서 공유하고 대비책을 새우는 것이 습관이 되다보니 보고서에도 그것이 듬뿍 묻어났었나 봅니다.

갑자기 왜 전 직장 상사분의 이야기를 했냐고요? 저는 저 내용을 읽으면서 이 분이 가장 머리속에 떠올랐거든요. 사실 보고서를 만드는 사람은 자신의 전문성을 발휘해서 상사가 판단을 내리기에 도움이 될 내용을 정리하는 것입니다. 자신의 지식과 경험을 기반으로 수집한 데이터를 정리하여서 가장 가능성이 있는 시나리오를 정리하는 것이 시나리오 A이고 가능성은 낮지만 경우의 수를 따져서 최악의 경우에 대한 대비책도 정리해서 보고하는 것이 보고서라고 생각합니다.

하지만, PO는 자신의 생각과 의견을 지우고 제품을 실제로 쓸 고객만을 생각하며 판단을 내려야 하는 역활이 맞는 것 같습니다. 끊임없이 고객을 알기위한 다양한 노력과 시도를 하며 최소한의 실패를 경험하고 고객에게 선택될 제품을 만들어 나가는 역활이겠죠.

후기

저가 어쩌다 보니 이곳 저곳에서 다른 분들에게 교육을 하는 입장이 된 경우가 꽤 있었습니다. 그때마다 저에게 가장 어려웠던 것은 교육의 수준과 교육 내용을 정하는 일이였습니다.

제가 단순히 제 교육이라는 업무 혹은 임무를 수행하는 것이라고 생각했으면 전달해야 하는 내용을 정의하고 그것을 정리해서 효율적으로 전달하는 데에만 힘썼을 것입니다. 하지만 교육을 받는 분이 이해하고 자신의 것으로 만들수 있도록 돕는 것을 목표로 한다면 교육에서 전달할 내용을 어디까지 어떻게 설명해야 할지 항상 고민이 되었습니다. 그래서 가장 먼저 교육을 받으시는 분들이 어떤 분들이신지부터 저는 알아보려고 노력을 했습니다. 교육을 받으시는 분들이 이해할수 있는 내용을 준비해야지 정말 서로에게 의미가 있는 시간이 될수 있다고 생각했기 때문입니다.

쿠팡의 현재(?)는 이 책에 있는 내용처럼 일을 하고 계실 것입니다. 하지만 처음부터 저렇게 잘 운영되는 조직은 아니였을 것이라고 생각합니다. 많은 분들이 함께 일하면서 만들고 정리하고 정의해 나간 결과가 현재의 모습이라고 생각합니다. 이 책의 내용과 자신의 현실이 다르다고 해서 "아! 쿠팡에 가서 저렇게 일하고 싶다!"보다는 "내가 처한 상황에서 어떻게 해봐야겠다!"라고 도전을 해보실 수 있는 책이 되기를 바랍니다.

제가 가장 싫어하면서 가장 좋아하는 말이 Tailoring입니다. 예전에 CMMI 프로세스 적용과 관련된 업무를 진행할 때에 가장 많이 저에게 화두가 되었던 단어입니다. 프로세스를 상황에 맞게 조정해나가는 것이였습니다. 사실 이것이 매우 어렵습니다. 양복 제단한다가 Tailoring인데 자신의 상황에 맞게 프로세스를 수정해서 적용한다는 것인데 이것이 정말 옳은 방향으로 잘하고 있는 것인가 확신을 가지기 어려웠거든요. 그런데 프로세스를 조직에 적용하려면 실패를 하면 그 후폭풍이 너무나 큽니다. 기존에 하지 않았던 업무 방식을 적용할 때에는 항상 저항할수밖에 없는데 실패한다면 적용했던 전체 프로세스를 다시 생각해봐야 하기 때문입니다.

하지만, 제가 그 이후에 이런 저런 경험을 하면서 얻은 제 결론은 다음과 같습니다. 실패가 두려워도 실패는 항상 언젠가는 할 수밖에 없는 것이고 자주 반복하지 않고 발전해나가도록 노력하면 됩니다. 다른 누구랑 비교 당하는 것이 중요한 것이 아니고 내가 그리고 본인이 소속한 조직이 발전하는 것이 중요한 것이니까요. 도전하지 않는 다면 정체되는 것만이 아니고 썩을 수밖에 없더라고요.

profile
Software Quality Assurance Engineer

0개의 댓글