技術者として成長するための手段の一つ

最近、業界の友人数人が私といくつかの仕事方法について話し合ったのですが、その雑談は今日は特にすることがないので、私の仕事方法を簡単に説明します。 (エイリアン風) 。もちろん、エンジニアにはそれぞれ独自の成長方法があるので、興味がある方は娯楽として以下をご覧ください。

1. 適切な関心点を見つける: 自分自身を知る

初心者プログラマーとして、仕事が A であると感じるためには、まず何から始めるべきかを明確に理解する必要があります。とても嬉しい事！

テクニカル エンジニアとして、次のような多くのキャリア オプションを選択できます。

• Web フロントエンド エンジニア (FE とも呼ばれます。企業によっては、より詳細な職種もあります) 、Html/Css エンジニア、JavaScript エンジニアなど)
• バックエンド エンジニア (RD とも呼ばれます。例: PHP エンジニア、Java エンジニアなど)
• クライアントサイドエンジニア (iOS エンジニア、Android エンジニアなど、RD として分類される企業も増えています)
• データ分析とマイニング (BI または DI と呼ばれる企業もあり、通常は製品数は少なくなります)ビジネス、主にビッグ データの分析と処理を行います。C またはシェル スクリプトがさらに使用されます)
• テスト エンジニア (QA とも呼ばれ、主にさまざまな製品機能のホワイト ボックス/ブラック ボックス テストと潜在的な発見を担当します)
• データベースエンジニア（DBAとも呼ばれ、オンライン運用保守エンジニアの一種ですが、主に各種データベースの管理を担当します）
• 運用保守エンジニア(OPとも呼ばれ、主にさまざまな開発、テストを担当します。オンライン環境の運用と保守はオンラインサービスの安定性を保証します。コマンドラインで最もよく使用される役割でもあります)

それぞれの役割には異なる労働条件が必要であり、コードを書くことで得られる達成感も異なります。

新人プログラマーとして、自分が書いたコードをユーザーが最も直感的な方法で見て触れられるものに変えて、仕事で達成感を得て恋に落ちることを望むのであれば、この仕事ならWebフロントエンドエンジニアかクライアントエンジニアを選ぶのが良いでしょう。

毎日、コマンド ラインを使用してオンラインでサーバー間を移動したい場合は、他の人が理解できないコマンドを大量に入力し、他の人が理解できないスクリプトを大量に作成します。達成感があり、より有能であると感じることができるので、運用保守エンジニアを選んだのは間違いではありません。

一部の新卒学生にとって、就職のために履歴書を提出する前に、自分が何をしたいのかを理解することが非常に必要です。もちろん、ほとんどの学生はキャンパス内での採用活動を通じて入社します。入社後に行うべきことは、すべて会社によってランダムに割り当てられることです。このグループの学生の場合、入社後一定期間内に仕事に興味のある点が見つからない場合は、他のチームへの異動を申請することを真剣に検討する必要があります。

仕事は、家族を養うためにお金を稼ぐためのツールであるだけでなく、何かをして成長する喜びでもあるべきです。たとえそれがどんなに大変でも、好きなことをすることにはそれだけの価値があります（誤解しないでください：私はすべての人に残業することを勧めているわけではありません、笑）。

2. 沈殿物に注意を払う: 自分自身を豊かにする

沈殿物は、あなたが何かを獲得したことを証明する最も直接的な方法です。それは、文書の沈殿物、テクノロジーの沈殿物などです。 🎜>

作業プロセス中に、技術的な調査、ソリューションの分析、レビューを必ず行います。これらの内容は、慎重に文書にまとめて 1 か所 (チームの Wiki コラムなど) にまとめることができます。レビューに移動すると、グループ内の他の学生も閲覧できます。

いくつかの大規模なプロジェクトを実行する過程で、ある種の問題に対して多かれ少なかれ優れた解決策が作成されます。それは、高パフォーマンスの実装方法や高効率のデバッグ スキルなどです。これらは、少しの努力で、クラス ライブラリまたはツールとしてグループ内の他の生徒に提供でき、蓄積する技術ポイントとして使用できます。

