したがって、小さなサービスにマネージャーが必要な場合、大きなサービスには製品マネージャーとプロジェクトマネージャーの2つの役割が表示されます。 英語主義のみで構成されるテクノロジー企業の俗語では、製品とプロジェクトマネージャーという異なる言い方をします。 開発者がフロントエンドとバックエンドを同時に行うことができるように、それは同一の人物でもかまいません。
しかし、マネージャーの役割の分離のポイントは何ですか？ 誰が製品で誰がプロジェクトですか？ 4月30日に終了するマネージャースクールへの新規採用の際に、4つの人気サービスのリーダーにこの質問をしました。 同時に、それぞれが初心者マネージャー向けに選択したリンクを共有しました。
Yandex.Videoの責任者、マキシムザグレビン
-チームが小さいため、プロジェクトと製品に分割されていません。 通常、製品スキルは仕事を構築するのに十分であり、そうでない場合でも、すぐにベースラインに行くことができます。 大きなプラスは、通信の損失がないことです。 製品は、競合他社、技術を分析し、ユーザーが好む製品または開発を提供します。 彼はこれがどのように機能するかを頭に描きます。 しかし、誰かがアイデアを需要、タスクに変えなければなりません。 たくさんの人がいる場合は、同意する必要があります。マキシムがアドバイスするプロジェクトの本
ほとんどの場合、MVP、レビュー、新しいプラットフォームでの発売を考慮して、製品にはさらに計画期間があります。 このプロジェクトは結果に焦点を当て、容赦なく範囲を削減し、基準を理解し、すべての人に明確になるようにします。 彼は、打ち上げがいつ行われるべきか、どんな人がいるのか、操作の自由、どれだけの品質を犠牲にすることができるかを決定します。 通常、プロジェクトには開発プロセスの組織があります。
多くの場合、片方の側だけがよりよく送られます。 勉強を終えなければなりません。 私たちは人にインタビューするときにすべての側面をチェックしようとします。彼はメトリックを導き出し、プロジェクトをリードすることができますか、技術的な背景はありますか？ ちなみに、管理者コードが必要かどうかは、厳密な要件はありません。 プロジェクトは、マネージャーの手でコードを1行も書くことなく実行できます。 主なことは、プロジェクトが開発者間で情報を伝える必要があることです。彼はこう言います。「ある程度の抽象化は、これが起こっていることを理解していますが、一緒に話すとクールです」 同時に、技術的なスキル-たとえば、CSVでコードを見つける能力-は、プロジェクト管理に大きく貢献します。 マネージャーは尋ねることはできませんが、コードを読み、読み、理解することができます。 または、分析のために、ログを読み取るスクリプトを作成します。
チームが解決策を選択できない場合は、次のように言った方が良いでしょう。 悪いでしょう-新しいサイクルでリメイクします。」 私たちは永遠にそれを大切にします。 マネージャーが設計から来た場合、描画とプロトタイプの作成方法を知っていれば、これも劣らない強みです。
それでも、マネージャーの特徴は、結果を得る能力、または私たちが有用な経験を得たが結果ではないことを認める能力です。 人々はそれを持っているかいないかのどちらかです。 そうでない場合は、「ここで下請け業者が失敗し、ここでアイデアが悪かった...」ということから始まります。通常、これはいくつかを他と区別します。
• PMBOKガイド
• 神話上のマン月
• クマとのワルツ
• 神風の道
• 猫の放牧方法
• 子供とコミュニケーションを取ります。 どうやって？
• ITプロジェクトを管理する技術
• https : //www.ozon.ru/context/detail/id/22433706/
製品の本
• 患者の手による精神病院
• 深byの橋渡し
• インスピレーション：顧客が愛する製品を作成する方法
• スクラムを使用したアジャイル製品管理
エリザベータ・セミャノフスカヤ、Yandexヘッド
-製品マネージャーは多機能です。 彼はマーケティングの専門知識の一部を持っています-彼は市場を分析する方法を知っています。 開発者は182のすべてのバックログポイントを実行できません。 戦略を策定し、それが目標にどのように関連するかを理解し、ユーザーの立場と競合他社の幅広い市場から首尾一貫したものにし、同時にビジネスの目標を達成する必要があります。
トランスポートは現在過渡期にあります-アナリストに複雑なタスクを処理させ、製品自体がログを記録できるようにします。 製品はタイプセットすることができます-たとえば、バックグラウンドでビデオを含むランディングページを作成したり、フォームを修正したりできます。 別の製品は、Sketchでプロトタイプを作成し、Invisionで組み立てて、ユーザーでテストできる必要があります。
技術的に自分自身とそれらをポンプで送りたい、ここにAndroid Studioをインストールした、目立たない場所-設定でトランスポートのアイコンを変更してみてください。 製品にコードをコミットさせたくないのですが、彼らはそれを見て、少なくともそれがどのように機能するかを大まかに理解するはずです。
Transportの製品の1つは多くのユーザーインタビューを行っており、人々は彼女と話すことを決して拒否しませんでした-路上で、地下鉄で、カフェで。 彼女にはそのような超大国がいます。 しかし、誰もがすぐに使えるわけではなく、そのようなスキルは活気づけられます。
さらに、Transportの特定のリリースのコンテキストに非常に没頭している製品が常に存在します。 これは、プロジェクトが病気になった場合や休暇中になった場合です。
製品にプロジェクトスキルがあればいいと思います。 私たちのプロジェクトは開発プロセスに携わっており、リリース要件があること、すべてが予定どおりであること、 トラッカーにダッシュボードを持っていること、タスクを設定していること、下請け業者からAPIを収集していることなどを保証する責任があります。同意する、誰かが何かをしたくないことを理解する、それについて話すことができる、期限に従う、非常に責任があり、自走し、正確であること。 そして-ルーチンで死なないでください。
Anddex Gevak、Yandex.MusicおよびYandex.Radioのヘッド
-私にとって、広義のマネージャーとは、あるビジネスに対して全責任を負う人のことです。 そのため、最初から最後まで。 Arkady Volozhが言うように、「始めて終わり」。アンドレイからのリンク
しかし、このような困難なパスでは、マネージャー自身、チーム、経営者、投資家、ユーザーなどに多くの疑問が生じます。
「なぜ？」および「何？」という質問には、製品が回答します。 製品に関連して、これらは最も重要な問題であり、特に最初の問題です。 多くのスタートアップが失敗した理由は、一部のプログラムを記述できなかったため、または設計が終了して閉じられなかったためではありません。 資金不足でもありません。 その理由は当たり前です。チームがやった製品は誰にも必要ではなかったからです。
まだ非常に多くの場合、製品はリードするリーダーです。 彼は絶えず自分の製品と競合他社の製品を使用し、対象をずっと知っており、すべての新しい製品について知っています。また、今後数年間は状況を見ます-または見ていると思います。 そして彼は、他の人が彼を信じるようになるという彼のビジョンを信じています。
「どのように？」および「いつ？」という質問に答えるのはプロジェクトです。開発者と一緒にいる、より技術的な偏見を持つ人です。 彼は開発の詳細をより高いレベルで理解し、製品を技術的な空想に変換し、現在の技術の枠組みにまだ適合していないと思われるアイデアを実現する方法を見つけることができます。 このプロジェクトは、チーム、チームの雰囲気、そしてその闘争精神の用語のファンです。 彼はいつ強くなるか、いつ逃げるかを知っています。 そして最後に、このプロジェクトはより独創的で時間厳守です。
これを1人で組み合わせることができます。 しかし、難しい内部対話が始まり、分裂した人格の始まりが生じます。 「まっすぐ」というカテゴリから何かを思いついた後、内なる声でチームが疲れており、期限に間に合わないことがわかります。
• 実践！製品分析ブログ
• イリヤ・クラシンスキー 、 マキシム・ドロフェエフ 、 ルートヴィヒ・ ビストロノフ スキー 、 アレクセイ・イワノフスキーによるビデオ
•テレグラムチャネル、 たとえば
•TEDのビデオ- 何十もの最も人気のあるショーから始めることができます
• ユーザーを「オンボード」する方法の例
Yandex.Navigatorの責任者、ミハイル・ヴィソコフスキー
-これらは正確に2つの異なる役割です。 それらが1人で組み合わされるかどうかは、規模によって異なります。 この製品は、何をするのか、なぜ行うのか、そしてどのようにいつ行うのかという質問に答えます。 製品は製品のイデオロギーであり、多くの場合コンテキストを変更し、特定のシナリオで製品がどのように機能するかを理解するために、全体像と詳細の両方を頭の中に保持します。マイケルからのリンク
彼には少なくとも5つの関心領域があります。 最初の分野は研究です。 彼は問題のテストと安価なプロトタイプの作成が得意です。 ナビゲーターのプロトタイプの1つは、携帯電話の上部にあるスティック上の紙切れの形でした。 また、ナビゲーターが動作し、その上で手動で画像、ポインターを切り替えることも起こりました。 人でアイデアをテストできる必要があり、方法とツールは常に異なります。
二番目。 製品は宇宙に住んでいません。 競合他社を監視することが重要です。 製品マーケティングと製品は似たような概念だと思います。 マーケティングコミュニケーションのマネージャーの役割のみを分離でき、製品は従来のマーケティングに関するすべての質問に答える必要があります。 第三に、MAUを使用したDAUレベルだけでなく、耐用年数とAB実験のさまざまな指標のコンテキストでのメトリックと分析の理解。 製品は数字に突っ込み、アンロードを行い、それを使用する準備ができています。 4番目-ロードマップ。 そのようなシナリオでは、製品がそのような方法で動作し、ターゲット、ターゲットオーディエンスセグメント、ポジショニング、メトリックをペイントする必要があることを策定する必要があります。 5番目の役割は、全員を刺激し、全員と共通の言語を見つけるリーダーの役割です。チーム内および周囲の利害関係者の両方です。
彼がマーケティングコミュニケーション、設計、開発、または分析の基本的なスキルを持っているなら、それほどクールではありません。
プロジェクトの目標は、プロジェクトが期待される形式で一緒になり、すべての参加者と関係者がこれがいつ起こるかを理解することです。 条件付きで製品を注文したスコープを実行する必要があります。 どのようにプロジェクト管理を構築する場合でも、ウォーターフォール、アジャイルなどを通じて。 主なことは、目標を時間通りに達成し、全員に共通の期待を抱くことです。
• IDEOのポータル 。製品の研究へのさまざまなアプローチと段階的な説明が含まれています。
•同じポータルからのデザイン思考に関する単一のPDFマテリアル
•Mind the Productカンファレンスでのプレゼンテーション： 2017年に最適 な完全なリスト （他の製品カンファレンスのビデオを見ることができます）
•より近いProductCamp： プレイリスト 、 チャンネル （他のエントリを自分で探してください）
•古いブログ投稿「実践に行く！」