技術的なKPIが必要な理由
ビジネステクノロジーチームには、悪い傾向があります。つまり、チームはますますビジネスを獲得し、技術はますます少なくなっています。誰もがビジネスについて話し、テクノロジー会議はビジネスについて話し、毎週の会議はビジネスについて、そして毎週のレポートはビジネスプロジェクトについてです...滅多に議論されないのはテクノロジーそのものだけです。これは、ビジネスが重要ではないということではありませんが、ビジネスを理解し、ビジネスニーズを管理することが技術担当者の基盤であり、すべてではありません。
が支払う
このような技術的な趣味の欠如は、技術チームにとって残念なことであり、技術スタッフの成長と発展にはつながりません。技術的な知識がないチームが、堅牢で保守可能でスケーラブルなシステムを開発できると想像するのは難しいからです。逆に、この種のビジネスコードスタッキングは、短期的にはビジネスニーズを達成するために「速い」かもしれませんが、長期的には、この種の悪いシステムの増加はビジネスの発展を大きく妨げ、ブラックホールアプリケーションを形成します。 （骨を吐き出さずに人を食べる）、そしてエンジニアはビジネスニーズと悪いシステムの間に閉じ込められ、疲れ果てています。
これにより、システムが破損して縮退し、技術的負債がますます大きくなり、醜いコードが乱暴に成長し、腫瘍のようにすべてのエネルギーを消費します。ロバートC.マーティンが言ったように、「あなたがどれだけ献身的で何時間残業しても、悪いシステムに直面しても何もできません。なぜなら、あなたのエネルギーのほとんどは要件の開発やカオスへの対処ではないからです。」
技術者として、私たちは技術者の主要な技術的使命がソフトウェアの複雑さを管理することであることを忘れてはなりません。
テクニカルリーダーの過失
この状況では、テクニカルマネージャーとTLが主な責任を負う必要があります。より重要な点は、職務の怠慢であり、この義務の怠慢は主に2つの側面に反映されます。
技術的な怠慢
今日、多くの技術系学生は、TLのポジションに昇格すると、自然なやり方で技術的な仕事を辞め始めます。TLがテクノロジーにまったく注意を払わず、コードを作成せず、テクノロジーに熱意がなく、学習しない、さらには独自のテクノロジーでさえも悪い場合、このTLのリーダーシップのもとにあるチームが技術的な好みを持っているとどうしたらよいでしょうか。！
したがって、技術のアリババ副社長であるXuan NanがP8のコード開発の量を検討するよう求めたとき（ここではXuan Nanに実用的な賞賛を与えるはずです）、それは非常に単純で失礼ですが、確かに技術からの多くのTLを反映している可能性があります。仕事の現実。また、シグナルを明確に伝えています。つまり、それほど多くの「上位」および「ポインター」のテクニカルマネージャーは必要ありませんが、実際にシステムに深く入り込み、コードの詳細に深く入り、チームに与える必要があるため、テクノロジー自体に戻る必要があります。本当の変化をもたらす最先端のテクノロジー。
考えていないビジネス
今日、多くのTLは毎日さまざまな会議で混合され、非常に忙しく、あらゆる種類のコミュニケーション（ジャンプ）コミュニケーション（JI）アソシエーション（BA）調整（軽い）ことを行っていますが、本当に多くのミーティングが必要なので、もっとコミュニケーションしますか？
コミュニケーションは重要ではありませんが、会議が多すぎます。私の個人的な経験から、多くの会議は非効率的で無意味です。そのため、TLは他の人と同じようにではなく、より独立して考える必要があります。
レイジュン氏：「戦略的な怠惰を使って戦略的な怠惰を隠そうとしないでください。」この文は、ほとんどのPD（製品マネージャー）をより適切に説明するために使用できないので、PDよりもむしろ「何もしない」のは、無茶苦茶にして価値のない製品をたくさん作るよりはましです。多くのシステムの複雑さは、これらの面倒で無意味な要件によって引き起こされるためです。
したがって、PDの学生へのアドバイスは、ビジネスを深く理解し、深く考え、PPTデザイナーやビジネスニーズに合わせてマイクに退屈させないでください。PRDを書いてデモを描くだけではなく、体系的な思考を使用してください。製品を計画し、ビジネス問題を解決して、技術者の尊敬を勝ち取ります。
テクニカルスタッフの疲労は、上記で分析したチームの技術的な嗜好の欠如が原因であり、外部の原因は主にPDの無秩序な行動です。
したがって、私たちのTLはビジネスについても深く考え、PD YYからの「顧客のニーズ」を厳密に制御し、これらの疑似ニーズや価値のないニーズをドアの外に保ち、チームの限られた技術リソースに侵入するのを防ぎます。したがって、システムの最適化と複雑さの管理に多くのエネルギーを費やすことができます。
テクニカルKPIの定量化
玄南氏は「人間性は利己的で利益を追求するものだ」と語った。したがって、技術的な雰囲気を高め、エンジニアの文化を築くためには言葉だけでは不十分であり、技術者の利益に拘束されるなど、特定の強制措置が必要である。拘束力を持たせるには、技術的な貢献の比較的公平な分解と定量化を実行できる必要があります。昇進の審査員であった学生は、今年、プロフィールにATAの記事の参照があることをすべて知っているはずです。これは、テクノロジーを力に変える試みでもあります。
テクニカルKPI
これに基づき、技術スタッフのKPIを事業貢献、技術貢献、チーム貢献の3つの主要部分に分解します詳細は以下の通りです。
ビジネスへの貢献：需要管理、ビジネスプロジェクト、ビジネスイノベーションなど。
技術的貢献：デザインリファクタリング、技術的影響、コードレビュー、革新と効率の改善、コード品質を含みます。
チームの貢献：採用、新人研修、チームの雰囲気など。
では、技術的な貢献におけるこれらの側面をどのように理解するのでしょうか？説明についてはあまり触れませんが、私たちの仕事でいくつかのケースを使用して説明します。
| 技術貢献 | 例えば |
|---|---|
| アプリケーションの品質 | 1.担当または共同で責任を負うアプリケーション品質スコア（コード反復率、円の複雑さ、階層化の合理性などの次元から調査できます） 2.アプリケーション品質スコアを改善するために何をしましたか |
| デザインのリファクタリング | 1.顧客コミュニケーションプロジェクトで、CRM販売ドメインをモデル化して設計しましたが、それは抽象的な合理的なものでした。設計ドキュメントを参照してください 。2.インフラストラクチャでのパッケージの分類が不合理であることがわかったので、再設計して再構築を完了しました。 3.システム内のエラーコードがわかりにくいので、新しいエラーコードの仕様を整理して、コードの再構築を完了しました。 |
| 技術的影響 | 1. ATAは10件の記事を共有し、いいね数は1000件 でした。2.チームは戦略クラス を共有しました。これはクラスメートに好評でし た。3.私は招待を受け入れ、QConでSOFAアーキテクチャを共有しました。 |
| コードレビュー | 1. XXのコードを確認したところ、スレッドが不安定になる危険が隠されている可能性があることがわかりました。 2. XXのコードを確認したところ、設計に不合理な点があることがわかりましたが、ここで責任チェーンを使用すると、問題を非常にエレガントに解決でき、ある程度のスケーラビリティがあります。 |
| イノベーションと効率 | 1.ローカルテストのためにPandoraBootを開始するのは時間の無駄であることがわかったので、セルフテストの効率を大幅に改善するためにTestContainerを作成し ました2.一部のボイラープレートコードを記述する必要がないことがわかりました 。特定のプロジェクトまたは技術的なポイントで、ドメインモデルに基づくビジネス構成である特許を作成しました。 |
| コード品質 | 1.テスト後のバグの数、オンライン障害の数（システムが抽出できるため、自分で入力する必要はありません） 2.特定のモジュールの単体テストを完成させ、自動回帰の問題を何度も発見しました。 |
テクニカルKPIに関する質問と回答
技術系の学生のほとんどは上記のKPIに同意していますが、もちろん多くの疑問がありますが、ここではいくつかの典型的な答えを取り上げます。
Q：技術的なKPIにより、技術的な学生は技術だけに集中し、ビジネスプロジェクトに集中できなくなりますか？
A：パフォーマンスに関しては、ビジネスへの貢献、技術への貢献、チームへの貢献を包括的に検討する必要があります。しかし、重要な参照および天候ベーンとして、テクニカルKPIはポジティブです。
Q：デザインのリファクタリングをどのように定量化しますか？
A：これをシステムで標準化することは困難であり、TLの採点に関する専門的な能力にさらに依存しますが、それでも、以前よりも優れています。少なくともメッセージを伝える際には、優れたデザインを奨励し、継続的なリファクタリングと最適化を奨励します。
Q：現在のビジネスニーズは既に蓄積されており、第一線の学生はリファクタリングして最適化する時間がない
A：この質問はすでに冒頭で述べましたが、ビジネス要件と不正なコードにとらわれ続けたいですか、それとも時間をかけてビジネスの改善とサポートを迅速化しますか？このトレードオフは難しいことではありませんが、重要なのは決断力と能力です。一部の成熟したビジネスでは、立ち上げを数日間遅らせることがビジネス環境に影響を与えるビジネスシナリオを見たことがないので、テクニカルチームとして、テクニカルストーリーをユーザーストーリーに追加して、ビジネス要件を完了する必要があります。そして、システムの再構築は私たちのコアタスクと見なされます。