프로덕트 매니저? 프로젝트 매니저? 차이점을 알아보자
차이는 회사가 돈을 버는 방법에서 비롯된다
Photo by Lala Azizli on Unsplash커리어에서 몇 번씩 나는 "프로젝트에서 프로덕트로" 전환하기를 원하는 팀에 합류했었다. 그러나 대기업이든 작은 애자일 팀이든지 간에 그 변화는 절대 매끄럽지 않았다.
프로젝트 (서비스)
프로젝트는 미리 규정된 결과를 성취하기 위한 하나의 노력이라고 볼 수 있다. 예를 들어, 다리를 건설하는 것이나 클라이언트를 위한 워드프레스 웹사이트를 만드는 일 말이다. 테크 월드에서, 고객을 위해 프로젝트를 한다는 것은 보통 하나의 서비스 또는 커스텀 된 소프트웨어를 판매하는 계약을 맺는 것을 의미한다.
프로젝트나 서비스로 돈을 버는 회사는 보통 클라이언트와 계약을 맺는 세일즈팀(또는 담당자)이 있다. 계약을 많이 따올수록 더 좋다. 이 계약은 보통 구체적인 데드라인과 예산, 그리고 모호한 스콥이 존재한다. 수많은 프로젝트를 했던 내 커리어 전반에서 명확한 스콥 정의를 본 것은 몇 번 안 된다.
프로젝트에 참여하는 사람들은 이 프로젝트가 결국에는 끝날 것임을 안다.
리더십
프로젝트팀은 무엇이 프로젝트에 가장 적합하냐에 따라서 종종 구성되고, 해체했다가, 다시 뭉치곤 하기 때문에 끈끈하게 뭉치고 결합되는 것이 어렵다. 그래서 생산성 유지를 위해 특정 리더십 방법론 (미션에 대한 유대감에 기반한)이 필요하다. 싸우고, 기준을 만들고, 구성하고, 퍼포먼스를 내는 과정을 거칠 시간이 없다. 이런 리더십은 말로는 잘 설명이 안 된다. 그래서인지 나는 프로젝트 맥락을 효과적으로 받아들인 뛰어난 리더를 많이 보지 못했다. 프로젝트 매니지먼트의 대부분은 "당근과 채찍" 운영이라는 짧은 단어로 묘사된다.
가장 큰 챌린지는 프로젝트 진행 기간 동안 팀이 최선으로 일할 수 있는 시스템을 찾을 시간이 없다는 것이다. 이런 프로젝트는 대부분 결과물을 빨리, 그리고 이만하면 잘 해낼 수 있는 소수의 개인에게 의존한다.
프로젝트 팀의 리더는 두 가지 태스크에서 균형을 잡아야 한다. 1) 클라이언트와의 관계 관리 2) 팀이 제 일을 제대로 하게 하기 때때로 둘 사이에서 균형을 잡는 것은 매우 어렵다.
요구사항
모두가 프로젝트에 끝이 있다는 것을 안다는 것은, 제한된 요구사항이 존재한다는 뜻이다. 요구사항은 보통 아주 구체적이지는 않지만, 프로젝트를 시작한 명확한 비즈니스 필요성은 존재한다. 프로젝트 레벨에서는 MVP도, 유저 니즈에 대한 탐구, 그리고 A.B 테스팅 등이 존재하지 않는다. 프로젝트를 매니징 하는 것은(프로덕트와 비교해서) 단지 스킬에 가깝다. 언제나 돈을 내는 클라이언트와의 직접적인 1:1 관계가 존재하고, 시간과 예산을 관리하는 것이 필수적이다. 시간제한과 모호한 스콥의 제약에 부딪힐 때, 퀄리티는 종종 트레이드오프 관계에 놓인다.
기술적 디테일들
데드라인을 맞추고 클라이언트를 만족시키기 위해서는 전략적이고 단기적인 생각이 필요하다. 그렇기 때문에 보통 프로젝트 전달자는 원활한 유지 보수를 위한 최적화에 거의 신경 쓰지 않는다. 기술 부채가 프로젝트 소프트웨어를 개발하는 사람에게 떨어지지는 않기 때문이다. 프로젝트를 전달할 때, 적절한 리팩터링을 위한 시간이 없는 경우가 많고, 이 경우 팀은 보통 퀄리티를 희생한다.
리팩터링이 반드시 필요한 것은 아니지만(예를 들어, 프로젝트 소프트웨어의 라이프사이클이 짧을 때) 그래도 이 부분을 인지하고 있는 것이 낫다.
보통 프로젝트의 개발과 유지 사이에는 강한 간극이 존재한다.
그 외 다른 요소들
프로젝트 드리븐 비즈니스에서 중요한 몇 가지 측면들이 더 있다.
다양한 프로젝트의 기술적 기초를 빠르게 세울 수 있는 일당백 "닌자" 고용
트레이닝은 기술이 아니라 프로젝트 온보딩에 집중한다. 즉, '특정한 프로젝트에 연관된' 엔지니어링 스킬 함양이 중요
리포팅 시스템을 클라이언트에 맞추기
비용 청구 가능 시간 측정이 중요
또한, 프로젝트 수임이 안정적이지 않다면 회사는 아마도 계약 담당자를 고용할 것이다. 이 과정에서, 그들은 빠르게 팀을 재조정하고 오직 필요한 엔지니어들에게만 임금을 지불할 것이다. 이 엔지니어들은 프로젝트에서 프로젝트로 옮겨가면서 일한다.
프로젝트를 진행하는 회사는 재사용할 수 있도록 CI/CD, 컨테이너화, 툴링, 테스트 자동화 같은 기술적인 요소들을 통합하고 표준화하는 것이 좋다.
프로덕트
프로덕트는 오랜 시간에 걸쳐서 사용되는 것이다. B2B 비즈니스에서, 프로덕트는 클라이언트 비즈니스의 블록을 건설하는 것과 같다. 프로덕트는 단기적인 페인 포인트를 해결하는 것이 아니다(그래서는 안 된다). 프로덕트는 그들이 설치되는 맥락에서 믿을 수 있고, 기능적이며 경제적인 부분이다.
예를 들어, 우리는 핸드폰을 단지 긴급전화를 하려고만 사지 않는다. 우리는 핸드폰을 하루에도 몇 번씩 사용하기 때문에, 핸드폰을 산 다음에는 우리의 데일리 루틴에 통합시킨다.
대부분의 프로덕트는 정해진 종료 날짜가 없다. 그들은 끊임없이 바뀌고 우리의 유저가 처한 맥락에 핏 되기 위해 계속해서 진화한다. 프로덕트 오너의 주요 과제는 프로덕트 라이브에 있어서 계속해서 변화하는 맥락을 따라가는 것이다. 프로덕트는 "빌드"하는 것이 아니다. 당신은 프로덕트가 살아 움직이고 성장하게 만들고, 맥락이 어떻게 변화하는지를 관찰하여 그것이 주는 기회를 노린다.
프로덕트가 얼마나 성공적인지 평가하는 다양한 지표들을 발명할 수 있지만, 궁극적으로 중요한 것은 매출이다.
리더십
프로덕트 팀은 보통 상당한 시간 동안 함께 일하기 때문에 오랫동안 잘 운영되는 것이 중요하다. 따라서 우리가 이미 잘 알고 있는 리더십 스킬들이 필요하다.
훌륭한 팀 구성, 좋은 분위기 유지, 심리적 안정감, 코칭, 그리고 문화. 여기에 대해서는 이미 많은 책들이 있다.
프로젝트를 다루는 것은 프로덕트를 다루는 것과 다르다. 프로젝트에서, 성취물은 프로젝트 데드라인, 예산 내 운용, 그리고 고객 만족과 관련 있다. 프로덕트는 어떠한가? 프로젝트가 돈을 많이 번다면 그것이야 말로 성공의 명확한 시그널일 것이다. 하지만 그것이 언제나 가능하지도, 그리고 언제나 가장 중요한 것도 아니다. 그렇다면 리더십으로부터 얻는 성공이나 목표 달성의 시그널은 무엇인가? 목표를 분명히 표현하고, 팀이 달성해야 할 것과 그로 인해 얻는 차이에 자부심을 느끼게 하는 것이다. 이것의 첫 번째 스텝은, 명확한 방향을 규정하고 매주, 또는 매 달 바꾸지 않는 것이다.
요구사항
프로덕트의 최종 요구사항은 없다. 오직 프로덕트가 사용되는 지속적으로 변화하는 환경에 적응하도록 이터레이션 하는 것만이 있을 뿐이다.
세상은 매일 변화하고 있고, 고객 니즈도 그러하다. 예를 들어, 새로운 트렌드가 프로덕트가 처한 환경을 바꿀 수 있다. 경쟁 프로덕트가 나타날 수도 있고, 고객의 경제적 상황이 바뀔 수도 있다. 새로운 발명이 당신 프로덕트를 구식으로 만들 수도 있다. 또는 단순한 싫증이나 지루함도 당신 프로덕트를 한 물 가게 할 수 있다.
우리가 "프로덕트 요구사항"이라고 부르는 것들은 실제로는 개선과 최적화를 위한 기회를 찾으려는 노력이다. 이러한 요구사항을 매니징 하는 것은 다음과 같은 스킬이 필요하다:
지식 수집, 가설 설정, 비즈니스 밸류 측정(가설을 실행할 가치가 있는지), 목표 설정, 그리고 기술 부채에 대해 주의를 기울이기 같은 것들 말이다.
기술적 디테일들
기술 부채에 관심을 가지지 않는 것은 차를 샀지만 정기적으로 보수를 하지 않는 것과 같다. 유지 보수 서비스 없이 몇 년 동안 차를 굴리는 것은 가능하지만, 퍼포먼스는 하락할 것이고 결국에는 작동하지 않게 될 것이다. 기술 부채를 해결하기 위해 투입되는 시간의 양은 프로덕트와 프로젝트 사이에 큰 차이를 만든다.
우리는 프로덕트가 계속해서 변화할 것이라는 것을 알기 때문에, 유연성과 안전성에 최적화하기를 원한다. 프로덕트를 만들 때, 쉽게 피쳐를 디플로이 하고 수정할 수 있게 하는 것이 중요하다. 유지 보수는 매우 중요한데, 프로덕트가 작동하지 않을 때마다 우리는 돈과 신뢰를 잃을 것이기 때문이다.
이 모든 것들은 기술적인 결정과 기획에 영향을 주는데, 어떤 토픽들은 프로덕트를 이야기할 때 특히 중요하다:
CI/CD의 안정성과 사용성
기술 부채를 어떻게 해결할지
유연성을 어떻게 최적화할지
코드를 어떻게 문서화하고 지식 전파를 어떻게 준비할지
그 외 다른 요소들
채용 측면에서 서로를 보완하는 사람들로 구성된 안정적인 팀이 이상적이다. 그래서 팀 구성과 협동이 중요해진다. 스킬 관점에서, 우리는 아마 특정 기술을 트레이닝하고 (예를 들어 클라우드 인프라 같은) 그리고 유의미한 트렌드를 따라가는 것에 투자하기를 원할 것이다. 왜냐하면 우리는 우리 제품이 언젠가는 바뀌어야 한다는 것을 알기 때문이다. 우리는 경쟁에서 뒤처지고 싶지 않다.
문서화는 프로젝트에서 그러한 것보다 더 중요해진다. 구조적인 결정이 어떻게 그리고 왜 만들어졌는지 집단 기억을 보존하는 것은 성장에 매우 중요하다. 그 정보를 보존하고 모든 엔지니어가 접근하기 쉽게 만드는 것에는 스킬과 의지가 필요하다.
프로젝트에서 프로덕트로 전환하기
프로젝트에서 프로덕트로 전환하기 위해 모든 회사와 비즈니스에서 통하는 매직 레시피를 제공할 수 있다면 정말 좋을 것이다. 그러나, 너무 많은 변수들이 있다. 나는 오직 기본 원칙만을 제시할 수 있고 - 실제 실행은 환경마다 매우 다를 것이다.
나는 성공적으로 전환된 케이스를 딱 한 번 봤다. 이 전환은 동시에 여러 레벨에서 진행되었다. 회사에서 오직 몇몇 사람들 만이 이 전환을 지휘할 수 있는 능력이 있다. 전체적인 시각과 전사에 걸친 영향력을 지닌 사람 말이다. 리더십이 변화의 폭을 다룰 수 있는 능력이 없고 통합적인 계획이 없을 때 실패하는 경우를 많이 보았다. 이런 경우에 중간 관리자와 엔지니어들은 리더십으로부터 오직 이런 약한 시그널만을 받게 된다. "우리는 프로젝트에서 프로덕트로 전환하기를 원해요."
현실적으로, 오너들은 단지 프로젝트를 하면서 더 적은 비용을 사용하기 위해 기술과 조직을 최적화하기를 원했다. 그들은 요청을 표준화하는 것이 프로덕트를 갖는 것과 동일하다고 생각했다.
내가 본 적절한 전환은 리더십이 고객의 산업에 대해 제대로 된 지식을 가지고 있을 때 일어났다. 창업자들이 그 영역에서 수년간 일했고, 연관된 프로젝트를 많이 해보았다. 수년 동안 그들은 프로덕트를 표준화했고 지나친 커스터마이제이션을 위한 몇몇 요청에는 "안 된다"라고 말할 수 있었다. 이들은 프로젝트 하나를 구현 전에 핵심 제품으로 선정했는데, 제품으로 키우려는 의도였다. 적절한 전환을 위해서는 예를 들어, CI/CD가 적절하게 세팅되고 철저한 문서화를 위한 요구사항들이 있었다. 코어 팀은 처음부터 함께 일한 경험이 긴 사람들도 구성되었다. 프로젝트를 프로덕트로 전환하려는 의도는 프로젝트를 마친 다음에 생긴 것이 아니었다. 프로젝트가 시작하기 전에 미리 규정되어 프로젝트 시작 단계부터 지켜졌다.
물론, 이것이 유일한 방법이라고 말하는 것은 아니다. 당연히 다른 성공 사례도 있을 것이다. 초점은 프로젝트와 프로덕트 사이의 모든 차이점을 고려하는 계획이 프로젝트에서 프로덕트 기반 업무로 성공적으로 전환할 확률을 높여줄 것이라는 것이다.
이 글은 다음 원문의 번역입니다.
제목: Project vs. Product Oriented Environments
저자: Andreja Dulović
번역자: 곽나래
원문 링크: https://medium.com/management-matters/project-vs-product-oriented-environments-9ac6085a74c9
