プロダクト マネージャーはスケジュールの問題についてエンジニアとどのように連絡を取りますか?

たとえば、何かを開発する必要がある場合、エンジニアは次のように言います: 30 日
なぜ 30 日なのか尋ねると、作業量が膨大であると答えるでしょう。
本当に 30 日かかるかどうかを判断するにはどうすればよいですか? (専門家ではないが) それが必要ないと思う場合、どうやってエンジニアとコミュニケーションをとることができますか?

返信内容:

ご招待いただきありがとうございます。

通常、エンジニアの発言に責任を負わせれば、責任ある答えが得られるでしょう。

率直に言って、この質問を見たとき、おそらく私は悪意のある推論をしたのではないかといつも感じています。彼は自分自身とエンジニアを上流と見なしている潜在意識を持っています。エンジニアと建設期間との関係を考慮し、見積もりを自分自身に対する約束として扱います。 「30日以内にお渡しできます。」 「いいえ、15日以内に欲しいです。」 これはコミュニケーションではありません。これは当事者間の交渉です。タオが間違っているなら、芸術を追求することに何の意味があるでしょうか？

製品の要件を正確に定義することが難しいのと同様に、工期を正確に見積もることは困難です。これら 2 つの問題を解決すると主張するいくつかの方法やツールを見てきましたが、
(1) それら自体が追加コストをもたらし、多くの場合、受け入れられないほど大きすぎます
(2) さらに重要なこと: これらは次の場合に効果的です。

エンジニアが通常の建設時間を見積もると、時間通りに完了しない可能性が非常に高くなります。そして、期限までに終わらせないとトラブルが起きる可能性があるので、自分の身を守るために十分な時間を与えてくれるのは当然です。

本当に効果的な方法は、将来の紛争の証拠にならないようにお互いにコミュニケーションをとることです。これは、最も信頼できる情報を入手し、正しい判断を下すのに役立ちます。もちろん、正確であることは依然として不可能ですが、インターネット自体は不確実性に満ちており、それがインターネットの魅力でもありますが、それが許容できない場合でも、建設期間の不確実性はこの「大きな不確実性」のごく一部にすぎません。総生産マネージャーとして働いています。 同様の質問への回答、元のリンク: プロダクト マネージャーはプロジェクト開発時間を合理的に見積もるにはどうすればよいですか?
====================リンクをクリックするのが面倒な学生の便宜のために、以下をここにコピーします== ====

プロダクト マネージャーがプロジェクトの開発時間をより正確に見積もろうとする場合、最も重要な 3 つの要素は、経験、プロフェッショナリズム、コミュニケーションです。
プロジェクトのライフサイクルを見積もる場合、経験ほど正確なものはありません。たとえば、以前に同様のプロジェクトを行った場合、今回のプロジェクトが同じ規模で、同じ品質要件があり、同じエンジニアのグループ（少なくとも同じレベル）であれば、1 か月かかりました。 )、このプロジェクトにはほぼ 1 か月かかります。
なぜそこまで経験に頼るのですか?プロジェクト サイクルのせいで、エンジニアがコードを書き、デザイナーが絵を描く時間に加えて、要件について議論するのに費やした時間、サーバーのアップロード速度が遅いために失われた時間、上司の気が変わり、再作業に必要な時間、バグ修正に必要な時間、ワークステーションが保存せずにクラッシュした場合の再作業に必要な時間などに加えて、これらの時間は公式を使用して計算するのが難しく、それに基づいて推定することしかできません。経験上。したがって、実行するプロジェクトが多ければ多いほど、時間の見積もりはより正確になります。
次にメジャーを使用します。計算式で計算できない時間や経験が必要な時間はたくさんありますが、それでも労働時間の中には「計算式」で計算できる部分（そしてその割合は小さくありません）もあります。この「公式」をマスターしたい場合は、それに対応する専門知識をマスターする必要があります。この専攻はプロダクトマネージャーの専攻ではなく、関連リンクの専攻です。たとえば、フロントエンド エンジニアに純粋に静的なページを切り取って、JS 特殊効果を追加するように依頼した場合、JS 特殊効果がフローティング レイヤーをポップアップするか、Ajax をドラッグするかによって、かかる時間は確実に異なります。時間も異なります。これらのさまざまな要件に対処するのにどれくらいの時間がかかるかを理解する必要があります。時間を短縮しながらニーズを満たす方法はありますか? (方法の詳細を知る必要はありません)。これはプロジェクト時間を計算するためにも必要です。
最後はコミュニケーションです。最初の 2 つの項目をマスターしないと、コミュニケーションの基盤がありません。エンジニアは高すぎる価格を要求しますが、エンジニアの目にはあなたは気まぐれな存在になります。 。適切な時間がどれくらいかを大まかに知っていて初めて、コミュニケーション スキルを活用してエンジニアを説得して、より適切な時間内でプロジェクトを完了させることができます。 自分の力を発揮したい急進的なプログラマーの場合、最終的にオンラインになれる時間を決定するには、楽観的に見積もった時間を 3 倍する必要があります。

