このプロジェクトのプロダクトマネージャーは誰ですか？彼はリードデベロッパーから抜け出すことができますか？

私の名前はリュドミラです。私は7年間プロダクトマネージャーとして働いています。 次に、その外観を説明します。

プロジェクトで最も高貴で優しい生物は建築家です。 彼は常に何世紀もの層を貫く思考を持っています。 しかし、アーキテクトは専門技術であり、アーキテクトはユーザーが必要とするものを直接決定しないという意味でプロジェクトを管理できません。 これはプロダクトマネージャーによって行われます。

製品マネージャーの機能は、他の多くの役割と強く重複しています。 プロジェクトマネージャーのタスクを遂行できる そして、その前後にまだ何かをします。 機能の概要は次のとおりです。

1. ユーザーが必要とするものを分析し、市場を調査します。 つまり、彼は新しいプロジェクトのアイデアを思いつき、それらに優先順位を付けています。
2. 技術チームと一緒に技術的ソリューションを選択します。
3. 製品の経済性を計算し、それを行う価値があるかどうかを判断します。
4. ワーキンググループを収集し、プロジェクトのアーキテクトやその他の主要人物のタスクを設定します。
5. 彼はすべて、すべて、組織全体のすべてを監視します。特に、彼はパートナーやベンダーとのやり取りを担当しています。
6. 実装後、彼は製品に同伴し、少なくとも1年間その開発と改善に取り組んでいます。
7. 夜に目を覚まし、目を覚まし、新製品のアイデアを出します。

製品マネージャーは、プロジェクトマネージャーから取得できます。 あなた自身が何かを発明し、それを作成したので、この役割には大きな責任がありますが、話題もあります-海。 私たちの仕事で最もクールなことは、クールなチームとともに、「離陸」する大規模プロジェクトを行うことです。 この感覚が刺激になります。 しかし、作業には多くの問題があります。

重要：以下では、ソフトウェア開発ではなく、サービスにおけるプロダクトマネージャーの作業について説明します。 これらは非常に異なる責任とタスクです。

どのようにしてプロダクトマネージャーになりますか？

時々、これは自発的な量子現象として起こります。 最初にエンジニアとして働き、次にチームリーダーになり、次にプロジェクトマネージャーになり、財務モデルを保護し、サプライヤーと通信するスキルを獲得した特定の人がいました...そして、ここにアイデアがあります。 彼はリーダーにそれを運び、リーダーは彼にそのエリアをより完全に探索するタスクを与え、その後計算が行われ、1、2か月後に私たちのヒーローは彼自身が思いついたプロジェクトの実施に従事します。 まだ彼が何に興味を持ったのか本当に理解していない。

実際、もちろん、98％のケースでは、製品について学ぶ必要があります。 プロダクトマネージャーは、プロジェクトマネージャー、チームリーダー、エンジニア、マーケティング担当者になることはほとんどありません（売り手が売り手になることはほとんどありません）。

最初のプロジェクトでは、すくい、汗、涙の海があり、子供たちのジャムと基本的なことの誤解がありますが、最終的にはすべてがうまくいくでしょう。 熱意だから。 そして、その瞬間、その人物がプロジェクトを終わらせたことが明らかになったとき、会社の創設者とCEOの見地から、彼は特別な価値を獲得しました。

事実は、彼らが導かれる必要はないということです。 これは、自分で仕事を見つけ、会社にとっての利益を正当化し、自分で仕事をする方法を知っているチームリーダーです。 つまり、ビジネスを前進させる人です。 当然、彼はこれらすべてのリソースを与えられます。

アイデアを検索する

企業戦略があり、市場があり、すべての企業リソースがあります（材料と知識とつながりの両方）-あなたは山を動かすことができます。 ある種の精神的緊張。 したがって、製品技術者が最初に行うことは、可能な「掘る場所」の方向を分析することです。 「2年以内にこの市場を獲得したい」などの紹介メッセージがある場合もありますが、売り手は顧客が何か新しいことを頻繁に求めていると言う場合もあります。

作業の最初の部分は、アイデアの精緻化です。 これは、考えられる仮説の検索、それらの確認の試み、市場分析、および製品アイデアの作成です。 アイデアの生成は創造的なプロセスです。 アイデアを市場向けの製品に変えるプロセスは、会社のさまざまな部門から多くの参加者があり、それぞれが独自の役割を持つプロセスまたはプロジェクトです。 製品マネージャー自身が製品コンセプトを担当します。 建築家、弁護士、投資家、その他の人々がアイデアを証明するために招待されますが、製品の専門家がこれをすべて実施します。 そして、これらすべてに責任があります。 そして、全員間の相互作用を提供します。

製品は、誰が製品を必要としているか、どのようなビジネスを引き付けることができるか、どの市場シェアを期待できるかを考えます。 主なアイデアはUSP、つまり、ユニークな販売提案です。 時々、アイデアが既に採用されていることがありますが、新しい技術的ソリューションであり、これにより、はるかに興味深い機能と機能を提供できます。

