実務経験7年のフロントエンドスーパーバイザーによる経験共有

実務経験7年のフロントエンドスーパーバイザーによる経験共有

今日はベテランの貴重な経験を共有します。著者は技術管理の経験が7年あり、多い時は80人以上を率いていました。現在は360で働いています。この記事は長年の仕事での彼の個人的な経験をまとめたものであり、決してチキンスープではありません>>>

この記事の著者は@十年馳迹です。著者の許可がない場合は寛大に扱ってください。よろしくお願いします:)

私は 7 年間にわたり技術管理に携わっており、7 ~ 8 人のフロントエンド チームから、複数の技術監督者を擁する最大 80 人以上のチームまでを率いてきました。自分がどれほど成功しているかは、途中でつまずいたため、あえて言うことはできません。管理と技術は異なるものであり、その多くは些細なことなので、技術に集中する方が得意だと常に感じています。コーディングがトラブルよりも喜びをもたらすのであれば、技術管理はまさにその逆です。しかし、私たちの人生は楽しみのためだけではありません。時々、テクニカル マネージャーよりもテクニカル エキスパートとしてフロントエンドに貢献できるのではないかと考えます。理屈から言えば、そうではないかもしれません。1 人の力には限界があります。この時代、フロントエンドに才能のある人材が不足することは明らかです。多くの場合、私たちは一人で戦っているわけではありません...

さて、文句を言い過ぎたので、実用的な話を始めましょう。

技術者とマネージャーの違いは何ですか?

技術レベルはさておき、優秀な技術者になるために一番大切なことは、自分の強みを知り、それを生かすことが得意だと思っています。優秀な技術者の多くは、これを熟知し、得意としているので、特徴や強みがはっきりしていて個性があることが多いです。有能なマネージャーにとって最も重要なことは、自分の長所を生かして自分の個性を宣伝することではなく、自分の短所を認識して自分自身を改善することです。その上で、他人の長所を知り、それを生かし、短所を許容することが得意でなければなりません。上記の比較から、技術とマネジメントは実際には同じ次元のものではないことがわかります。また、多くの優秀な技術者がマネジメント職に転向する機会があったときに苦労するのも、思考の転換ができず、スキルポイントが正しく加算されないためであることがわかります。

自分が魚でないのに、どうして魚を知ることができるでしょうか?

川を渡る小さな馬の寓話を覚えていますか? リスは水が深いと思いましたが、年老いた牛は水が浅いと思いました。どちらが正しかったでしょうか? 技術管理者が犯すよくある間違いは、自分の感情をチーム メンバーの感情と置き換えてしまうことです。

「こんなに簡単なのに、なぜ『彼』はできないんだろう?自分でやったほうがいいかも。」

「こういうことはとても面倒で、やりたくないし、下の兄弟たちに迷惑をかけるのが嫌だから、自分でやったほうがいい。」

経営学を学んでいる皆さんは、上記 2 つの状況に遭遇したことがありますか? すべての親が自分の子供のことをすべて知っていると思っているのに、実際には本当に理解しておらず、見ているものは真実からかけ離れているのと同じです。多くの場合、メンバーが辞めようとしているときに彼と話をすると、彼に対するあなたの期待や判断が彼自身の期待や判断と大きく異なっていることに気づきます。この状況を引き起こしたのは誰の過失でしょうか?

生活空間:私たちにできること、やりたいこと、そしてやるべきこと

技術研究、プラットフォーム ツール、プロジェクトのいずれを行う場合でも、技術者とチームが環境内で成長するには、「できること」、「やりたいこと」、「行う必要があること」という 3 つの概念を一致させる必要があります。

できる + やりたい + 必要とされている = コアバリュー

できる + やりたい + 必要とされていない = 潜在的な価値

できる + やりたくない + 必要とされている = ルーチンワーク

できる + やりたくない + 必要じゃない = バックアップ

できない + やりたい + 私が必要 = 成長の余地

できない + やりたい + 必要じゃない = 自己中心的

できない + やりたくない + 必要とされている = できない

できない + やりたくない + 必要とされていない = 気にする必要がない

優れたマネージャーは、メンバーの「潜在的な価値」と「成長の余地」に特別な注意を払います。

実務経験7年!優れたフロントエンドスーパーバイザーはどのようにしてチームをリードするのでしょうか? 123WORDPRESS.COM

チーム開発:依存と頼られること

