主任開発者を交代させるのは良い考えですか、悪い考えですか？

私は数ヶ月前に作成されて以来、組織的にフラットなチームで働いています。私のマネージャーは非技術的であり、これは私たちのチーム全体が意思決定に責任があることを意味します。

私のマネージャーは、リード開発者（タスクの単一の連絡先と単一の責任者）と私たち（紛争解決、組織的な技術ガイダンスなど）の両方のために、リード開発者を持つことにはいくつかの利点があることに気付き始めています。

チームがフラットであるため、1つの懸念は、1人のリード開発者を選ぶと他の開発者を落胆させる可能性があることです。開発者以外の人が、この問題を回避する方法として、開発主任を交代させることがマネージャーに提案しました。1人の開発者が1か月間、別の開発者が1か月間、というように続きます。

これはいい考えですか？なぜですか？

これはすべての開発者を意味することに留意してください—すべての開発者は優れていますが、必ずしもリーダーシップに等しく適しているわけではありません。

そうでない場合、単に利己的な理由であるように見えることなく、このアプローチを避けることをどのようにお勧めしますか？

回転しないでください。

私は誰も回転しているポジションから何も得ないと思います（リードに値しないものは別として、現在受け取っているよりも多くのお金を得るかもしれません）。

次のことができる優秀な開発者がいることは、開発プロセスに驚くべきことです。

1. 委任する方法を知っています。
2. 制御されています。
3. 経験豊富な開発者です。

彼は他のチームが尊敬し、助言を求めるための単一の情報源です。彼はまた、上級管理職とコア開発チームとの間の仲介者でもあります。変化に対処するのが好きな経営チームは知りません（彼らがそれを引き起こしているのでない限り）。

あなたが本当にそのポジションに最も適しているなら、誰もがそれを知っているでしょう。誰もがそれを知っているでしょう（例えば、上級管理職、チームメイトなど）。ポジションをローテーションすることは価値がないと信じている（そう信じている場合）。次に、座って任命させます-名前を落とすことや自己宣伝のようなものは控えましょう

リード開発者になるには2つの部分があります。

• 技術的リーダーシップ技術的リーダーシップの 場合、プロジェクトレベルで別のリード開発者を選択することは理にかなっています。各開発者を異なるプロジェクトのテクニカルリードにし、プロジェクトの回転に応じて必要に応じて回転させます。この種のアプローチは、チームのダイナミクスに対処でき、全員が適切にチャレンジされるようにします

• コミュニケーション 外の世界とのコミュニケーションのための単一の接点は、外の世界にとっては良いことであり、接点にとっては悪いことです。コミュニケーションボールにこだわる人は、実際の仕事をする時間が少なくなり、全員から情報を引き継ぐために走り回らなければなりません。あなたが最高のコミュニケーターであり、すべての会話をすることと引き換えに、楽しい仕事をするのをやめることをいとわないなら、あなたへのより多くの力。

関係する開発者が関与し、（理想的には）能力があるのであれば、必ずしも悪い考えではありません。

私はこれに関する参考文献を見つけるのに苦労しています（しかし、私は探し続けます）が、いくつかのアジャイル企業がこれを正しく覚えている場合-反復ごとまたは他の事前定義時に「チームリード」のタイトルを回転させます期間。これにより、開発者の関与が促進され、開発者をその役割に永続的に移動させることなく、全員にチーム管理/外部コミュニケーションの一部を行う機会が与えられます。

いくつかの欠点には、情報の損失の可能性（これはさまざまな方法で軽減できます）や、「悪い」リーダーシップの可能性が高いことが含まれます。また、チームのビジョン/方向性を維持することも困難です。ただし、全員がこのアプローチを採用しており、チームメンバーがこのようなシステムを機能させることに知識があり、関心がある場合は、一見の価値があります。

