채팅 GPT에게 PM에 대해 물어보자

채팅 GPT에게 PM에 대해 물어보자

프로젝트를 올바로 이끌기 위해서는 ‘허세 지표’를 사용하지 말아야 합니다

---

이 글에서 언급되는 PM은 소프트웨어 서비스기업의 프로덕트매니저(오너)/프로그램매니저/프로젝트매니저를 모두 지칭하고, 허세지표, 허영지표* 라는 말은 Eric Ries 의 저서 ‘The Lean Startup‘에 나온 단어 Vanity Metrics으로 부터 차용했습니다.

 

 

[PM은 체질보다 어드벤쳐] 좋은 PM은 ‘허세 지표/메트릭’을 사용하지 않습니다.

 

셜록홈즈 가라사대

많은 분들의 어린 시절을 풍요롭게 해 주었던 셜록 홈즈 시리즈중 ‘네개의 서명 The Sign of the Four’이란 작품에 이런 유명한 말이 나옵니다.

 

 

 

“개개인은 풀기 어려운 하나의 퍼즐이지만 전체가 맞추어진 상황에서의 그 사람은 수학적 확실성이 된다.” While the individual man is an insoluble puzzle, in the aggregate he becomes a mathematical certainty.

 

이 말을 요즘 많이 회자되는 데이터기반 Data-Driven개념으로 다시 해석하면, “조각 조각의 데이터는 미완성의 정보이지만, 많은 데이터가 모여서 패턴이 되고 정보가 되면, 원래의 그 조각데이터는 큰 그림을 이루는 완벽한 공식속에 존재를 한다”고 해석해 볼 수도 있을 듯 합니다. 이해되기 어려운 작은 데이터가 큰 가치를 제공하기 위한 하나의 방법으로 우리는 많은 곳에서 자주 한눈에 이해되고, 쉽게 파악될 수 있는 지표 Metrics를 사용하여 변환하여 보고 그 표현된 정보를 믿고 나눕니다. 그런데, 이 지표를 만들어 내는 과정에서 필요없는 허영과 허세가 가득 들어가 있다면 어떨까요? 이때 말하는 허영과 허세는 통계자료를 특정한 관점을 주장하기 위해 왜곡, 과장을 하는 것을 말하지는 않습니다. 오히려 정확한 데이터를 왜곡없이 표현하지만, 그것이 보여주는 사람이나 보는 사람에게 좋은 느낌을 전달할 뿐 그 이상의 정보, 인사이트, 지혜 등을 전달하지 못하는 지표를 말합니다. 

좋은 느낌에서 그치는 그런 지표는 상황을 정확하게 전달하지 못하기에 건강하지 못한 지표가 되고 결국은 프로젝트, 상품, 서비스의 성공을 보장하기 어려워지는 결정에 기여하게 될것입니다. 지표를 만들때 그 허영과 허세라는 것은 무엇이고, 그것을 방지하려면 어떻게 하는것인지를 예를 들어 이야기 해 볼까 합니다.

 

0. 데이터 스스로는 아무것도 해결할 수 없다.

요즘의 어딜 가도 쉽고 흔하게 듣는 말이 데이터기반 Data-Driven이란 말입니다. 데이터기반 의사결정 Data-Driven Decisions, 데이터 기반 개발, 데이터 기반 디자인등, 데이터의 중요성이 그 후의 품질을 결정한다라는 뜻을 함축하고 통용되고 있습니다. 인터넷 데이터 조사 사이트인 DOMO Report에 따르면 2020년 지구상에 있는 모든 개개인은 1초당 1.7메가 바이트의 데이터를 자동으로 생성시키고 있다고 합니다. 이 양은 사실 우리 머리로 생각할 수 있는 한계를 넘어서고 있습니다. ( 왓츠앱메신저는 4천2백만개/1분당 의 메시지를 날리고, 넷플릭스는 40만4천시간/1분당 의 영상을 스트리밍합니다. 링크 참조 )

