開発者のチームにはマネージャーが必要ですか？

バックグラウンド：

私は現在4人のチームの一員です。1人のマネージャー、1人のシニア開発者、2人の開発者です。約3500人のスタッフを抱える組織のために、さまざまな特注の社内システム/プロジェクト（6〜8週間など）を実施しているほか、以前に作成されたシステムに必要なすべてのメンテナンスとサポートも行っています。潜在的に私たちがやってくるすべての仕事をするのに十分な人はいません-人員が不足しています。経営陣はこれを認めていますが、予算の制限により、チームに追加のメンバーを採用する能力が制限されています（たとえ給与を貯金に戻したとしても）。

変更

これにより、現在の場所に残ります。私たちのマネージャーは、牧草地の役割を新しいままにして、チームに空席を残す予定です。経営陣はこの機会を利用してチームを再構築し、チームマネージャーの役​​割が別の開発者と別の上級開発者に置き換わるようにします。彼らの論理は、より多くの開発者が必要であるということなので、ここに資金提供の方法があります（役割の1つは、別の空いているポストから部分的に資金提供されています）。

チームには直接的なラインマネージャーはなく、役割と責任はシニアと（比較的新しいポストの）サービスマネージャーに分けられます（技術知識がほとんどない開発知識/経験があり、焦点が共有されています）他の多くのチームや個人の中で）-フードチェーンの次の実際のマネージャーになる人。

最後の質問は：

マネージャーなしで開発チームを実行することは可能ですか？これを経験したことがありますか？そして、どのようなことがうまくいかない/私たちに利益をもたらす可能性がありますか？

理想的には、「光を見る」ことと、この方法で物事を行うことの利点、またはそれに対する議論のためのいくつかのポイントを考えたいと思います。

リスクが大きいほど、「エアカバー」が必要になります。これは、マネージャーが実際に提供することになっているものです。チームが作業を行う間、マネージャーはチームがチームの目標を達成するのを妨げるものがないことを保証することになっています。スケジュールの調整、チームとセールススタッフ間の干渉の実行、またはチームが時間通りに支払われ、コーヒーマシンが正常に機能していることを確認するだけです。本当に素晴らしいマネージャーは、チームがマネージャーがそこにいないかのように機能できるようにします。

もちろん、ほとんどのマネージャーはこれにまったく失敗します。彼らはマイクロ管理するか、時代遅れにされて、会社の上層部がより直接的に物事を管理できるようになり、本当に素晴らしいマネージャーは本当に珍しい鳥です。ソフトウェアチームに関する限り、階層的またはフラットなチーム構造を持つことに関しては、両方の方法に長所と短所があります。チームが非常に小さく、完了した作業がほとんど必要ない場合（つまり、すべての人が独立したプロジェクトを持っていることを意味します）、すべてがチームメンバーは規律されます。しかし、チームメンバーが行う作業に多くの重複がある場合、2人以上の比較的強い個性がある場合、

多くの要因が関与しますが、実際には、関与する人格、個々の動機およびキャリア目標、およびマネージャーまたはチームリーダーの位置がどの程度必要であるかを決定する上級管理職によって提供される例とガイダンスに要約されます。一般に、混乱があり、チームがそれを求めている場合、チームには明らかにリーダーシップが必要です。通常、管理者の入力なしに問題が発生しない場合、チームは少なくとも非階層構造内で、少なくともワークロードとスケジュールの管理が難しくなりすぎるまで管理できます。

誰かがマネージャーである必要がありますが、あなたのチームの場合、これがフルタイムのポジションだとは思いません。別のシニアを雇う。開発し、そのうちの1人をマネージャーにします。理想的には、マネージャーであり、必ずしも最高のプログラマーである必要はありません。

マネージャーは、コンセンサスがない場合は最終決定を下す必要があるため、その人は技術的に適格である必要があります。他のプログラマー、会議を評価し、上級管理職をかわすことは仕事の一部です。

推奨読書：パンツのない年。大規模なソフトウェアプロジェクト（WordPress）でさえ、直接のマネージャーなしで進むことができますが、いくつかのタスク（誰もやりたくない/非常に難しい）があるか、同じタスクのために多数の開発者を統合する必要があります。集中管理。