自由な信頼もなければ、自由な発言権もありません。多くの管理職は、会社や上司が「フロントエンドに気を配ってくれる」ことを期待しますが、実は「フロントエンドに気を配ってくれる」環境を望むなら、自ら努力すべきです。どのようなチームが発言権を持つことができるでしょうか? 答えは簡単です。信頼できるチームです。私が現在率いているチームは、会社の多くの事業を担当しています。ほとんどの事業において、フロントエンドの発言力は大きいです。それは、フロントエンドがその事業や会社全体にとってどれほど重要かということではなく、長期にわたる円滑な協力を通じて、ビジネス側がこのフロントエンドチームがかけがえのない存在であることを理解し、認識できるからです。多くの企業では、以前はフロントエンドが存在せず、フロントエンドの作業はバックエンドの学生が行っていました。一部の企業では独自の独立したチームもありましたが、最終的には例外なく全員が私たちのチームに全幅の信頼を寄せており、私たちもビジネスチームに対して多くの発言権を持っていました。

それはなぜでしょうか? それは、私たちが効率的かつ専門的に、そして責任を持って仕事をしてくれると彼らが期待しているからです。

マネージャーたちは何を犠牲にしたのでしょうか?

前述のように、信頼を築くことはプロセスです。人々やチームは皆、安心感を求めています。選択の余地がない限り、通常の環境は常に現状維持の傾向があります。マネージャーとして、現状維持の慣性を打破して前進するために、馬車を運転することがよく必要になります。どうすればいいのでしょうか。実は、それは非常に簡単です。つまり、チームの開発スペースと引き換えに、自分の安心感を打破するのです。 「給料は自分で決めるものではない」「上司に迷惑をかけたくない」「同僚を怒らせたくない」「迷惑な人やチームと関わりたくない」「上司を喜ばせ、同僚を喜ばせ、他人の要求に盲目的に従う」など、安心感を維持するための言い訳はたくさんあります。

第一のポイントは給与の問題です。多くの技術者は神経質で、自分の給与や福利厚生のために一生懸命働く気がありません。管理職になると、少ない仕事は多い仕事よりも悪いという考えに慣れてしまいます。

2 点目は、クソマネージャーは常にチームの要求を抑え、上司が他人に干渉しない部下を最も好むと思っているかのように、上司を喜ばせようとすることです。

3 点目は、良い人になり、調和が長続きすることです。

4 番目は、他のチームとのコミュニケーションを拒否したり、自分のチーム内で他のチームに関する否定的なニュースを広めたり、保護的な考え方をしたりすることです。

第五に、私たちは需要を止めることはできず、圧力に耐えることができません。

本質的には、チーム マネージャーがチームの成長の余地と引き換えに自分の安心感を犠牲にしたくない (十分な厚顔無恥さがない) ことが、上記の理由です。実際、これは意図的なものではなく、性格や能力の問題であることが多いです。そのため、悪いマネージャーは常に自分自身を標的にしたり、チームを抑圧したりしているように感じることがあります。しかし、実際には、マネージャーはそれに気づいていなかったり、意図的にそうしていないことがよくあります。

20150512 (2) ...

チーム開発 2: 成長の余地

技術開発者として、私が必要としているのは満足できる給料だけです。マネージャーとして、自分のためではなく、チームの成長の余地のために高い給料を要求することがあります(自分の給料を上げる理由、笑)。マネージャーとして、自分のスキル、管理レベル、給与がチームの成長の上限になる可能性があることを認識する必要があります。では、私たちは何をすべきでしょうか? 技術管理者は、テクノロジーに対してもっと危機感を持つべきです。本当にうまくいかない場合は、自分よりも優れたテクノロジーを持つ人を見つけて、支援してもらうべきです。言うまでもなく、管理レベルは時間をかけて磨いていく必要があります。給与に関しては、できるだけ高い給与を得るように努めてください。どうしても高い給与を得られないのであれば、自分よりもはるかに高い給与を得ている人(前述の技術専門家など)を雇ってください。そうすれば、チームメンバーに給与を上げる余地が生まれます。多くのマネージャーは平等主義を好み、チームメンバーの給与を常に平等にしますが、これは実際にはお勧めできません。

マネージャーはなぜ日常生活の細部に注意を払う必要があるのでしょうか?

