Product Management와 DR
JB의 주간 여행 #1
Brunch에 가입한지는 꽤 오래전이었다.
그런데 막상 글을 제대로 쓰지 못했다. 바쁘다는 핑계이기도 하지만 뭔가 글을 잘 써야 한다는 생각 때문에 발행하지 않고 작성하다 말곤 했다. 이번에는 글을 꼭 발행해야지 하는 마음으로 가벼운 글로 써보기로 한다.
앞으로의 글들은 한 주간 있었던 일 기반에 떠오른 생각들과 삽질에 대한 이야기이다.
현재는 TPM(Technical Program Manager)이란 역할로 일을 하고 있다. 해당 역할에 대하여 설명하면 장황해지기 때문에 간단히 Tech 기반의 대형 Project를 관리하는 Manager이라고 보면 된다. 예전에는 Agile Coach 역할도 했었는데 비슷한 계열이라고 봐도 무방하다. 어떤 타이틀을 갖고 있냐는 중요하지 않고 어찌 됐든 기획, 개발, 디자인을 제외하고 거의 모든 일을 한다고 보면 된다. 그래서 나는 복잡계와 혼돈계의 어떤 지점에 놓여 있곤 한다. 그래서 고민하고 갈등하는 부분이 많다.
요즘 고민은 나는 오랫동안 Management에 대하여 공부하고 업무도 해보았는데 Product Management에 대하여 잘 모르겠다는 것이었다. Product Manager 들과 함께 일해 왔지만 그들의 생각과 관점을 진지하게 생각해 보지 않았다는 것이다. 여러 가지 정리도 할 겸 몇 권의 책을 선정해서 나의 경험과 전문가들의 지식을 연결하는 작업을 해보기로 했다. 혼자 하기 힘들어서 스터디 운영을 해서 다른 사람들의 경험도 연결하고자 하였다. 그 스터디가 지금은 중반을 가고 있다.
잠시 중간 회고를 해보면 역시나 새로운 지식을 익히기보다는 리마인드 하는 상황이 되었다. 이미 알고 있지만 잘 생각하지 않았던 것들을 떠올리게 했다. 함께 스터디를 하면서 다른 사람들의 생각과 경험을 듣다 보니 또 얻을 수 있는 인사이트들이 생겼다. 아쉬운 점은 책에서 다른 책을 추천하는 경우가 많은데 그걸 소화하지 못하고 있다는 것이다. 그러면서도 또 탐구해 볼 영역이 생겼다는 것은 기쁜 일이라는 생각도 들었다. 여기에 스터디 내용을 몇 개 적어보면 이런 것들이 있다.
"Product Management에 대한 하나의 올바른 정의는 불가능하다"
역시나 복잡계와 혼돈계 사이 어딘가에 위치한다는 것은 Management를 하는 사람이면 동일하다는 것이다. 정의되어 있지 않은 직무는 당신 것이다라는 말은 공감하면서도 씁쓸함을 주기는 했다.
CORE : C(Communication), O(Organization), R(Research), E(Execution)
Product Management의 비기술적 역량이라고 소개하고 있다. 복잡계의 일이기 때문에 역시나 방향성에 대하여 제시하고 있다. 부가적인 설명들이 많았지만 방향성을 놓치지 않기 위해 쉽게 외워두기 좋은 상태로 소개하고 있다.
"Looks Fine", "Disagree and Commit"
좋은 게 좋은 거다. 미사여구를 펼치거나 모호하게 말하며 책임을 지지 않으려는 말들이 많이 있다. 우리 회사의 경우 "좋은 것 같습니다."라는 말들을 자주 사용한다. 명료하지 않다. 그래서 문제가 되곤 한다.
침묵은 동의인가? 아니다. 침묵은 절대로 동의가 아니다. 그냥 회피인 것이다. 많은 의사결정에서 침묵으로 대응하는 경우들이 많다. 특히 일본과 일하는 우리의 경우 또 다른 현상이 있지만 명확하게 밝히지 않은 의견은 의견이 아니다. 저자는 동의하지 않더라도 참여나 헌신에 대한 답을 듣도록 하라고 말하고 있다. 이 부분에 많은 공감이 들었다. 반대할 수 있지만 함께 정했다면 참여하겠다는 의사는 명확히 밝혀야 한다. 말하지 않고 협조하지 않음으로 방해하는 것은 결코 좋은 행동은 아니다.
Persona no grata
가짜 페르소나들을 만들 필요는 없다. Product Manager 로서 사용자의 가치를 만드는 것에 집중하라는 의미에서 자칫 가짜 페르소나를 만들지 말라는 것이다. 특히 이해관계자가 원하는 페르소나를 만들거나 나 자신이 생각하는 이상적인 페르소나를 만들지 말하는 것이다. 진짜 고객을 이해하면 되기 때문에 가짜 페르소나를 만들지 말라는 것이다. 그럼 신규 서비스는?? 방법은 있다. 비록 처음에는 소수이겠지만 회사 내부와 돈을 들여 외부 인원들을 직접 만날 수 있다.
Best Practices는 동화 같은 결말을 꿈꾸게 하지만 결코 그런 결과를 주지 않는다.
저자는 베스트 프랙티스를 싫어했다. 이게 이상적인 결과를 만들어 낼 것이라고 광고하지만 막상 해보면 그런 효과가 없다는 것이다. 다만, 긍정적인 변화를 일으키는 중요한 첫걸음이 될 것이라는 것이다. 그러면서 프레임워크나 모델을 소개하였다. 이 부분에 대하여 나도 많은 공감을 했다. 수많은 성공사례는 생각해 볼만한 여지를 주지만 그들의 방법이 나에게 동일한 효과를 내지 않았다. 그래서 사실 성공사례 공유는 하는 발표는 썩 좋아하지는 않는다. 과대광고처럼 하는 성공사례 공유를 말이다.
암튼 저자는 본질이 중요하다는 말을 책 전반부에 담고 있다. 프레임워크나 모델은 그 본질을 유지하면서도 생각할 수 있게 해 주기 때문에 추천하는 것이고 Product Manager 라면 역시나 사용 자에가 가치를 전달하는데 집중하면 된다고 설명하고 있다.
그래서인지 조직의 상한선을 끌어올리는 작업보다 그 상한 선내에서 사용자에게 가치를 전달하는데 집중하라고 한다. 나의 경우는 조직의 상한선을 끌어올리면 사용자에게 가치를 전달할 수 있다는 생각이었는데 결이 달랐다. 그래서 많이 생각해 보는 지점이 되었다.
저자는 애자일에 대하여도 자신의 생각을 이야기하면서 비판하고 있다. 정확히는 애자일 맹신자들에 대한 비판이다. 저자는 Manifesto 가 중요한데 이상한 것들이 붙으면서 Monster 이 되어서 망가트렸다고 한다. 애자일은 Movement이라는 것이다. 공감한다. 어느 순간 단단한 프로세스처럼 활용되는 애자일을 보면 안타까움이 있다. 사실 나는 애자일을 대차게 까고 멀어지려 했다. (https://www.youtube.com/watch?v=gHVVOvTcE5s) 머릿속에 잔뜩 생각들이 있지만 여기까지.
스터디해야 할 부분은 아직 남아있다. 이 부분은 모두 학습했을 때 책 리뷰 겸 한번 더 정리해 보고자 한다.
지금 참여하고 있는 프로젝트는 DR(Disaster Recovery) Project이다. 프로젝트의 시작은 오래전에 시작되었는데 카카오 사태로 우선순위가 높아지기도 했고 요구사항도 바뀌었다. 그리고 카카오에서 Dev 2022 발표를 하면서 장애 회고를 발표하기도 했다. 아마도 많은 회사들이 DR에 대한 것들을 모두 점검하는 시기이지 않을까 싶다.
해당 프로젝트에 참여하면서 전에 생각해보지 않은 것들을 많이 살펴보고 있다. 기술적으로 지식을 정리하는 시간이 되기도 하지만 흥미로운 점은 Business 관점에 대하여 경험하는 것도 재미있다. 그것은 BCP(Business Continuity Plan)이라는 것이다. 기업에 대한 잠재적인 위협을 방지하고 복구하는 시스템이라고 한다. 인력이나 자산을 보호하고 재해 발생 시 신속하게 기능하도록 설계하는 작업을 말한다. 단순히 계획을 세우는 것이 아니라 훈련과 테스트를 위한 트레이닝까지도 포함하고 있다. 내가 참고한 자료는 아래의 글이다.
https://www.investopedia.com/terms/b/business-continuity-planning.asp
또 흥미로운 점은 회사 내에 Risk Management Committee라는 것이 존재하고 많은 임원들이 참여하여서 회사의 Risk 사항을 도출하고 그에 대한 우선순위를 결정하여 Risk 방지 활동이 이루어질 수 있도록 의사결정을 한다는 점이었다. 당연한 일인데 직접 동작하는 것을 보니 흥미로왔다.
DR 프로젝트는 매우 큰 프로젝트이다. 인프라에서부터 플랫폼, 서비스 프로덕트까지 대상이 되어서 복잡하다. 그래서 경험할 수 있는 것들이 많이 있다. 경력이 많다고 해도 경험할 수 있는 것은 한계가 있다 보니 이렇게 새로운 프로젝트를 만날 때면 배우는 것들이 많이 있어서 좋다.
너무 고민하지 말고 생각나는대로 글쓰기 끝.
