프로젝트 관리에서 우리가 놓치고 있는 것
원문: https://productcoalition.com/product-thinking-vs-project-thinking-380692a2d4e
이 글은 프로덕트팀 문화를 프로젝트 중심에서 프로덕트 중심으로 전환하는 것이 왜 중요한지, 이러한 사고의 전환을 어떻게 이루는지 설명한다.
프로젝트 중심적 사고방식은 특정 기능, 소프트웨어 혹은 어떤 것이든 무언가를 딜리버(deliver) 했는지 그 아웃풋(Output)에 초점을 둔다. 때문에 주로 타임라인이나 스케줄이 성공의 척도가 된다. 사전에 얼마나 타임라인을 정확하게 계획했는지, 특정 아웃풋을 얼마나 스케줄에 맞게 딜리버했는지. 스펙을 받으면 일정에 맞게 마일스톤을 설정하고, 최종적으로 그 일정을 달성했는지에 따라 성공 여부를 판단한다.
반면 프로덕트 중심적 사고방식은 결과물(Outcome)에 초점을 둔다. 프로젝트 중심적 사고와 근본적으로 다른 점은 목표(Goal)에 집중한다는 것이다. 그렇기 때문에 프로젝트 초기에 바로 타임라인을 정의하기 어렵고 시도하는 것조차도 사실 의미가 없다. 목표를 어떻게 달성 해야할지 초기에는 아직 알 수 없기 때문이다. 프로젝트 매니지먼트에 익숙한 사람들은 정기적으로 감시하고 체크할 타임라인이 없다는 점이 불안하게 느껴질 수도 있다.
프로젝트 타임라인 대신 결과물에 집중해서 좋은 점은?
어떻게 달성하는가는 중요하지 않기 때문에 목표를 도달하는데 더욱 효율적인 방법을 찾도록 도와준다.
프로젝트 마인드셋에서는 프로젝트를 어떻게 시행할지 미리 계획을 짜고, 타임라인/마일스톤을 설정하고 시작한다. 물론 그 계획이 완벽하다면 문제 없지만 예상했던 것들이 엇나가면 그때는 어떻게 해야 할까? 계획했던 솔루션으로는 우리가 희망하는 결과물을 달성할 수 없다면? 계획했던 날짜가 다 틀어진다면? 회사에서는 계획이 애초에 잘못됐던 점이 무엇인지 회의하고 어떻게하면 다시 스케줄을 따라 잡을 수 있는지 고민하느라 종종 결과물의 퀄리티를 희생 시키고 워라밸을 파괴한다. 이는 특히 대형 조직에서 문제가 된다. 날짜가 정해지고 모든 사람들이 계획에 동의하고나면 어쩔 수 없이 사람들의 포커스가 모두 그 계획에 맞춰지기 때문이다.
하지만 프로덕트 마인드셋을 가진다면 무언가 뜻대로 되지 않고 고객에게서 원하는 반응이 없더라도 그것들을 염두에 두고 조정하기만 하면 된다. 우리가 원하는 결과물에 도달하는 것만이 유일한 목표이기 때문이다.
실생활 속 사례를 들어보자
저자는 프로젝트 매니지먼트의 좋은 적용사례로 건설 현장을 예시로 들었다. 각 파트의 사람들이 무엇을 해야 하는지 처음부터 명확하고 주 단위로 타임라인을 안정적으로 체크할 수 있는 전형적인 사례다. 소프트웨어 개발은 불행하게도(?) 건설 프로젝트처럼 딱딱 맞아 떨어지지 않는다. 아무리 계획을 잘 짜도 그대로 실행하는 것은 정말 불가능하다는 것을 개발자들은 잘 알 것이다. 잘 짜여진 타임라인은 우리의 마음을 편하게 만드는 효과는 있을지라도, 프로덕트 개발을 그렇게 해서는 안된다.
다음으로 저자는 실제로 그가 어떻게 프로덕트 마인드셋으로 해결방식을 제시했는지 설명한다.
전통적인 접근방식에 따르면 개발 착수 전 전형적으로 요구되는 과정은 요구사항 취합 → 프로젝트 범위 정의 → 기능 개발이다. 그러나 저자는 핵심 문제를 이해하고 무엇을 해결해야 하는지 먼저 파악했다. 그러고는 솔루션 리서치에 들어갔고 (기능을 직접 구현하는 것과 써드파티 소프트웨어 적용하는 옵션 검토) 그 과정에서 실은 아무것도 개발할 필요 없다는 것을 깨달았다. 예컨대 포트폴리오 툴을 개발하는 것이 중요한게 아니라 사용자가 어떤 포트폴리오 툴을 원하는지 자율도를 제공하는 것이 답이었던 것이다. 이런 해답을 제시할 수 있었던 이유는 새 기능 개발에만 집중하는 것이 아니라 팀의 최종 목표인 애플리케이션 유저를 늘리는 것에 초점을 두었기 때문이다.
이 사례에서는 개발 공수가 들지 않았지만 일반적으로는 팀에서 원하는 목표를 달성하기 위해 어떤 기능이 필요할지 알기 위해 디자인이나 개발 프로토타이핑이 몇번 필요할 수 있다. 어쨌든 핵심은 그 과정에서 시행착오를 통해 학습하는 것이지 프로젝트 계획을 얼마나 잘 따르는지가 아니라는 점이다.
그래서 어떻게 해야 하냐면..
물론 어떤 프로덕트든 어느정도의 프로젝트 관리는 필요하다. 비즈니스와 예산과 각종 이해관계가 얽힌 조직에서 약속된 일정이 전혀 없이 일한다는 것은 오히려 비현실적이다.
핵심은 계획과 일정에 대해 강한 확신이 생기는 시점에 약속(commitment)을 하는 것이다. 즉, 미리 특정 계획에 commit하는 것이 아니라 무엇을 해야 하는지 확실히 이해한 후에 commit하는 것이다. 이 지점에 도달하기까지 1-2 스프린트가 소요될 수도 있다. 너무 늦은게 아닐까 조바심을 느낄 수 있지만 이때야말로 예측과 계획에 의미가 생긴다. 팀에게 사전조사를 철저히 할 시간을 먼저 주고 그 다음에 일정에 대한 약속을 받는 것이다.
전통적인 방식에 익숙한 사람에게는 특정 기능 구현이 아닌 그보다 한단계 상위 레벨을 보도록 함으로써 프로덕트 매니지먼트 방식의 이점을 충분히 설명해줄 필요가 있다 (설득과 타협도 필요할 것). 만약 리스크 관리를 위해 타임라인에 집착하는 것이라면 사실 진정한 리스크는 일정을 놓치는 것이 아니라 우리가 딜리버하고자 하는 것을 완전히 놓치는 것이라고 말이다.
프로덕트 매니지먼트를 실천하기 위해서는 이 방식에 따르는 어느정도의 불확실성과 시행착오에 익숙해지는 연습도 필요하다. 개발은 결국 유저와 고객에게 밸류(value)를 딜리버하는 일이다.