他の人が指摘しているように、あなたの質問に対する簡単な答えはイエスです。

あなたの質問に対するより完全ではあるがより複雑な答えは、以下に対処することです：

「経営陣はこれを認めているが、予算の制約により、チームに追加メンバーを採用する能力が制限されている」

「はい、私たちはそれを認め、私たちはそれを認めます」と言う経営陣は、あなたが気分を良くするための単なる「言葉」です。彼らはしていない組織の成功には、それが重要な考慮、またはそれらを考え、実際に誰かを取得し、実際にサポート！

気を付けるべき他の事柄（これには多くの心理学があるので）は、経営者が悪いニュースを伝えるが、ある種の冗談を混ぜて、問題を直接言及するかもしれませんが、そうではないかもしれませんが、それは基本的にそれを疑問視することを不可能にします（その微妙で巧妙なテクニック）。もう1つ注目すべきは、3時間の会議で、計画が提示され、2時間55分で意見が求められます。

正しいことを「行う」管理とは対照的に、正しいことを「言う」管理に慎重であること。

マネージャーなし=説明責任なし=少なくとも長期的には混乱。誰もが好きなように物事を行い、中間管理職は、特定の問題や要求に対して誰と話すべきか、誰が正しいか、誰が間違っているかわからない状態で走り回ります。タスクがそれほど分離されていて、ほとんどまたはまったく関係がない場合を除き、特定のタスクを実行する方法は非常に多く、管理には専門知識が必要なため、忙しい開発者が常に獲得できるとは限らないため、多くの「小さなマネージャー」を持つことは開発では機能しません。誰かが全体像を見る必要がある。提案されたスタイルは、レガシーまたは現在のアプリケーションのサポートを提供しているが、開発中のチームでは機能しない場合があります。楽観的であるためには、これが合理的にうまくいく前にあなたの組織といくつかの試行錯誤が必要です。

上記の回答に同意しますが、重要な考慮事項があります。

「マネージャー」は役職ですが、役割の観点から考えると、マネージャーは特定の責任を負う人です。これらの責任が何であるかに関係なく、CxOとの交渉、レポートの作成、休暇の管理、さらにはコーヒーマシンの満杯まで、あなたのチームにはこの責任者が必要です。

プロの —それはあなたの一人かもしれません、そして、これは彼/彼女のキャリアの大きな後押しになるかもしれません。チームの他のメンバーは、「上から割り当てられた」人ではなく、チームのニーズを深く理解している人を獲得します。
もちろん、管理作業にどれだけの時間を費やすか、以前は何をしていたかについて交渉することを忘れないでください。

Con's — マネージャーになりたいと思わない人もいます。これには何も悪いことはありません。多くの開発者は、レポート、図、会議で「時間を浪費する」よりも、キーボードや他の開発者を好むでしょう。私を信じてください、毎朝叫ぶ上司との5分間は非常にやる気を起こさせます！:)

だから、私はあなたの質問を次のように言い直します：専用のマネージャー
なしで開発チームを実行することは可能ですか？— はい。
あなたのチームはその変化に備えていますか？—言えない。
それを試してみてください。試してみる価値があります。

現在、マネージャーのいない小さなチームで働いています。小さな会社。うまくいきます。

あなたのマイレージは異なる場合があります。

はい、テクニカルリードとマネージャーが必要です。しかし、個人的にはテクニカルリードがはるかに重要だと思います。（それが何であるかわからない場合は、基本的に作業を手渡し、全員が本来あるべきことをしていることを確認するのは人です。）

各人がチームとして働き、利害関係者の期待に応えるのに十分な成熟度を持っている場合、開発者のチームはマネージャーを必要としません。

特定の役割（開発者など）は、他の環境要因を心配せずに、解決する必要がある問題に集中する必要があります。そこにマネージャーがいるのが役立ちます。

価値を高めることができる先輩が常に助けになると言った。CEOでさえ、マネージャー（取締役会）のチームに報告します。

私の2セント...