製品の外観のソースは通常次のとおりです。

1. 世界の動向-ロシア連邦の私たちは、アメリカとヨーロッパのクラウド市場を約5年間支えています。 たとえば、2010年にヨーロッパでのIaaSの販売が本格化したとき、顧客はこの現象を疑っていました。
2. 顧客のニーズ。 製品のスペシャリストは、セールスマンと一緒に大規模な顧客を訪問し、ニーズについて詳細なインタビューを注文し、社内のスペシャリストと連絡を取ります。 最も経験豊富な製品の専門家の一部は、対象業界で働いている人です。 これは、顧客の期待に応えるのに役立ちます。 そのような製品は、誰が何を傷つけるのかを確実に知っており、彼らが作成する製品は、業界の技術者に幸福の涙を引き起こす。
3. エンジニアリングのアイデア。 ベンダーに新しい技術があると言う会社に会社が登場することがありますが、これで盲目にしましょう-それは素晴らしいことです。 または、紛争のエンジニアが地獄のようなものをプロトタイプの形で収集し、予想外の商用アプリケーションを使用します。 などなど。 ちなみに、成功したエンジニアリングのアイデアは、魂が嘘をついている場合でも、エンジニアがプロジェクトに挑戦する稀な機会です。
4. 長期的な開発を行い、市場を変えます。つまり、イノベーションの探求です。 これは多くの場合、研究所、ソフトウェアスタートアップ、または内部「インキュベーター」の大手ベンダーによって行われます。

アイデア保護

アイデアを見つけるだけでは不十分です。それを保護する必要があります。 つまり、土地と収益化です。 あなたはそれをどのように誰に売るかを明確に理解しなければなりません。 市場評価、技術マーケティング、ビジネスケースの作成が開始されます。 技術、設計のコストを考慮する必要があります。 サードパーティ-パートナーの参加を検討する。 すべての価格をご覧ください。 プロジェクトのさまざまな部分の成績を取得します。 事前に同意するには、価格表を収集し、鉄とすべてのリソースを数えます。

たとえば、TechnoDisk（クラウドベースのファイルホスティング）を起動するために、ITインフラストラクチャとソフトウェアを展開し、既成のソリューションに基づいてユーザーポータルを適合させ、ISや他のシステムと統合し、ライセンス契約、サプライヤーとの契約などを作成しました。これらすべてが必要でした。事前にカウントします。

その後、プロジェクトが保護され、詳細な仕様がありますが、予算内で、以前のステップで正当化されました。 購入のさらなる承認が与えられます。

ビジネスケースを準備する際の最も難しいことは、収益を予測することです。
これを行うには、市場を評価します。「ロシア市場の10％が欲しい」などの現実的な目標を設定するか、現在の販売データを推定して、西側の類似物を使用して評価を行います。 インタビュー「エカテリンブルグにはいくつのかかとがあります」での一連の質問からの素晴らしい分析作業。 当然、いくつかの仮定がありますが、それらはさまざまなツールによって最小化されます。

たとえば、クラウド（IaaS）に基づいて、多くのPaaSおよびSaaSサービスがあります。 ミニプロジェクトは次のようになります。AmazonS3 APIを完全にサポートするオブジェクトストレージが必要です-転送されるクライアントの数は？ 彼らは評価を行い、招待し、それを使い始めました。

完全に新しいサービスで、最も難しいこと。 多くの場合、研究機関と一緒に何百ものクライアントを経由する必要があります。 予測を確認し、顧客の期待に応えることが重要です。場合によっては、顧客とテストを行うこともあります。 また、市場で製品が登場することで消費の予測が変わりますが、これは別の話です。

実装

これはプロジェクトマネージャー （プロダクトマネージャーが別のプロジェクトを持っている場合に便利です。これにより、作業がはるかに楽になります）とアーキテクトの仕事です。 私の参考同僚はすべてを非常によく描いた。 実際、私たちは計画を立て、ワーキンググループとアルビテンをまとめます。 私たちは演技しています。

建築家、プログラマー、請負業者がそれぞれのタスクを実行している間、製品技術者は関税を設定し、製品ドキュメントのセット（製品の販売キットとマーケティング資料（サイトのコンテンツを含む））を準備します。 マーケティング担当者と一緒に、製品プロモーション計画を作成できます。

次に、受け入れられる前にテストが開始されます。

受理後

承認後、製品のスペシャリストは売り手向けのトレーニングを実施し、すべての人にすべてを説明します。 どのようなアイデア、誰がそれを必要とし、なぜそれがクールなのか、どのように販売するのか。
さらに、製品マネージャーはすべての人をサポートおよびアドバイスします。販売に参加したり、会議やクライアントイベントに行って製品について話したりできます。

