프로그래머들에게 인기 있는 프로덕트 매니저가 되는 방법

주제. PM의 경우 대부분 인문학 배경을 갖고 있으며 경험을 공유하는 경우가 많지만(RD는 일반적으로 PM을 바보라고 직접 부릅니다) 지식 체계와 사고 습관을 고려하면 이러한 공유의 대부분은 영양가가 없고 부족합니다. 참조 값.

저는 업계에 들어오면서부터 프론트라인 개발을 해왔는데, 프론트엔드이고, 사용자에게 가깝고, 제가 하는 일의 대부분이 인터페이스와 상호작용을 중심으로 이루어집니다. 사업을 시작한 지 2년 동안 '프로덕트 디렉터'로 활동하며, 프로덕트 매니저로서 자체적인 요구사항을 충족시키기 위한 개발도 하고 있습니다. 다음으로 RD들에게 인기 있는 PM이 되는 방법을 알려드리겠습니다.

어리석음은 이제 안녕

많은 PM의 가장 큰 문제는 자신도 모르게 바보가 된다는 것입니다.

현재 대부분의 RD는 전문적인 배경을 갖고 있으며 체계적인 컴퓨터 관련 지식과 기술 훈련(학교 및 자발적 포함)을 받았습니다. 그들은 일반적으로 약간의 논리적 사고를 가지고 있습니다. 인간과 컴퓨터의 상호 작용도 필요하지 않습니다. 제품 관리자는 각계각층에서 왔으며 지식, 기술 및 도구에 대한 통일된 표준이 부족합니다. 이 경우 RD가 어느 정도 우월감을 갖는 것은 정상입니다. 정리하자면, 초기 상태에서 RD가 보기에 PM은 이렇습니다.

학력, 학습능력, 공부습관에 문제가 있지만 말이 너무 많아요

사용(모바일인터넷)제품이 내것(집...)만큼 좋지 않고, 경쟁제품에 대한 관찰도 내것만큼 세밀하지 못하다(카피하고 싶은 제품을 반년 넘게 써왔다) 년)

황제의 칙령을 속이고 호랑이의 힘을 속인다

특히 많은 PM은 RD와 대화할 때 "내 생각엔..."이라는 문장 패턴을 사용하는 것을 좋아합니다. 어려움이 있으면 추가 논의를 위한 데이터나 경쟁력 있는 제품 디자인을 제시하지 못하는 경우가 많습니다. "언제나 누군가는 있을 겁니다..." "나 같은 사람은..." 또는 "내 생각엔..."이라고 계속 말할 수밖에 없습니다. 그들은 한 가지 문제를 무시했습니다. 모든 사람의 운명은 제품과 밀접한 관련이 있습니다. 제품에 대한 RD의 관심과 감성은 PM 못지 않습니다. 제품에 대한 RD의 기대치는 PM의 기대치보다 낮지 않습니다. 이때 PM이 좋은지 나쁜지 불분명한 작품, 심지어 엉뚱한 디자인의 작품을 가져오면 당연히 보이콧되거나 부정적인 대우를 받는 것이 당연하다.

멍청해 보이는 것을 어떻게 피할 수 있나요? 사실 복잡하지 않아요.

더 경쟁력 있는 제품과 더 많은 인터넷 제품을 사용하세요. 방법이 없습니다. 이 밥 한 그릇을 먹으려면 투자를 해야 합니다. 인터페이스 상호작용의 새로운 트렌드와 새로운 시도를 항상 파악하세요.

데이터를 찾을 수 있다면 최대한 많은 데이터를 활용하세요.

직접 협력하는 RD 외에도 몇 명의 RD 친구를 사귀어 보세요. 요청하기 전에 그들에게 개발 비용을 평가하는 데 도움을 요청하세요. 그러면 자신의 RD와 소통할 때 더 많은 준비가 될 것입니다. .

PM은 자신의 전문적 권위를 확립하고 이러한 요구가 유익하고 효과적이며 자신에게 보너스를 가져올 수 있다는 점을 RD에게 설득해야 합니다. 그러면 적극적인 협력이 당연히 필요합니다.

RD에 대한 이해

모든 사람에게는 자신만의 작은 행운이 있으며 RD도 예외는 아닙니다.

코드를 명확하고 읽기 쉽고 확장하기 쉽게 특정 패턴을 사용하여 교묘하게 재구성했을 수도 있습니다.

우연히 발생한 규칙일 수도 있습니다. ;

아마도 새로운 기술을 배우고 새로운 프레임워크를 찾는 것일 겁니다...

RD를 이해한다는 것은 그 이후를 이해하는 것입니다. 주변의 작은 축복을 발견하고, 만족할 수 있는 충분한 공간을 제공하십시오. 예를 들어 프로젝트 일정을 너무 꽉 채우거나 RD가 자발적으로 제기한 요구 사항을 포함하도록 기능 요구 사항을 적절하게 조정하지 마십시오.

또 다른 부드러운 이해는 방해하지 않는 것입니다. 일부 PM은 프로젝트 배경을 통제하거나 갖고자 하는 강한 욕구를 갖고 있으며 "진행 상황 수정"에 열중하고 있어 진행 상황이 옳든 아니든 진행 상황은 여기에 있으며 전진하거나 후퇴하지 않습니다. . 프로그램 개발은 선형적이지 않으며, 시간당 12.5시간, 하루 100시간이 아니며, 200줄을 쓰고 또 200줄을 쓰고 완료되는 것도 아닙니다. 그것을 끝내는 데 시간이 얼마나 걸릴까요?