이 수많은 데이터가 모여 정보 information이 되고, 개개의 정보가 지식 knowledge과 인사이트 insight, 지혜 wisdom으로 발전을 하면서 그 부가가치가 올라가게 됩니다. 그 부가가치를 쉽고 이해도 높게 전달하기 위해 우리는 지표 Metrics이란것을 자주 사용합니다. 지표를 정의해 봅시다. 메트릭/지표란 현재 진행중인 사업/프로젝트의 성과나 상태를 측정 measure해서 수량화/수치화 quantify/qualify를 한 결과물을 통칭합니다. 보여주고자 하는 것들을 여러가지 형태의 그래프나, 장표, 강조된 숫자들을 이용하게 표현하는 방법이죠.

 경영의 신이라 불렸던 피터 드러커의 한 마디 말 “측정할 수 없는것은 관리할 수 없다” 이 금언처럼 인용이 됩니다. 측정을 하려면 기준을 만들어야 하고, 그 기준은 수치/수량으로 설정하게 될테이고, 그것을 잘 보여주는것이 지표/메트릭이 되어야 한다는 뜻이구요. 하지만 데이터기반이라고 외치면서,그 사용 특히나 경영의 중요한 결정이나 프로젝트의 중요상황을 나타내는 지표로서 이용될때는 ‘허세/허영 지표’를 경계하자에만 포커스를 맞추려 합니다.

 

 

 

 

최첨단 데이터기반, 사용자 경험 기반의 기술의 아주 재미있는 부족한 점을 예로 들어 보겠습니다.

인터넷 쇼핑몰에 들려 청바지를 구매하려 합니다. 여기저기 사이트를 보고, 모델의 핏도 보고, 청바지 세탁상태와 컬러도 확인을 하고 마음에 드는 상품을 바구니에 담아 결제까지 모두 마쳤습니다. 이후부터 어떤 상황이 발생하나요? 내가 방문하는 페이지, 앱에 많은 수의 청바지 광고가 쇄도를 합니다. 어디선가 메일도 오고, 매우 귀찮고, 짜증이 나는 일이기도 합니다. 데이터 기반 시스템은 내가 잠시전에 방문하여 발자국 데이터를 남긴걸 기가 막히게 알아차리고선 ‘이 사람은 청바지가 관심이 있구나’ 라는 과거 사실 데이터에 근거하여 광고를 쏟아 붓습니다. 여기서 중요한 사항은 모든 사이트가 ‘중요 정보’라고 생각하는 그 데이터는 ‘매우 불확실한 과거‘ 데이터이고, 그것에 따른 페이지 광고 결정은 매우 잘못되었을 가능성이 많다는 것입니다. ‘쇼핑몰에서 청바지를 구경/쇼핑 했다’라는 데이터는 ‘청바지를 구매하고 결제를 완성하였다’라는 사실까지는 알려주지 않습니다. 청바지를 이미 구매 했는데, 그 사용자에게 지속적으로 청바지 광고 노출을 하는것은 합리적이지도, 지능적이지도, 비즈니에 도움도 되지 않습니다. 이 데이터기반 시스템이 실생활에 도움이 되려면, 오히려, 청바지와 매칭할만한 티셔츠나, 선글래스, 핸드백등을 광고에 노출시키는것이 훨씬 효과적일 수 있기 때문입니다.

제가 말씀드리려는 사실은 “데이터에 집중하는것은 무의미한 일이다”가 아닙니다. 오히려 반대입니다. 시간이 지나고, 전문기술이 발전함에 따라 그 가치는 증가하고, 빛이 날겁니다. 그러나 그 데이터를 지표로 보여주고, 그것에 따른 결정을 할때는 좀 더 신중하고 의미있는 데이터의 해석이 필요합니다. 그 이야기를 해 볼까 합니다. 

 

1. 허세, 허영, 허풍, 허무 지표 Vanity Metrics

 

 

 

A. 허세의 전형- 누적 지표

허세/허영 지표의 정의는 “데이터를 얻는데 큰 노력이 필요 없으며,보는이의 기분을 좋게 할 수는 있지만, 이것을 보고 난 후 무엇을 하면 되는지 프로젝트/비즈니스 인사이트를 제공 하지 못하는 지표”입니다. 그 반대의 개념으로도 설명이 쉽게 되는데 허세 지표의 반대는 Actionable실행이 가능한 지표 입니다. 허세 지표는 주로 프로덕트/서비스 홍보나 마케팅쪽에서 투자자나, 비전문가들을 대상으로 하는 PR을 할때 또는 언론에 제공하는 경우에 많이 나타나지만, 엔지니어링 프로젝트 진행중 내부 회의 자료로도 많이 등장합니다. 스스로를 칭찬하고 분위기를 고무시키기 위한 가장 대표적인 허세지표는 다음과 같습니다.

-웹페이지의 히트 수

-앱의 다운로드 수

-팔로워 수

-좋아요 수

-가입자 수

 

