プロジェクト運営内容（運営アイデア：新規プロジェクトをうまく進める方法）

新しいプロジェクトをうまく進める方法

企業内でオペレーション担当者が製品オペレーションを行う場合、オペレーションは 2 種類しかありません。1 つは既存事業のオペレーション、もう 1 つは開発が必要なまったく新しい事業のオペレーションです。長年にわたる業務の中で、私は多くの新しいプロジェクトにも取り組んできました。以前のプロジェクトと比較すると、まったく新しいプロジェクトに直面すると、運用上の考え方が以前の製品とは異なることがわかりました。

具体的なアイデアは何ですか?この記事では、新しい問題に直面したときにオペレーターが持つべき優れたアイデアと、オペレーターが遭遇する可能性のある落とし穴を詳細に分析し、新しいプロジェクトを開始しようとしている学生にインスピレーションを与えることを目指します。

新しいプロジェクト運営の核となる考え方：

• 市場調査
• 実行可能なソリューションを開発する
• プロジェクトのフォローアップと調整
• 要約とフィードバック

具体的な分析は以下のとおりです。

諺にあるように、軍隊が出発する前に食糧と飼料を送らなければなりません。ここでの食べ物と草は市場調査を指します。当社では、新しいプロジェクトが生まれる前に、まずプロジェクトを立ち上げ、評価を行うことが重要だと考えています。市場調査は、プロジェクトを開始する前に行う必要がある作業です。調査の目的は、新規プロジェクトの開発コストと投資収益率を評価することです。研究中に新しいプロジェクトが時代遅れであることが判明した場合、そのプロジェクトを開発する必要はありません。

私たちがモバイル ゲーム プロジェクトに取り組んでいたとき、最初はオンライン ゲームから始めました。その後、ゲームの収益の半分以上がスタンドアロン ゲームから得られたことを各チャンネルから聞きました。オンライン ゲーム市場が 1 つのチャネルだけで数千万ドルの売上を上げていることを想像してみてください。スタンドアロン ゲームはもっと大きな利益をもたらすのではないでしょうか。結局のところ、オンラインゲームと比較すると、開発コストとサイクルがはるかに低くなります。そこで私たちは独立したプロジェクトチームを立ち上げ、スタンドアロン ゲームの市場調査を開始しました。約 2 週間かかりましたが、スタンドアロン ゲームの市場規模、ゲームプレイ、競合製品について総合的に理解することができました。

市場調査は詳細かつ正確でなければならないため、業務の情報処理能力に高い要求が課せられます。たとえば、以前、あるスタンドアロン ゲームが特定のチャネルで非常に高いランクにランクされていたため、そのゲームのコア ゲームプレイと数値の何が優れているかを調べるために特別にダウンロードして分析しましたが、ユニークな点はありませんでした。困惑していると、事業部は、そのチャンネルがこのゲーム会社に投資していることを知り、その会社を推薦し続けたのです。正確な情報が得られなければ、導き出される結論はまったく異なるものになる可能性があります。

市場調査のための情報は、Baidu や Zhihu などのインターネットからの情報と、オフラインで同業者に相談した情報という 2 つの情報源から得られます。どちらの情報にもそれぞれ長所と短所がありますが、どちらも不可欠です。 Baidu の情報は非常に公式なもので、表示されるのは表面的なものだけです。データリサーチをしたい場合は、Baiduで検索したり、ニュースのインタビューを見たりすれば、貴重な情報も得られるかもしれません。 Zhihu には現在、より価値があり、より信頼できる情報が掲載されており、多くのヒントが Zhihu で見つかります。

同僚に相談することも最も重要です。オペレーションに携わる学生の多くは、他の人が自分のことをよく知らないのではないかと常に心配しています。では、なぜ情報を問い合わせたときに教えてくれるのでしょうか?この戦略は当初から疑問視されてきた。実はこれは誤解です。私はインターネット企業の人たちと何度もやり取りをしてきましたが、彼らには皆、他人を助けようとするという一つの特徴があることに気がつきました。質問やアドバイスを求めると、詳しく説明してくれます。開発プロセス中に難しい問題に遭遇したとしても、そのうちのいくつかは完全な解決策を提供します。もちろん、それが会社の中核的な秘密に関わることであれば、自分自身を困らせてはいけません。