簡単に言うと、次の原則を理解できます。

• 文書による記録を使用して物事を行うことができる場合は、口頭だけに頼らないでください。口から伝えられ、徐々に形が崩れてしまいます。よく言われるように、良い記憶力は悪いペンほど良くはありません。

• コンポーネントまたはクラス ライブラリに抽出できる、使いやすく実用的な技術実装メソッド。最大限に再利用可能にし、詳細な使用方法ドキュメントとして添付します。できるだけ！同様の機能を求めてグループ内で車輪の再発明を繰り返さないでください。

• もっと読んで、もっと書いて、もっと研究してください (時には遊び心のある姿勢で学ぶことも必要です) しかし、テクノロジーの分野で働く人にとっては、実際の成果がなければ、それは意味がありません。ただいじっているだけですが、理由はわかりませんが、効果は良くありません。

個人的には、Baidu であろうと Meil​​i.com であろうと、私が解決できること、または皆が解決できることはすべて役に立ちます。一緒に解決してください、私はそれを手放しません。

たとえば、ドキュメントに関しては、チーム固有のドキュメント プラットフォームを構築しました。これには、プロジェクトの設計と実装計画のレビュー ドキュメント、プロジェクトの概要のドキュメントの共有、大規模プロジェクトのスケジュールとリズムのフォローアップ ドキュメントが含まれます。技術調査ドキュメント、チームの技術共有のためのドキュメント、チームの週次レポートのアーカイブされたコラムなどがあります。

テクノロジーの面では、以下に準拠する統合ソリューション、コンパイルツール、開発ツール、フロントエンドおよびバックエンドのオンラインサービス監視および警報システム、バックエンドサービスパフォーマンス監視および分析プラットフォームなどがあります。チーム開発仕様。

テクノロジーを使った遊びという点では、たとえば、Web フロントエンド アシスタント (FeHelper) は、Baidu がフロントエンドに取り組んでいたときに Chrome 拡張機能を使って段階的に開発されました。当時CSDNも中国でChromeブラウザのプラグイン開発コンペティションを開催していて、FeHelperも見事3位を獲得したと記憶しています。

その後、WeChat の公開アカウントが登場し、友人のサークルでの圧倒的な再投稿には 1 つのタイトルしかありませんでしたが、当時は 2048 ミニゲームが PC と Wap で特に人気がありました。それで、私もそれを書きました。WeChat でみんなで一緒にプレイできるようにするという精神で、私は WeChat 公式アカウントに基づいて一連の SDK を作成し、それをこの小さなゲームに適用しました。それ以来WeixinApiを使用しています。 WeChat が js-sdk の正式バージョンをリリースする前に、WeixinApi は多くの人々に恩恵をもたらしました。

他人が見たり触れたりできるものはすべて「降水量」と呼ばれ、価値を測る基準となります。

3. プロジェクト リーダーになる: 自分自身を訓練する

リーダーの命令を受け入れ、単独で製品の機能を完成させてオンラインに公開できるようにする。

いつか自分で製品の機能に責任を負えるようになったと感じたら、メンターやリーダーの支援はもう必要ありません。その後は、より包括的な次元から始めて自分自身を体験してください。率先してプロジェクトを開始し、プロジェクト リーダーとしてそれを最後まで実行してください。

少なくとも次の側面からより多くのことを獲得し、より多くの達成感を得ることができます:

• ニーズを分析し、プロジェクトに何が必要かを決定する 関連する役割

• さまざまな役割を組織してプロジェクト要件を検討し、製品機能の技術的実現可能性、時間コストなどを分析

• 要件を評価 機能モジュールを合理的に分割フロントエンドとバックエンドのエンジニアの作業範囲を実装します

• フロントエンドとバックエンドのエンジニアを組織して技術的解決策を検討し、優先順位を付けて分割する必要があるかどうかを判断します要件で指定された起動時間に基づいてバッチに分割

• を実行します。 合理的な分業を実行し、研究開発スケジュールを出力し、共同デバッグ、セルフテストのテストスケジュールをまとめます。 、QA、およびプロジェクトスケジュールを均一に出力