組織内のチームのために戦う必要がある戦いに依存することをお勧めします。あなたがあなたの仕事をするのを妨げる問題があるならば、マネージャーはそれらを整理するべきです。

それは、優先順位が適切な方法で制御および設定されていることを確認すること、仕事をするために必要な機器、ソフトウェアなどがあることを確認することなどです。彼らは組織におけるチームの擁護者でなければなりません。

どのようにビジネスに関与しますか、どのように取り組むべきか、誰がいつ「完了」するかをどのように決定しますか。マネージャーが多くのことをしなくても、組織がこれらのことを処理する場合、素晴らしいことです。しかし、その後、チームの外で変更が行われる可能性があります。おそらく、ビジネスの主要な1人または2人が役割を変更すると、困難な状況に陥る可能性があります。

おそらく、あなたはあなたの擁護者になれる組織の強力なリーダーを選ぶことができますが、あなたの日々の管理に参加する必要はなく、彼らにアプローチし、彼らがあなたのチームを彼らの下に置くかどうかを確認します。（おそらく、あなたが言及した「サービスマネージャー」で既にそれを行っているでしょう。）

短い答え：はい、できます。

長い答え：しかし、それはチームの個性に依存します。明らかに、誰かがあなたが何をしているのかを決定しなければならないので、誰かに報告する必要があります-これはあなたのチームのマネージャーである必要はないかもしれませんが、誰かがあなたに仕事を与える必要があります。チーム内では、優先順位や技術的な問題を決定する誰かが必要になる場合がありますが、それはチームリーダーが簡単に行うことができます。

開発チームを別の開発チームと統合する必要があるかもしれません。テストチームがあります>開発チームを半自律的に保ちながら、両方に同じマネージャーを使用する方が良いでしょうか？

私には、サービスマネージャーはあなたが実行する必要がある仕事を非常に喜んで提供し、必要な品質に合っていることを確認でき、このタスクを行うために開発経験を必要としないようです-ソフトウェアはビジネスツールです要件に適合するか適合しないか、通常はそれがユーザーであると判断するのに最適な人物です。サービスマネージャーは、お客様とお客様との間の連絡役として行動し、うまく機能することを願っています。彼があなたのチームの責任を十分に制御できなかったことを心配します。物事がうまくいかなくなった場合、経営者が彼（または、さらに悪いことに、他の誰か）に責任を負わせるまで、あなたは不幸な状態になってしまいます君は。

自己管理チームは、普通のことではありません。通常、内部で生成された説明責任を作成するには、明確なパフォーマンスメトリックが必要です。あなたの組織はこれを持つことができますが、コスト削減に基づいて追加の人員を生成できない場合、おそらくこれは機能しません。もう1つの課題は、新しい上司が才能に報いる方法を知っている人のように聞こえないことです。

良くも悪くも、プレーヤーのコーチが必要なようです。チームを管理し、その中で活躍できる人。4つのグループでは、これは確かに実行可能です。8または10のグループでは、そうではありません。課題は、このプレーヤーのコーチとなる人物を特定することです。デフォルトでは最高のプログラマーになりますが、必ずしもそれらを管理者と結び付けたいですか？優秀な組織が最高の技術者全員を管理者にさせない方法を見つけたと言う以外には、難しい答えはありません。

マネージャーは、組織と開発チームの間のミッシングリンクになる傾向があります。

• 彼らはあなたの仕事が関連し、組織のニーズを満たしていることを確認します。
• 経営陣への回答
• プロジェクトが予定通りになるようにスケジュールを管理する
• プロジェクトのニーズに気をつけてください。

責任が小さい小規模なチームは、マネージャーを指定しなくても機能します。しかし、責任が大きくなるにつれて、これらすべてのリスクと問題を管理する人が必要になります。

そして、設定が与えられると、チームの誰かがそのように指定されていなくても、マネージャーの役​​割を果たせます。通常、分散責任はうまく機能しません。配布方法と関係する人々のタイプに大きく依存します。

マネージャーを持つことの利点は、彼らがあなたのチームのために果たしている役割に依存します。だから、それは本当にチームに必要な役割に帰着します：

