マネージャーとプログラマを同時に兼ねることはできますか?[閉まっている]


43

自分がプログラミング労働力の一部である間に他のプログラマーを管理する。

少なくとも私が働いていた会社では、これは非常に一般的なスキームです。

両方を同時に行う場合、優秀なプログラマーまたは優秀なマネージャーになれますか?

私は非常に異なるスキル、環境、集中力、組織などを必要とする2つの非常に異なる役割を果たさなければならない個人の有効性に疑問を抱いています。

更新:私の質問には、チーム管理ではなく、会社の管理(私の場合)が含まれます。しかし、私はもちろん両方に興味があります。


1
ビル・ゲイツに聞いてください。
アンドリューアーノルド

6
します。参照として使用できますか?

ここで「プログラマー」の仕事の一部としてコードレビューを検討しているかどうか疑問に思っています。チームマネージャーがコード機能と連絡を取り続けるのは素晴らしい方法であるように思えます。また、レビュー中に中断されても問題ありません(速度が低下する可能性があります)。
マチューM.

Matthieu:言及しなかったが、チームではなく会社の管理について話していた。実際、チームは自己管理されるべきだと思います。しかし、以下の答えはすべて私にとって有効で価値があります。

1
簡単な答えは次とおりです。noはどちらの役割でも効果的ではありません。あなたがどちらか一方にいると、もう一方は比例して苦しみます。

回答:


36

それはあなたがする必要があるプログラミングの量と種類、そしてあなたが実行しなければならない管理職の量と種類に依存します。

マネージャーになることは、多くの中断、タックの変更、会議などのことを意味します。

プログラミングが緊急でない作業の小さな部分に「限定」されている場合、これらを管理職の職務に適合させることができます。プログラミングタスクにかなりの量の「質の高い」時間を費やす必要がある場合、管理責任のためにその時間を得ることができません。

チームが大規模かつ/または複雑な場合、1つまたは2つの製品/プロジェクトに専念する小さなチームである場合よりも、管理に多くの時間を費やす必要があります。小さなタスクであっても、意味のあるプログラミングを行う時間がないことがわかります。

以前の仕事ではこの役割を担っていましたが、プログラミングタスクを小さく抑えたのでうまくいきました。実際に私たちにとって有利に働いた。

まず、入ってくるすべてのリクエストを評価し、それらが小さい場合は、キューに追加する(常に短い)か、クライアント(この場合は別のマネージャー)に戻ると、作業が行われる時間をより正確に把握できます終わり。

第二に、チームの開発者は、マイナーなバグを修正したり、小さな機能強化を行ったりするために、現在の作業を絶えず引き離していませんでした。

第三に、緊急の問題がかなり迅速に修正されたため、クライアントは満足していました。

コードベースと連絡を取り合っているので、チームを常に関与させることなく、チームと問題について、マネージャーやクライアントとタイムスケールについて有意義な会話をすることができました。


2
+1私はマネージャー兼プログラマーです。私はクリスがここで説明しているように仕事をしています。私は優れたプログラマーですが、素晴らしいオーガナイザーです。マネージャーとして技術的でプロジェクトに関与し続けることは大きな利点だと思います。私のスタイルは、マネージャーでありプログラマーでもあった最初のボスからのもので、両方とも得意です。
-bogeymin

4
チームで働くために適切な人を雇ったなら、あなたはマネージャーとプログラマーになることができます。
Naweed Chougle

1
これは、マネージャー/プログラマーが素晴らしい場合にのみ機能すると思います。ほとんどの場合、これはMartin Wickmanの答えのように失敗します。
アンドレイヴァイナII

12

私は1人のプログラマーがマネージャーでもある開発者チームの一員でした。これにより、生産性に似たものが完全に崩壊しました。要するに、すべての決定はその男によって行われ、彼は完全なマイクロマネージャーでした。彼が同意しなかったアイデアや提案は打ちのめされたか無視されました。これは最終的にすべての創造性と動機を殺しました。

だから、開発チームの誰もが「より高い」地位にいるのは悪い考えだと思う。私の場合、この男はコマンド&コントロールマネージャーでしたが、優れたマネージャーでさえ(意図せずに)他の開発者に影響を与え、最終的にはパフォーマンスの低下につながります。少なくともチームのメンバーが彼に報告しています。


4
私は完全にあなたが、何を言ってるのか知っているjoelonsoftware.com/items/2006/08/08.html
ダコタ州のデビッド・

8

はい
、プログラマーとマネージャーであるマネージャーを同時に見ました。これらのマネージャーの下で働くことは素晴らしいと信じていました。
マネージャーおよびプログラマーであると、マネージャーが正面からリードできるようになるだけでなく、部下が最善を尽くすよう動機付けられます。
従業員のほとんどは、マネージャーには価値がないと不平を言っていますが、マネージャーだけでなくコードを書くマネージャーも常に最高の結果をもたらします。
私が言及した2人のマネージャーは、プログラミングが情熱であり、他の人を助けるだけでなく、バ​​グのないアプリケーションを作成しました。


8