管理者は従業員のケアなど、細かいことにも注意を払う必要があります。なぜなら、マネージャーは、パフォーマンスやその他のインセンティブ(プラスのインセンティブとマイナスのインセンティブを含む)を自由に利用できるからです。これを積極的に行う方が簡単で、誰もが幸せになります。従業員にネガティブなモチベーションやプレッシャーをかけることは、多くのマネージャーにとって扱いが難しいことです。時には、会社がKPI指向であることを非難しますが、実際には、よく考えてみると、優れたマネージャーの手にあるKPIは単なるツールです。S、A、C、Dのいずれであっても、それらはすべてモチベーションの手段です。CとDはホットポテトではありません(多くのマネージャーはそう考えています)が、日常生活で優しさと厳しさの両方を使用し、チーム内での威信を持ち、チームメンバーに好かれる限り、便利なツールです。報酬を与える方法を知っているマネージャーは 60 ポイントを獲得し、罰を与える方法を知っているマネージャー (効果的な罰は従業員の成長を助け、恨みを生みません) は 90 ポイントを獲得します。

ジレンマ:私たちは上司に対して責任を負うべきでしょうか、それとも部下に対して責任を負うべきでしょうか?

上司は私に、あなたの仕事は上司ではなく部下を助けることだと言いました。あなたが私によく尽くしてくれるのは構いませんが、私が見たいのはチームメンバーによく尽くしてくれることです。

すべての上司が私の上司のように優れているわけではありませんが、理解すべき真実が 1 つあります。それは、物事を成し遂げるために一生懸命働いているのは誰なのか、ということです。上司でしょうか、それとも部下でしょうか。

<<:  Linuxシステムにおけるプロセス管理の詳細な説明

>>:  この記事では、イベント委任を使用してJavaScriptメッセージボード機能を実装する方法について説明します。

推薦する

Div CSS 命名標準 CSS クラスの命名規則 (SEO 標準に準拠)

検索エンジン最適化 (SEO) では実行すべきタスクが多数ありますが、その中でもコードの最適化は重要...

高並列処理 nginx サーバー向け Linux カーネル最適化構成の説明

デフォルトの Linux カーネル パラメータは最も一般的なシナリオに基づいており、高い同時アクセス...

Vueが初めて要素を取得できなかったときの解決記録

序文Vue で要素を初回取得できない問題の解決方法は、ポップアップ ウィンドウで要素を取得するために...

Vue.js のミックスインの詳細な説明

ミックスインは、コンポーネントに分散された再利用可能な機能を柔軟な方法で提供します。 Mixin オ...

JavaScript イベントの概念の詳細な説明 (静的登録と動的登録の区別)

目次js のイベントイベントタイプ一般的なイベントイベント登録静的および動的登録の例onload 読...

Bash の山括弧の深い理解 (初心者向け)

序文Bash には、ls、cd、mv などの重要な組み込みコマンドが多数あるほか、grep、awk、...

CSS の clip-path プロパティの使用方法の詳細な説明

クリップパスの使用ポリゴン値は複数の座標点で構成されます。最初の値は x 方向、2 番目の値は y ...

JavaScript ベースのパスワード ボックス検証情報の実装

この記事では、パスワードボックスの検証情報を実装するためのJavaScriptの具体的なコードを例と...

Navicat Premier の MySQL へのリモート接続エラー 10038 の解決方法

MySQL へのリモート接続が失敗する場合は、次の理由が考えられます。 1. 若い男性/女性の方は、...

H5ウェイクアップアプリの実装方法と注意点のまとめ

目次序文APPメソッドにジャンプURLスキームメタタグユニバーサルリンクさまざまな使い方URLスキー...

iframe なしの div ネスト HTML

最近、宿題をしているときに、iframe を使用せずにページをネストする必要があったため、jquer...

CSS3 クリアフロートメソッドの例

1. 目的この記事を通じて、誰もがフロートをクリアする原理と方法を理解し、最終的にこの記事が最良であ...

Docker nginx + https サブドメイン設定の詳細なチュートリアル

今日はたまたま友人のサーバーの移転を手伝うことになり、サーバーの基本的な設備の設定を行ったのですが、...

linxu での Svn ワンクリック インストール シェル スクリプトの詳細な説明

#!/bin/bash #SVNをダウンロード yum -y サブバージョンをインストールします ...

MySQL でスロークエリを有効にする方法の例

序文スロー クエリ ログは、MySQL で非常に重要な機能です。MySQL のスロー クエリ ログ機...