プログラマーは制御不能になりつつあるプロジェクトをどのようにして救っているのでしょうか?

返信内容:

私は上記の状況すべてに遭遇しました。
一般的なビジネス指向の企業には、荒っぽく早い開発習慣があり、技術的な製品を理解し、状況を制御し、ビジネスのプレッシャーに耐えることができる技術的な話者が不足しています。時間が経つにつれて、開発は不規則になり、コードの蓄積、人材の離職、能力の低下、アーキテクチャの破損が徐々に構造の崩壊につながります。ビジネスのプレッシャーが石膏コードをもたらし、石膏コードがより大きな技術的プレッシャーと頭脳の流出をもたらし、疲弊していきます。その後、ビジネス上のプレッシャーがさらに大きくなります。それは飛行機が失速スパイラルに陥って抜け出せなくなるようなものです。
かつて、多大なコストをかけてこのような悪循環を変えるためにチームを率いるのに半年かかり、7、8年の歴史を持つ古いシステムを包括的に再構築するのに数百人日を費やし、その犠牲を払って暴露しました。外の世界に対する独自のパフォーマンスはあまり美しくありません。
戦いに長けた者には、目立った功績はないと言われます。
先祖は木を植え、将来の世代は木陰を楽しんでいます。 知識豊富な上司なしでこの種の仕事をすると、感謝されることはありません。

何千もの単語が 1 つの文に凝縮されています。会社全体が信頼できる技術管理と技術文化を持たなければなりません。これは CTO の責任です。
これを要約して翻訳すると、質問は次のように単純化されます:

1. コードの品質を向上させるにはどうすればよいですか? 【開発力】
   
2. アーキテクチャレベルを高めるには？ [アーキテクチャ能力]
   
3. 製品要件の合理性と反復リズムをどのように制御するか? [プロジェクト管理 - 要件分析/プロジェクト計画]
   
4. 残業の激しさを減らすには? [プロジェクト管理 - リソース管理]
   
5. 知識ベースを蓄積し、口頭指導への依存を減らすには? [チームビルディング - 知識ベースの構築]
6. チームワーク文化を促進するにはどうすればよいですか? [チームビルディング - 価値観構築/パフォーマンスデザイン]
7. 少数のコア従業員に大きく依存せずにチームの技術階層を育成するにはどうすればよいですか? [チームビルディング - エシュロントレーニング]
8. 製品の品質を確保するために QA に合格しなければならないというジレンマを回避するにはどうすればよいですか? 【開発力・品質保証】
9. システムの安定性や使いやすさをどう向上させるか？ [アーキテクチャ能力]
10. 製品写真を通して明確なビジネスモデルを体系化するには? 【アーキテクチャ力-商品企画】
11. 取引先からの不当要求をどう断るのか？ [プロジェクト管理 - 需要管理]
12. スタッフの離職率を下げる方法 [チームビルディング - 残念な離職率]
13. 急速に発展するビジネス環境で上記の質問にどう答えるか? [実装可能な解決策]

上から順に解決する必要があるポイントは次のとおりです。

