オペレーションで成功したいなら、まずはこれを学ばなければなりません！

製品プロジェクト チームには通常、製品、設計、研究開発、テスト、運用と保守、オペレーション、マーケティング、ビジネス、チャネルなどの職種のメンバーが含まれます (人員は具体的な状況や期間に応じて増減する場合があります)。

製品開発の初期段階では、製品および研究開発の学生が主導して製品をゼロから作成し、製品が要求どおりに完成するようにします。製品が発売された後は、日々の管理やデータ指標は運用部門の責任になります。製品のユーザーベースに「0」がいくつあるかは、運用、マーケティング、チャネル、ビジネスがどれだけできるかによって決まります。

当社製品が市場を征服する過程で、ユーザーから機能やニーズに関する多くのフィードバックを受け取ります。時には、製品データをさらに改善するために、自社の運用プロジェクトに製品の反復要件を提示することもあります。現時点では、製品に要件を提示し、テクノロジーをスケジュールし、UI を操作する必要があります...次に、私たちが直面しなければならない長いが必要なコミュニケーションが続きます。

アメリカの有名大学であるプリンストン大学は、1万人の人事ファイルを分析した結果、「IQ」「専門スキル」「経験」は成功要因の25％しか占めず、残りの75％は良好な対人コミュニケーションによって決まることを発見しました。また、ハーバード大学キャリアガイダンスグループの調査結果によると、解雇された男女500人のうち、82％は対人コミュニケーション不足が原因で仕事に不適格だったことがわかりました。

解雇を避けるためには、オペレーション担当者が他のチームメンバーと良好なコミュニケーションを確立することが特に重要です。

オペレーション業務に携わったことがある人なら誰でも知っていると思いますが、社内には頻繁にコミュニケーションを取る必要がある人がプロダクト、技術、UI（ビジネスやチャネルは少人数）の3つに分かれています。以下では、そのコミュニケーション方法を一つずつ解説していきますので、プロジェクトにおけるコミュニケーション促進の一助になれば幸いです。

1/オペレーションと製品がうまくコミュニケーションするにはどうすればよいでしょうか?

業務と製品という二つの立場が生まれて以来、両者の関係は常に最も微妙であり、お互いを軽蔑し合うことは非常に容易です。会社が業務と製品を別々の部門に分け、それぞれを異なるリーダーが率いると、各部門は互いに監視し合い、問題が発生するたびに争いを始めると予想されます。

運用の観点から見ると、製品は非常に多くの開発リソースを消費し、ほとんどの場合、作成された機能は役に立たず、私たちはそのたびにその混乱を片付け、スケープゴートにならなければなりません。

製品側から見れば、ちょっとした景品を配ったりイベントを開いたり、製品開発に役立たないフリーライダーを大量に招き入れるくらいで、運営部門は大した影響力を発揮していないように思える。私のように製品にインパクトを与え、業界に衝撃を与えるようなことはできないのだろうか…

業務と製品の方向性が合わない場合に発生する可能性のある問題の 1 つは、業務プロジェクトを時間どおりに推進できず、製品機能に後続の業務管理がなく、最もコアとなる製品の日々の活動データさえも低下することです。誰が責任を負っているかに関係なく、不平を言うことで貴重な時間が無駄になり、結局誰が得をするのでしょうか?

この状況を打破する方法は 2 つあります。高価なものと無料のものです。会社の予算が許せば、運用チームはプロダクト マネージャーを採用し、製品チームは運用スタッフを採用することができます。コストをかけたくないのであれば、組織体制を簡素化し、製品ラインごとにフルスタッフを配置した製品部制にすることもできます。これにより、機能別部門とタスク割り当てによる大規模な部署体制よりも、従業員の製品に対する責任感と熱意を高めることができます（組織体制の調整は簡単ではないようです）。または、オペレーション部門の私たちが率先して率先してコミュニケーションをとることもできます。

1. 同じチャネルでの言語コミュニケーション

運用部門の日常業務は主にコンテンツの作成、計画書の作成、PPT の作成などですが、製品部門の業務にはユーザー ニーズの分析、競合製品の機能の分析、要件ドキュメントの作成、プロトタイプの作成などがあります。私たちが行うさまざまなタスクによって、コミュニケーションのさまざまな媒体と方法が決まります。

オペレーションは、製品とコミュニケーションをとるために適切なオペレーションを使用する必要があります。この計画をそのまま実行することはできません。製品要件ドキュメント (MRD) も作成する必要があります。これは、製品に私たちのニーズと実行する必要があることを迅速に知らせることができるドキュメントです。最初のコミュニケーションの詳細を必ずしも明確に述べる必要はありませんが、コア機能ポイントの相互作用要件は明記する必要があります。

