製品思考とテクノロジー思考の違い
「同じことがデマンドサービスにも当てはまります。製品の考え方は何ですか**」**
01序文
まったく新しい製品を最初から設計します。実際、基本的な作業はプログラマーのことを心配する必要はありません。作業は、製品マネージャーと顧客が最初の連絡と設計を行うことから始まります。ここで言及されている製品マネージャーは実際には名前であり、実際のマネージャーの位置ではありません。一般的には、Party Aが事前要件を提示し、その後製品マネージャーが製品図面を事前に設計します。厳密な場合は、通常、最初のバージョンを決定するために顧客とのさらなるコミュニケーションを行います。
実際、どのようなステップを踏んでもコミュニケーションは重要なスキルポイントであり、効果的なコミュニケーションを通じて、双方が許容範囲内で製品を設計できるため、製品を上手く着陸させることができます。プロダクトマネージャーは、実際には多数のデザインビジネスパーティーを持つポジションであり、プログラマーとパーティーAだけを対象としているとは限りません。効率的なコミュニケーションに加えて、スキルも非常に必要です。
02製品思考
製品と研究開発の間の戦いをしばしば目にするかもしれません。実際、これは効果的に解決できますが、何らかの理由で無効な通信が発生した可能性があります。次に、これがそうである理由についてお話しましょう。
まず、製品マネージャーの出発点はパーティーAの需要計画を実現することであり、プロジェクトのライフサイクル全体を通じて顧客のニーズを追跡し続けます。実際、一見すると、これはプログラマーの出発点と非常に似ているので、戦いではありません。同じですが、商品の原点は商品思考に基づいているので、商品思考とは？一般に、次の3つのポイントから開始できます。
- ユーザー値
- シーンを使用
- 事業価値
1つ目はユーザーの価値ですが、簡単に言えば、この製品はユーザーにとって有用で、開発されたものです。つまり、ユーザーの苦痛を効果的に解決できる製品であり、ユーザーの苦痛が解決できれば、当然のことながら、後の操作やプロモーションレベルで、誰かが自然に使用してくれます。優れた製品であるWeChatを例にとると、まず、WeChatは無料のリアルタイムチャット、WeChat転送、エンターテイメント（友達の輪）など、多くのユーザーの悩みを解決します。これらは素晴らしいアイデアです。チャット機能がない場合、テキストメッセージや通話で全員がコミュニケーションする可能性があり、不便で非効率的です。そのため、ユーザーの課題を解決すると、誰かが自然に製品を使用し、ユーザー価値が実現します。
使用シナリオとは、人々が余暇や退屈を過ごして人々の日常のニーズを満たすことができるミニプログラムゲームなど、この製品が使用に適したシナリオを指します。たとえば、流行時に立ち上げられたSui Kangの小さなプログラムは、マスクを予約して健康情報を報告する人々を満足させ、特定のシナリオで使用できます。したがって、製品の誕生は、使用シナリオの側面や研究開発の方向性と組み合わせる必要があります。
商業的価値、多くの人々は、上記のユーザー価値は商業的価値と同じであると考えるかもしれませんが、そうではありません。まず、ユーザーの価値とは、ユーザーの期待される需要、品質の需要、価格の需要、その他の関連要素など、ユーザーがニーズを満たすために求めている価値です。ユーザーの期待に応えられない要素があると、本製品のユーザー価値が低下し、商品価値が低下する可能性があります。
たとえば、初期の頃はすべてBaiduの検索エンジンを使用していましたが、その検索エンジンのコンテンツのほとんどは希望どおりではないため、ほとんどが広告です。したがって、ここで強調される最初の問題は、ユーザーの価値の欠如であり、ユーザーの価値よりも大きな商業的価値にのみ焦点を当てています。したがって、BingやGoogleなどの別の代替手段を探している可能性があります。常識的には、一般利用者が一定の水準に達すると、広告などの商業的利益などの商品価値の実現を検討します。まず第一に、Baiduは非常に典型的な例であり、WeChat Momentsも広告を開始しました。これは、商業的価値を達成する方法でもあります。しかし、一般市民がWeChatより優れた代替案を見つけられなくなったため、基本的に影響はありません。
03技術的思考
知覚的思考に焦点を当てた製品思考とは異なり、技術的思考は製品自体の実現に焦点を当てることがより重要です。簡単に言えば、製品の重点は知覚的思考、ビジネス価値、ユーザーエクスペリエンスであり、技術的思考は技術の底から始まり、合理的な思考によって推進される製品開発に焦点を当てています。
プログラマーの観点からすると、主な懸念事項は次のとおりです。
- 技術的枠組みと原則
- 実現可能性分析
- 研究開発サイクル
テクニカルフレームワークの選択は、通常、ソフトウェアアーキテクトが選択します。さまざまな考慮事項を検討した後、使用するツールは、欠陥があるかどうか、コミュニティのフィードバックが妥当であるかどうかなどを確認するためにも使用されます。たとえば、ソフトウェアの開発に使用するほとんどのテクノロジーは、オープンソースフレームワーク/コンポーネントライブラリを使用して、ビジネスの記述を減らします。選択基準は、一般に、このフレームワークがニーズを満たすかどうか、問題が発生した場合にテクニカルサポートを受けることができるかどうかを調べます（エコロジー/コミュニティは完璧ですか）など 一般的に言って、一度モデルを選択したら、それを変更しないでください。モデルの選択が基本です。建物を建てるのと同じように、基礎を変えるのは難しいので、話し合って慎重に選びます。
製品には、実装する必要のある期待される機能と製品のインタラクティブな機能を含む需要分析設計図書があり、評価する必要があるときにそれを達成できます。例えば、ユーザーの電話ケースの色に応じてテーマを変更する必要は実現できない。プログラマーは、各アイテムの要件を包括的に評価し、実現可能性を判断して、それを製品にフィードバックします。
最後はR＆Dサイクルですが、製品のR＆D評価に加わるのに1カ月かかりますが、どうすれば1週間以内に納品できますか？お金が整っていない限り。
要約：
上記の分析の結果、両者の出発点は同じですが、実際の考え方が異なり、コミュニケーションが難しい場合があることがわかりました。プログラマーは厳密な態度で各問題と要求を合理的に分析している間、製品マネージャーはより知覚的な評価を持っています。
04まとめ
上記では、製品思考と技術思考の違いを紹介しましたが、マクロ開発の観点から言えば、製品開発には準備段階があり、主に製品マネージャーと顧客がコミュニケーションと設計を行ってからレポートを作成し、中期は主に技術スタッフが行います運用とは、コーディングによる製品の実現であり、後の段階は、運用とプロモーション、および製品のメンテナンスの段階です。
全員の分業を理解することで、全体のプロセスが明確になり、問題があれば、どのリンクが問題なのかをすぐに見つけることができます。一般に、製品思考と技術思考は互いに補完し合い、高品質な製品を生み出すことができます。