• プロジェクトの進捗状況を追跡し、スケジュールされたレビューに基づいてプロジェクトの出力をレビューし、リスクポイントを迅速に発見し、タイムリーに調整して報告します

• 大規模なプロジェクトの場合、プロジェクト全体の円滑な進行を確保するために、定期的なスタンドアップ ミーティングを開催することがさらに必要です。

• プロジェクトのプロセス中、一時的な新しい要件、要件の変更、または技術実装計画の調整がある場合、すべての役割を明確な方法で分析し、全体的な状況を見て、全体的な立ち上げ要件を組み合わせることもできる必要があります。

• テストの初期段階では、技術実装のために QA でテストの核となるポイントを明確にする必要がありますより複雑な領域の場合、不完全なテスト ケース カバレッジを避けるために、テストの強度を明確に通知する必要があります。

• プロジェクトがオンラインになる前に、すべてのオンライン環境の展開と構成を次の手順で完了する必要があります。運用および保守エンジニアがプロジェクトを確実にオンライン化できるようにします。多くのエッジ製品が関係するプロジェクトの場合は、プロジェクトのテストが完了した後、災害復旧計画を検討する必要があります。製品の需要が大きい場合は、製品に連絡する必要があります。社内エクスペリエンスを実施するか、オンラインの低トラフィック (グレースケール) テストを実施するかをクラスメートと話し合い、合理的な問題フィードバック チャネルを提供し、ユーザー フィードバックを収集して整理し、迅速に最適化します。 🎜>

• プロジェクトの開始 その後、サービスの安定性に細心の注意を払い、ユーザーからのフィードバックに注意を払う必要があります。安定した後は、オンラインでプロジェクトを報告できます。

• プロジェクトチーム内のすべての役割を整理してプロジェクトの概要を作成し、プロジェクト協力プロセスで発生した問題を分析し、プロジェクトでの適切な問題処理方法を記録します。 、最後にプロジェクトの概要をチームと共有して、プロジェクト全体を終了します。

• あなたがリーダーである限り、プロジェクトに問題があれば、リーダーは必ずあなたに質問します。プロジェクトのプロセス全体を通して、必ずプレッシャーがかかります。しかし、この一歩を踏み出す勇気がなかったら、自分の能力をどうやって知ることができるでしょうか？
  だから、果敢に挑戦してください。チームは、責任を持って率先して行動する人を間違いなく好みます。

4. 指導者になる: 人々を教育することを学びましょう

すべての成熟した仕事のやり方を他の人に教え、また新人にも内省をしてください

素晴らしいやり方ですより多くの人が優秀になるために費やす時間を短縮できるように、物事を行う方法を広めるべきです。職場では、成長してからメンターになり、次のような新入社員が一緒に成長するのを手助けするのが最善の方法です。

• 新入生の仕事能力、ビジネス範囲、技術力を組み合わせる興味のある生徒の成長プロセスにおける本当の抵抗 (または盲点) を一緒に分析します

• 新入生の短期、中期、長期の成長計画をカスタマイズします。定期的に成長の利益と損失を確認し、タイムリーに修正を加えます

• 新入生を連れて、現在の仕事の能力を超えた何か (ビジネス機能、技術的なトピックなど) に挑戦し、支援します新入生は自分自身に挑戦し、徐々に自分の能力の限界を突破していきます

• 手放すことを学び、指導とバックアップのサポートを提供し、新入生に一つのことを完全に完了させてください。つまずいても、成長の過程では誰しも浮き沈みを経験するはずです。風と雨がなければ、どうやって虹を見ることができるのでしょうか。

• 新入生がドキュメントや技術的な側面を蓄積するよう指導および促し、新入生がチーム内で自分のポジションを見つけてしっかりとした足場を築くのを支援します

• 新入生が共有することを学び、他の役割とのコミュニケーション スキルを学び、プロジェクトの全体像をコントロールすることを徐々に学ぶように指導します

もちろん、あなたも成長する必要があります。新しい人が十分にうまくやっていないのは私のせいでしょうか？その新人は素晴らしい仕事をした、私は称賛に値するだろうか?