経験豊富なプログラマは、開発中に困難な技術的問題や変更要件に対処するための時間をより確実に見積もることができ、それらを解決するために残業することができます。遅延による士気への深刻な打撃を避けるため。

したがって、工期の見積もりは開発者の性格や経験に関係するものであり、これを区別するには開発チームとの長期的な協力の暗黙の了解が必要です。

初期の推定労働時間は、胸をなでながら「これは要件の最終版であり、今後変更されることはありません」と言う人たちと同じくらい信頼性が低いです。

唯一確実なことは、進捗状況を毎日連絡し、少なくとも隔週で残りの作業量を再評価し、スケジュールを修正するか、開始時刻を変更する必要があるということです。

時間を大切にしたいなら、最も役立つのは、要件をできるだけ早く設定して、プロジェクトの時間管理の本質です。日々のコミュニケーションと継続的な評価において。

1. 大きなタスクを小さなタスクに分割し、個別に評価します。
2. 複数のエンジニアを組織して同時に評価し、平均値を取得します。
3. 最後に 1/3 の余白を残しておいたほうが安全です。

【はじめに】
製品プロジェクトの標準的なプロセスは、大まかに市場調査と分析、需要分析と設計、技術分析と設計、コーディング開発、テスト、承認と発売、運用と保守などを経ます。 CMMI の R&D プロセスによれば、プロジェクト確立段階、要件段階、設計段階、コーディング段階、テスト段階、リリース段階の 6 つの主要な段階があります。
その内:
プロジェクトの確立と要件フェーズ、主に プロダクト マネージャーの仕事は、
設計フェーズの 2 つの側面に分かれています。 1 つは、主に UI デザイナーとプロダクト マネージャー の仕事である プロダクト UI デザイン であり、もう一方は テクニカル デザイン です。主に技術者の仕事 (アーキテクト、プロジェクトマネージャー、または直接の開発者)
コーディング段階、主に技術スタッフの仕事。
テスト フェーズは主に テスター の作業です。
受け入れおよびリリース フェーズ は主に プロダクト マネージャー 。 上記の 6 つの段階では、各段階でプロジェクト チームのメンバー間で作業が分担されます。もちろん、プロダクト マネージャーとプロジェクト マネージャーはプロジェクト プロセス全体を通して存在します (一部の企業の一部のプロジェクトでは、プロジェクト マネージャーとプロダクト マネージャーが同じ役割を担っています)。
インターネット製品は短く、迅速に反復することに重点が置かれており、構築期間は比較的短いですが、プロジェクト全体も上記の段階を経る必要があります。

[分析]
プロダクト マネージャーが製品プロジェクトに取り組む場合、工期評価は通常 2 つのカテゴリに分けられます。
1. 最初のカテゴリには期限があり、評価できるのは 1 つだけです。逆時間法に基づいています。たとえば、市場や業務からのフィードバックに基づいて、緊急の製品需要を 2 週間以内に開始する必要がある場合、製品プロジェクトの目標は、需要分析、定義、設計、その後の技術を含めて、合計で 2 週間しかかからないことが非常に明確です。設計、コーディング開発、そして最後にテストが受け入れられ、オンラインでリリースされます。したがって、既存の制限時間内で、プロジェクト チームのメンバーは実際にはスケジュールどおりに完了する以外に選択肢がありません。この場合、プロダクト マネージャーがしなければならないことは、各段階の時間比率を考慮すると同時に、プロジェクト チームのメンバーとより多くのコミュニケーションを図ることであり、時間は厳しく、仕事量が多いという現状に直面しています。スケジュール通りに目標を達成するために残業するだけです。 できる人 何も差し控えることはできません (プロジェクトの時間が非常に明確で変更できない場合、つまり、リーダーからの完全な命令であり、プロジェクト チームのメンバーはそうしなければなりません)。まだ変更がある場合は、プロダクト マネージャーはプロジェクト チームのメンバー (時間とリソース) に合理的な利益をもたらすよう努める必要があります。