우리 사이트/서비스/제품이 얼마나 인기가 있고, 이 앱, 포스트, 개인이 얼마나 사랑받고 있는지를 보여줄때 빠짐없이 나오는 지표입니다. 그런데 왜 허세 vanity라고 하는지 이 숫자를 얻기 위해 내 역할이 얼마나 공헌한 것이지 명확한 구분을 할 수 있나요? 이 숫자에 따라 내가 다음달, 다음해에 무엇을 하여야 하는지, 어떤 행동을 취하여야 하는지가 명확한가요? 대부분의 경우 저 숫자만으로는 알 수도 없고, 어떻게 해야하는지도 모릅니다. 이미 여러분이 눈치 채셨겠지만, 대부분의 허세지표는 누적숫자를 이야기 합니다. (밑에서 이 허세지표가 실행가능한 지표 actionable metrics이 되려면 어떤것을 보강해야 하는지에 대해서 설명하겠습니다.)

위의 예에서 말한 ‘다운로드 수’는 초기 프로모션이나 광고효과로 내려받은 후, 더 이상 사용하지 않거나, 앱을 삭제한 경우에 해당이 되도 이미 숫자로 카운트가 된 상황이라 ‘허세’지표라 부릅니다. 같은 이유로 가입자 수 역시 가입이탈이 일어나도 그 숫자는 추적을 하지 않기 때문입니다. 

허세지표가 나쁜 이유는 ‘노력없이 쉽게 얻어지는것’과 ‘지표의 명확성 부족‘입니다. 그 숫자 자체의 표현 이외에는 어떠한 백그라운드 제공하고 있지 않습니다. 지표가 좋으면 모두 내 덕이라고 생각을 하고 지표가 나쁘면 그건 네 탓이라고 생각하게 되는 나쁜 문화를 생성하기도 합니다. 그런데 이 허세지표는 이렇게 바깥으로 보여지는 지표 뿐만이 아니라 기업의 내부에도 존재합니다. 그것도 훨씬 나쁜 형태로 말입니다.

 

B. 허세가 독으로 쓰일때 – 팀간 비교 지표

어떤 지표를 사용하여 팀을 비교하려 하면, 그 즉시 그 지표는 독이 됩니다. 팀들간의 분위기는 둘째치고, 그 지표의 타겟값에 오염이 일어나기 시작합니다. “측정치가 목표치가 되는 즉시 , 그 측정치는 지표로서의 가치를 잃는다” 라는 굿하트의 법칙이란 것이 있습니다. 다른 말로 하면, 그 목표치를 얻기위한 모든 방법을 동원하면서, 원래 측정하려던 의도가 오염이 일어난다는 뜻입니다. 예를 들어, 우리의 제품/서비스를 많은 사람들에게 노출시키기 위해서 제품품질에 역량을 다하기 보다는, 검색엔진을 위한 SEO작업을 통하여 검색랭킹을 올리는데 더욱 집중시키는 결과를 만들려는 노력을 한다는 것입니다. 영업 이익을 측정하려는데, 월말 분기말이 되면서, 영업부서는 팀간 경쟁을 위해 밀어내기를 무리하게 합니다. 즉 영업 이익 자체가 줄어드는 결과가 나타나는 상황 같은 것입니다.

또한 중요한 편향을 설명할때 나오는 호쏜 효과 라는 것도 매우 중요하게 작용합니다. “자신의 행동이 관찰되고 있음을 인지하게 될 때 그에 대한 반응으로 자신들의 행동들을 조정, 순화시킨다.” 라는 행동 편향입니다. 누가 보고 있으면 내 행동은 원래와 다르게 바뀐다 라는 뜻입니다.

여러분이 매일 경험하게 되는 프로젝트 진행중의 예를 들어봅니다. 스프린트를 진행할때 속도Velocity 라는 지표를 매우 자주 사용합니다. 하나의 스프린트 동안에 ‘스토리’라는 개발목표 기능에 각각 포인트를 부여하고 그것을 완성하면, 부여된 그 값을 더하여 ‘속도’라는 지표로 사용합니다. 이 ‘속도 Velocity’라는 지표는 사실 팀이 지난 3개월 이상 프로젝트를 진행하면서 취합된 데이터를기반으로 평균속도를 계산하여 다음 스프린트 플래닝에 참고하려는 용도 이외에 다른 목적은 있을 수 없는데, 가끔 여러 팀을 매니지하는 PM이나 상위 매니지먼트 그룹은 팀간의 퍼포먼스를 비교하는 지표로 씁니다.