スタンドアロンの調査を行っていたとき、スタンドアロン マシンを 4 ～ 5 年間使用し、オペレーターと請求処理に非常に精通している業界の大物と偶然出会いました。そこで私たちは彼を訪ねる約束をしました。訪問前に、知りたい質問をノートに書き留めておきました。質問は全部で20問くらいありました。相談に行ったとき、私はほぼすべての質問を一つずつ確認しました。私は多くのことを得て、想像もできない暗黙のルールをたくさん学びました。私は今でも彼らと連絡を取り合っていますが、あの訪問が私たちが初めて会ったときだったことを覚えています。

すべての情報を収集したら、それを処理します。操作の価値がここに反映されます。通常、上司は特に要約を要求しませんが、情報を整理した上で調査レポートを作成することをお勧めします。まず、あなたは価値ある成果を出し、上司は非常に喜び、あなたが信頼できると思うでしょう。給料の上昇を待つこともできます。もう 1 つは、分析と要約のスキルを鍛えることです。個人の能力向上にも非常に役立ちます。

前回の調査レポートが発表された後、結果は 2 つあります。実行するか、実行しないかです。しかし、それについては議論しないでおこう。それは私たちとは何の関係もない。研究によってプロジェクトが実行可能であることが証明されれば、私たちは前進することができます。次のステップは、実行可能な運用計画を策定することです。

ここでの計画は開発計画とは多少異なり、具体的な作業の取り決めを盛り込むほど詳細ではありません。計画には、人員配置、開発サイクル、プロジェクトフェーズ、期待される結果が含まれます。結局のところ、私たちは新しいプロジェクトを完全に理解していないので、各リンクの評価に大きな偏差があるのは普通のことです。問題が発生したら、自分を責めずに、初期段階と実行で最善を尽くしてください。

計画を立てる際には、多くの運用担当者が技術を理解していないため、製品マネージャーに技術評価の完了を支援するよう依頼することができます。スタンドアロン プロジェクトの実現可能性を評価した後、解決すべき 2 つの主要な領域、開発と課金アプリケーションが見つかりました。私は頭が良いのですが、当然ながら開発については何も知りません。そこで私たちは製品チームを招集し、協力して提案書を作成しました。バックグラウンド、サーバー、バックエンド、フロントエンドの計画はすべて製品チームによって完了しました。私が行うのは、プロジェクトの設立、開発、アクセス、立ち上げなど、これらを全体的な計画に組み込むことです。

より正確に言えば、これまでの作業はすべて紙上のものであり、この作業は実際の実装段階に入っています。操作中に留意しなければならないことが 1 つあります。このフェーズでは操作が比較的遅くなるため、慌てないようにしてください。チェスやカードゲームの運営ビジネスをしている友人がいます。研究開発段階の会社に入社し、8月末に立ち上げる予定だったが、6月に入社した。彼は毎日何もすることがなかったが、それでも給料をもらっていた。彼は上司に対してとても同情した。同じような感覚を持つ別の職種として、ビジネスがあります。彼らは本当に、喜びも悲しみも分かち合う良いカップルです。

プロジェクト開発中、最も忙しかったのはテクノロジーの部分でした。スタンドアロン ゲームの開発中、私は何も理解していないにもかかわらず、毎日技術専門家を訪問し、見て回り、質問しました。ただし、この期間中も運用部門は開発計画を把握する必要があります。プロジェクト マネージャーはプロジェクトを分割した後、現在および将来開発される機能モジュールと時間ノードを明確に計画します。オペレーションが行う必要があるのは、プロジェクト開発が予定通りに完了するように促し、確実にすることです。オペレーターとして、ある程度の技術を理解し、ある程度のコードを知っていれば、さらに良いでしょう。多くのスキルを持つことは常に良いことです。私が知っているモバイルゲーム会社の社長も、採用する運用担当者はコードを理解し、VB などを自分で書ける必要があると言っていました。

プロジェクトのフォローアップで最も一般的な問題は、会社ごとに異なる論争です。多くの新しいプロジェクトでは、新しく結成されたチームが中心となります。バックエンド、フロントエンド、サーバーサイドにはそれぞれ独自の隠れた目的があります。強力な技術リーダーがいなければ、各部門が独自に作業を進めてしまう可能性が高くなります。うまく協力できないと、プロジェクト全体の開発の進行に影響を及ぼします。したがって、オペレーションを専攻する学生がプロジェクトのペースをコントロールすべきだと私は提案します。彼らが非常に強いなら、彼らは自分たちだけで問題を解決することができます。取るに足らない存在であれば、上司の力に頼ることもできる。

より良い方法は、毎週上司に仕事の進捗状況を報告することです。特に、調整できないコミュニケーションの問題については、上司に介入してもらうと効果的です。 BOSS を私のために機能させる方法については、「Tiger Talks Operations」公開アカウントで詳しくお答えします。