1. 値構築
1. チームワークを促進します。協力を促進しますか？でも、誰もあなたのことなんて気にしてないし、今忙しいなんて言ったら首を絞め殺してしまうよ。リーダーとして、良好な対人関係を維持し、協力を促進するために顔認識に頼る必要があります。
2. 献身と情熱を促進します。まずはロールモデルにならなければなりませんが、最も重要なことはインセンティブ政策に注目することです。
2. パフォーマンス設計原則
1. 結果を出すことを重視し、実行プロセスにさらに注意を払います。コードをうまく書き、ビジネスをうまく進める人を発見し、賞賛し、昇進させます。管理は表面上にとどまることはできず、コードにまで入り込む必要があります。
2. 個人の技術力を重視し、技術の継承と人材の育成に一層注力します。おい、君はどうする？ 人に教えたことのないクラスメートに昇給を期待しないでください。昇進したければ、まず弟子を 3 人連れてきてください。
3. 技術革新を重視します。毎日同じことを繰り返す人は、どんなに年長であっても、警報を鳴らし、発砲すべき時は発砲しなければなりません。プロジェクトに残された時間を絞り出して、アイデアを持った人たちに何か違うことをしてもらうには、プログラマーのチームではなく、発明者のチームが必要です。そのため、風水を利用するためにナマズを参加させることは有益です。
3. 製品開発プロセス
1. プロセスの保護。製品チームとビジネス チームで一定の反復プロセスとリズムを確立し、それを遵守し、不当な要求とリズムに断固として抵抗し、理由と証拠を伴う上向きのフィードバックを提供できること。
2. 製品について話す権利。製品には技術所有者がおり、開発者は製品のニーズと設計をレビューする権利を持っていなければならず、開発者はビジネス調査/ビジネス分析に参加し、製品設計に影響を与え、製品計画とビジネスモデルについて発言する権利を獲得するよう努めなければなりません。純粋な技術リソースになって疲弊することを避けてください。
3. 部門を越えてコミュニケーションを図ります。事前に商品部門と双方の期待や能力を伝え、商品企画や技術企画を一緒に検討し、3ヶ月に1回程度調整します。
4. チームビルディング
1. 人材階層の構築。マスターは多すぎても少なすぎてもいけません。繊細で自意識が強いオリーブ型の社会が最もダイナミックです。
2. を雇って解雇する。解約率60%、このホール！まずは賃金を上げて、しっかり上げて、まずはチームを強化して、リストラに取り組むエネルギーを十分に蓄えることが大切です。
3. チーム文化の構築。米国であろうと中国であろうと、すべての大統領や議長は、自分が何をしたいのかを国民に知らせ、自国と敵を区別するための政策スローガンを持たなければなりません。
4. チームの技術能力の開発。まず全員を見つけてください。 。 。
5. プロジェクト管理
1. アジャイルであろうとウォーターフォールであろうと、自分に合ったプロジェクトプロセスを見つけて、厳格かつ柔軟に実行する必要があります。
2. プロジェクトレビュープロセスとコードレビューを強化します。
3. 適切な作動気密性を維持してください。
4. プロジェクトマネジメントの本質とは何か》》》個人的には制度化だと思っています。制度化には実際には多くのデメリットがありますが、導入する価値のある利点が 1 つあります。私の手配に従って手配する理由 私が手配した時間と場所で戦います。優秀な PM は皆、時間管理の達人であり、システムを超えて無差別に干渉しようとするリーダーにノーと言える勇気を持っています。これはプロジェクト チームにとって朗報です。
6. システムアーキテクチャ
1. 実際のニーズに関連して、SOA、サービスガバナンス、ミドルウェア、負荷分散、劣化など。シンプル、明確、信頼性が高く、迅速に水平方向に拡張可能なシステム アーキテクチャが基礎となります。
7. ビジネス アーキテクチャ
1. ビジネス モデルの再構築
2. モジュラー、プラグイン設計
3. プラットフォーム アーキテクチャ
8. 製品品質
1. プログラミング仕様
2. 設計パターン
3. 単体テストとセルフテスト
4. QAとコードレビュー
5. 障害のレビュー
9. 組織開発
   
1. 知識の継承
2. 技術の深さとイノベーションの認識の探求
3. 社内トレーニングと社外トレーニング
4. イノベーションを促す仕組み

書いて見直してみると面白いし、中身が空っぽで実装できない気がする（笑）。困難は間違いなく予想をはるかに超えています。船の針路を変えたい場合は、第一に操舵手の影響力（優れた資格、技術チームの直接管理）が必要であり、第二に船長（上司）のサポートが得られなければならず、第三に正しい知識を持っていなければなりません。コース（やり方）を理解してから、クルーのサポート（社内の他のチームの理解）を得て、自分の力を最適化して動員し（すべての開発者がコンセプトに同意し、適切な人材を採用する）、その後で回避します。隠された岩（プロジェクトを失敗させないでください）、そして何度も勝利して、あなたの正義を強化してください。

それは難しすぎるので、多くの人が逃げるべきだとアドバイスしますが、それは正しいのです。なぜなら、99% の上司は上記の言葉とその価値を理解できないからです。しかし、上司は依然として人を加える方法を知っています。給与の増加は希望があることを示しています。 ~~