回転させる場合は、プロジェクト中に回転させないでください。特定のプロジェクトの各ポジションで誰が最も適切であるかに基づいて、異なるプロジェクトの異なる人々に異なる役割を割り当てることは本質的に間違っていません。しかし、Joeが仕事を行うのは名簿に載っているという理由だけで、Joeを「リードプログラマー」にしないでください。彼はそれに対して熟練していないかもしれません、彼は仕事を望んでさえいないかもしれません。

時間に基づいて主任開発者を交代させることは悪い考えです。

誰もが優れた開発者であるということは、誰もが優れたリーダーであるという意味ではありません。優れたリーダーは、このプログラムのリーダーにふさわしいという意味ではありません。

開発者に割り当てられるミッションの重要性は異なり、各開発者のリーダーシップは異なると思います。投票を行うようにマネージャーにアドバイスできると思います。1人1人が最高の候補者に2人を投票し、最も多くの票を獲得した人がリーダー開発者になります。

私は、主任開発者を交代させることは悪い考えかもしれないというジョナサン・クーに同意する傾向があります。一般に、大規模なプロジェクトでは、プロジェクトを率いる単一の技術リードがあり、その人は、システム全体のさまざまな問題について議論するために、複数のコンポーネントリードから報告を受けることがあります。

ただし、ジョナサンが言及しなかった重要な点の1つは、技術リーダーがプロジェクトの他の人にはないかもしれない高度な制度的知識も開発するということです。テクニカルリードをローテーションすることで、誰かがその位置にローテーションされるたびにその知識を開発するように要求します。さらに、リードは、エンドユーザーとの（より大きな）ミーティングのいくつかに参加することが理想的であるため、プロジェクト外の顧客との関係を築きます。

技術的なリードを持っていることは良いことですが、それらをローテーションしてみれば、それなしで済ませる方がいいかもしれません。

私は最初に、誰がどのくらいの期間それを行うかよりも、この人の役割が何であるかを決定する必要があると思います。

また、これにより他の人の作業方法が大幅に変わるかどうか、およびパフォーマンスが低下するかどうかを判断する必要があります。一人の人があなたのコードのすべての行を「承認」する必要があるのは、他のピアがそれを行うよりも深刻な影響を与える可能性があります。

異なる特定の役割を異なるチームメンバーに付与することができますが、誰もが「優秀」になることはありません。マネージャーと他の人との間のコミュニケーションが得意な人には、それを行うための特定の役割が与えられる場合がありますが、それは彼らが「リード開発者」であることを意味しません。コードレビューを行う。

チームは表面上はフラットですが、彼らの中にはすでにリーダーがいて、全員がすでにそれを知っていることを賭けたいと思います。

組織図は、人々が実際にどのように働いているかをほとんど反映していません。「フラットなチーム」のような特に理想的なチャート。

組織が平坦な場合は、すべての開発者が要件とソリューション分析（RSA）トレーニングを受けて、正式なプロセスに従うようにします。その後、複数の主題専門家（SME）をプロジェクトに割り当て、文書化されたプロセスをすべてのソリューションに適用できます。

また、マネージャーは非技術的であると述べたため、その個人は引き続きRSAプロセスを推進し、コミュニケーションを促進することができます。また、特定のSMEをプロジェクトのリードとしてプロジェクトごとに割り当てて、円滑化を支援し、個々のスキルセットを構築することもできます。

開発チームが匿名で投票しないのはなぜですか？私は優先投票を使用します。

1. あなたのチームの中から誰かを選んであなたのチームを率いてください。
2. あなたの上司はこのポジションを取るために別の経験豊富な人を雇うことができます

PSローテーションは良いアイデアだとは思いません。人はコミュニケーションのスキルが必要で、チームの管理に優れた経験が必要です。

あなたの質問が示唆するように、チーム全体が意思決定に責任があります。私はあなたがそれを同じように保つことを提案します。ただし、チーム外の当局に連絡して報告するために、チーム内でチームコーディネーターを選択することができます。彼/彼女の責任には、技術的でないものすべてが含まれます。すべての技術的側面について、チームはあなたが今と同じように座って議論する必要があります。どのような決定を下しても、Co-Ordinatorを介して外部に伝達されます。この位置は、時間ベースで簡単に回転できます。