• 新人は、ある業務をうまく遂行できませんでした。事前にプロジェクトの実施計画を見直しませんでしたか?それとも、あなたが彼に与えた計画に何か問題があるのでしょうか？

• その新人さんは、あるプロジェクトで大幅な遅れをとっています。私が彼のプロジェクトの進捗状況をもっと確認しなかったからでしょうか?それとも、プロジェクトの立ち上げ計画が何なのか理解できていないのでしょうか?

• 新人のプロジェクトにバグが多すぎるのは、私がメンターの指示に従い、適切なコードレビューを怠ったためでしょうか?それとも、いつものプロジェクトには頻繁にバグがあり、新人はそれに倣うだけですか?

• 新人は他のキャラクターの前ではいつも無口です。彼に自分の考えを表現するように指示しませんでしたか。大胆に？それとも、写真を撮られるのが怖くて、人前であまり話す勇気がないのでしょうか？

• 新人は他の登場人物とコミュニケーションをとるときに常に衝突します。彼にもっと良いコミュニケーション方法を教えませんでしたか?それとも私は他人とコミュニケーションが取れず、他のキャラクターとトラブルになることが多いのでしょうか？

• その新人さんは、とても工夫した方法で見事に完成させ、みんなから褒められました。それとも、この出来事から、自分が新しいクラスメートほど優れていないことに気づき、お互いから学ぶ必要があると思いますか?

• 新しいクラスメートは、彼が学ぶことができるように、率先してあなたと 1 対 1 でコミュニケーションを取り、成長の総括と自己批判を行います。積極的に学ぶには？それとも、自分にそのような主体性があり、批判や自己批判ができるかどうかを考える必要がありますか？

• 新しいクラスメートのことを十分に知っていますか?あなたは自分自身のことを十分に知っていますか？

良い指導者よ、突然 Qing が Lan よりも優れるようになることを心配しないでください。これは良いことであり、これが彼の能力であり、それがあなたの能力だからです。もし彼が本当にランに勝つことができるなら、それは彼が十分に優れていることを意味し、私たちがより早く成長できるように、良い人々と一緒にいることを学ばなければなりません。

5. 業界の動向に細心の注意を払う: 高いところに立つことによってのみ、遠くを見ることができます。

技術革新は非常に急速であり、プロジェクトの成果だけに依存してはなりません。自分自身を豊かにし、向上させてください。コーディング コミュニティには賢い人が多すぎるので、優れた技術的なアイデアをすべて吸収する必要があります。

徐々に、自分を技術責任者とみなす必要があります。もちろん、条件が許せばチームの技術責任者になることもできますし、チームがより詳細な方向に分かれている場合は、特定の事業方向を担当する技術責任者になることもできます。

チームが業務中に遭遇した技術的問題のいくつかを分析し、要約して分類します。インターネット業界の発展以来、チームが遭遇した問題のほとんどは他の企業でも経験しているはずです。より成熟した企業やより成熟したテクノロジー チームがこの種の問題を解決するためにどのような方法を使用しているかをさまざまなチャネルから理解する方法を見つけてください。それらを真似することはできませんが、少なくともそこからより多くの洞察を得ることができます。

新しいテクノロジーは、特に Web フロントエンドで非常に速く更新され、新しいソリューションが登場するまでにそれほど時間はかかりません。テクノロジー愛好家として、業界の動向に細心の注意を払って、他の企業が何をしているのか、なぜこれほど多くの新しいフレームワーク、クラス ライブラリ、ツールなどが存在するのかを確認する必要があります。たとえば、次のように理解します。

• jQuery が登場する前は、誰もがネイティブ DOM を使用して関数をうまく開発できました。では、なぜ jQuery が登場したのでしょうか。それはどのような問題を解決すると思われますか?プロジェクトで使用する場合と使用しない場合の違いは何ですか?

• jQuery はすでに非常に使いやすいのに、なぜ Baidu WebFE は以前に社内で Tangram を構築したのでしょうか?それは単に車輪の再発明をしているだけなのでしょうか、それとも実際にさまざまな API のカスタマイズされたパッケージを実装できるためでしょうか? jQuery のベテランにとって、Tangram を使用する場合の違いは何ですか?

