ご存知のように、プロダクトマネージャーは非常に辛辣な役割で、どのような役割にも対応しなければならないほど辛辣で、こちら側では調整し、あちら側では懇願しなければならず、多くの人が深く理解していると思います。しかし、私たちは皆プロダクトチームのメンバーであり、お互いに協力し合ってプロダクトの目標を達成するためには、お互いの距離が近く、協力の障害となるものがなく、またお互いに我慢と寛容が必要です。したがって、私たちはただプロダクトマネージャーに開発スタッフを収容するように求めることはできません、誰もが自分の個性を持って、開発者もプロダクトマネージャーを収容する必要があり、お互いから一歩後退、海は広いです。
[]
プロダクトマネジャーが最も望むことは、製品の意図が完全に実現され、PRDのビジョンに沿って、一歩一歩少しずつ達成されることです。PRDレビューでは、チームメンバーが意見を出すこともできますが、最終的にはプロダクトマネージャーが最終決定をしなければなりません。特にプロダクトマネージャーは、チーム、把握の製品レベルに責任がある、プロダクトマネージャーは、製品が達成するためにステップバイステップで計画に従うことができることを確認するように、決定を下す権利を持つ必要があります。製品の指示の開発者は、開発プロセスでは、自分のアイデアの多くに参加する場合は、物事のケーキの上のアイシングに追加された場合、製品の機能構造の混乱の場合には、大丈夫ですが、間違いなく、製品全体の計画に影響を与える、間違いなくプロダクトマネージャーは非常に落ち込んでいるようになり、さらには全体の製品チームのパフォーマンスに影響を与えます。
諺にもあるように、聴覚の順序があり、専門分野があります。我々は、すべての自分の仕事を行うには、それぞれのプレーの最良の部分は、あなたがより多くの干渉の分野で自分の良くないのではなく、製品に大きな助けを持つことができます。私は多くの開発者がプロダクトマネージャーになる可能性があることを認める、確かにプロダクトマネージャーの数は技術的な起源である、私自身がありますが、あなたが仕事を変えていない場合は、まだ自分の役割を果たす必要があります、プロダクトマネージャーは、主に製品の企画設計を担当している、開発者は実装を担当しています。これはまた、開発者のどのような種類は、製品マネージャーの好みのトピックである誰かを持っています。
*** は体験型
時間をかけて製品設計の考え方や意図を理解したことを証明する質問があるのは良いことで、開発者がビジネスに精通し、自身のレベルアップにもつながります。プロダクトマネージャーの責任体制は、決して「ワンボイス」で関わるのではなく、不一致の場合だけでなく、****決定権を持つ非常に民主的なものです。この時の製品チームは、PRDの強固な実装であることであり、改ざんする開発プロセスで懐疑的な態度を保持することはできません。
本心でないことを言う人は嫌いです。
製品の要件の議論では、我々はすべて同意したときに、***開発は全く別の話の発見のうち、この時間は最も落ち込んでいるプロダクトマネージャーは、自分のデザインは、他の人によって変更されただけでなく、プロジェクトの全体的な進捗状況に影響を与える、言うだけでなく、リファクタリングに時間を費やすために。長い時間滞在する製品チームでは、開発者の学習能力の多くは、製品やビジネスの特定の洞察力と自分の理解を形成するために責任を負うことになり、この理解は、時には開発者がすぐに新しい要件を理解するのに役立つ良いことですが、時には悪いこと、それは先入観は、開発者が非常に多くのコンテンツで遊んで、彼はすでにマスターしていると思うようになりますし、自分のアイデアのいくつかを生成し、製品にこれらのアイデアを追加します。彼は自分自身のアイデアをいくつか得て、それを製品に加えるでしょう。これは一番やってはいけないことです。
つまり、開発者がプロダクトマネージャーを踏み倒して、ビジネス担当者とコミュニケーションを取り、ビジネス担当者が迅速に対応する要件を達成できるように手助けさえすれば、自分たちは初見の要件を持っていると考えることは、非常に悪い状況です。彼らの知らないところで、初見の要求のほとんどは使い物にならず、変換する必要があり、ほとんどのユーザーは自分のニーズを明確に表現することができず、日常業務をそのように表現することしかできません。あなたが達成するために、この方法で行く場合は、製品は、オンラインのオフラインの操作だけで、製品の企画を話すことはありません、また、ビジネスロジックを満たしていません。そうすることは、PRDを空にしているに等しく、PRDを完全に飾りとして扱い、非常に望ましくない行動です。
開発者が持つべき能力
最も基本的なのは、技術のレベルです。開発者は、技術を勉強しないように、新たな技術を学び、最終的に淘汰される、IT業界は最速の更新業界であり、常に新しい技術、新しい概念があり、時代と歩調を合わせていない放棄されます。そしてまた、技術は底なしの穴であり、より詳細な研究内容は、より多くの、特定の技術に精通し、わずかにNの技術を知っているよりも、より貴重になります。時には、実務経験の長さは、技術的な能力を表していない、キーはまだ彼らが研究する意思があるかどうかを確認することです。間違いなく、プロダクトマネージャーは技術力の高い開発者を好みます。
技術的なアーキテクチャ能力：PRDは製品要件を明確に表現しているだけで、技術的な設計レベルは依然として開発者の設計に依存しています。システムの拡張性と安定性は、技術的なアーキテクチャが合理的かどうかによって決まります。良いアーキテクチャーは、製品が常に変化する能力を持つことを可能にします。このような構造は間違いなく、より高く評価されます。
論理的思考能力。主にコードのロジックが厳密で、特に条件判断が多い場合、私たちは皆、ifとelseを知っていますが、andとorも知っていて、どのように製品のビジネスロジックとプロセスロジックを満たすために組み合わせのうち、さまざまな条件でそれらを作るために、開発者が考慮することです。これは、バグの数に似ています。
コミュニケーション能力。製品チームの任意のメンバーは、良好なコミュニケーションスキルを持っている必要があります、少なくともあなたが言いたいことを明確に表現する必要があり、半日を言うことができない、人々はあなたが話しているのか把握させることはできません。例とのコミュニケーションは、より効果的である、あなたは、PRDの設計に従うことができるプラス例、プロダクトマネージャが理解するのが最も簡単であるように、疑いの設計を表現するために。しかし、その前提としてPRDをきちんと読まなければなりません。文書を読まずにいきなり質問攻めにしても、人を憤慨させるだけです。
プロダクトチームの中で、プロダクトマネージャーと開発者が仲が良く、協力し合って仕事をすることは、プロダクトの成功を強く保証するものです。逆に、両者が矛盾していれば、何も生まれません。したがって、プロダクトマネージャーと開発者の関係は常に頭痛の種であり、ほとんどの場合、妥協と協力でプロダクトマネージャーに、ここで、私はまた、開発者が同情し、プロダクトマネージャーと協力することができます願っています。