• チームメンバー間の紛争を解決し、質の高い仕事を時間通りに提供することにチームを集中させる権限を持つ人が必要ですか？
• それとも、トップアンサーで言及されているように、誰かがエアカバーを提供する必要がありますか？スケジュールの管理、優先順位の決定、上級管理職とチーム間の介入など。

それで、あなたはそれを必要としますか？あなたが注目した役職の人はあなたのためにこれをすることができますか？もしそうなら、あなたは大丈夫です。そうでない場合は、おそらく災害に向かっています。

出典：グループプロジェクトおよび管理されたチームと管理されていないチームの個人的な経験。

フラットチームは、同じ/類似グレードのエンジニアのグループを群がらせるために1人の担当者を配置しない限り、常に問題であると考えています。

S.Robinsが述べたように、すべてのチームメンバーがよく訓練されている場合、マネージャーを置くことはここで不必要なボトルネックになる可能性があります。私が働いてきた中小企業のいくつかは、（他の理由の中で予算の制約のために）人的資源の制約があります。 。

「1レベル上の」マネージャーが人を管理できない場合、これは裏目に出ます。彼らのキャリアを始めた新入生は非常に競争力があります-チームでできるだけ早くしっかりと自分自身を確立しようとし、誰かが彼らの競争力が協力を傷つけないように時々人々を抑える必要があります。

フラットなチームを持つことの問題は、プロジェクトのスケーリングでは、必然的に1人または2人の男にもう少しやらせて、もう少し責任を負わせる必要があることです。この時点で、明確に定義された階層を作成し、電話を受けて人を管理する適切なマネージャーを確実に配置する必要があります。同じグループ内からのプロモーションがある場合、常に不幸な束が常に存在するからです。

多くの小規模なCosで見られるもう1つの悪い考えは、マネージャーとしての指名または経験の点で最も年上の男を置くことです。または、グループで最も技術的に熟練した人がマネージャーの役​​割に昇進します。私はこの仕事を見たことがありません。

プロジェクトの規模が適切であれば、4人以上のチームはタイムラインの早い段階で確実にマネージャーが必要になると思います。理想的には、男性管理スキルを備えた技術者であり、特定の意思決定を適切に行う必要があります。

私はアジャイルプラクティス、特にスクラムを採用している会社で働いています。開発チームと経営陣はすべて満足しています。彼らは欲しいものを手に入れます。

1. すべてのエンジニアは、エンジニアリングマネージャーに報告します。エンジニアリングマネージャーは非常に技術的かつ機能的な役割であり、この部門ではより多くのビジネスを獲得する必要があります。この役割は製品所有者と同等です。
2. プロジェクトマネージャーは、スクラムマスターのような別の役割であり、通常は一定期間（12か月から18か月、契約の延長なしで）請負業者です。
3. プロジェクトマネージャー（スクラムマスター）は、非機能的および非エンジニアリング活動に完全に責任を負います

開発チームはエンジニアリングの側面に焦点を当て、ビジネスアナリスト/製品所有者はビジネスの側面に焦点を当てているため、これは見事に機能しています。プロジェクトマネージャーは、タスクの追跡、レポート、およびその他の典型的なスクラムマスターの業務を担当します。

中間管理は外部委託されており、中間管理からトップ管理への成長経路はありません。成長の機会は、開発チームまたはビジネスアナリストの役割からエンジニアリングマネージャーまでであり、監督者の役割からではありません。

当社は、中間管理職は企業にとって大きな付加価値ではなく、外部のコンサルティング会社に任せるのが最善であると強く信じています。

注目に値する1つのポイントは、彼らがマネージャーとして人を指定するかどうかに関係なく、あなたの誰かが「事実上の」マネージャー、おそらく最も経験/時間の多い人になる可能性が高いということです。

特に、これは再構築を通じて考えるのではなく、コスト削減策として（つまり、マネージャーにお金を払わず、開発者を雇うため）行われているため、上級管理職は引き続き彼らが働いているようです以前は、単に彼らがよりよく知っている人々（すなわち、最長のサービス）に対処していました。