2. メリットを伝え、自分の功績を主張しない

運用は細部の最適化から始まりますが、製品では製品レベルでの大規模な反復が行われます。すべての業務や製品作業の本質的な目的は製品の価値を最大化することですが、手段や考え方は異なります。

運用担当者がプロジェクトの機能要件について製品マネージャーとコミュニケーションをとると、現在担当している製品の利点をプロジェクトに明確に伝えることができます。製品開発者が気にするメリットは、より多くの人に製品を使ってもらうこと、または開発した機能が製品のコアターゲットデータに役立つことを証明することだけです。たとえば、プロジェクトで製品チームの機能を直接再利用し、プロジェクトを立ち上げるときに、機能的なサポートに対して製品マネージャーに直接感謝すると、コミュニケーションがよりスムーズになるでしょう。

3. 心を開いて学び、感情的にならないようにする

心理学によれば、人々はリーダーに個人主義の兆候が見られると、無関心になったり、敵対的になったりするそうです。逆に、舞台裏にいて目立たないリーダーの方が、より広く尊敬されるようになるでしょう。

ニューヨーク・ワールド紙の創刊者であり発行人でもあるピューリッツァー氏はかつて、緊急事態の際に自分が出した命令が新聞社の方針に違反する場合には、編集者はそれを無視できると編集者に伝えたことがある。謙虚になることを学ぶことは、対人関係において「一歩下がれば、空が広くなる」ということに他なりません。

オペレーターとして、私たちはあらゆる種類の興味深い創造的なアイデアや考えを思いつくことができます。製品のロジックはより良くなり、製品のすべてのデータとインターフェースをよりよく理解できるようになります。小規模なプロジェクト運営の場合、製品要件ドキュメントの作成を自力で完了することは確かに可能ですが、大規模な製品反復要件の場合は、謙虚に学び、感情的にならないようにするのが最善です。製品について議論し、協力することができれば、より良い結果が得られると予想されます。少なくとも、技術とコミュニケーションをとるときは、製品のすべての詳細についてより明確に考えることができます。

4. 対立ではなくリーダーシップを活用する

かつて深圳でシェアしていたとき、ある人が私に「部門間のコミュニケーションを改善するにはどうすればよいですか？」と尋ねました。その時の私のアドバイスは、「まず自分で問題を解決してみてください。それでも解決できない場合は、衝突を避けるために、部門のリーダーにコピーしたメールを送信し、リーダーにプロジェクトの推進を手伝ってもらうように依頼することができます。その時、Tieba で営業担当者がメールを副社長にコピーしたところ、製品がすぐに問題を解決したのを見ました。ハハ！人気があれば、もっと良い方法があるかもしれません。」でした。

プロジェクトの推奨事項についてリーダーシップを活用するには、事前にリーダーシップに通知し、このメールに何を書くべきかを指導してもらう必要があります。オペレーションが行う必要があるのは、プロジェクトの背景、プロジェクトのメリット、プロジェクトの状況、現在の需要の問題をリーダーに伝え、ニーズ（どの機能を実行する必要があるか、そうしないとプロジェクトを完了できないか）に優先順位を付け、製品からどのようなサポートを得たいのかを決めることです。

2/運用とデザインをうまく連携させるにはどうすればよいでしょうか?

製品の特定の機能を最適化/開発する場合、運用と PM が機能のプロトタイプを完成した後、UI はプロトタイプ上のテキストとインタラクティブ モジュールのビジュアル デザインを実行する必要があります。

ユーザーにとって、見た目が重視されるこの時代では、美観がその機能を使用するかどうかを決める鍵となります。一方、操作にとっては、機能の視覚効果がプロジェクト データに直接影響するため、操作と UI 間のコミュニケーションが機能の品質とプロジェクト データの品質を直接決定します。

理論的には、プロトタイプを描いてデザイナーに渡せば、図面が完成するのを待って受け取るだけです。しかし、現実には、プロジェクトに取り組んでいると、UI との連携中に次のような状況が発生することがよくあります。皆さんも同じ問題を抱えているのではないでしょうか。

• UI は機能のロジックには関心がなく、製品の美観のみに焦点を当てています。たとえば、投票ボタンの横にある親指を立てたマークは、もともとボタンを「支持」として強調するためのものでしたが、UI はこれではページが混雑して見えると判断したため、単に「支持」というテキストに変更しました。
• UI キッズが設計したページ効果は満足できるものではなく、操作上の期待を満たしていません。再作業と修正が必要です。
• 機能をより面白くするために、操作や製品は新しいインタラクション方法を伝えることがよくありますが、UI 担当者はそれが不要だと感じているため、変更を躊躇します。
• 製品、操作、UI のすべてにおいて、ページの見た目には非常に満足していますが、直属の上司は十分ではないと考えており、さらにデザインの修正が必要です。
• 機能のビジュアルは完成していますが、機能はまだリリースされておらず、UI 担当者は進捗を促し続けています。