즉 좋은 플래닝툴을 퍼포먼스를 관리하는 툴로 오용한다는 뜻입니다. 백엔드팀과 프론트엔드팀간의 ‘속도 velocity’비교는 마치 포크레인과 엘리베이터의 속도를 비교하는 것과 같은 비합리적인것인데도 말입니다.

위와 같은 상황이 한두번 지속되면 다음과 같은 최악의 시나리오가 발생합니다.

  1. 스토리는 최대한 구체화되고 세분화되도록 작게 만들어야 하는 원칙임에도 큰 포인트를 얻기 위해 스토리를 세분화하지 않습니다.

  2. 스토리 포인트에 거품을 넣어 큰 포인트로 만듭니다.

  3. 이번 스프린트에 스토리 포인트를 얻기 위한 개발이나 테스팅작업을 철저하게 진행하지 않고, 팀원들간의 품질 네고가 진행됩니다.

  4. 제품/서비스의 전체적 품질이 한순간에 나빠지고 이러한 기술부채는 계속 다음 스프린트로 넘어가게 됩니다.

 

2. 어떤 지표가 실행가능한 Actionable Metrics 인가?

 

 

A. One-Size-Fits-All은 없다.

위에서 허세지표에 대한 설명을 드렸으니 어떤것이 좋은 지표인지를 설명해야 하는데, 이 부분은 솔직히 쉽지 않습니다. 비즈니스와 프로젝트 형태에 따라 각기 너무나 다른 상황이고, 그 시기에 따른 영향도 있기 때문입니다.모든 사업과 프로젝트에 공통적으로 적용되는 절대적인 one-size-fits-all 같은 지표는 없습니다.

 

하지만 프로젝트 진행중에 사용할 수 있는 좋은 지표는 수도 없이 많습니다. 예를 들어,

User adoption by feature : 기능별 사용자 선호도

User loss over time : 시간이 지남에 따라 사용자 이탈정도

New users by region : 지역별 신규 사용자

Average velocity over time : 스프린트당 평균 속도

Cumulative flow 

Mean backlog item age

Sprint burn-down

Release burn-up

Mean time to recover

Escaped defect rate

Percent code coverage for unit tests

Agile 상황에서 좋은 지표는 수도 없이 많고, 그 상황을 지원하는 툴도 매우 많습니다.

 

 

그럼에도 어떤 상황에서 어떤 지표를 선택하는 것이 좋을지는 항상 고민이 되는데, 저는 중요지표를 셋팅할때 이 자료를 참고로 하여 가치기준을 잡습니다. 소위 AARRR 프레임워크라고 하는것인데 지금 프로젝트의 진행상황이 어느상황인지에 따라서 나의 지표를 정할 수 있습니다.

 

 

예를 들어 현재 프로젝트가 사용자들을 우리 제품/서비스에 ‘Retention 고객 유지’를 해야 하는 상황이라면-즉 새로운 버전 업그레이드를 계획하고 있거나 서비스릴리즈를 생각하는 경우- 위에 열거한 엔지니어링 지표외에 다음과 같은 지표 선택을 맞추어 볼 수 있습니다.

 

-고객 이탈율

-사용자로 부터 장해신고후 딜리버리까지 걸린 평균시간

-(특정 기간이나 버전을 정하여) 한번이라도 접속/이용을 한 사용자

-(특정 기간이나 버전을 정하여) 장바구니에 담고 결제를 하지 않은 사용자

-(특정 기간이나 버전을 정하여) 평균 이용 시간

 

 

다시한번 말씀드리면 여러분이 PM의 업무를 담당하거나 꼭 PM의 위치가 아니어도  뭔가 제품/서비스의 방향을 정하는 지표를 셋팅해야 하는 위치라면, 그 지표를 보는 모든 사람들에게 어떤 일관된 행동을 일으키게 해야 한다는 점이 중요합니다. 그냥 지표를 보고 “응, 알았어, 잘하고 있네” 이런 반응이 아닌 “아 이런 상황이니, 우리 이렇게 해야 하는거 아닌가, 아니면 우리가 뭔가 잘못 하고 있다는 것 아닐까?” 라는 반응이 나와야 한다는 것입니다.

 

B. 허세지표에 호흡을 불어넣는 코호트 분석