自分に問いかけてください、しっかりと飛びつく力はありますか？ これを「技術的負債」といいます。
企業債務を会計だけで完全に解決できないのと同じように、プログラマーが果たせる役割は限られています。
もちろん、プログラマーとしての職業倫理には、「クリーン コード」で言及されている「ボーイ スカウトの規則」が含まれるべきです。ボーイ スカウトであることを誇りに思い、ガール フレンドがいることを恥じましょう。 (違う、違う、これは違う、その場所を離れるとき、来た時よりもきちんとした清潔な場所を離れるときだ。)
リファクタリングはしないでください!リファクタリングはしないでください。リファクタリングはしないでください。 (トリソラ人はケンタウロスから遠方の挨拶を送ります~~) 対象者はどのくらいの期間このプロジェクトに関わっていますか?飛行機で来たのですか、それともずっとそうしていたのでしょうか？

空中の場合。個人的な経験によれば、プロジェクトが複雑になるほど、さまざまな人々がプロジェクトに対する判断を逸脱しやすくなります。特に、これまで比較的高品質なプロジェクトを経験してきた人は、古いプロジェクトの表面的な品質に先入観を持っているかもしれませんが、実際には核心は見つけられず、見つかったとしても核心は見つけられない可能性があります。総合的な計画を立てること。

あなたが仕事をして責任者に成長したのであれば、プロジェクトの失敗の責任はあなたにあります:) それなら、前のアプローチには何か無理があるはずです。この時点で、このプロジェクトには多くの問題があることはすでにご存じかもしれませんが、この山の人々の考え方の影響で、すでに資金の限界に達しています。新しい方法や新しいアイデアの影響を受け入れなければ、無力になります。

私の個人的な提案は、2 つのチームを編成することです。1 つは主に採用目的で、高い技術レベルを持ち、主にサポート体制を担当する、主にビジネスを理解した社内異動のグループです。 , 基幹業務を中心に事業再構築。 2 つのチームは、いつでも高度なコミュニケーションを維持し、経験を交換する必要があります。同時に、プレッシャーに耐えて、新しいビジネスに取り組むために奪われないようにする必要があります (残りの人々は苦しみます:P)。リズムの観点から、結合度が満足できるまで代表的なコア モジュールを選択することをお勧めします。

通常、最初のステップが最も困難です。最初の事業分割が完了すると、コスト投資と実装ステップがすべて計画され、次の N 番目のビジネス アーキテクチャ方法論も準備できます。法律に従って。 多くの人とは反対に、私は今が輝く時だと思います。

まず、「プロジェクトが多額の収益を上げている」ということに気づきませんか?金鉱山を前にして、掘り始める前に世界最高のツルハシを購入する必要がありますか?他人に引き抜かれるのが怖くないですか？

第二に、Google ほど強力で、世界でトップの人材だけを採用できる企業は多くありません。少数の優秀な人材と多数の一般人がいるのが業界の常態です。この場合、コードの品質は必然的に低下します。率直に言って、Google ですら、時間が経つと、理解できないジャンク コードや冗長なアーキテクチャが大量に存在するようになるでしょう。転職を推奨している方は、次の会社の規定がこれほどひどいのではないかと心配していませんか?中国では、BAT レベルの企業であっても、不正なコードは珍しくありません。その場合彼はまた転職するでしょうか？

あなたは、人生で悪いコードではなく、良いコードだけを書くという自信がありますか?一流の専門家とのみ協力し、卒業したばかりの新人を無視しますか？

したがって、高速車でのタイヤ交換を学ばなければなりません（以下は技術的な部分にのみ焦点を当てます。部門を超えた協力/製品との交渉の経験については、美しいRDは見た目に頼ることができます） 、裕福なRDはゲストのおもてなしに頼ることができ、diaosi rdは敗者仲間の同情に頼ることができます。つまり、各村には独自のトリックがあり、それは理解することしかできませんが、言葉で表現することはできません。

具体的には、いくつかの側面にすぎません:

1. ビジネスを深く理解します。これがすべての前提であり、これが「建築家になれるかどうか」を決めるのです。ビジネスの理解に基づいてのみ、アーキテクチャを実行し、どのモジュールがホット交換可能であるかを知ることができます。実際、多くの巨大システムには活電交換できない部品はほんの一部しかなく、その他の部分は活電交換によって徐々に改善されます。 8割が改善されれば、残りの2割の対応は難しくなくなります。