• 後にみんなが絶賛したAngularJS、Backbone.js、Ember.jsとは一体何なのでしょうか？どの会社のどのチームがどのような課題をもとに作ったのか？特定の製品機能のためだけにこれらのツールを使用しているのでしょうか、それとも一般的なソリューションとして存在しているのでしょうか?自分のプロジェクトチームに導入したい場合、本当に適用できるでしょうか?そこからあなたはどのようなインスピレーションを得ることができますか?また、他の人は何を学ぶことができますか?

• Nodejs が表示されるのはなぜですか? io.js がブランチとして個別に開発されるのはなぜですか?なぜ後でまた合併したのでしょうか？

• もう 1 つの例は、今年普及するであろうクロスプラットフォームのモバイル開発ツール、PhoneGAP、Titanuim、Xamarin、および React Native です。なぜ同じ問題を解決するものがこれほどたくさんあるのでしょうか。そしてそんなに更新が早いのですか？ようやく世に出た製品は先人の優れた性質を備えているのでしょうか？どのようなユーザーグループをターゲットにしているのでしょうか?なぜこれほど大衆の間で人気があるのでしょうか？彼らとネイティブの違いは何ですか？

• PHP 7 がリリースされましたが、最初にサービスを開始したときに PHP 5.3.29 を使用したのはなぜですか? PHP を最新バージョンにアップグレードするには、コードの互換性を確保する必要がありますか?以前と比べて開発に変化はありますか？パフォーマンスの向上によってサーバーの数を大幅に減らすことができますか?

• 全文検索エンジン Sphinx と Solr とは何ですか?インデックス作成の効率、検索パフォーマンス、中国語単語分割のサポート、およびリアルタイム インデックス作成のサポート、これらの点の違いは何ですか?プロジェクトで使用する必要がある場合、実際のニーズに基づいてどちらを選択するのがより適切ですか?

• 別の例として、あなたのチームは、すでに市場に存在する Zabbix、Nagios、Open TSDB、または Open Falcon の多次元監視を行う必要があることをご存知ですか。これらはどのレベルで監視されますか?オンラインでの展開とアプリケーションのコストはいくらですか?その後の水平方向のスケーラビリティについてはどうでしょうか?自分で書きたい場合は、まず明確な監視レイアウト図を描くことができますか?

つまり、空いた時間に技術的な視野を広げ、Github や国内外の才能ある人々のブログをもっと閲覧して、他の人がどのような問題に遭遇し、どのような問題に直面しているのかを確認してください。この種の質問については、さらにいくつかの仮定を立ててください。この問題に遭遇したら、どうしますか?

6. もっと考えて、もっと行動する: 自分の能力を証明する機会を増やす

会社は老人ホームではありません。給与を支払うためには、価値を創造する必要があります。どのような仕事 (製品の機能、技術システム、一連の開発仕様、または一連の作業プロセス) にも必ず問題があり、より多くのことを考え、より分析し、問題を見つけて解決することでのみ、価値を生み出すことができます。私たちも成長するために！

もしかしたら、あなたのチームは混乱のようなもので、同僚は文句を言うのも怠け者で、仕事を終わらせてオンラインにすることだけを気にしているかもしれません。おそらく、あなたのチームではすべてが順調に進んでおり、同僚は和気藹々としており、仕事の後は話し合って笑い、非常に幸せで満足しているでしょう。

しかし、世の中に 100 点の人は存在しません。もちろん、100 点のチームも存在しません。誰もが欠点を抱えており、チームも同様です。乱雑なチームに怖気づいたり、チームがとても良さそうだから始められないと考えたりしないでください。

• いつもの開発方法は何ですか? 反復的な肉体労働をしていますか?もしそうなら、これを自動化するためのツールを開発できるでしょうか?

• 各学生が独自の開発システムを持っている場合、そのようなコードを保守するのは間違いなく困難になります。チームには古い人も来ますし、さまざまな種類の新しい人も来ます。コードの数について、文句を言わない理由はありますか？実際の実装を促進し支援するには、開発プロセスと仕様に統一された標準が必要です。