良好な協力関係は尊敬とコミュニケーションに基づいており、相手方の専門的レベルを信頼する必要があります。 UI デザイナーが最も恐れていることは何でしょうか?

彼らが最も恐れているのは、自分たちがデザインしたページがオンラインに公開されず、作品の価値が認められず、ディスク上に眠る PSD のままになってしまうことです。本質的には、彼らは自分の作品がより多くのユーザーに見られることを望んでいますが、継続的な修正のモチベーションを高めるには操作が必要です。したがって、通常、変更の必要がある場合、運用では、次の方法を使用して回避し、説得的に伝えることを試みることができます。

1. 早期参加と効果的な設計

オペレーションは機能設計の初期段階からデザイナーを関与させることができ、製品でプロトタイプを描く際に彼らの提案を参考にすることができます。何と言っても彼らはプロのデザイナーであり、私たちよりも多くのインタラクション方法やページを見てきたので、より良い機能の提示方法を考え出せるかもしれません。もちろん、最も重要なことは、デザイナーが早期に参加することで、その後のページ設計プロセスでプロトタイプ内の各ボタンのインタラクションについて繰り返し説明する時間を節約でき、デザイナーが操作レベルで各ボタンの配置の背後にある考え方をよりよく理解できることです。

2. 間接的に説得し、肯定する

すべてのデザイナーの背後には、アドバイスを与える一団の神々がいます。「こうすると見栄えがよくありません。左上隅のテキストを大きくして、色を暗くしてください。全体のスタイルが十分にフラットではありません。」

誰も否定されることを好みません。製品のビジュアルデザインについて独自の意見がある場合、最も良いコミュニケーション方法は「このボタンを青で塗りつぶし、ページの色を変更すると、より快適に見えるようになりますか？ もちろん、これは私のアイデアにすぎません。結局のところ、私はあなたほどプロフェッショナルではありませんし、あなたの方がより良い修正プランを持っているかもしれません。」です。

ポジティブな従業員は皆、良い結果を目指して働いています。良好なコミュニケーションに基づいて、あらゆることを話し合うことができます。もちろん、自分のプロトタイプの間違いによる頻繁な修正は起こらないことが前提です。

より良いインタラクションと改善の要件がある場合は、自分の変更要件を提案する前に、まず彼の仕事に肯定的な評価を与えることができます。「現在のデザインはとても良いです。製品とコミュニケーションをとった後、このボタンはバウンドボールになる可能性があり、ページ全体のスタイルにもっと合うのではないかと思います。あなたもそう思いますか？」

3. グループコミュニケーションと進捗状況の共有

機能の発起者として、運用部門は技術、製品、設計の各関係者間で情報が伝達されないようにする必要があります。メッセンジャーになって常に走り回らないでください。そうしないと、データ目標を達成するために他のことを考えるエネルギーがなくなります。グループコミュニケーションとは、プロジェクトディスカッショングループを設定し、UIデザイナーがページレイヤーの配分や画像カットロジックについて技術スタッフと調整できるようにし、デザイナーがカラーRGBデータに関して技術スタッフにタイムリーに応答できるようにすることを意味します。

そうすれば、技術者はグループ内の開発の進捗状況を一目で同期でき、デザイナーもプロジェクト全体の開発の進捗状況をよりよく把握できるため、運営側がページデザイン作業を棚上げしていると考えることがなくなります。

3/オペレーションとテクノロジーをうまく連携させるにはどうすればよいでしょうか?

UI デザイナーがページを作成した後、運用部門はそれと製品チームが作成した製品要件ドキュメントを技術部門に持ち込み、スケジュールを検討する必要があります。毎日進捗状況を尋ねたり、特定の要件が満たされていないことを心配したり、テストとバグの報告を延々と繰り返したりすることを避け、プロジェクトをスムーズに立ち上げるために、運用スタッフは技術スタッフとのコミュニケーションにおいて以下の点に注意する必要があります。

1. 生徒のやる気を引き出すために十分な説明をする

プログラマーは自らを「コードファーマー」と呼ぶのが好きです。彼らを本当にコードを書くだけの責任があるインターネット移民労働者とみなすのは悲劇です。技術とオペレーションは同じ部門ではありません。両者は協力関係にあるだけで、リーダー主導の関係ではありません。オペレーションが一方的に要求を押し下げて、自分たちがこれをやりたいと言って、R&D にこれをこのように実現しなければならない、指定の時間に完了しなければならないと指示することは決してありません。