2. 優れた技術的基盤を築きます。最初のポイントが「建築家になれるかどうか」を決めるとすれば、このポイントが「良い建築家になれるかどうか」を決めることになります。十分な技術的基盤があれば、注意深く洗練されたアーキテクチャが他人の口の中でゴミになることはなく、後継者や部下があなたのようにため息をつくこともありません。

3. コードが汚くて汚いという事実は最も重要ではありません。優れたアーキテクチャでは、コードがどれほど汚れていても、影響を受ける範囲はそれ自体のモジュールのほんの一部にすぎません。コードがアーキテクチャ全体に影響を与えるほど悪い場合は、次の点を参考にしてください。 a. アーキテクチャの結合度がまだ高すぎますか? b. 非常に重要なタスクを担当できるほど年上ではない人を割り当てていますか?

実際、本物のアーキテクトはコードの最前線から離れることはないと思います。システムの最も困難でやりがいのある部分は、アーキテクトが個人的にコーディングする部分であるはずです。独自のコーディングの結果が満足のいくものでない場合は、所有しているリソースがこのプロジェクトを完了するのに十分であるかどうかを検討する必要があります。プロジェクトが追求する目標は引き下げられるべきでしょうか?

4. アーキテクチャは、低冗長性の過度の追求とパフォーマンスの過度の追求は、実装コストと保守コストの増大につながります。建築家が最初に考慮すべきことはコストです。

5. あなたは建築家ではないかもしれません。それはまったく問題ではありません、誰もが建築家の観点から問題を検討する必要があります。アーキテクトの観点からこの問題を考えると、「汚いコード」と「冗長アーキテクチャ」はより深いレベルの経験を持っているように見えます。一見無秩序に見える巨大なシステムに直面しても、方向性がなく、開始する方法もないと感じることはありません。

要するに、ことわざにあるように、金鉱を未開拓のままにしておくのは無理があるということです。金鉱山があり、その構造がめちゃくちゃな場合にのみチャンスがあります。こんなめちゃくちゃな構造でも儲かるのに、構造さえ改善すればもっと儲かるんじゃないの？ 私たちの TFS にはこのようなシステムがたくさんあります (十数個?! いずれにせよ間違いなく 10 個以上)

それらのほとんどは純粋に手書きです (もちろん、それらは私によって書かれたものではありません。私は尻を拭いて最適化するためにここにいます)。
aspx ファイルをランダムに開くと、数千行の JS が含まれます。js ファイルを開くと、3,000 行以上の JS が含まれます。数千行のJSが何百行もあるのに、書き換えを促したって言ってましたよ～～？ ！
考えないでください、このくだらないものを書くのに 100 人以上の人が数年かかり、今でも毎日大量のコードがインポートされています。

もう本当に耐えられない、もう辞めるしかないよ〜〜。 文句を言うのを減らして、もっと行動しましょう。 混合する場合は複数のモジュールに分割し、パブリック インターフェイスのみを文書化します。これにより、たとえそれがクソだったとしても、変更する方法はありませんが、続行できます。これを変更すると、新しいモジュールを作成して新しい機能を実装できます。これにより、そのクソな部分が将来の開発から切り離されます。 辞職して逃げてください。一刻も早い救済を祈ります。 提案できるものは何もありません、あなたが救えるのはあなた自身だけです。

あなたへの知恵の言葉:

1. 自分の立場にない場合は、政治的なアドバイスを求めないでください。また、十分なお金がない場合は、相談しないでください。問題を探してください
2. 壊れない場合は、簡単にやり直さないでください
3. コードへの執着を取り除くには、どんなに素晴らしくても、汚い修正を行うことも方法です
4.アーキテクチャは、すべての問題を解決できるわけではありません
5. 物事を行うときは人に依存し、物事を行うときは神に依存します
6. 自分に優しくすること、自分自身を改善すること、自分を大切にすること

あなたは理想的だと信じていますし、私もそうですが、あなたの情熱をゴミ箱にこぼさないでください、それは価値がありません。 ジョブホッピング