開発者のチームにはマネージャーが必要ですか？
背景：
私は現在、1人のマネージャー、1人の上級開発者、2人の開発者の4つのチームに所属しています。約3500人のスタッフを抱える組織向けに、さまざまな社内システム/プロジェクト（6〜8週間など）のほか、以前に作成されたシステムに必要なすべてのメンテナンスとサポートを行っています。私たちには、私たちの道を歩む可能性のあるすべての作業を実行するのに十分ではありません-人員不足です。経営陣はこれを認めていますが、予算の制約により、チームに追加のメンバーを採用する能力が制限されています（たとえ給与が貯蓄に戻ったとしても）。
変更
これにより、現在の場所に戻ることができます。私たちのマネージャーは牧草地に新しい役割を残し、チームに空席を残す予定です。経営陣はこの機会を利用してチームを再構築し、チームマネージャーの役割が別の開発者と別の上級開発者に置き換えられるのを目にします。彼らの論理は、より多くの開発者が必要であるということなので、これに資金を供給する方法があります（役割の1つは別の空いているポストから部分的に資金を供給されています）。
チームには直属のラインマネージャーはなく、役割と責任はシニアと（比較的新しいポストの）サービスマネージャー（開発に関する知識や経験がほとんどまたはまったくない非技術的な役割）に分けられます。他の多くのチームや個人の間で）-フードチェーンの次の実際のマネージャーになります。
私は最後の質問だと思います：
マネージャーなしで開発チームを運営することは可能ですか？これの経験はありますか？そして、何がうまくいかなかったり、私たちに利益をもたらすことができるのでしょうか？
私は理想的には「光を見る」ことと、このように物事を行うことの利点、またはそれに反対する議論のポイントを考えたいと思います。
リスクが大きいほど、「エアカバー」が必要になります。これは、マネージャーが実際に提供するはずのものです。チームが仕事をしている間、マネージャーはチームがチームの目標を達成するのを妨げるものがないことを確認することになっています。スケジュールの微調整、チームと営業スタッフ間の干渉の実行、または単にチームに時間どおりに支払いが行われ、コーヒーマシンが正常に機能していることを確認するために。本当に優れたマネージャーは、まるでマネージャーがいないかのようにチームを機能させることができます。
もちろん、現実には、ほとんどのマネージャーがこれにまったく失敗しています。彼らはマイクロマネージするか、企業の上位階層が物事をより直接的に制御できるように時代遅れになっています。そして本当に優れたマネージャーは確かに珍しい鳥です。ソフトウェアチームに関する限り、階層的またはフラットなチーム構造を持つことに関しては、長所と短所があります。チームが非常に小さく、作業の重複がほとんどない場合（つまり、すべての人が独立したプロジェクトを持っていることを意味します）、フラットな（管理されていない）チーム構造は、チームのメンバーは規律があります。ただし、チームメンバーが行う作業にかなりの重複がある場合、2つ以上の比較的強い性格がある場合、または作業負荷が高く、比較的ストレスの多い作業環境がある場合、チームリーダーまたは責任が明確に定義されたマネージャーが一般的に不可欠です。
関与する要素はたくさんありますが、実際には、関係する人格、彼らの個々の動機とキャリア目標、そしてマネージャーまたはチームリーダーの地位がどれほど必要かを決定する上層部が提供する例とガイダンスに要約されます。一般に、混乱があり、チームがそれを要求している場合、チームには明らかにリーダーシップが必要です。管理の入力がなくても問題が解決しない場合、おそらくチームは非階層構造内でしばらく管理できます...少なくともワークロードとスケジュールの管理が困難になるまで。
誰かがマネージャーになる必要がありますが、あなたのチームの場合、これはフルタイムのポジションではないと思います。別のシニアを雇う。開発して、そのうちの1つをマネージャーにします。理想的には、マネージャーとして最適であり、必ずしも最高のプログラマーである必要はありません。
マネージャーはコンセンサスがない最終的な決定をする必要があるので、その人は技術的に資格を持っているべきです。他のプログラマー、会議を評価し、上級管理職をかわすことは仕事の一部です。
推奨される読み物： パンツのない年 。大規模なソフトウェアプロジェクト（WordPress）であっても、直属のマネージャーがいなくてもかまいませんが、いくつかのタスク（実行したくない/非常に難しい）があるか、同じタスクに多数の開発者を統合する必要があります。中央制御。
他の人々が指摘しているように、あなたの質問に対する単純な答えはイエスです。
あなたの質問に対するより完全ですがより複雑な答えは以下に対処することです：
「経営陣はこれを認めていますが、予算の制約により、チームに追加のメンバーを採用する能力が制限されています」
経営陣が「そうだと認め、それを認める」と言うのは、あなたをより気持ちよくするための単なる「言葉」です。彼らはしないでくださいそれが組織の成功にとって重要であると考えます、そうでなければ本当に実際に誰かを獲得することをサポートします！
他にも注意が必要なのは（心理学はたくさんあるので）経営陣から悪い知らせが聞こえてくるときですが、ある種の冗談が混じり合って、問題について直接言及しているかもしれませんが、そうではないかもしれません。その微妙で巧妙なテクニック）。もう1つの注意点は、3時間の会議で計画が提示され、2時間55分後にあなたの意見が聞かれます。
正しいことを「行う」経営者とは対照的に、正しいことを「言う」経営者に忠実であること。
マネージャーなし=説明責任なし=少なくとも長期的には混乱している。誰もが自分の好きなように行動し、中間管理職は誰と話をするべきか、誰が正しいのか、特定の問題や要求に対して誰が間違っているのかわからないでしょう。タスクがそれほど分離されておらず、関係がほとんどないか、まったくない場合を除き、特定のタスクを実行するには非常に多くの方法があり、管理には多忙な開発者が必ずしも習得していない可能性があるため、多くの「小さなマネージャー」がいても、開発では機能しません。誰かが全体像を見る必要があります。提案されたスタイルは、レガシーアプリケーションまたは現在のアプリケーションのサポートを提供しているが、開発中のチームには有効です。楽観的になるには、これがかなりうまくいく前に、組織といくつかの試行錯誤が必要になります。
上記の回答には同意しますが、重要な考慮事項があります。
「マネージャー」はポジションですが、ロールの観点から考えると、マネージャーは特定の責任を持つ人です。これらの責任が何であるかに関係なく、CxOとの交渉、レポートの作成、休暇の管理、さらにはコーヒーマシンへの記入など、チームにはその責任者が必要です。
プロ —それはあなたの1人になることができ、これは彼/彼女のキャリアへの大きな後押しになるかもしれません。チームの残りのメンバーには、「上から割り当てられた」人ではなく、チームのニーズを深く理解している人がいます。
もちろん、彼女が管理タスクに費やす時間と、以前は何をしていたかについて交渉することを忘れないでください。
Con's —あなたが誰もwishマネージャーにならないことも可能です。これには何も悪いことはありません。多くの開発者は、レポート、図、および会議で「時間を浪費する」よりも、キーボードや他の開発者と一緒に楽しんでいます。私を信じて、毎朝ボスが叫んでいる5分は非常にやる気があります！ :)
だから、私はあなたにこのように質問を言い直します：
専用マネージャーなしで開発チームを実行することは可能ですか？— はい。
あなたのチームはその変更の準備ができていますか？ —言えません。
試してみてください。試してみる価値があります。
はい、技術リーダーとマネージャーが必要です。個人的には、テクニカルリードの方がはるかに重要だと思います。 （それが何であるかがわからない場合は、基本的には作業を手渡し、全員が本来あるべきことを実行していることを確認する人です。）
私は現在、マネージャーのいない小さなチームで働いています。小さな会社。それはうまくいきます。
あなたのマイレージは異なる場合があります。
開発者のチームは、各人がチームとして作業し、利害関係者の期待に応えるのに十分成熟している場合、マネージャーを必要としません。
解決する必要がある問題に集中し、他の環境要因を気にする必要がない特定の役割（開発者など）があります。マネージャーがいると助かります。
付加価値を与えることができる誰かが常に助けると言っていました。 CEOでさえマネージャーのチーム（取締役会）に報告します。
私の2セント...
マネージャーがいることの利点は、マネージャーがチームのために果たす役割によって異なります。したがって、それは本当にチームに必要な役割に帰着します。
- チームメンバー間の紛争を解決し、時間どおりに質の高い仕事を提供することにチームを集中させる権限を持つ誰かが必要ですか？
- または、トップアンサーで述べたように、誰かにair coverを提供する必要がありますか？スケジュールの管理、優先順位の決定、上層部とチーム間の介入など。
それで、あなたはそれが必要ですか？あなたが指摘した立場の人々はあなたのためにこれを行うことができますか？もしそうなら、あなたは大丈夫です。そうでない場合は、おそらく災害に向かっています。
出典：グループプロジェクトおよび管理されたチームと管理されていないチームの個人的な経験。
それは組織のチームのために戦う必要がある戦いに依存することをお勧めします。あなたがあなたの仕事をするのを妨げる問題があるなら、マネージャーはそれらを整理するべきです。
それは、優先順位が賢明な方法で制御および設定されていることを確認したり、仕事に必要な機器、ソフトウェアなどを用意したりすることなどです。彼らは組織におけるチームの擁護者である必要があります。
どのようにしてビジネスに従事し、どのように取り組むべきかを決定し、誰が「完了」するかを決定します。組織がこれらのことを扱う場合、上司が多くのことを行う必要はありません。しかし、その場合、チームの外で変化が生じる可能性があり、ビジネスの1人または2人の重要な人物が役割を変更すると、困難な状況に陥る可能性があります。
おそらく、擁護者になることができる組織の強力なリーダーを選ぶことができますが、日常の管理に参加する必要はなく、彼らにアプローチして、彼らがあなたのチームを彼らの下に置く用意があるかどうかを確認します。 （おそらく、あなたはあなたが言及している「サービスマネージャー」ですでにそれを行っていました。）
短い答え：はい、できます。
長い答え：しかし、それはチームの人格に依存します。明らかに、誰かがあなたが何をしているかを決定する必要があるので、あなたは誰かに報告する必要があります-これはあなたのチームのマネージャーである必要はないかもしれませんが、誰かがあなたに仕事を与える必要があります。チーム内では、優先順位や技術的な問題を決定するために誰かが必要になる場合がありますが、それはチームリーダーが簡単に行うことができます。
開発チームを別のチームとマージする必要があるかもしれません。テストチームはありますか？開発チームを半自律的に保ちながら、両方に同じマネージャーを使用する方が良いでしょうか？
サービスマネージャーは、実行する必要のある作業を非常に喜んで提供し、必要な品質に適合していることを確認でき、このタスクを実行するための開発経験は必要ありません。ソフトウェアはビジネスツールでもあります。要件に適合するか適合しないか、そして通常それがユーザーであるかを決定するのに最適な人々。サービスマネージャーはあなたと彼らの間の連絡係として行動し、うまくいけばあなたは正しく働き続けるでしょう。私は、彼があなたのチームの責任を十分に制御できなかったことを心配しているだけです。物事がうまくいかなくなった場合、管理者が彼（またはもっと悪いことに、他の誰か）に責任を負わせるまで、あなたは不幸な状態になってしまうでしょう。君は。
自己管理チームは、通常のことではありません。通常、内部で生成された説明責任を作成するには、明確なパフォーマンスメトリックが必要です。組織でこれを使用することもできますが、コスト削減に基づいて追加の人数を生成できない場合、これはおそらく機能しません。もう1つの課題は、新しい上司が才能に報いる方法を知っている人のように聞こえないことです。
良くも悪くも、プレイヤーのコーチが必要なようです。チームの管理と実行の両方ができる人。 4人のグループでは、これは確かに実現可能です。 8人か10人のグループでは、そうではありません。課題は、このプレーヤーのコーチになる人を特定することです。デフォルトはそれをあなたの最高のプログラマーにすることですが、あなたは必ずしもそれらを管理者と結び付けたいですか？優秀な技術者全員がマネージャーになることを強制しない方法を見つけていると言うことを除いて、難しい答えはありません。
マネージャーは、組織と開発チームの間の欠けているリンクである傾向があります。
- 彼らはあなたの仕事が関連性があり、組織のニーズを満たすことを確認します。
- 上級管理職への回答
- プロジェクトが時間通りになるようにスケジュールを管理する
- プロジェクトのニーズに注意してください。
小さな責任を持つ小さなチームは、指定されたマネージャーがいなくても機能する可能性があります。しかし、責任が大きくなるにつれて、これらすべてのリスクと問題を管理する人が必要になります。
そして、あなたのセットアップが与えられれば、チームの誰かは、そのように指定されていなくても、最終的にマネージャーの役割を担うことになります。通常、分散された責任はうまく機能しません。それがどのように配布されるか、関係する人々のタイプに大きく依存します。
私は、アジャイルプラクティスを採用している会社、特にスクラムで働いています。全体的にうまく機能します。開発チームと経営幹部は皆幸せです。彼らは欲しいものを手に入れます。
- すべてのエンジニアはエンジニアリングマネージャーに報告します。エンジニアリングマネージャーは、非常に技術的かつ機能的な役割であり、部門でより多くのビジネスを獲得する必要があります。この役割は製品所有者と同等です。
- プロジェクトマネージャーは別の役割であり、スクラムマスターのような役割を果たし、通常は一定期間（12か月から18か月、契約の延長なしで）請負業者です。
- プロジェクトマネージャー（スクラムマスター）は、非機能的および非エンジニアリングの活動に完全に責任を負います。
開発チームはエンジニアリングの側面に焦点を当て、ビジネスアナリスト/製品の所有者はビジネスの側面に焦点を当てているため、これは素晴らしい働きをしました。プロジェクトマネージャーは、タスクの追跡、レポート、その他の典型的なスクラムマスターの職務を担当します。
中間管理職は外部委託されており、中間管理職からトップマネジメントへの成長経路はありません。成長の機会は、監督チームからではなく、開発チームまたはビジネスアナリストの役割からエンジニアリングマネージャーまでです。
当社は、中間管理職は会社にとって大きな付加価値ではなく、外部のコンサルティング会社に任せるのが最善であると強く信じています。
注目に値する点の1つは、その人がマネージャーとして指定されているかどうかに関係なく、あなたの1人が「事実上の」マネージャー、おそらく最も多くの経験/時間を提供されている人になる可能性があるということです。
特にこれは、リストラによる思考ではなく、コスト削減策（つまり、マネージャーに支払わずに開発者を雇う）として行われているため、上級管理職はこれまでどおりに機能し続けると思われます。以前は、よく知っている（つまり、最長のサービスを提供している）人々に対処するだけでした。
平等なチームは、1人の担当者が同じまたは類似したグレードのエンジニアのグループをまとめるのでない限り、常に問題だと思います。
S.Robinsが述べたように、すべてのチームメンバーが十分に統制されている場合、マネージャーを配置することはここで不必要なボトルネックになる可能性があります。私が働いたいくつかの小企業は、人的制約（他の理由の中で特に予算の制約のため）を抱えているため、少数の新入生/後輩のグループを、1人のラングを上に配置してフラットチームに配置する傾向があります。 。
「1レベル上位」のマネージャーが人を管理できない場合、これは逆効果になります。キャリアを始める新入生/後輩は非常に競争が激しくなります-チームでできるだけ早くしっかりと自分自身を確立するようにしてください。誰かが時々人々を拘束し、競争力が協力に悪影響を与えないようにする必要があります。
フラットなチームを持つことの問題は、プロジェクトのスケーリングでは、必然的に1人または2人の担当者にもう少し多くのことをさせ、もう少し責任を負わせる必要があることです。この時点で、明確に定義された階層を作成し、確実に適切なマネージャーを配置して、電話をかけたり人を管理したりする必要があります。なぜなら、同じグループ内からのプロモーションがあると、常に不幸な束があるからです。
他の多くの小さなCosで見られるもう1つの悪い考えは、マネージャーとしての指名または経験の点で最も年上の男性を置くことです。または、グループで最も技術的に熟練した男がマネージャーの役割に昇進します。私はこの仕事を見たことがありません。
4人を超えるチームでは、プロジェクトのスケーリングが適切であれば、タイムラインの早い段階で必ずマネージャーが必要になると思います。理想的には、人の管理スキルを持つ技術者であり、特定の決定については適切なコミュニケーションが必要です。