テクニカルプログラムマネージャーとプロダクトマネージャー:違いは何ですか?

組織がどのような専門知識やニーズを持っているかを評価する際には、さまざまな配信役割のニュアンスを理解することが重要です。 責任が重複し、役割の定義が部門や企業によって異なる場合、これはかなり複雑になる可能性があります。 たとえば、テクニカルプログラムマネージャー(TPM)とプロダクトマネージャーまたはテクニカルプロダクトマネージャーのような、プログラム、プロジェクト、およ

まず、TPMsとプロダクトマネージャーの一般的な特性と責任を打破しましょう:

プロダクトマネージャー:

  • ビジネスに焦点を当てた
  • 強力なプロジェクトとプログラム管理スキル
  • は、製品のビジョンを作成するのに役立ちます
  • は、製品関連のビジネ
  • には、エンジニアリング作業ストリームを担当する製品所有者がいる可能性があります。 たとえば、製品マネージャーが次世代のXboxを担当し、製品所有者はXbox Live、コントローラ、ネットワークなどの小さなコンポーネントに焦点を当てることができます。
  • 注–テクニカルプロダクトマネージャーまたはテクニカルプロダクトオーナーは、上記と同様の役割を果たしますが、高度に技術的な製品

テクニカルプログラムマネージャー:

  • エンジニアリングの実行、計画、設計に焦点を当てた
  • 通常、元ソフトウェアエンジニア
  • は、TPMがどのように技術的に精通しており、配信の必要性が何であるかに応じて、開発者と緊密に協力することが多い
  • は、バリューストリームのビジネス側に合わせてより整列することがあります。
  • 組織のための一つ以上の技術プロジェクトのすべての配信側面を処理する担当
  • 通常、SOA(service-oriented architecture)とマイクロサービスアーキテクチャ技術を採用している技
  • プログラムの推進、進捗状況のフォロー、問題が発生した場合のサポートを担当
  • は、プロジェクトを起動するために変更を加えなければならない技術的な依存関係を駆動することが多く、
  • は、アイデアの生成から展開までのプロジェクトのライフサイクル全体を作業し、完全なリリースバリューストリームを最適化することが多い
  • は、組織を継続的な統合と展開、DevOpsに向けて移動させることができる技術、ツール、およびプロセスを確立するのに役立ちます。動作モデル。
  • 多くの場合、アプリケーションの遠隔測定、パフォーマンス、信頼性、回復力、セキュリティ、コンプライアンスなどのソフトウェア配信の非機能的な側面に関

商品配送における役割の違いを視覚化するために、以下の図を評価しましょう:

テクニカルプログラムマネージャー対プロダクトマネージャーベン図

ご覧のように、各役割は、価値の流れの中で異なるポイントを占めています–製品のアイデアは、アイデア、またはコンセプトから、製品開発、および技術的な実行を通じて、組織を介して進行するために必要なステップ。 プロダクトマネージャーは価値の流れの概念的な、ビジネス側面に大いに近い傾向がある一方Tpmは一般に価値の流れのエンジニアそして実行端とよ これは、TPMsがアーキテクチャの会話にもっと関与し、組織がそれを必要とする場合にはコード化する可能性があるため、技術的な専門知識のレベルと一致し

考慮すべきもう一つの層は、バリューストリームを介して製品を移動するために必要な技術的な深さです。 私たちは、技術的な経験が少ないことを意味するTPMの小さな”t”と、多くの技術的な経験をもたらすことを意味する大きな”T”TPMの観点からこれについ この範囲では、上記の役割間の重複を可能にします。 たとえば、テクニカルプログラムマネージャーが技術的な専門知識が少なく、tPMの方が多い場合、製品開発と管理のビジネス側とより緊密に連携する可能性 彼らが技術的に強い場合、彼らは製品やビジネス側にあまり焦点を当てておらず、エンジニアリングに大きく関与する可能性があります。 これを想像する良い方法は、図の技術プログラムマネージャーの円を工学的適性に基づいて左または右にスライドさせることです。

最終的には、責任の重複は、組織が必要とするものに依存します。 こういうわけでAIMの相談の配達リーダーシップの練習は異なった顧客の必要性に合うために深い技術的専門知識に穏健派のtpmsの範囲を持っていること

あなたの組織はプロジェクト配信支援を必要としていますか? あなたの挑戦について教えてください。

コメントを残す

メールアドレスが公開されることはありません。