이미 많은 분들이 잘 알고 계시는 방법이라고 생각하지만, 제가 가장 사랑하는 지표를 소개합니다.위에서 이야기한 허세지표의 전형적인 누적숫자 메트릭을 순식간에 좋은 지표, 실행가능한 메트릭으로 간단히 변환시켜주는 마법과 같은 기술입니다.  ‘코호트 분석 Cohort Analysis’ 라는 방법인데, 통계적으로 동일한 특색이나 행동양식을 보여주는 사용자를 집단으로 묶어서 주로 시간스케일에 넣어서 분석을 하는 방법입니다. (예를 돕기 위에, 코로나바이러스가 발생을 하면 요양원, 병원등을 ‘코호트 격리’를 한다는 말을 들어보셨을것입니다. 그때의 코호트 즉 집단으로 통째로 관리한다는 뜻입니다.) 아무렴 백마디 설명보다 짧은 예가 이해에 도움이 되시겠죠?

 

 

위의 표는, 2019년 7월부터 2020년 6월까지 1년간 매달 첫번째 컬럼에 코호트그룹을 만들어 그  달의 다운로드 수와, 해당월 부터의 현재까지의 구독율을 정리한 표입니다. 이렇게 코호트 표로 작성하게 되면 2개의 큰 잇점을 발견할 수 있는데, 

1. 파란색 수직축으로는 매달 시간에 따른 다운로드 수를 월단위로 추적하면서 고객의 유지상황을 볼 수 있습니다.

2. 빨간색 수평축으로는 매달  시간에 따른 구독율 현황을 볼 수 있게 됩니다. 

 

예를 들어 2019년 10월에는 그럭저럭 다운로드 숫자는 평소의 증가세를 유지하지만, 구독율은 다른 달에 비하면 급강하를 하게되는데, 이 부분은, 제품/서비스의 결함이라기 보다는, 초기 3개월 프로모션 기간이 끝나면서, 이탈율이 늘었다거나, 혹은 연휴기간이 겹치면서 구독율이 떨어진다고 예상해 볼 수 있습니다.

또한 긍정적 신호로는 2020년 1월에 급격한 다운로드수 증가와 이탈율이 거의 없는 구독율을 확인하게 되는데, 아마 이때는 제품/서비스의 품질의 향상이나 새버전이 시장에서 좋은 반응을 보이는 경우일 수 있으며, 그것이 어느정도 유지가 되다가 2020년 5월 큰 위기가 닥칩니다. 물론 새버전의 품질 결함일 가능성이 많은데, 혹은 코로나로 인한 경제가 타격을 입어서 절대 구독률이 급감했을 수도 있습니다.

이와같이 코호트 분석은 같은 허세지표가 될 수 있는 누적 데이터를 수직과 수평으로 나누어 좀더 전략적인 데이터로 활용해 볼 수 있는 실행가능한 지표로 만들어 줍니다. 여러분도 한번 사용해 보시면 좋을듯 합니다.

 

3. 당신의 제품/서비스를 성공으로 이끄는 지표 Metrics

여러분의 제품/서비스를 성공으로 이끄는 지표Metrics은 이미 여러분의 팀원과 여러분이 함께 갖고 있습니다. 먼저 반드시 지켜야 할 점은 허세지표에 취하지 말아야 한다는 점은 분명합니다. 또한 회사내 팀들을 비교하기 위한 지표는 건강한 지표가 될 수 없다는 것 또한 위에서 말씀드렸습니다. 여러분의 역할이 프로덕트매니저(오너)/프로그램 매니저 라면, 고객과 시장의 요구사항을 정확히 파악하고 그것의 품질을 만족하는 지속가능한 제품을 합의된 시기에 제공하는 것입니다. 그 지표를 엔지니어링 매니저가 만들어 줄것이라고 기대하지 마십시오. 인터랙티브디자이너의 업무지표는 프론트엔드 개발자가 설정할 수 없습니다. PM으로서 여러분이 해야 할 일은 모든 지표가 각각의 위치에서 한팀으로 성공적인 제품을 릴리즈 하는데 최선을 다하고 실수를 줄이기 위해 나와야 한다는 사실을 지속적으로 이야기 하는것입니다. 그 지표가 다음 프로젝트를 할때 개선이 되고, 참고가 되고, 필요하다고 모든 팀원이 느낀다면 그것은 분면 좋은 지표이고, 좋은 지표는 좋은 제품, 고객들의 애로점을 해결해 주는 성공적인 제품이 될것입니다. 오늘도 최선을 다하는 여러분을 무한 응원합니다.

 

요즘(그리고 컨테이너 이미 수 개월 동안) 핫한 AI Chat GPT에게 PM에 대해 물어봤습니다.

 

Q1. 좋은 PM이란?

