技術チームのマネージャーとして、自分の問題について何を知っておく必要がありますか?
たとえば、あなたがある案件の所有者である場合、その案件の問題はすべてあなたの問題です。
マネージャーとして、チームの問題はすべて自分の問題です。
人員が限られた体制なので、シフトを減らしてほしいと思ったのですが、止められました。システムには多くの問題があるため、業務を遂行するにはより多くのエネルギーが必要です。これが問題であり、その解決方法を考える必要があります。
問題の核心を他人に任せるのではなく、担当者としてあなたが解決すべきです。自分が責任を負っていることに責任を持たない人もいます。実際、彼の心には担当者の肖像はなく、とても担当者には見えなかった。
私たちはよく「問題に遭遇したときは、まず自分の中に原因を見つけなければなりません」と言います。
他人が全く問題ないのではなく、外の世界にあまり介入できない、相手の上司が頼りない、代わってもらえますか？会社のプロセスは複雑ですが、自分の都合に合わせて変更できますか?
まずは自分から理由を見つけて、物事をうまく意思決定し、決定し、最適化できるようにしましょう。
レビューを終えて、何も変更するところがない場合は問題ありませんが、問題がそれほど多くない場合は、あまりレビューしないでください。
研究開発の価値は主にコスト、効率、品質、リスクを中心に展開するとよく言われます。
しかし、企業は気にするだろうか？コードの品質と配信効率の遅さはすべて、独自の研究開発の問題です。
たとえば、営業担当者は DingTalk の顧客にこう言いました。「私も DingTalk はひどいと思うので、それを変えるのに協力したいのですが、残念ながら自分にはできません。」上海在住の 32 歳の PHP プログラマー、技術専門家、マネージャーが 12 年間のキャリアから得た 9 つの人生の洞察
Ye Jun はこの文を社内に転送し、次のように言いました。「顧客の前でどうやって説得できますか?」押せないって言うのは、あなたには何も問題がないってことですか？これらはすべて他人の問題です。あなたは DingTalk の従業員ですか? DingTalk のメンバーとして、DingTalk のすべての問題はあなたの問題であり、あなたには問題を促進し解決する責任があります。
イェジュンはかつて「紳士と淑女のように奉仕せよ」という本を勧め、誰でもそれができるようになり、顧客の問題を解決するまで回避しないでほしいと願った。問題があれば持ち帰ってサポートを見つけることができ、誰も見つからない場合は CEO に相談することができます。
問題を解決するのはあなたの仕事であり、他の人が提供するのはサポートだけであることを忘れないでください。
より成熟したマネージャーは、チームのビジネスとサービスに対する感覚を継続的に養う必要があります。
多くの場合、人々はあまりにも大きなエゴを持つよりも、しゃがんだほうが合意に達しやすいのです。
製品づくりの共通認識は、ユーザー価値に立ち返り、深い価値を開発し、顧客の中核的なニーズを定着させることです。
また、顧客に対処し、顧客に適切にサービスを提供する方法を学ぶ必要があります。
ミドルオフィス部門には顧客満足度という評価指標が必要だと思います。
ミドルオフィスが良いサービスを提供できない（顧客満足度が高くない）場合、多くのプロジェクトの納品効率が低下し、コスト削減と効率化という目的を達成できなくなります。
そして、フロントオフィス業務にクレームがあり、自分でやる、ミドルオフィス業務は必要ない、ということであれば、高確率でコスト削減と効率化（人員削減）が必要になります。
より高い次元で考えると、各リンクはネットワークに織り込まれるべきです。組織の価値は、ネットワーク全体の効率を向上させることです。エンドツーエンドのリンクにより、各リンクが出会うノードがスタックしないことが保証されます。ネットワーク データ フローのポイント。
