brunch

매거진 App Monetization

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Stephan Seo Jan 15. 2023

일이 되게 만드는 동료들과 일하는 행복

PO가 외롭지 않은 조직, 딜라이트룸

1인 기업이 아니고서야 세상 모든 조직은 '협업'으로 굴러간다. 연차가 쌓여갈수록 '협업'과 관련한 경험치는 다양한 사람들을 거쳐가며 다채로워진다. 특히 그 포지션이 PO 또는 PM 인 경우 더더욱 그러하다. 함께 '협업'하는 동료 (마케팅, 사업개발 등 비즈니스 부서 / 개발자, 디자이너, 데이터 분석가 등 제품 부서)의 범주는 말할 것도 없고, 겪게 되는 '협업'의 종류부터 (B2B, B2C, 그리고 각각의 세부 도메인을 고려하면) 그 스펙트럼이 넓기 마련이다.

PO로서 총 3군데의 조직을 거치며 적게 잡아 100명 남짓의 개발자, 10명 남짓의 제품 디자이너, 20명 남짓의 비즈니스 담당 동료와 협업 경험을 쌓았다. 거쳐온 조직들 자체가 인재 밀도를 탄탄히 챙기는 조직인만큼 모든 동료들과의 협업 경험은 성장의 연속이었다. 그럼에도 현재 속해 있는 딜라이트룸의 섭스 스쿼드 동료들과의 협업은 이전 경험들과 사뭇 다르다. 무엇이 어떻게 다른지 한번쯤은 꼭 되짚어보고 싶었는데, 새해를 맞이하여 근래의 실제 사례들을 나열하며 정리해보려 한다. 각자의 협업의 경험을 떠올리며 만약 나라면 어떻게 했을지 한번 생각해보며 읽으면 더 재밌을 것 같다.

일이 안되면, '내가' 되게 만든다.

새로 깨달은 오너십의 정의

01. 작업 중에 Blocking 요소가 예상된다면?

섭스 스쿼드에 소속된 개발자와 디자이너는, 섭스 스쿼드의 태스크도 있지만 각 그룹 자체 태스크도 함께 병행한다. 또한 그룹 내부적인 리뷰 프로세스 (코드 리뷰, 디자인 리뷰)가 존재한다. 그렇기 때문에 스쿼드의 태스크를 완수하기 위해서는, 그룹의 태스크와 내부 프로세스 절차를 스스로 잘 고려하여 업무를 수행해야 한다. 이 때 해당 고려 요소들로 인해 스쿼드 태스크를 제대로 수행하지 못할 수 있는 상황이 왕왕 벌어지는데, 섭스 스쿼드 동료들의 자발적 대응은 아래와 같다.

일단 진행하다가 Blocking 에 막히면 이를 공유하고 해당 시점의 잔업을 다음 스프린트로 미룬다. [X]

미리 예상 Blocking으로 인해 완수가 안될지도 모른다고 말하고 진행은 해본다. [X]

일단 되게 만드는 것을 목표로 '되는 방법'을 스스로 생각하고 이를 수행해본다. [O]

예상되는 병목 현상을 대비하여 '유연하게 미리' 빌드를 공유 주는 동료들

예상되는 병목 현상을 대비하여 빨리 끝내두면 좋을 작업을 스프린트 시작하는 날에 바로 완료짓는 동료들

물론 이렇게 했음에도 blocking 요소로 인해 마무리가 안될 수도 있다. 그러나 결과 값이 똑같이 '안되었음'일지라도 팀의 모티베이션 레벨은 크게 다르며, 중장기적인 퍼포먼스도 분명 다르게 나타날 것이다.

02. 특정 과제가 너무 헤비해서 분기 내에 모두 완수하기가 벅찰 것 같다면?

분기 목표 달성은, 각 작업자의 역량도 주요 변수이지만, PO 가 어떻게 플래닝 하느냐가 굉장히 중요하다. 각 백로그들의 Impact, Confidence, Ease 를 고려하여 스프린트를 맛깔나게 구성해야 의도한 목표치를 달성할 수 있다. 이 때 Impact가 커서 꼭 해보고 싶지만 Ease가 지나치게 낮은 백로그는 전반적인 분기 생산성을 해치게 되어 플래닝에 인입하기가 망설여지곤 한다. MVP 레벨로 기획을 나누고 쪼갰음에도 불구하고 Ease 가 여전히 낮을 때, 섭스 스쿼드 동료들의 자발적 대응은 아래와 같다.

안된다고 한다. [X]

일단 해보겠다고 하고 일정 부분 진전을 내고 다음 분기로 넘긴다. [X]

매 스프린트 버퍼 시간을 활용하여 조금씩 작업을 미리 해두어 Ease를 높여둔다. [O]

** 참고) 섭스쿼드는 플래닝시 가용 업무 시간의 25%를 버퍼(buffer)로 잡아둔다.

신규 피쳐를 소리 소문없이 분기 내에 뚝딱 출시한 우리 팀

이런 경험들은 아무리 어려운 기획도 함께 협업한다면 만들어 낼 수 있겠다는 자신감으로 이어졌다. 상자 안에서 '매출 20%, 30% 증진을 위한 가설' 위주였던 과거와 달리, 어느 새 섭스의 백로그는 상자 밖에서 '매출 2배, 3배 증진을 위한 과감한 가설'들로 가득차게 되었다.

너의 일 = 나의 일 = 우리 일

팀의 효율을 위해 기꺼이 희생하는 나의 비효율

01. 플래닝 했던 것과 다른 새로운 서프라이즈가 발생한다면?