심지어 일부 PM은 유통기한이 지난 닭고기 수프를 마신 적도 있습니다. 그들은 실제로 끈질기게 인내심을 갖고 질문을 계속한다면 RD의 진행에 대한 합의에 도달할 수 있다고 생각합니다. RD는 그들이 절망적인 바보일 뿐이라고 확신했습니다.

마지막 이해는 'PM이 말을 하면 RD가 다리를 부러뜨린다'는 것이다. 이것을 이해할 수 있다면 다른 모든 것도 더 쉽게 이해할 수 있을 것입니다. 모든 요구 사항에는 개발 비용이 있습니다. 기술적인 배경이 부족한 PM은 물론이고 다른 RD인 경우에도 이 개발 비용을 정확하게 추정하지 못하는 경우가 많습니다. 따라서 많은 PM은 신중한 고려 없이(또는 분명히 상위 PM과 논의하지 않거나 다른 수요 당사자와 확인하지 않고) 매우 캐주얼하게 요구 사항을 제시합니다. 변경 사항은 훨씬 더 캐주얼하며 다음 문장이 동반되는 경우가 많습니다. You just do it, 아주 간단해요. "솔직히 말하면 RD가 이 말을 듣고 당신을 죽이려고 칼을 꺼내지 않았다는 건 당신을 사랑한다는 뜻이에요. 개선하고 싶다면 작업을 시작하기 전에 더 많이 소통하여 재작업 가능성을 줄이고, 요구할 때 RD의 판단을 존중하고, 작업을 시작한 후에도 계획을 유지하도록 공동으로 노력하십시오.

RD를 이해하는 PM이 정말 매력적이에요.

오해 방지

첫 번째 오해는 말도 안되는 말을 하는 것입니다.

이 글을 쓰기 위해 간단히 '제품관리자 자가 재배'를 구글링하다가 영혼을 위한 닭국물을 많이 발견했습니다. 이러한 기사는 거의 "가짜이고 공허한" 제품 관리자의 대표작으로 간주될 수 있습니다. 업계에 많은 신규 이민자를 오도하는 것은 이러한 기사입니다.

가끔 RD를 처리해야 하는 PM으로서 그는 실용적이어야 하고, 그의 아이디어는 구현되어야 하며, 그가 제안하는 것은 구체적인 구현 세부 사항과 고려해야 할 표준이 있어야 합니다. 그것에 대해 너무 많이 이야기하면 안 되고, 매 단계마다 전략적 계획을 세우고, 매 단계마다 명사('파괴적 혁신')를 사용하고, 매 단계마다 유명한 인용문을 인용하면 안 됩니다. 우리의 목적은 간단하고 통합되어 좋은 제품과 운영을 만들고, 사용자 경험을 개선하고, 사용자를 확보하고, 활성 사용자를 늘리고, 최종적으로 트래픽으로 수익을 창출하고 모든 사람과 돈을 공유하는 것입니다. 그 사이에 필요한 것은 연이은 구체적인 요구, 연이은 지속적인 개선, 통계적 포인트의 합리적인 계획, 데이터를 기반으로 하는 모든 선택 단계입니다. 그리고 앞서 언급했듯이 RD는 멍청할 수도 있지만 실제로는 매우 똑똑하고 우월감이 있습니다. 실제 정보를 제공하지 못하고 말에만 의존하는 PM은 곧 신뢰할 수 없는 사람으로 분류됩니다.

두 번째 오해는 우리가 팀이라고 말한 결과가 잘못 표기되었다는 점이다.

상사나 리더가 만족스럽지 못한 요구를 내놓고 총리에게 이를 전달하는 경우가 흔하다. PM은 RD에게 “나는 하기 싫은데 상사가 고집한다”고 조언한다. 앞서 말했듯이 PM이 움직이면 RD가 다리를 잃게 되고, 최종 개발 비용은 RD가 부담해야 하므로 사장님을 설득할 수는 없지만 쓴 열매를 맺어야 한다. 그러니까 우리가 한 팀이라고 말하지만 사실은 나를 배신하고 있는 거잖아... 리더나 상사를 먼저 설득하려고 노력하는 게 올바른 방법이 아니라면, 상사의 뜻을 이해하고 RD를 설득하려고 노력하는 거야. 동시에 적시에 프로젝트 진행 상황을 수정하십시오.

요약

사실 PM과 RD는 적이 아니다. 오히려 그들의 사활적 이해관계는 밀접하게 연관되어 있다. PM들이 유능한 RD를 찾기를 희망하는 동안, 수많은 RD들 또한 하나님께서 그들에게 믿음직한 PM을 주시기를 바라고 있습니다. 대부분의 RD는 자신을 표현하는 데 능숙하지 않고, "평신도"와 말도 안되는 이야기를 하기에는 너무 게으르기 때문에 PM에 대해 무관심하거나 심지어 적대감만 나타내는 경우가 많습니다. 사실, 그들이 기능을 수행하기를 꺼린다거나 변화를 받아들이지 않는다는 것이 아니라 좀 더 명확한 이유가 필요할 뿐입니다.

RD의 신뢰를 얻은 후에는 쉽게 친해질 수 있다는 것을 알게 될 것입니다. 위의 사항을 준수하는 한 RD의 환영을 받는 것은 불가피합니다.