• オンライン技術システムは巨大なため、簡単には調整できないため、新しい機能のために常にパッチが適用されているというのは本当ですか?時間が経つにつれて、チーム内のすべての生徒はパッチについてのみ知っているようになり、その実際の機能や実際の動作原理については知ることができなくなります。したがって、私たちが率先して核となる部品を再編・再配置して分離し、適切な機能を発揮させる第一歩を踏み出さなければなりません！そして詳細なドキュメントも付属しています！

• 業務システムが肥大化しているのは、皆が現在の開発、テスト、デプロイなどのやり方に慣れているため、垂直分割をやりたがらないからでしょうか？このようなシステムが作業効率を低下させている場合は、それを整理して修正し、機能的に独立した、小さくて美しく、業務運営が明確で、プロジェクト間で競合が発生する可能性が低く、保守性が大幅に低い複数のサブシステムに変える必要があります。改善されました！同時に、チームは各サブシステムに異なる所有者を割り当てることが推奨されます。

• 上記の技術チーム自体に問題がない場合は、製品機能のオンライン サービスの安定性を検討できます。オンラインでアラームが頻繁に鳴りますか?すべての業務ログは正常ですか?ユーザーは、よく使用される機能に関して頻繁にフィードバックや苦情を抱いていますか?つまり、ツールを使用して自動的に監視し、警報を発することができるのであれば、それを解決するために物理的な力を使用する必要はありません。ツール プラットフォームを使用して、運用担当者や製品担当の学生が問題の原因を自己チェックできるようにする場合は、研究開発部に手動でそれを行わせてはなりません。

落ち着いて、小さな点から分析を開始し、問題を発見し、それを解決するために利用可能なすべてのリソースを使用する意欲がある限り、小さなことを恐れないでください。一つずつ積み重ねていくと、自分の価値が反映できるようになる 上司が求めているのは「あなたのおかげでチームが良くなる！」しかし、あなたの利益はお金だけで測ることはできず、他人が奪うことのできない財産です。

7. チームのリーダーシップ: 標準化とプロセス

もちろん、2 人の兄弟が働いている場合、誰もがチームリーダーに昇進する機会があるわけではありません。良好な関係を築いていれば、彼らはあなたにチームを引き継いでくれるでしょう。あなたの普段の仕事は、あなたがこのチームを率いて一緒に発展する能力があることを十分に証明しているはずです。

もちろん、私の意見では、管理職としての肩書きよりも、今やっていることがチームを率いることである限り、物事を行うことの方が重要です。それはマネージャーの肩書きであり、まったく重要ではありません。中小企業の技術責任者が大企業になると、正直に研究開発の最前線でやらなければいけないこともありますよね。本当に優秀なのに会社で不当な扱いを受けて辞めてしまったら、会社にとっては損失でしかありません。だから、ただ正直にやれば、来るべきものは自然にやってくるのです。

ビジネスチームおよび技術チームのマネージャーとして、少なくとも次のことを行う必要があります:

• チームが担当する各ビジネスに応じて明確な計画を立てる、同じ釜の飯を食わないでください、少数のチームで働く方が良いです; エリートチームはより強い責任感を持ち、誰もが自分が何をしたいのかをより明確に知っています。

• 各ビジネスラインには明確なニーズの範囲があり、グループ内の各チームの作業をよりスムーズに実行できるように、部門間のニーズには明確な境界線が必要です

• グループ内の各小さなチームは、統一された開発仕様を持っている必要があります。外に出る前に、まず落ち着く必要があります。自分のチーム内の開発仕様が混乱している場合、どのようにしてインターフェイスを提供すればよいでしょうか。第三者部門との統合は可能ですか？

• グループ内の各小規模チームは、プロジェクト全体のプロセスを統一する必要があり、すべてのリンクで実際の成果 (降水量) に焦点を当てる必要があります

• このグループは、パブリック コンポーネント ライブラリ、クラス ライブラリ、およびパブリック サービス レイヤーを蓄積する必要があります。これは間違いなくチームのバックボーンを形成し、開発作業のほとんどはそれを中心に展開できます。チーム内の誰もが何も考えずに直接完了できる要件があれば、それで十分です。

