3개월 간 경험한 사내 목적 조직 후기
3개월 간 경험한 사내 목적 조직 후기
살아생전 처음으로 목적조직에 개발자로 참여하여 겪은 경험을 정리해 보려고 한다.
참여 계기
처음부터 자의적으로 난 목적조직을 경험하고 싶어! 라고 생각하며 참여한 것은 아니었고, 목적조직의 참여를 제안 받고나서야 고민을 하기 시작하였다. 목적조직 PO 분은 목적조직이 해결하고자 하는 문제와 그 문제가 중요한 이유 등을 이야기해 주셨고, 내가 목적 조직에서 무엇을 할 수 있는지, 어떤 것을 기대할 수 있는지를 설명해 주시며 모바일 클라이언트 개발자로 참여하는 것을 권유 받았다.
처음 제안을 받고 기존과 색다른 업무를 할 수 있을 거라는 들뜬 마음에 바로 참여를 결정하려고 하였지만, 앞으로의 긴 시간을 결정하는 중요한 결정이기에 조금 더 장/단을 고려해 보기로 하였다. 실제 목적조직에 참여하며 얻고자 하는 경험들을 정리해 보면 아래와 같았다.
- 목적의식을 분명히 가지고 의사결정에 참여하며 프로덕트를 만드는 경험을 하고 싶다.
- 지표를 중심적으로 사고하며 문제를 해결하기 위한 빠른 실험을 진행해보고 싶다.
- 애자일 실천을 위한 방법론을 적용해 보고 프로세스의 점진적 개선을 만들고 싶다.
결국 고민 끝에 개인적인 성장 / 전체 팀의 조직적 성장에서 의미있는 일을 많이 할 수 있을 것 이라 판단하고 목적조직에 참여하게 되었다.
목적조직을 참여하고 가장 처음에 한 것은 우리가 어떤 목표를 향해서 달려가야 할 지 그 커다란 지표를 팀원들과 함께 설정하는 일을 진행하게 되었다.
목적 지표 정의
라이드 헤일링 (택시) 서비스의 고객 리텐션 유지라는 전사적인 지표 개선을 위해, 우리 조직은 이용자에게 높은 퀄리티의 탑승경험 을 제공하는 목적을 가지고 만들어 졌다. 또한, 부차적으로 사내에서 최초로 목적조직으로서 리소스를 할당받은 상황이었기에 우리의 성과를 증명하여 목적조직 방법론의 유효성을 증명하는 것도 노골적이지만 중요한 목표 중 하나였다. 이를 위해 우리는 추상적인 탑승경험 을 정량화 할 수 있는 북극성 지표(OMTM) 나 OKR 를 정의하는 과정이 필요했다.
하지만 너무나 정성적인 탑승경험 지표에 대해서 정량화 할 수 있는 데이터가 고도화 되지 않은 상황이었고, 이 때문에
- 탑승경험과 인과관계가 비교적 분명한 백로그 들을 지표 정량화 보다 우선시 하여 임팩트를 빠르게 내자
- 보다 명확한 정량 지표 설정에 힘을 쓰고 이를 개선하기 위한 백로그가 따라와야 한다
에 대한 여러 의견이 오고갔다.
결국 모두에게 이상적인 북극성 지표 정의를 얻을 수는 없었고, 대신 탑승경험과 상관관계가 뚜렷한 다수의 지표를 선정한 후 이를 개선하는 것을 목표로 일하는 방식으로 합의되었다. 하지만 지표에 대해 함께 고민하는 과정을 통해 구성원 각각이 들쑥날쑥한 도메인에 대한 이해도 및 조직 목적에 대한 공감대를 끌어올릴 수 있었고, 이 부분은 앞으로의 목적조직 진행 및 의견 합의에 있어서 큰 도움이 되었다.
이후 탑승경험을 정량화 할 수 없는 상황에서 탑승경험을 개선하기 위한 액션이 병행되는 문제의식이 더욱 커져, 현재는 이 레슨런을 바탕으로 탑승경험 자체의 정량화를 목표로 목적 조직의 개편이 진행되었다.
목적조직의 운영
이제 합의된 목적을 이루기 위한 행동이 시작되었다. 목적 조직의 전환이 일어나는 궁극적인 이유는 결국 정의된 목표를 달성하기 위해 빠른 실험과 개선을 할 수 있어야 했다.
스크럼 방법론 도입
이를 달성하기 위해 스크럼 방법론을 빠르게 도입해 보고, 빠르게 실패해 보자 라는 지극히 애자일스러운 판단(?) 으로 스크럼을 도입하였다. 초기 2주 단위의 스크럼과 일정 추산, 데일리 스크럼, 백로그 정리 등의 구체적인 방법론 도입에 힘을 썼다. 하지만 스크럼을 왜 하는가에 대한 명확한 이해도가 공유되지 못하였고 스스로도 방법론 도입에 매몰되는 느낌을 받았다. 이를 해결하기 위해 스크럼에 대해 좀 더 근본적으로 이해할 수 있는 스터디를 일부 팀원들과 함께 진행하였다.
이때 함께 하던 북스터디에서 함께 자라기, 스크럼 등의 책을 같이 읽고 공유하며, 지금은 결국 그로스 해킹 등에 대해서 같이 공부해 보는 스터디로 점차 발전해 나갔다. :smile:
결국
목적 달성을 위해 집중해야할 일에만 집중할 수 있도록 하고, 잦고 빠른 조직내의 공유/싱크 로 현 상태를 명확하게 파악하여 일정을 조율할 수 있어야 하며, 이런 짧은 주기의 일정 조절의 성공과 실패를 바탕으로 프로세스의 개선(자기 조직화)이 일어나야 한다.
라는 이상적인 스크럼 도입 목적을 이해하고 기억하며 일할 수 있도록 노력했다. 하지만 고상한 이야기를 실제로 야생의 조직에 도입하는 과정은 쉽지 않았다.
시행 착오와 개선
우선 초기에는 팀 내에서 처음부터 위와 같은 스크럼 도입 이유에 공감대가 형성되지는 않았다고 생각한다. 공감대를 맞추고 나서 이를 위한 구체적 방법론의 도입이 진행되었다면 좋았겠지만, 앞서 말했듯이 진행 초기에는 나 혼자 방법론 도입에 매몰 되어 팀 내의 충분한 공감을 만들지 못했던 적도 많았다. 그래도 팀원들과 함께 스크럼 스터디를 진행하며 실제 스크럼을 통해서 얻을 수 있는 가치에 대한 공감대가 형성되기 시작했으며, 점차 회고를 통해 프로세스의 문제점을 파악 하고 이를 개선하기 위한 액션 플랜 수립이 일어나기 시작했다.
기억나는 개선점과 개선 방향은 아래와 같다.
- 일정 추산을 정량화 및 회고하기 위한 JIRA 도입 과 JIRA 를 사용하며 생기는 문제점을 지속적으로 개선
- 출시 일정에 이해 관계자가 많이 얽혀 있을 수 밖에 없는데, 관계자 모두의 이해를 돕기위한 관리를 위한 시나리오 시각화
- 스펙/QA 의 명료화를 위해 기획 시 Test Case (인수조건) 를 명확히 정의하고 개발할 수 있도록 하기
- 문제해결을 위해 드는 리소스를 개발자가 보다 먼저 제시하거나, 에스티메이션 정확도를 높일 수 있는 pre-dev 단계 설정
등과 같은 문제 발견 및 개선이 일어났다.
하지만 이런식으로 모든 문제점이 모두 개선된 것은 아니며, 실제로 3개월 동안 해결하지 못한 많은 문제점 들이 있었다
- 개발 에스티메이션의 정확도를 끌어올리는 것이 쉽지 않고, 이를 해결하기 지라/많은 회고 액션 플랜들이 오히려 오버헤드가 되는 경우가 자주 발생했다던지
- 정성적이고, 운영 중간중간 미세하게 변경되는 목적 지표 설정으로 인해 발생하는 일의 임팩트에 대한 실험 및 공유가 쉽지 않았던 점
- 에스티메이션의 실패에 대해서 관용할 수 있는 일정 수립이 불가능해 (외부 조직과 엮인 문제) 에스티메이션 실패 시 구성원의 워크로드가 과해지는 문제 등...
그럼에도 불구하고, 프로세스 자체의 개선을 위해 문제점을 확인하고 해결하려는 과정을 통해서 개인적 관점에서도, 조직의 관점에서도 성장을 확실하게 경험할 수 있었다.
전반적인 회고
위와 같은 실험과 개선을 통해 2022년 1분기의 3개월을 보내게 되었다. 다시 내가 목적조직에 참여하여 얻고자 했던 것을 떠올려 보자.
- 목적의식을 분명히 가지고 의사결정에 참여하며 프로덕트를 만드는 경험을 하고 싶다.
- 지표를 중심적으로 사고하며 문제를 해결하기 위한 빠른 실험을 진행해보고 싶다.
- 애자일 실천을 위한 방법론을 적용해 보고 프로세스의 점진적 개선을 만들고 싶다.
이 중 2번, 실제 정량적인 지표를 중심으로 가설을 검증하고 개선해 나가는 경험은 비교적 아쉬운 부분이 많았다. 특히나 목적조직 참여 후반 부 쯤 그로스 해킹에 대해 공부하며 지표를 중심으로 일하는 것에 갈증이 생기기 시작했기에 더욱 아쉬운 부분이었다.
하지만 1, 3번의 관점에서는 앞에서 설명한 바와 같이
- 애자일 방법론의 도입을 통해 얻을 수 있는 장/단에 대한 이해를 할 수 있는 경험이나,
- 구체적으로 적지는 못했지만 탑승경험을 개선하기 위해서 도메인을 깊이 이해하고 팀원들과 함께 문제를 해결하는 과정을 경험했다.
목적조직에 3개월간 참여하며 코드를 짜는 사람이 아닌 프로덕트를 만드는 사람의 관점에서 성장 할 수 있었기에 유의미한 경험들 이었다. 실제로 내가 만드는 제품으로 시장에 빠른 임팩트를 가져오게 하는데 관심이 있는 사람이라면 목적조직을 경험하며 성장하는 것을 추천드리며 글을 마무리 하려고 한다. :)