優秀なエンジニアに必要な3つの考え、継続的に更新
ガイド
さまざまな立場と責任を持つ技術者は、エンジニアの思考の深さについてさまざまな要件を持っていますが、多面的に考えることは、すべての技術者が持つべき品質でなければなりません。実際の仕事では自分の投稿とは関係がないと思われる点や事柄を、誰もが正しく扱うことができればと思いますが、チームの有効性に大きな影響を与えます。
社会的な分業という文脈では、ソフトウェア業界のエンジニアのグループは、開発、テスト、製品などの多くのポジションに分かれており、協力して価値を創造します。ソフトウェアへの依存度が高いインターネット業界は、人々の生活をまったく新しい方法で改善していると同時に、改善の道での価値創造の有効性に対する要求が高まっており、その背後には、個人とチーム間のコラボレーションの有効性に対する要求が高まっています。 。
チームのコラボレーションの有効性をさらに向上させるために、特別な人と専用のポストコラボレーションモデルが直面する最大の課題は、「ポストウォール」にあります。つまり、ポスト間の接続には必然的にいくつかのあいまいな領域があり、これらのあいまいな領域は互いに無視されやすく、注意を失う原因になります。そして、チームの有効性を大幅に低下させました。たとえば、開発エンジニアは、品質保証はテストエンジニアの一方的な責任であると考えます。開発エンジニアは、ユーザーエクスペリエンスではなく、実現要件のみを考慮します。また、このコラボレーティブモデルは、個人の思考やメンタルモデルを固め、ポスト内の個人の思考やマインドを構成するため、ポスト外の内容がよく理解できず、個人がコラボ活動全体に関与します。共感と体系性の欠如があり、それは仕事の幸福に影響を及ぼします。
これらの実際の作業シナリオの読者はなじみがない
と思います。●開発エンジニアは、製品エンジニアが提示するユーザーエクスペリエンス要件が重要すぎると考えています。
●製品エンジニアは、テクノロジーの実装原則を理解しておらず、不合理で根拠のない要件を提示しています（この特別なイノベーションのケースについては、ここでは説明しません）。
●テストエンジニアは、エンジニアリング効率の意味を理解していないため、作業を手動作業に変えます。
●開発エンジニアは、ソフトウェア品質に対する自分の責任について明確ではなく、代わりに自分の作業を行います。些細な作業はテストエンジニアに渡され、快適に実行できます。
●ユーザーは、ハードワークによって開発された使いにくい機能について不満を漏らします。
これらの問題の最終的な結果は、チームワークの効率が低いことであるに違いありません。では、専任の担当者よりも優れたコラボレーションモデルがない場合、チームのコラボレーションの有効性を向上させるために、個人の力をどのように活用できるでしょうか。改善の出発点は、エンジニアの思考を包括的に整理し、個々のエンジニアが職場とキャリア開発においてより包括的な思考とビジョンを確立するのを支援し、各エンジニアがコラボレーションの過程で個々の能力を最大化してチームのコラボレーション効率を促進することを奨励することです。プロモーション。
私はエンジニアの考えを製品、技術、エンジニアリングの3つの考えに分解します。次の図に示すように、各ディメンションの主な関心事はいくつかのキーワードで表されます。以下では、図の上から下の順に、それぞれの考え方に注意が必要な単語を説明します。キーワードによる説明ですので、段落間のつながりが鈍く見える場合がありますので、ご容赦ください。
製品思考
製品思考の起源は、ユーザー（または顧客）の価値です。ユーザーの価値は、技術的な手段を通じて、ユーザーの問題点を解決したり、製品やサービスの形でさわやかな点をもたらしたりすることです。間違いなく、エンジニアは日常業務における自分の仕事とユーザー（または顧客）の価値との関係に常に注意を払い、明確にする必要があります。また、ユーザーの価値に焦点を当てて、仕事に優先順位を付け、エネルギーを割り当てる必要があります。
ユーザーの価値が十分である場合、製品が市場で足場を築き、真にメリットを享受できるかどうか、最初のテストは製品のユーザーエクスペリエンスです。優れたユーザーエクスペリエンスは、ユーザーの視点に基づいて、ユーザーの心に基づいてコンセプトを形成する必要があります。コンセプトには理解と解釈のコストがかかるため、コンセプトは十分に軽く、小さく、理解しやすいものでなければなりません。コンセプトが形成されると、コンセプト間の関係も決定されます。これらの関係は、基本的に製品とユーザー間の相互作用プロセスを決定します。優れた製品は「使いやすい」という言葉で具現化されており、その究極はユーザーの本能的な反応に応え、さまざまな生活や職業上の常識に準拠することです。
すべての製品には進化の過程があり、作成されたユーザー価値は絶えず探求され、探求されています。その時点で、さまざまな洗練された価値が製品の特性を通じて区別され、表現される必要があります。機能は製品の差別化の現れでもあり、機能はソフトウェア実装レベルで機能モジュールの境界を間接的に決定します。開発エンジニアは、製品の特性を完全に理解し、それらを抽象化してソフトウェア実装レベルで機能モジュールに変換できる必要もあります。2B製品に非常に必要な販売を実現するには、販売ライセンスやその他のフォームを通じて機能のオン/オフを検討する必要があります。
製品をより良く進化させるためには、閉ループデータの形でユーザー価値を生み出す効果をテストし、製品の開発、運用、マーケティングをターゲットにできるようにする必要があります。製品価値創造の道で、最も怖いのは、頭を下げて追加を行うことです。多くのことを行いますが、誰も結果を気にしません。また、データベースのクローズドループの形式を通じて、製品チーム全体がコアバリューに集中できるだけでなく、チームがユーザーバリューを探求する道を合理的に差し引くのにも役立ちます。ほとんどの場合、減算は加算よりもはるかに困難です。
技術的思考
技術的思考の源は需要です。需要は、市場需要、システム需要、機能需要など、さまざまなレベルに分けることができ、技術レベルで「何をすべきか」という質問に答えます。明らかに、明確に表現された要件と要件の正確な理解により、物事が正しく行われることが保証されます。間違いなく、要件の逸脱によって引き起こされる無駄は非常に深刻であり、そのため、エンジニアは要件の品質を非常に重要視しています。
要件が確立されると、モジュール性のアイデアに基づいて複数の機能モジュールに分割され、実装のローカルの複雑さが軽減され、最後にすべての機能モジュールが「スプライス」されて、全体的な要件が達成されます。各機能モジュールは個人またはチームに割り当てられます。機能モジュールは要件分解の結果であるため、エンジニアは実装プロセス中に「ツリー」のみを表示し、「フォレスト」を忘れるのは簡単です。
パフォーマンスは、機能モジュールを実装するときにエンジニアが注意しなければならないことです。特に、機能モジュールが高周波で時間に敏感で、計算能力が限られている状況で使用される場合はそうです。実際には、技術力を反映して究極のパフォーマンスを追求したいエンジニアや、パフォーマンスを追求するのが早すぎて過剰設計と誤解されているエンジニアもいます。
正式なチームが通常、プロジェクトベースの複数の反復方法で機能モジュール開発作業の提供を完了することは間違いありません。多くのエンジニアはここで誤解を持っており、機敏な思考によって提唱されている「プロジェクト計画の目的は変化に適応することである」ことを忘れていますが、「時間通りに配達する」ことは義務であると考えています。 「鶏の羽の場所」の光景を見ました。
第4の産業革命への道のりで、人工知能、ビッグデータ、機械学習、Kubernetes、Istio、Knative、Go、Dart、Flutter、およびその他の新しいテクノロジーは、エンジニアが習得したスキルに影響を与え続けています。テクノロジーの反復的なペースにすばやく追いつくことは、プロ意識を継続的に向上させる意欲的なすべてのエンジニアのパフォーマンスの1つです。エンジニアは心の中で新しいテクノロジーの追求を欠いてはならず、彼らが習得したテクノロジーがある程度進歩することを望んでいます。
エンジニアリング思考
エンジニアリング思考の出発点はプロセスです。プロセスの背後には科学があり、確立されたステップと段階的な入力/出力によって価値の創造を完了し、プロセス制御によって最終結果が満足のいくものになるようにします。プロセスには各エンジニアの作業品質と効率が関係するため、その意味は定義、工具、検査などだけでなく、プロセスをエンジニアの作業環境とシームレスに統合するために、エンジニアの日常の作業習慣に基づく必要があります。プロセスで具体化された「シームレス」の概念は、価値のない負担を加えることなく、それでも使いやすさを保証することなく、エンジニアコミュニティによって確立された専門的な常識と一致しています。
このメカニズムの意味は、解決すべき問題を分析することにより、モードで同様の問題を解決することです。このメカニズムは、「頭痛は頭を治し、足の痛みは足を治す」ではなく、ある程度の体系性を反映する必要があります。体系性は最初から見ることはできません。進化の過程で徐々に発見され、改善される可能性があります。そのため、エンジニアは作業プロセス中に時々確認して実践する必要があります。エンジニアにとって、このメカニズムは体系的なソフトウェア設計によって実現されます。
製品の品質は、エンジニアの仕事や生活の幸福を直接左右すると言えます。信頼性の低い品質の製品は、間違いなくユーザーやエンジニア自身に問題を引き起こし、取り返しのつかない経済的損失や社会への悪影響さえ引き起こします。エンジニアにとって、それは個人の仕事と生活のリズムを混乱させるに違いありません。製品の品質を信頼できるものにするためには、ユニットテスト、静的分析、動的分析などのプロジェクトの品質を確保する手段をエンジニアの基本的な作業内容にする必要があります。これらの手段をCI（Continuous Integration）プロセスと統合して、ソフトウェアを継続的に構築します。製品品質の信頼。
インターネット業界では、ソフトウェア製品の信頼できる品質に加えて、リスク管理も無視できないコンテンツです。制御可能なリスクは、体系的なメカニズムと信頼できる品質に基づいています。これは、サーバー側のソフトウェアにも当てはまります。リソース使用の極端なシナリオでは、リスクがしばしば発生します。外部からのトランザクションの流入がソフトウェア製品の処理能力をはるかに超える場合、製品全体が比較的スムーズに応答したり、リソースを拡張したり、制限したりするには、特定のメカニズムが必要です。トランザクションに流れ込みます。
ソフトウェアに必要なマシンコストは、比較的見過ごされがちなトピックです。ソフトウェアコストは、ソフトウェアのパフォーマンスだけでなく、ソフトウェアの依存関係や技術的なソリューションなどの要因にも関係しています。ソフトウェアを社内から社外にエクスポートする必要がある場合、コストの懸念を無視すると、コストの問題が発生します。たとえば、特定のソフトウェアを実行するには、膨大な量のコンピューティングリソースが必要であり、その結果として生じる資本支出は、顧客にとって受け入れられない場合があります。
これまで、私が理解していると考えているエンジニアを大まかに紹介してきました。
拡張する
エンジニアの考え方を理解することの価値は、個々のエンジニアが日常業務で直面するジレンマや混乱をより包括的な視点で見るために、製品、テクノロジー、エンジニアリングの3つの主要な考え方を徐々に確立する必要があるということです。単一の思考から直面する問題を見ると不合理に感じるかもしれませんが、3つのレベルの思考から得られた結論は完全に反対である可能性があります。チームワークの観点から、チーム内に複数の次元から考えている個人が多い場合にのみ、ポジションが接続されている無人の灰色の領域を見つけ、サプリメントとアシストを使用し
てチームのパフォーマンスを最大化することが容易になります。有効性。
明らかに、異なる立場と責任のエンジニアは、これら3つの思考の深さについて異なる要件を持っていますが、複数の次元から考えることは、すべてのエンジニアが持つべき品質でなければなりません。