8. チームの育成と発展: 健全で持続可能な発展

10 人以上のチームは、効果的な階層構築と全方向のチーム構築を考慮する必要があります。ビジネス＆テクニカルリーダー研修

• 各事業方向のチームリーダーを育成し、担当者が独自のバックアップを構築する

• チーム内に技術ディレクションの責任者を育成し、チーム内でより代替的な技術ソリューションを継続的にアウトプットする

• リーダーを先頭にチーム内で良好な指導体制を形成するディレクション担当者が最前線の研究開発をリードすると同時に、階層をフラット化し、バリアフリーなコミュニケーション・報告の仕組みを構築することも必要です。

  週に 1 回以上の機会を確保するための毎週のチーム会議システムがあり、全員を集めて過去 1 週間のチームのプロジェクトの全体的な状況と来週の作業リズムを把握できます

• 少なくとも週に 1 回、大規模プロジェクトの技術実装計画の共有とレビュー、プロジェクトの概要の共有など、優れた技術共有メカニズムをチーム内で形成する必要があります。大規模なプロジェクト、またはプロジェクトにおける特定の人物の共有、技術的なポイントの詳細な分析とアプリケーションの紹介、特定のツール プラットフォームの構築アイデアや動作原理の分析である場合もあれば、さまざまな議論である場合もあります。仕事で必要不可欠なスキル (セクシーなスキル)、または業界の最先端テクノロジーの調査レポート分析である場合もあります。また、いくつかの新しいテクノロジーの体験である場合もあり、チーム間または会社間の技術的なものである場合もあります。交換。つまり、このチームにはやるべきこと、学ぶべきことがあると全員が心から感じられるようにする必要があります。

• 生徒の問題を解決するために不定期で 1 対 1 のコミュニケーションをとり、問題があれば直接指摘し、釣り方を教えます。生徒の成長を助けるのはメンターとリーダーの責任です。

• 会社は、怠惰な人をサポートせず、優秀な人材がいる場合にのみチームが健全かつ持続的に成長することができます。

• 大なり小なりチームビルディングを時々行う 全員が集まって仕事以外のことも話し合えるような環境づくりが必要です。身体的にも精神的にも幸せだと感じているのに、良いコードを書けないことを心配する必要はありません。

リーダーとして、自分がどのレベルにあるかに関係なく、次のことを考えるべきです。現在行っているすべてのことをいつ自分のバックアップに引き継ぐことができますか?

チームの現状から自分自身を完全に切り離すことができて初めて、チームにとってより重要なことを考える機会が得られます。これはバックアップの機会でもあり、自分自身にとってもチャンスです。

9. 他のテクノロジーを学ぶ: クロスボーダー、フルスタック

よく言われるように、スキルが多すぎる場合は、より技術的な知識を身につけるべきです。いつか、あなたはできるようになります。 見知らぬ戦場に行くことは、何も怖いことではありません。

もちろん、成長する技術エンジニアにとってフルスタックは必須の道ではありませんが、テクノロジーの 1 つを深くマスターした後は、より広い視野を持つことは常に良いことです。

フロントエンドをやるとして、フロントエンドチームが完全に抱えて、徐々にバックエンド、サーバー、クライアントに関わっていくというやり方が実はあります。同じ。すべてのテクノロジーを再度学習するのに時間を費やす必要はありません。この分野のコアテクノロジーを理解し、動作原理を習得し、他の分野との違いを理解できれば十分です。

自分の能力が限られていて、ある分野が得意で、同じやり方でそれを極めれば、他の技術分野もそれほど難しくありません。

過去数年間の仕事を振り返ると、最初は Java、次に VB.Net、次に C#.NET、そして Web フロントエンドに取り組み、その後 3 年間続けて iOS を学びました。その後、Android に戻り、引き続き Web フロントエンド チームを率い、次に PHP バックエンド チームを率います。正直に言うと、その方法が正しければ、物事はより簡単に処理できるでしょう。