私は何年もプログラミングプロジェクトマネージャーを務めており、さまざまな企業、プロジェクト、チームで働いています。

プロジェクト管理とプログラミングは非常に異なる種類のジョブ/ロールであるため、「優れた」レベルで同時に両方を行うことはできないと主張します。それは妥協です-なしのマスター、すべての取引のジャック、種類のもの。

私にとって最大の苦痛は、マネージャーモードとプログラマーモードの間のコンテキストスイッチです。彼らは脳のさまざまな部分(または何か)に関与しているようです。ある日プログラミング、ある日管理すればうまくいくことができますが、これらの役割を絶えず切り替えることは困難です。


7

両方のシナリオを見てきました。コーディングの{ある程度の時間}を行う開発マネージャーと、コーディングをまったく行わない開発マネージャー。

問題は、あなたが年をとるほど、あなたはより多くの支払いを受けたいと思う可能性高く多くの場所でそれを得る唯一の方法は管理職に移行することです。(もちろんすべてではありませんが、多くの場所)。そのため、この状況で立ち往生するマネージャーになる準備が本当にできていない人々につながる可能性があります。

(もちろん、Dev、Devリード-もちろんDevマネージャーとは異なる-を介してArchitectなどのポジションに移動できる会社があります)

技術者である可能性あるため、人事管理に役に立たない可能性があります。さらに、コードからさらに離れることができます。だから、あなたは悪いマネージャーになり、あなたが楽しむものの少ない仕事をしていて、おそらく開発に着手しました!

私にとって、マネージャーになるためには、コーディングから手を離す必要がありますが、少なくとも問題について首尾一貫して話すことができるように、テクノロジーを常に最新の状態に保つ必要があります。

たまたまこの正確な理由でフリーランスを始めました。私は人事管理に興味がなく、私はそれが特に得意ではないだろうと思うし、それだけコードを書くこともできないだろう。


6

それはできますが、落とし穴に満ちています。グループの規模と中断レベルが大きな役割を果たしますが、最も重大なリスクは、マネージャーが技術リーダーでもあることです。意見を正当化するのに十分な時間/労力がかかっていないとき、あまりにも重い利き手の意見は、いくつかの悪い決定につながる可能性があります。そして、方向性に関する議論は、マネージャーとチームの他のメンバーとの間のあまり平等な場ではありません。

このパスを検討している場合、いくつかのアドバイス:

  • アーキテクチャの役割から抜け出し、グループ内のリードを特定します。

  • クリティカルパスの項目で作業しないでください。上司があなたの注意をそらすためにより多くの「重要なもの」を見つけたときに、バグを修正したり、プロトタイプやその他のアイテムをすぐに破棄することができます。

  • 注目レベルを上げて、全体的な効率に焦点を当て、チーム、プロセス、士気、およびチームを成功させるために必要な他の側面を擁護および促進します。あなたの目標は、成功したプロジェクトだけではありません(上司、PM、または他の人が何を言っているかに関係なく)。

  • チームの成長を支援します。より独立し、自己組織化し、技術に長け、認識を高めます。

  • 多くの点で、あなたはチームと外の世界の間の橋渡し役です。あなたの焦点の大部分はチームの外にあるべきです。

質問に答えるために、はい、できます。いいえ、それは簡単なことではなく、家の技術的な側面から非常に多くの新しいマネージャーがいます。


3

良いマネージャーはそうです、はい。断定的で一貫性がある限り、通常は問題ありません。

従業員がマネージャーとチームメイトの問題を持ち出すように言われた場合、マネージャーがチームメイトでもあると、粘り気になります。すべてのフィードバックを客観的に表示し、時々間違っている可能性があることを理解することが不可欠です。また、フィードバックのために何らかの匿名手段を提供する必要があります。

スタートアップ企業でこれを見るのは(あなたが言ったように)非常に一般的です。


3

私は違うと思います。

両方の仕事は、多くの焦点、エネルギー、献身を必要とします。両方を同時に実行することは非常に困難です。チームリーダーの責任を負わなければならなかったとき、プログラミングに費やした時間(およびその結果、私が行ったプログラミング関連の作業の量)が減少しました。

チームリーダーの役割から管理の役割を引き受け、1か月以内にコーディングを完全に停止した別の同僚を知っています(彼は両方を試みましたが)。

また、マネージャーになるように依頼された建築家も知っています。また、管理責任を引き受けてから1か月以内にコーディングを停止しました。8か月後の同じアーキテクトは、重大なフィールドの問題のためにコーディングに戻る必要がありました。彼はバグ修正に大きく貢献しましたが、1か月以内に、管理責任を引き継ぐために代替マネージャーを見つける必要がありました。

私の限られた経験では、完全なプログラマーのような他のプログラマーやコードを管理する人はいません。


3

私の意見では、ほとんどのシナリオで可能ですが、それは適切な取り決めではありません。これが彼らの特定のスキルセットまたは望ましいポジションではないのに、開発者として熟練している人々がどのように気づき、チーム管理の役割に育てられるかに関する多くの記事があります。彼らは、レポートを作成したり会議に参加したりするのではなく、「仕事」をプログラミングの完了と見なしているため、「管理」に集中し続けることに苦労しています。