プロジェクトのフォローアップ中に、計画中に問題を十分に検討せずに要件が開発のために提出されるという状況が発生することがあります。開発の過程で、彼は偶然に神々の祝福を受け、何が起こっているのかを突然理解し、開発計画を変更することを決意しました。このとき、まずプロダクトマネージャーとコミュニケーションを取る必要があります。結果は深刻なものとなるため、要件をテクノロジーに直接押し付けないように注意してください。要件の変更は詳細な議論によって裏付けられる必要があり、感情に基づいて行われるべきではありません。そうしないと、後で同様の問題が発生した場合に権限を失ってしまいます。

テクノロジー開発における最大のタブーは、要件の変更です。以前、ブラウザ プロジェクトに取り組んでいたときにも同様の状況が発生しました。当時の戦略は、まずコア機能を開発し、バージョンが予定通りにリリースされるようにし、最適化の問題を反復的に実行するというものでした。結局のところ、その製品は発売されたばかりで、ユーザーはほとんどいなかったのです。以前の戦略が間違っていたとしても、その影響は無視できる可能性があります。小さなことのために全体像を見失わないでください。誰もが運用が信頼できないという考えを形成すると、将来の作業はさらに面倒になります。

これまでの努力が実り、ようやく製品の発売に至り、運用を開始する時期になりました。プロジェクトの調査や企画はすべてオペレーションが担当するため、製品発売後の効果分析では、誰も監督しなくても、責任感を持って全員が主体的に総括作業をやり遂げてくれると信じています。

私たちのスタンドアロン ゲームとブラウザーは金曜日にリリースされました。結局、週末の2日間はどこにも行けませんでした。私は朝早く起きて、Umeng のデータに目を凝らし、新しい追加、ユーザーの行動、保持などを調べました。ここで皆さんへの提案があります。新しいバージョンをリリースするのに金曜日を選ばないのが最善です。週末にゆっくり休めないだけでなく、問題が起きたときには誰も見つけられず、解決が難しくなってしまいます。仕事中は 10 分で解決できる問題でも、週末には解決するのに少なくとも半日かかるかもしれません。

週末の 2 日間のデータを通じて、基本的にプロジェクト全体が期待どおりであったかどうかを確認できます。一般的なプロセスは次のとおりです。バージョン 1.0 がリリースされた後、少数のユーザーがテスト用にインポートされ、2 ～ 3 日間実行した後に概要レポートが生成されます。製品が保持データを非常に重視している場合は、数日間遅らせて、7 日間の保持データが利用可能になった後に概要レポートを作成できます。

私たちは以前、情報フロープロジェクトに取り組んでいました。オンラインになってから 2 日間経過した後、ユーザー維持データのみを分析し、概要レポートを提出しました。それは非常に簡潔で、たった一文で、その効果は業界標準と同等でした。要約を作成する際には、業界の標準データも入手する必要があります。たとえば、保持データの業界標準は 421 です。これは、翌日に 40% の保持、7 日間に 20% の保持、月単位で 10% の保持を意味します。この基準を達成できれば、製品のレベルが平均以上であることを意味します。

参照できる業界標準がなければ、取り組んでいるプロジェクトを評価することは困難です。以前、当社の製品の定着率は 50% でしたが、上司から「なぜこんなに低いのか」と尋ねられました。少なくとも70％は、ただ笑っただけです。同僚のデータを比較することで、必要に応じて修正したり、必要に応じてそこから学んだりすることができます。

バージョン 1.0 の概要、つまり大きなテストが終わった後、このプロジェクトの運命を決める時が来ました。バージョン開発を続けるか、ここで止めるかは、各操作学生の能力レベルに依存します。優れた能力を持つ人は、ひどいプロジェクトでも業界レベルにまで引き上げることができます。能力が弱い人は、良いプロジェクトを台無しにしてしまう可能性があります。これができる人はたくさんいるけど、私じゃない！

要約すると、この短い分析では、2 ～ 3 か月、あるいは 2 ～ 3 年のサイクルを持つプロジェクトに必要なプロセスをまとめています。もちろん、実際の実装プロセスはより複雑で変更可能になります。運用では状況を評価し、戦略を適切に調整する必要があります。プロセスがどんなに困難であっても、目標が達成されたときにのみ運用の価値が反映されます。

Tiger Talks Operations、WeChat公式アカウント：誰もがプロダクトマネージャーのコラムニスト、Tiger Talks Operations。 100年先を見据えた経営とアイディアを持った若者になろう！

この記事はもともと、Everyone is a Product Manager で @老虎 によって公開されました。無断転載は禁止です。