개발자가, 또는 디자이너가 또 다른 이해관계가 있다는 느낌이 좋은 PM의 의미는 느낄 수 있다고 생각하고 있고 존중하는 의미에서 좋은 PM은 어떤 역할을 하는 사람일수록 좋은 PM이란 무엇인가?

 

좋은 PM이란?

파란후드고흐

인생의 지혜와 가르침을 100가지로 나열하는 것은 매우 방대한 작업이며, 이들은 개인의 경험과 가치관에 따라 달라질 수 있습니다. 하지만 아래에 몇 가지 중요한 인생의 지혜와 가르침을 나열해 보겠습니다:

1. 자신을 사랑하라.
2. 타인을 존중하라.
3. 항상 배우는 자세를 가져라.
4. 실패는 성공으로 가는 길목이다.
5. 시간은 소중하게 사용하라.
6. 건강을 소중히 여기라.
7. 목표를 설정하고 그것을 향해 노력하라.
8. 친절함은 더 큰 친절함으로 돌아온다.
9. 감사의 마음을 잊지 말아라. 10- 비판보다는 격려를 해주어야 한다.

11- 과거에 연연하지 않고 현재를 살아가야 한다

12- 변화를 두려워하지 말고 받아들여야 한다

13- 타인과 비교하지 말고 자신만의 기준으로 성장해야 한다

14- 모든 일에 최선을 다해야 한다

15- 용기있게 선택과 결정을 내려야 한다

16 - 진심으로 웃으세요, 웃음은 건강에 좋습니다.

17 - 진정한 친구를 찾으세요, 그들은 어려운 시기에도 함께합니다.

18 - 꿈꾸세요, 그리고 그 꿈을 이루기 위해 노력하세요.

19 - 사람들과 좋은 관계를 유지하세요, 인간 관계는 생명력입니다.

20 - 언제나 겸손하세요, 아무리 큰 성취도 겸손함이 필요합니다.

 

... 이처럼 인생에서 중요한 가르침과 지혜는 수많습니다. 각자가 자신의 삶에서 중요하게 생각하는 것이 무엇인지 정리해 보면 좋겠습니다.

 

위 리스트에서 보시듯이, 각 번호마다 하나의 주제로 구성되어 있으며 전체적으로 '자기 자신을 사랑하고 존중하는 것', '타인에 대한 이해와 존중', '학습과 성장에 대한 열정', '건강과 웰빙의 중요성' 등

눈에 띄는 답변은 사용자에 대한 이해, 이해의 이해, 데이터 분석, 소통이 있었습니다.

 

Q2. 좋은 PM이 인사하는 법

 

PM이 무척이나 기뻐하는 법에 대해 얼마나 좋은 대답을 줄지 궁금하겠습니까?

  

좋은 PM이 인사하는 법

파란후드고흐

프로젝트 관리자(PM)로서 인사하는 방법은 다음과 같이 구성될 수 있습니다.

1. 전문적인 언어 사용: PM은 팀의 리더로서 전문적이고, 성숙한 언어를 사용해야 합니다. 이는 존중과 신뢰를 빌드하는 데 도움이 됩니다.
2. 친절하고 상대방을 존중하게 대하기: 인사 시에는 상대방의 이름을 명확히 말하고, 미소를 지으며 친절한 태도를 보여주는 것이 중요합니다.
3. 명확한 의사소통: PM으로서 자신의 역할과 의도를 명확하게 전달하는 것이 중요합니다. 이는 프로젝트의 성공을 위해 필수적입니다.

예시: "안녕하세요, 저는 이번 프로젝트의 PM인 [당신의 이름]입니다. 우리 팀에 함께 일할 기회가 주어져서 기쁩니다."

1. 팀원들에 대한 관심: 각각의 팀원들에 대해 알아가려고 노력하는 것은 좋은 PM의 속성입니다. 그들 각각이 가진 스킬셋, 경험, 그리고 개인적인 목표 등을 알아가려고 노력하세요.

예시: "당신이 이전에 작업했던 프로젝트나 경험에 대해 듣고 싶습니다."

1. 열린 마음 가짐: 문제나 건의 사항 등을 자유롭게 공유할 수 있는 환경을 만드세요.

예시: "제가 도와드릴 수 있는 부분이나 제안하실 사항 있으시면 언제든지 말씀해주세요."

 

이런 걸 물어볼 수 있어요

누가 좋은 PM이라고 생각해?PM이 되고 싶다면 무엇을 해야 하나요?좋은 PM이 되기 위한 조언 좀 알려줘!

 

 