2. 2 番目のカテゴリは、デッドオーダーがなく、プロジェクトの期間と各段階の作業時間が通常の研究開発プロセスに基づいて評価できることです。この場合、各段階の対応するメンバーは、対応する段階の作業を評価するために適切な時間を与える必要があります（もちろん、これは要件が確定しているという前提で評価されます）。プロダクト マネージャーが行う必要があるのは、各段階の時間比率を合理的に評価し、プロジェクト全体の期間を調整することです。この場合、各メンバーは自らが定めた労働時間に責任を持ち、その時間内に業務を完了しなければなりません。ある段階で遅れが生じると連鎖反応が起こり、放置される可能性があります。プロジェクト全体が遅延する可能性がありますが、これは通常は発生す​​ることは許可されていません。プロセス全体を通じて、プロダクト マネージャーとプロジェクト マネージャーはプロジェクト全体の進行状況を監視し、制御する必要があります。

【方法】
上記のいずれの状況であっても、プロダクトマネージャーは技術担当者の評価時間(実際には技術担当者だけではなく、各メンバーの評価時間)を信頼する必要があります。プロダクト マネージャーがしなければならないことは、すべてのメンバーの評価時間を収集し、それを予想されるプロジェクト期間と比較することです。期待を満たしており、これが最良の効果である場合は、評価時間に従って続行します。期待を満たしていない場合 (通常は期待と一致していません)、各段階の時間比率を比較検討し、再度調整します。時間。プロダクト マネージャーがこれを行うには、1 つは過去のプロジェクトの経験に基づくもの、もう 1 つは特定のプロジェクトの条件に基づくものです。
タイムリーなコミュニケーションは、プロジェクトの進行を促進するために必要かつ最も基本的な要素です。これは、プロダクト マネージャーだけでなく、プロジェクト チームのメンバーにも必要です。
プロジェクトでは、予期せぬ事態や緊急事態を恐れることはありません。恐れる場合は、自分で問題を隠し、他の人が気づくまで待ってから連絡する必要があります。プロダクト犬にせよプログラマーにせよ、聞かない、死ぬほど自分に言い聞かせない人は失格、ましてやバカなことを言うのは自分自身が反省したほうが良いです。 まず、エンジニアを信頼してください。第二に、このプロジェクトには明確な時間の予想が必要です。

成功するすべての協力は相互信頼に基づいています。このような信頼を確立します。要件は信頼でき、効果的であると信じています。この前提がなければ、協力は不幸になるでしょう。

PM がリクエストを行うときは、許容できる期限はどれくらいなのか、なぜこのタイミングなのかを自問する必要があります。次に、ニーズを伝えます。このとき、プロジェクトの青写真、期待、および必要な時点の理由を説明し、相互に有益な前提があり、それが過度すぎない場合は、説得力が必要になる場合があります。質問。

コミュニケーションをとる際は、誰もが理解できるように、必ず自分のニーズを明確に述べてください。次に、30 日間のプロジェクトなど、本当に大規模なプロジェクトの場合は、プロジェクトのメンバー全員を招待して、一緒に分割してください。この大きなプロジェクトを小さな需要点（ユーザーストーリー）に分割し、それぞれの小さな需要点で、どのような作業が必要か、各作業にどれくらいの時間がかかるか、毎日どのようなタスクが完了するかをリスト化し、プロジェクトを進行させます。 、全員がスケジュールに従っていると、より信頼性が高くなります。

