leader - チームリーダーのタイプ：より多くのプログラマー|| もっと！プログラマー

Question

昨日、別のチームのチームリーダーに、私がwikiページに書いたものを理解するのに時間がかかったと言われました。これは、ソース管理からコードを取得することを「チェックアウト」と呼んでいたためです。彼らは、Clear Caseに慣れていて、「プロジェクトに参加する」という言葉を聞いただけで、長い間実際にはあまりプログラムしていないと述べました。

これは問題ありませんが、それから私に考えさせられたのは、私が何年にもわたって持っていたさまざまなタイプのチームリーダーです。私には、ほとんど純粋に管理的なものがあり、同時に管理的なことを行うプログラマーのものもあります。

人々は彼らがどのようなチームリーダーを持っているかについて好みがありますか？チームリーダーが製品の開発に積極的に取り組んでいるかどうかをどのように気にしますか？チームの他のメンバーと同じように実際に座ってコーディングしているチームリーダーは、（私の経験から）次のようなことを理解する可能性が高いと思います。

• 物事は必ずしも思ったほど単純ではありません。私が持っていたチームリーダーは、コーディングを行わないか、ほとんどコーディングしないので、すべてが簡単なことであり、それほど時間はかからないと信じています（一緒にハックしたい場合は、おそらくそうかもしれません）。
• 彼らは、開発者が常に長い会議に参加することを好まないことをより理解しており、チームができるだけ多くの無意味な会議に参加することを避けるために最善を尽くしています
• 彼らはあなたが言うことを技術的な観点から理解しています。しばらくコーディングしていなかった可能性のあるものは、多くの新しいテクノロジー、テクニック、または用語に対応していない可能性があります

開発者の心を持ち、コードでも手を汚すのが好きなチームリーダーがいることは、はるかに満足のいくことだと思います。おそらく、実際のコーディングの側面から距離を置いて作業を単純に行うチームリーダーのように、または私が言及していない別のタイプのチームリーダーのように、そこにいる人がいますか？

Answer 1

チームリーダーはコーダーである必要があります。チームが彼らを尊重し、全員をどこに連れて行くかを尊重しない限り、チームを率いることはできません。

一方、チームマネージャーは、コーダーでも、よく組織されていて、いつ質問したり、他の管理者とやり取りしたりできるかを知っている人でもかまいません。

同じ人物の中にマネージャーとリーダーの両方を見つけることは可能ですが、多くの場合、役割は別々で別個のものである必要があります。

Answer 2

好みはありません、できません。料理人が多すぎてスープが台無しになりますが、それらすべてと協力する必要があります。複数の開発者が参加する典型的なプロジェクトでは、テクニカル リーダー、プロジェクト マネージャー、および技術者以外の顧客がいます。もちろん、部門とプログラムの管理者はそれぞれ頭を悩ませます。

リーダーにはいくつかのタイプがあり、それぞれに独自の特徴があります。

技術に詳しくない顧客: 「顧客は常に正しい」多くの場合、棒で月を望んでいます。経営陣と技術部門の両方に電話し、最良の答えを福音として受け取ります。

チームマネージャー・ラインマネージャー：やや牧歌的な役割。私が今取り組んでいるプロジェクトには特に興味がありません。プロジェクトの優先順位を決定する必要がある場合に介入します。おそらく本当にコーダーになりたいと思っており、残りのすべての作業を部下に任せています。

プロジェクト マネージャー:さまざまな程度の技術的ノウハウ。時間スケールとコストのみに関心があります。わからない、「どれくらい時間がかかるかわからない。まずは数日使ってみて感触をつかむ必要がある。」

チーム リーダー/テクニカル リーダー:単なる開発者ですが、経験は豊富です。プロジェクト全体に影響を与える技術的な意思決定を担当します。短期的には時間がかかる場合でも、優れたエンジニアリング プラクティスを実行するためにプロジェクト マネージャーとしばしば争う。

チーム リーダー/栄光の秘書:チームを率いることになっているが、秘書としての役割を果たしている人。（通常、チームより上の学年）。電話に応答し、顧客を技術機関から隔離します。これは、彼らが技術的な質問をするまでは問題なく機能し、栄光に満ちた秘書がそれから抜け出す方法を自慢しようとし、最終的には秘書を回避してチームと直接話します。

Answer 3

あなたは本ManagingHumansを読むべきです。私は、マネージャーがコードから手を離すべきだと考えています。彼らには、人々を開発者から遠ざけるなどのより重要な責任があり、彼らは自分の仕事をすることができます。彼らが開発に飛び込むことは、彼らが何が起こっているのかを知るのに十分ではなく、それと他のものの間で彼らの時間を分割するので混乱を引き起こします。さらに、上司に今書いたものを変更する必要があることを伝えなければならないとき、それは本当にひどいです、そしてあなたは戻ってそれをやり直さなければなりません。マネージャーは、チームの他のメンバーの手榴弾に飛び乗ることができるので、目前のタスクの達成に集中できます。

そうは言っても、マネージャーはソフトウェアエンジニアリングについて知っておくべきですか？はい、もちろん彼らはそうすべきです、それは彼らがいる分野です。最新で最高のウィズバン技術でコーディングする方法を知っているべきですか？彼らがソフトウェア開発がどのように機能するかを理解している限り、それは実際には問題ではないはずです。

Answer 4

通常、管理者からプロジェクトを管理する PM (非技術者) がいます。視点と、技術的な側面を管理し、チームに技術的なリーダーシップを提供する技術リーダー。

Tech Lead はプロジェクトの一部をコーディングし、おそらく「概念実証」段階のメイン (唯一) の開発者になります。

いくつかの小さなプロジェクトでは、彼らは同じ人物ですが、まれな組み合わせです.

Answer 5

私が一緒に仕事をした中で最悪のソフトウェア リード/チーフ ソフトウェア エンジニアは、技術的な詳細に深く関わりたいと思っていた人たちでした。あまりにも多くの重要なタスクが見逃されたか、単に完了していませんでした。チームの管理はフルタイムの仕事です。リーダーが技術的な側面に関与したい場合、それは確かに管理的な側面を犠牲にして行われます.

数十人のソフトウェア リード/チーフ ソフトウェア エンジニアのうち、価値があると思ったのは 2 人だけでした。どちらも以前はソフトウェア エンジニアでしたが、2 人ともその時代はとっくに過ぎ去りました。彼らはそれを知っていました。彼らはふりをしようともしませんでした。彼らの仕事は管理することになりました。彼らの仕事は、開発者が成功するためのあらゆるチャンスを確保することでした。彼らはすべての障害を取り除き、全員が進歩していることを確認するために最善を尽くしました.

私は理論を持っていますが、それが実際に実行されているのを見たことがありません。最高のソフトウェア リードは、ソフトウェア開発者ではない、またはソフトウェア開発者であったことがない人です。彼らは真の経営精神、特にファシリテーターであることを専門としています。残念なことに、ほとんどの管理者は政治的な動機を持っているか、技術的に頂点に達したために仕事に就いているだけです。