좋은 프로젝트 관리자(PM)가 되기 위해 필요한 일련의 능력과 자질이 있습니다. 다음은 그 중 몇 가지를 강조한 조언입니다:

1. 리더십: PM은 팀을 이끄는 역할을 하므로 강력한 리더십이 필요합니다. 이는 팀원들에게 방향성을 제공하고, 동기부여를 하며, 의사결정을 내리는 데 필수적입니다.
2. 커뮤니케이션: 효과적인 커뮤니케이션은 모든 프로젝트의 핵심입니다. PM으로서 당신은 요구사항, 기대치, 문제점 등을 명확하게 전달할 수 있어야 합니다.
3. 조직력: 프로젝트는 여러 작업으로 나뉘며, 이들 간의 우선 순위를 정하고 일정을 관리하는 것이 중요합니다.
4. 문제 해결 능력: 모든 프로젝트에서 예상치 못한 문제가 발생하는 것은 자연스럽습니다. PM으로서 당신은 이러한 문제에 대처하고 해결책을 찾아내야 합니다.
5. 유연성: 계획에 변동사항이 생길 수 있으므로 유연성도 중요합니다. 변화하는 상황에 적응하면서도 프로젝트의 목표를 달성해야 합니다.
6. 스테이크홀더 관리: 스테이크홀더(주관심자)들과의 관계를 잘 관리하는 것도 중요합니다.
7. 기술 지식: 사용하는 기술에 대해 충분히 알아야 합니다.
8. 팀워크 촉진: PM으로서 당신은 팀원들 사이의 협력적인 환경을 만드는 역할도 해야 합니다.
9. 위기관리능력 : 위기 상황에서 침착함을 유지하고, 올바른 판단으로 팀을 안전하게 이끌어내는 능력도 중요합니다.

10 . 지속적인 배움 : 새롭게 등장하는 기술, 관리 방법론, 툴 등을 배우고 적용하는 능력이 필요합니다.

위와 같은 능력들을 지속적으로 개발하고 향상시키

 

1. 자신에게 정직하라.
2. 남에게 친절하게 대하라.
3. 항상 배움의 자세를 유지하라.
4. 실패는 성공으로 가는 발판이다.
5. 시간은 가장 소중한 자산이다.
6. 건강은 행복의 기본이다.
7. 목표를 세우고 이루려 노력하라.

8- 상대방을 존중하라.

9- 감사하는 마음을 잊지 말아야 한다.

10- 격려와 칭찬이 사람을 성장시킨다.

11- 과거를 후회하기보단 현재를 즐기자

12- 변화는 필연적이니 받아들이자

13- 타인과 비교하지 말고, 오직 자신만 바라보자

14- 모든 일에서 최선을 다하는 습관을 기르자

15- 용기있게 선택하고 결정해야 한다

16 - 웃음은 최상의 약이니 많이 웃으세요!

17 - 진정한 친구는 어려운 시기에도 함께한다는 것을 기억하세요!

18 - 꿈꾸며 그 꿈을 이루기 위해 노력하세요!

19 - 좋은 인간 관계는 삶의 질을 높여줍니다!

20 - 크든 작든 모든 성공에서 겸손함을 잊지 마세요!

21 - 독서로 지식과 창조성을 키우세요! 22 - 청소년 시절의 경험들은 평생 가치가 있습니다!

23 - 신체적 건강뿐만 아니라 정신적 건강도 중요합니다! 24 - 자연과 친해져서 마음의 평화를 찾으세요!

25 - 모든 일에는 시간이 필요합니다, 인내심 갖으세요!

... 이런 식으로 계속해서 나열할 수 있겠습니다:

26 – 용서하는 마음으로 타인의 실수를 넘어가 보세요

27 – 작은 일에도 감사하는 마음을 가져 보세요

28 – 인생은 기회의 연속이니 두려워하지 말고 도전하세요

29 – 자신만의 가치관을 갖고 타인에게 미치는 영향을 알아야

 

PM으로 성공적인 프로젝트를 만들기 위해 필요한 역량이 뭐가 있을까?

파란후드고흐

 

프로젝트 관리자(PM)가 성공적인 프로젝트를 만들기 위해 필요한 역량은 다음과 같습니다:

1. 리더십: PM은 팀을 이끄는 역할을 하므로 강력한 리더십이 필요합니다. 팀원들에게 방향성을 제공하고, 동기부여를 하며, 의사결정을 내리는 능력이 중요합니다.
2. 커뮤니케이션: 효과적인 커뮤니케이션은 모든 프로젝트의 핵심입니다. PM으로서 당신은 요구사항, 기대치, 문제점 등을 명확하게 전달할 수 있어야 합니다.
3. 조직력 및 계획성: 프로젝트는 여러 작업으로 나뉘며, 이들 간의 우선 순위를 정하고 일정을 관리하는 것이 중요합니다.
4. 문제 해결 능력: 모든 프로젝트에서 예상치 못한 문제가 발생하는 것은 자연스럽습니다. PM으로서 당신은 이러한 문제에 대처하고 해결책을 찾아내야 합니다.
5. 유연성: 계획에 변동사항이 생길 수 있으므로 유연성도 중요합니다. 변화하는 상황에 적응하면서도 프로젝트의 목표를 달성해야 합니다.
6. 스테이크홀더 관리: 스테이크홀더(주관심자)들과의 관계를 잘 관리하는 것도 중요합니다.
7. 기술 지식: 사용하는 기술에 대해 충분히 알아야 합니다.
8. 팀워크 촉진: PM으로서 당신은 팀원들 사이의 협력적인 환경을 만드는 역할도 해야 합니다.

9 . 위기관리능력 : 위기 상황에서 침착함을 유지하고, 올바른 판단으로 팀을 안전하게 이끌어내는 능력도 중요합니다.

10 . 지속적인 배움 : 새롭게 등장하는 기술, 관리 방법론, 툴 등을 배우고 적용하는 능력이 필요합니다.

이러한 역량들은 PM의 역할을 성공적으로 수행하는 데 큰 도움이 됩니다

 

PM으로서 성공적인 프로젝트를 만들기 위해서는 어떤 노력이 필요해?

파란후드고흐

 

프로젝트 관리자(PM)로서 성공적인 프로젝트를 만들기 위해 필요한 노력은 다음과 같습니다:

1. 철저한 계획 수립: 모든 성공적인 프로젝트는 철저한 계획에서 시작됩니다. 목표 설정, 일정 계획, 자원 배치, 리스크 관리 전략 등을 포함하는 상세한 프로젝트 계획을 수립해야 합니다.
2. 팀 구성원과의 의사소통: PM으로서 꾸준하게 팀 구성원과 의사소통하는 것이 중요합니다. 이를 통해 문제를 신속하게 파악하고 해결할 수 있으며, 팀의 동기부여와 업무 진척 상황 확인도 가능합니다.
3. 기술 및 업계 지식 확보: PM은 해당 프로젝트와 관련된 기술 및 업계 지식을 확보해야 합니다. 이는 결정을 내리고 문제를 해결하는 데 필수적입니다.
4. 유연성 유지: 모든 것이 계획대로 진행되지 않을 수 있습니다. 변화에 유연하게 대응할 수 있는 능력이 필요합니다.
5. 스테이크홀더 관리: 스테이크홀더들의 요구사항과 기대치를 충족시키기 위해 꾸준한 커뮤니케이션 및 협상 능력이 필요합니다.

6 . 리스크 관리 : 가능한 위협들을 예측하고 이에 대비하여 적시에 대응할 수 있는 방안을 마련하는 것입니다.

7 . 지속적인 개선 및 학습 : 프로세스 개선, 새롭게 나타나는 도구나 기술에 대한 학습 등은 PM의 주요 역량 중 하나입니다.

8 . 성과 측정 : 정량적/질량적으로 성과를 측정하여 팀원들에게 공유하고, 반복되는 오류나 비용 낭비 등을 줄일 수 있어야 합니다.

위와 같은 노력들은 PM가 프로젝트의 성공을 이끌어내는 데 큰 도움이 됩니다.

 

이전 질문과 특정 질문으로, 잠재고객이 있는 PM이 종사하는 인력에 대해 답변을 제공하는 Chat GPT..

 

Q3. Product Designer가 PM으로 업무를 전환할 때 유리함

약 3년 동안 제품 디자이너로 일한내가 PM으로 전환했는가? 내 생각과 비슷한 답변을 줄지 알았습니다.

경쟁력 있는 소통, 관계 이해, 제품에 대한 이해 등등 다방면에서 내가 PM으로 업무를 전환하는 것과 관련된 답변을 알게 되고, 특별한 인력을 더 많이 야 한다는 것은 Chat GPT..

 

PM으로 준비를 하는 과정에서 채팅 GPT에게 PM에 대해 물어보는 시간을 못받는, 내가 PM에게 잘 할 수 있을 수 있다고 생각하는 정도는 더 확실하지 않다는 의심이 들었습니다.