最後に、pmさんは実際のプロジェクトでゆっくりと経験を積んでください。技術的なバックグラウンドを持つ PM の方が優れています。そうでない場合は、このプロジェクトでどのような手順を完了する必要があるか、および各手順にどれくらいの時間がかかるかについて、R&D と詳細に連絡してください。何かが予想外に長かったり短かったりした場合は、その理由を尋ねてください。そういった積み重ねが信頼性を高めます！ 勉強して、自分自身を「理解できる」人間になってから評価するか、
または、プログラマーを信じるか、または、30 日間評価したプログラマーを 15 日間評価したプログラマーに置き換えます。それを完了できなかった場合、その結果はあなたが負うことになります。 私たちが使用するスクラムは、そうです、誰もが大騒ぎし、一部の人はそれを叱責するスクラムです。答えてみると、Po さんの元の質問と少し矛盾していることがわかったので、試してみます。

=========================================== == ===========================
私たちがやっていることはまだ良くありませんが、いくつかのポイントがあります。何か参考にさせてください。

1. ビジネス契約 ここでの契約とは、最終的に何を納品するか、製品がどのようなものになるか、どのようなリソースが必要になるかについての合意を指します。ユーザーの使用シナリオはビジネス レベルでのみ提供されますが、技術的な詳細には焦点を当てないようにしてください。

2. 結論として、チームを信頼してください。 チームを完全に信頼し、チームにあなたを完全に信頼してもらいましょう。
作っていないものは分からないので、プロにやってもらいましょう。未知のものを見積もるには、研究開発担当者のスキル、経験、プロ意識が非常に重要です。しかし、1 つ言えるのは、他の人自身の見積も​​りが妥当かどうかを判断するよりも、チーム メンバーがどのように時間を見積もるかを理解する方がはるかに有益であるということです。まず第一に、私たちが提示した所要時間を信じてください。

3. プロセス中の継続的な最適化 一度に適切な推定時間を達成することは基本的に非現実的です。彼らの推定方法を理解した後、まず全員の数サイクルの推定時間を信頼し、その後、効率が向上したか低下したかを全員が確認できるように記録を残すことができます。物事をやりたい人は頑張らないし、やりたくない人は頑張らないでしょう。やりたくないことは頑張らないと子どもの初期のマイナスポイントは大きくなります。 信じてください、エンジニアは完了までに 30 日かかると言っていました

通常は実際には 60 日かかります

だから、他の人がわざと怠けているのではないかと疑わないで、もっと考えてください。 30日以内に仕事を終わらせられない場合の対処法。 プロダクトマネージャーになりたくないアーキテクトは、優れたプログラマーではありません...

この文で答えを始める目的は、社会はすでに包括的な分業の時代に入っており、それに依存する人々は、中規模以上のプロジェクト/製品を自社の努力だけで完了することは不可能です。同時に複数のスキル (製品 + アーキテクチャまたはアーキテクチャ + 開発または開発 + テスト) を持つ人材を抱えることは、割合の観点から見て贅沢です。

「これほど現実的なものはない」という経験的推定であっても、CMMI の FPA であっても、さまざまなワークロード推定方法の中でも、組織に適用される条件下では優れた推定方法です。しかし、元の投稿者のような問題がほとんどの中小企業で発生する理由はいくつかあると思います。
1. 統一された
見積り方法/基準の欠如: 組織が使用していることを確認している場合。推定には経験が必要です。その場合、作業量の精度は推定者の能力、仕事の姿勢 (場合によっては気分) によって決まります。そのため、個人的には比較的客観的な FPA 手法を組織に導入することをお勧めしますが、この手法は組織によって認識される必要があります。 2. 効果的な
監督/反映メカニズムの欠如: 多くの組織では、プロジェクトが遅れている理由を振り返り、その理由を分析して改善し、日々のプロジェクトの研究開発を行っていません。モニタリングはあまりうまく実装できません。このままでは、プロジェクトの遅れが常態化するでしょう。3.
約束に対する敬意の欠如: 個人の信用と同じように、多くの人は計画を約束ではなく、計画としてしか考えません。 、このような要求は一見少し高いように見えますが、何度も遅延すると必然的に他の人に不信感を与えることになります。
PS. 誰もが他人に厳しくありたいと思っていますが、多くの場合、自分自身に厳しくすることが最も難しいのです。