[제로베이스 PM스쿨 29기] 강한 제품팀의 원칙 - 인스파이어드
제품팀이 하나의 프로젝트나 기능을 만들어 내는 것이 아니라는 점을 강조하기 위해 때로는 제품 전담팀(dedicated product team) 또는 지속 제품팀(durable product team)이라고도 부른다. 혹은 스쿼드(squad)라고 하는데, 이는 군사적인 개념에서 유래한 것으로, 제품팀이 다기능 팀이라는 의미를 강조하기 위해 사용된다.
제품팀은 각기 다른 전문적인 능력과 책임을 진 사람들의 집단이며, 단일 제품 또는 큰 제품의 주요 영역에 대한 실질적인 주인 의식을 느낀다.
미션팀
“우리가 원하는 것은 용병팀(team of mercenary)이 아닌 미션팀(team of missionary)이다.” - John Doerr
용병팀은 지시한 것만을 만든다. 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 제품 전담팀은 마치 사내 스타트업처럼 행동하고 느낀다. 그것이 제품팀에 바라는 모습이다.
팀의 구성
일반적인 제품팀은 한 명의 제품 관리자, 한 명의 디자이너, 그리고 두 명부터 최대 10명에서 12명까지의 엔지니어로 구성된다.
계획된 연산을 수행하는 API(Application Programming Interface)의 조합으로만 구성된 프로그램과 같이 제품이 사용자 접점의 경험을 다루는 것이 아니라면 아마 제품 디자이너는 필요 없을 수도 있다.
팀은 상황에 따라 제품 마케팅 매니저, 테스트 자동화 엔지니어, 사용자 경험 연구원, 데이터 분석가와 같은 다른 멤버들도 포함될 수 있다.
팀의 권한과 책임
목표 달성을 위한 제일 나은 방법을 찾아내는 권한이 있으며, 그 결과에 대한 책임도 동시에 가진다.
팀의 크기
제품팀을 구성하는 최소 조건은 있다. 보통 한 명의 제품 관리자, 한 명의 디자이너, 두 명의 엔지니어다. 하지만 어떤 팀들은 다섯 명의 엔지니어와 두 명 혹은 그 이상의 테스트 자동화 엔지니어로만 구성되어 있다.
피자 두 판의 법칙(two-pizza rule)이란 팀의 규모를 두 개의 피자를 먹을 만한 사람 수 이내로 유지하라는 것을 의도하는 표현이다.
팀의 절대적인 규모보다 더 중요한 것은, 팀이 올바른 제품을 올바르게 만드는 데 필요한 고른 역량을 갖추고 있냐는 것이다.
팀의 보고 체계
팀의 구성원들은 보통 그들의 직무 관리자와 지속적으로 상황을 공유한다. 예를 들어, 엔지니어는 엔지니어 매니저와 공유한다. 그래서 제품팀은 보고하는 관계가 아니다.
제품 관리자는 제품팀 구성원의 상사가 아니다.
팀 협업
제품팀은 어려운 비즈니스 문제를 해결하기 위해 장기간 함께 일하는 숙련된 기술을 가진 구성원들의 조합이다.
제품팀이 계층 구조가 아니라는 것을 이해하는 것이 중요하다.
팀의 위치
제품팀은 가능하면 같은 장소에서 함께하기 위해 최선을 다해야 한다.
팀의 업무 범위
각 제품팀의 업무 범위와 권한은 무엇인가? 각 팀의 책임은 무엇인가?
여기에서 한 가지 축은 해야 할 **일의 유형(type of wokr)**이다. ****팀은 제품과 관련된 그 어떤 일에도 모든 책임이 있다고 보면 된다. 프로젝트, 기능 구현, 오류 수정, 성능 관리, 최적화, 콘텐츠 수정 등을 모두 포함한다.
다른 축은 해야 할 **일의 범위(scope of work)**다. 어떤 회사는 제품팀이 단일 제품 전체를 다룬다. 하지만 대개는 하나의 제품이 모든 고객 경험을 포함하고 있고, 각 팀은 부분이지만 유의미한 단위의 사용자 경험을 담당한다.
실제로 많은 경우에 우리는 주로 아키텍처를 기준으로 팀을 정의한다. 일반적으로 아키텍처가 기술 스택을 결정하는데, 이 기술 스택별로 전문적인 인력이 필요하기 때문이다.
어떤 경우라도 제품 관리와 기술 구현이 잘 어우러져야 한다는 점이 핵심이다. 이러한 이유로 보통은 제품 총괄과 기술 총괄이 팀의 크기와 범위를 정하기 위해 함께 협력한다.
무엇이 가장 중요한지를 먼저 결정한 다음에 실행하기 바란다.
팀의 지속성
제품팀은 특정한 프로젝트를 수행하기 위해 형성된 조직이 아님을 분명히 하고자 한다. 특정 프로젝트를 위해 몇 달간 모여서 나중에 해체될 사람들이 미션을 지향하는 팀이 되는 것은 불가능에 가깝다.
팀의 자율성
팀이 판단하기에 주어진 문제를 해결하는 데 가장 적절하다고 발견한 최고의 방법을 시도해 볼 수 있다는 의미다.
자율성은 팀 간의 의존성을 최소화할 수 있다. ‘최소화’할 수 있다는 것이지 ‘완전히 제거’하는 것은 아니다. 확장하는 상황에서 모든 의존성을 단순히 제거하는 것은 불가능하며, 지속적으로 최소화하기 위해 노력해야 한다.
원칙과 기법
우리가 일하는 방식을 개선해야하는 이유의 근본적인 원칙?
한 사람이 원칙에 대해 깊은 이해를 하는 수준에 이르게 되면 각 기법(technique)이 어떨 때 적절하고 유용한지와 그렇지 않은지에 대한 현명한 판단을 할 수 있는 좋은 심성 모형(mental model)을 가지게 된다. 나아가 새로운 기법이 나왔을 때 그들은 빠르게 그 기법의 잠재적인 가치를 평가한다. 그리고 언제, 어디에서 가장 유용하게 쓰일지 판단한다.
기법은 꾸준하게 변화하지만, 근본적인 원칙은 변하지 않는다.