유저에게 전달할 가치를 적시에 잘 전달하는 것을 골자로 하는 '스프린트'는 그 플래닝과 리뷰&회고를 통해 스프린트의 예측 가능성을 높이는 것을 중시한다. 예측이 잘 될수록 정확도 높은 플래닝이 가능하고, 안정적으로 유저와의 약속을 지킬 수 있게 되기 때문이다. 허나 여기서 스프린트의 목적은 '적시에 전달' 이 아니라 '적시에 잘 전달'이라는 점이 중요하다. 만약 플래닝대로 '전달'은 할 수 있을 것 같은데, '잘 전달'하는 것이 아닌 것 같다는 느낌이 든다면 급하게 계획을 수정하는 것이 맞다. 이러한 것을 '서프라이즈'라 표현하곤 하는데 대부분의 스타트업 그로스 조직이라면 흔히 겪는 일이다. 이에 대한 섭스 동료들의 반응은 아래와 같다.

안된다고 한다. 플래닝대로 하자고 한다. [X]

된다고 하지만, 서프라이즈로 인한 불괘함을 드러낸다. [X]

가능하다고 하며 오히려 더 잘 전달할 수 있게 되어 기쁘다고 한다. [O]

서프라이즈 덕분에 가치를 '더 잘' 전달하게 된 할인 SKU 실험. 기꺼이 변화를 수용하는 동료들.

심지어 하나의 태스크가 아니라 스프린트 플래닝이 통째로 바뀐 경우도 있었다.

연산자 게임은 아예 계획에 없었는데, 남은 분기 일정을 고려하여 급히 구두로 싱크하여 뒤늦게 플랜에 인입하였다.

되도록 서프라이즈가 적게 생기게끔 잘 관리하는 것이 PO의 주요 역할이다만 모든 것을 어찌 다 예측할 수 있겠는가. 유저들의 피드백, 타 부서의 갑작스런 요청사항, 멤버 개개인들의 일정 등 예기치 못한 일들은 벌어지기 마련이다. 예전엔 그러한 것들이 동료들의 개인 효율을 떨어뜨리기 때문에 PO로서 매우 큰 스트레스를 받으며 나조차 플래닝 변경에 보수적이었는데, 지금은 팀 전체의 효율을 고려하는 동료들 덕분에 결과적으로 팀 퍼포먼스에 가장 이로운 최적의 선택을 합리적으로 취할 수 있다. 그러면서 우리는 공동의 목표를 함께 달성하는 '한 팀'이라는 느낌이 강하게 들게 된다. PO의 자리가 결코 외롭지 않은 자리인 것이다.

02. 협업 프로세스상, 아직 디자인/개발 작업할 준비가 되어 있지 않다면?

보통 이번 스프린트에 PO가 A를 기획하고, 디자이너가 B를 디자인하고, 개발자가 C를 개발하면 - 그 다음 스프린트에 PO는 새로운 D를 기획하거나 배포된 C를 분석하고, 디자이너는 A를 디자인, 개발자는 B를 개발한다. 아주 안정적이고 착착 진행되는 이상적인 경우에 말이다. 일당백을 수행해야 되는 스타트업 특성상, 개발할 백로그가 아직 디자인 작업이 덜 되어 있거나, 디자인할 백로그가 아직 기획이 덜 되어 있는 경우가 더러 있다. 이럴 경우 어쩔 수 없이 기획/디자인/개발을 한 스프린트 안에 병행해야 한다. 이에 대한 섭스 동료들의 반응은 아래와 같다.

병행은 비효율적이니 프로세스대로 기획이 준비가 된 이후에 디자인, 개발로 이어가자고 한다. [X]

병행을 하긴 하겠는데, 효율적이지 못한 부분에 대한 불편을 드러낸다. [X]

병행하자고 하며, 빠듯한만큼 미리 챙길 수 있는 부분들을 챙겨두어 완수해보자고 한다. [O]

플래닝 미스로 디자인과 개발이 병행되었던 구매화면 실험

심지어 스프린트 중 디자인이 확정되기 전에, 미리 디자인 작업물을 훔쳐 보며(?) 개발 초벌까지 빌드해준 사례도 있다. 혹여나 큰 수정사항이 발생하더라도 기꺼이 수정하겠다는 것이다. 확정되고 정돈된 디자인을 보며 개발하는 것보다는 개인 공수가 더 많이 들겠지만, 팀의 목표인 '작업의 완수'에 더 가까워지는 것이기 때문이다. 덕분에 이틀만에 전체 작업(기획~디자인~개발)의 90%를 완수할 수 있었다.

기획 - 디자인 - 개발 이 동시에 진행되었던 멀티플 미션 사례

물론 예측 불가한 '서프라이즈 변수'도 아닌, '플래닝 미비'로 인한 이러한 '작업 병행'은 지속 가능성 측면에서 분명 옳지 않다. 동료들이 더 안정감을 갖고 오래 달릴 수 있게끔 PO가 파이프라인 관리를 체계적으로 잘 해줘야 한다. 동료들에게 매우 미안해야 하는 부분인 것이다. 그럼에도 이런 상황들을 동료들이 이해해주는 것은 서로에 대한 강한 신뢰와 감사가 자리하고 있기 때문이라 생각한다. 재밌는 건, 이러한 상황 덕분에 나또한 역으로 동료들에 대한 신뢰와 감사가 강해진다는 사실이다. 하여 나또한 그들의 혹시 있을 '미비'한 상황에 유연하게 대응하게 되는데, 일종의 신뢰와 감사가 강화되는 루프 같기도 하다. 신뢰 받으니까 한발 양보 받고, 양보 받으니까 나도 신뢰하게 되고, 그러니까 나도 한발 양보하게 되고 그럼 또 신뢰를 받게 되는 ...