なぜ、技術系の学生の多くが、プロダクトマネージャーに転身したり、CEO として起業したりできるようになったのでしょうか。それは、アイデアと野心を持った信頼できる研究開発担当者は、単に仕事を引き受けて機械的に仕事をこなすような人ではないからです。

彼らはビジネスに関して独自の理解とアイデアを持っており、専門的な技術的観点からより良いソリューションを提供できる場合もあります。前提条件は、この需要の詳細を彼らに十分に理解してもらうことです。この需要の背景は、私たちが何をしようとしているのかを知るだけでなく、もっと重要なのは、なぜ私たちがそれをしているのかを知ることです。現在の製品の需要は、調査と分析後の私の操作によって決定されます。私の説明は十分に理解できましたか？それでは、R＆Dの観点から、他に隠れた問題がないか確認してください。より良い解決策はありますか？一緒に話し合いましょう。

2. 要件を明確にし、簡単に変更しない

運用作業は広範囲かつ些細なものであり、多くの場合、「マルチスレッド タスクの並列処理」とさまざまなユーザーとの頻繁なやり取りが必要になります。したがって、運用上の思考は比較的多岐にわたり、かなりの柔軟性が求められます。これが運用業務の大きな特徴であり、コミュニケーションにおける最大の問題でもあります。

機能設計段階では、新しい要件の追加や変更についてコミュニケーションをとることは可能かもしれませんが、開発段階で要件が変更されると、技術系のクラスメイトとの友情が危うくなる可能性があります。

したがって、要件を明確にし、簡単に変更しないでください（ケーキの上のアイシングの要件は次のバージョンで完了する必要があります）。提供される技術開発ドキュメントとページは、最終バージョンであることが望ましいです。変更が大きいほど、プロジェクトが他のプロジェクトのスケジュールに押し出される可能性が高くなります。プロジェクトがうまく実行できない場合、デザイナーはあなたに不安を感じるでしょう。

3. 問題解決のためのモジュール通信

技術者はデータ コードを扱い、基本的に単一のプロセスで作業します。単位時間あたりのコーディング効率を向上させるには、基本的に「飛行」作業モードにする必要があります。時には、他のすべてのことを忘れてコードの世界に完全に浸るほどハイになるまで書き続けることもあります。

もしオペレーションスタッフが数分おきに彼の邪魔をして、ここで何かを変更したり、あそこで何かを修正したり、あるいは質問をしたりしたら、R&D の思考の流れは中断され、これらの単一スレッドの学生たちはおそらく気が狂ってしまうでしょう。したがって、運用と技術コミュニケーションでは、需要を管理するためのツールを使用する必要があります。生成されたすべての要件と提案をプロジェクト管理ツールに入力します。たとえば、JIRA は非常によく使用されるツールです (大企業は基本的に独自の開発要件コミュニケーション ツールを持っています)。要件のバッチをまとめ、R&D と定期的にコミュニケーションを取り、優先順位とスケジュールを決定します。

緊急の要望や重大なバグ（ユーザーがログインできないなど）が発生した場合は、いつでもR＆Dに処理を依頼できますが、要望を断片的に報告しないようにしてください。特に、QQや電話などのインスタントコミュニケーション方法を使用してR＆Dに要望を報告しないでください。何かを見逃しやすく、カウントやフィードバックが難しく、R＆Dにも支障をきたします。

コミュニケーションの本質は、自分が何を望んでいるのかを相手に知らせること、そして相手が何を望んでいるのかを自分が知ることです。つまり、チームの全員が、自分の仕事を前提として、率先して他のチームメンバーの仕事内容を理解する必要があります。技術、デザイン、製品の同僚とコミュニケーションをとるだけでなく、マーケティングやチャネル部門ともコミュニケーションをとり、データの改善に役立つポイントを事前に把握する必要があります。

運用の目標は、製品の価値を最大化することです。どのような手段を用いるにしても、それが合理的かつ合法であり、会社の規則に違反しない限り、問題はありません。しかし、常に他人を利用し、利用することばかり考えていると、しばらくはうまくいくかもしれませんが、長期的にはうまくいきません。

コミュニケーションと協力の最良の方法は、部門間の単純な調整や助け合いではなく、参加者全員が共通の利益を持ち、喜んで共有し、報酬と罰を明確に区別することです。製品がうまく作られていれば、全員が貢献し、必要に応じてお金を分配し、チームビルディングを行う必要があります。あなたと一緒に働くことに何の害もないことは誰もが知っています。時間が経つにつれて、信頼できる人々はあなたと協力し続けたいと思うようになり、あなたの評判と職場での信頼性が確立されます。