Spolskyは、Developer Abstraction Layerに関する記事で次のように書いています。

「ソフトウェア会社の場合、管理の最優先事項は、プログラマーのためにその抽象化を作成することです。」

記事(意見はあるが十分に理にかなっていると思う)では、マネージャーの役​​割はコードやソフトウェア開発に入ることではなく、それを作成する人が完全に集中できる環境を作ることです。


2

元上司が試した。彼の管理役割からの中断が多すぎました。

彼は今でも私が知っている最高の開発者の一人です。


2

絶対にできますが、だからといって簡単だというわけではありません。ある種の人が良い開発者になるには、ある種の人が良い管理者になるには、ある種の人はその両方になる必要があります。その人(またはその人)を見つけることができる場合、明確な利点があります。プログラマーの第1レベルまたは第2レベルのマネージャーは、従業員が毎日何をしていて、何に遭遇するかを真に理解する必要があります。あなたが開発者でなかった場合、実行するのは難しく、開発を続けることなく最新の状態を保つことは困難です。

私がこれまでに持っていた最高のマネージャー(私はビジネスに約25年の経験があります)は、アクティブな開発者であり、マネージャーであり、会社の半分の所有者(約40名)でした。彼は特別でしたが、彼は明らかにこの質問に成功しました。


2

確かにいいえ!!

試してみることはできますが、何よりも管理することになります。問題は、人々が5分ごとに電話をかけたり、1時間ごとに「ステータス」ミーティングを行おうとするとコーディングできないことです。それはばかげている...私は今それをやっているので、私はこのスレッドにつまずいた。

ハイテク企業のマネージャーは..いいえ...コーディング方法を知っている必要があります。クライアントの問題を推定したり理解したりすることはできません。コーディングと管理は2種類の人々です。片方は人とオタクで不器​​用です(顔を立てて、私が話していることを知っているオタク)、そしてもう片方は人と一緒です。サイドを選択する必要があります。両方を行うと、コーディングはどこにも行きません。コーディングが好きで、妻が邪魔をしなければ24時間年中無休でできるなら、管理から離れてください。必要に応じて給料をもらってください。私はこれをやろうとしていますが、上司がこれを好むとは思いません。なぜなら、私は彼らの生活を管理の部分でやりやすくするからです。お金とそれが買う幻想よりも幸せとあなたが愛することをすることの方がずっと重要だから、彼らが同意しない場合、フリーランスに戻らなければならない。

あなたの努力を心から願っており、これらの投稿を続けてください。あなたたちは素晴らしいです。

このサイトの「プログラミング中心のキャリアパスの欠如」セクションをお読みください。かなり良いものと非常に関連性:http//c2.com/cgi/wiki?ProgrammingIsNotFun


1

「すべてのジャックは誰のマスターでもない」という言葉が思い浮かびますが、人は優れたマネージャーと優れたプログラミングスキルの両方を備えている可能性があります。

しかし、両方の機能を同時に組み合わせると、両方のジョブを半分しか実行しない傾向があります。それは、行わなければならない管理の量に依存しますが、必然的に、まったく異なる性質の2つのタスクをジャグリングしていることになり、この要求が集中するシフトは非常に大きくなります。いくつかの管理タスク(私の場合は、コースの管理とレポートの作成)を行うと、コーディングセクションのパフォーマンスが大幅に低下することに気づきました。

別の落とし穴は、あなたがグループを管理していることですが、あなたも直接関与しているパーティーです。それが報われることもあれば、大きなトラブルを引き起こすこともあります。他のプログラマーがあなたの仕事に同意しない場合、あなたがマネージャーであるという事実は、彼らが完全に開かれないようにすることができます。

繰り返しますが、管理している同じプロジェクトでコーディングしているときは、コード自体にもう少し感覚を保つ必要があります。その場合、プログラミングビットは実際に管理ビットに役立ちます。すべては、あなたが管理しなければならないもの、それがどれだけの時間を必要とするか、そしてあなたが取り組んでいるコードにどれだけ関連しているかに依存します。

明確な答えはありませんが、両方を混ぜすぎないようにする傾向があります。私の2セント


1

まあ、私はソフトウェアプロジェクトのマネージャーは間違いなくコーダー自身であるべきだと読みました。

マネージャーは、管理するという1つの理由でマネージャーだと思います。私はこれを経験則として考えます...いくつかは両刃の剣でありえます。


1

私はそれが機能する1つのケースを知っています。男は一種の仕事中毒なので、マネージャーとしてフルタイムで働き、プログラマーとしてほぼフルタイムで働いています。

通常の労働時間を考えると、このような二重の役割は良い考えだとは思いません。管理プログラマー(またはプログラミングマネージャー)は、プログラマーにそれを行わせるのではなく、常に自分でプログラミングの多くを行うように誘惑されます。「説明するのに時間がかかる」という言い訳は常にありますが、長い目で見れば、彼が行う50%のプログラマーの仕事が管理部分に欠けているため、他のプログラマーの効率は低下します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.