もう1つの方法は、経験のレベル>同じプロジェクトでの経験>同じ会社での経験に基づいて開発者をリードすることです。必要に応じて、位置を位相ごとに回転させることができます。理想的には、各開発段階には独自の要件と成果物のセットがあり、それらを計画してミニプロジェクトとして作業することができます。フェーズごとに異なるリードを設定すると、回転の悪影響をほぼすべて最小限に抑えることができます。

回転する主任開発者を配置する代わりに、回転するプロジェクトリーダー、xプロジェクトを完成させるための知識と理解が最も高い人を配置します。

リード開発者は通常プロモーションであり、獲得する必要があります。

しかし、リーダーシップスキルのトレーニングと開発を支援し、さまざまなプロジェクトの担当者を交代させてから、彼らがどれだけうまくやったかを明確に測定します。

十分に大きな船に船長がいるのと同じように、チームリーダーがいなければなりません。

マネージャーがその役割を果たさない、または果たすことができない場合、開発者の一人を任命する必要があります。

最初に、開発チーム内ですべての技術的な決定を下すことができることの幸運を理解する必要があると思います。技術的な気まぐれを課すマイクロ管理階層の負担に苦しむチームの数は、多くの場合、一貫性のない選択、互換性の悪夢、開発者のフラストレーションをもたらします...

あなたが言及する開発リーダーの利点では、技術スキルの面で自然に傑出した人が実際にいた場合、それらのいくつか（組織化された技術ガイダンス...）がすでに起こっているはずです。この場合、その人を公式にリード開発者にすることで、現在入手しているものよりも良い結果が得られるかどうかはわかりません。こうしたチームメンバーがチーム内に存在しない場合は、私がどのように正式に技術的な権限を与えて見ることができません任意の議論と集団的意思決定よりも良い結果につながるであろう人。

デンマーク人が言ったように、組織のリーダー、つまりコーディネーターを確立することにはもっと価値があると思います。マネージャーではなく、上司ではなく、集団的意思決定プロセスを組織し、チームのスポークスマン、つまり外部へのインターフェースとして行動する人。そうすれば、給与の違い、avoidなど、前述の問題を回避するためにローテーションを行うことをお勧めします。

リーダーになることは、他の何かよりも重い責任になることもあります。誰かが選択に対して責任を負います。それは、他の誰もそれを望んでいないときに社会がどのように機能するかです。

チームがリーダーを交代させたいという事実は、誰もが自分のやることに責任を負うことができると感じていることを意味する可能性があり、誰にも有利になりたくないし、良いことのように思えます：誰もがチームの成功を望んでいます。

そのような場合、難しい決定を下す場合は、それらの決定に投票するだけで、他の人と話すために代表者が必要な場合は、最高のコミュニケーションスキルを持っている人を選ぶだけです。

まず第一に、役割を分離する必要があると思います。チームと他の会社との間の連絡窓口として行動する人が、必ずしも最終的な技術的決定を下す人である必要がある理由はありません。

連絡先として機能することは権限を付与するものではないため、決まったスケジュールでその責任を交代する必要はありません。チームに座ってもらい、誰もが仕事をやりたいと思うと言って（一部の人はそれを好むかもしれません、他の人はそれをすることに強く反対するかもしれません）、そして誰かを投票して役割を果たしてください。彼らがそれをすることにうんざりするときはいつでも彼らがそれを他の誰かに引き渡すことができることを理解させます。

テクニカルリード側については。全員が同じスキルセットとほぼ同じレベルの経験を持っている場合は、必ず、全員がリードになるように手を試してください。重要なことは、プロジェクトの途中で絶対に変更しないことです。新しいプロジェクトが開始されるまで待ってから、その分野で最も経験のあるリーダーまたはランダムにリーダーを選びます。