プロダクトマネージャーは営業に行きます。 初めて何をどのように理解するか。 フィードバックを取得します。販売方法、修正対象、製品が実際にどのように機能するか。 ただ水泳のために製品を受け取って送ることはできません。

製品が配信されると、製品マネージャーはサポートを継続します。 多くの場合、パッケージサービスの開発と改良、処理が必要です。 これは通常、製品が何か大きなものにカプセル化されているか、単に寿命を終えているという事実で終わります。

プロジェクトは受け入れ、サービスの開発、新しいプロジェクト、またはバックログの維持で終了します。 つまり、受け入れられた後に製品が開発されると、製品マネージャーはその製品に費やす時間を減らし、新しいものにますます多くの時間を費やします。 プロダクトマネージャーは、いくつかの製品を実行できます。たとえば、いくつかはメンテナンスと開発で、1つは起動時-新しいものです。

難しさ

まず、市場で発生するすべてのことに常に注意する必要があります。 つまり、新しいトレンドに従ってください。 ほとんどの場合、これはゴミの海であり、新しいものの10％
テクノロジー。 しかし、重要なものを見逃さないためには、すべてを知る必要があります。

新しいクールな製品のアイデアは、時にはありふれたものを実装するときに出てきます。 ここでは、製品委員会の前で保護した後、犠牲にして別の製品専門家に渡す必要がある場合があります。 残念ですが、まったくやらないと悪いでしょう。

製品エンジニアと開発エンジニアとの間の議論は、製品のアイデアの議論で非常に頻繁に起こります。 実際には、開発者は製品に関する独自のビジョンを持っている可能性があり、それをより良くする方法を知っています。 これはしばしば完全主義で表現されますが、技術的完全主義は必ずしも売り物ではありません。 それは、市場が必要とする理由と製品の非常に詳細な説明によって解決されます。 そして、最小限のパッケージから始めて、開発中にハング機能に取り組む必要があります。

時々、建築家の壮大な戦いがあり、それぞれに何かを実装するための独自の計画があり、特定の技術を守る必要があります。 理解することは困難ですが、最も美しくはありませんが、最も機能的で合理的なソリューションが勝ちます。

それどころか、エンジニアが特定の分野の知識や経験を欠いていることはめったにありません。そして、彼らが自信がないと感じる製品から部品を取り除こうとします。 または特別な場合-エンジニアにとって信じられないほど複雑に見えることは、非常に当たり前のことです。 複雑さは常にお金に変換されるわけではないので、時にはよく考えて美しい実装を取得する必要があります。 エンジニアがこれは不可能だと言ったプロジェクトがあり、数日後に彼らは来て、それを実装する方法を見つけたと言った。

会社の長の鉄の意志が必要な場合があります。 最も深刻な戦いは、情報セキュリティの分野です。 さらに、私たちと顧客の両方-たとえば、クラウドテクノロジーの歴史において、顧客の情報セキュリティサービスは外部から不信感を抱いています。 面白いことがあります。「ベンダーは誰ですか？ イワノフ？ 彼は学校で私たちのCSOを破りました、私たちは働きません。」 「ワイヤレスネットワークを使用しない」、「「M」でベンダーと連携しない」などのようなものがあります。

製品スペシャリストはどのように評価されますか？

• サービスの開始のタイミングによって。 あなたが時間通りに撤回しない場合、会社は直接または間接的な損失を被ります。
• 収入のため。 製品の発売後、製品マネージャーは販売を監視し、問題を解決します。 計画された収入が達成されない場合、彼はこれが起こる理由を見つけます、彼の過失（売り手が彼ら自身の計画を持っているかもしれないか、売り手自身が売れないかもしれません、または製品自体の宣伝は不十分に届けられます）。 それでも問題が製品にある場合は、改善の計画が作成されます。
• 価格設定：関税、製品マージン。
• SLAメトリックの形成（メンテナンスサービスはコンプライアンスに責任があります）。
• まあ、新製品のアイデアの品質のため。 より正確には、アイデア自体は誰も必要としません-最初の誤算と保護の質、そして実装のためです。

さらにいくつかのこと

製品が機能するとき、それは勝利ではありません。 勝利は、製品が予測可能な収入を生み出すときです。 たとえば、私にとって、 Technoservクラウドは巨大なストーリーであり、一方ではすべてを最初から最後まで計算し、実際の財務結果を達成することができましたが、他方では、さらに多くの必要性を理解しています！

プロダクトマネージャーはどこから入手できますか？ 事業部長、製品ポートフォリオディレクター、事業開発ディレクター、コンサルタントとして、営業に入るか、独自のビジネスを開始します。 しかし、これには、プロジェクトマネージャーの役​​割から始めて、関連性のある非常に優れた管理スキルとコミュニケーションスキルが必要です。

テキストは、Technoserv CloudのプロダクトマネージャーLyudmila Lepekhinaによって作成されました。