リード開発者をローテーションすることは良いアイデアですか、悪いアイデアですか？
数か月前の創設以来、組織的にフラットなチームで働いています。私のマネージャーは技術者ではないため、チーム全体が意思決定を担当しています。
私のマネージャーは、彼の目的（単一の連絡先とタスクの単一の責任者）と私たち（紛争解決、組織化された技術ガイダンスなど）の両方のために、リード開発者がいることにはいくつかの利点があることに気づき始めています。
チームがフラットであるため、1つの懸念は、1人のリード開発者を選択すると、他の開発者を落胆させる可能性があることです。開発者以外が、この問題を回避するためにリード開発者を交代させることが可能な方法であるとマネージャーに提案しました。 1人の開発者が1か月後にリードし、別の開発者が次の月にリードします。
これは良い考えですか？なぜ、またはなぜそうではありませんか？
これはall開発者を意味することに注意してください—すべての開発者は優れていますが、必ずしもリーダーシップに等しく適しているわけではありません。
そして、それがnotである場合、単に利己的な理由であるように思われることなく、このアプローチを回避することをどのように推奨しますか？
回転しないでください。
私は、回転されたポジションから誰も何も得ないと思います（リードに値しないものを除いて、彼らが現在受け取っているよりも多くのお金を得るかもしれません）。
次のことができる優秀なリード開発者がいると、開発プロセスに疑問が生じます。
- 委任する方法を知っています。
- 制御されています。
- 経験豊富な開発者です。
彼はチームの他のメンバーが調べてアドバイスを求めるための単一の情報源です。彼はまた、上級管理職とコア開発チームの間の仲介者でもあります。変化への取り組みを好む経営陣は知らない（彼らがそれを扇動するものでない限り）。
あなたが本当にその地位に最も適しているなら、誰もがそれを知っているでしょう。誰もがそれを知っています（たとえば、より高いレベルの管理、チームメイトなど）。ポジションを回転させることは価値があるとは思わないことを伝えます（信じている場合）。次に、座って彼らに任命させます-名前を付けたり、自己宣伝を控えたりすると、専門家ではないように見えます
リード開発者になるには2つの部分があります。
テクニカルリーダーシップテクニカルリーダーシップの場合、プロジェクトレベルで別のリードデベロッパーを選択することは理にかなっています。プロジェクトのローテーションに応じて必要に応じてローテーションし、各開発者を異なるプロジェクトのテクニカルリーダーにします。この種のアプローチはチームのダイナミクスに対処でき、全員が適切に挑戦されることを確認します
Communication外界とのコミュニケーションのための単一の連絡先は、外界にとっては良いものであり、連絡先にとっては悪いものです。コミュニケーションボールに行き詰まった人は、実際の仕事をする時間が少なくなり、みんなから情報を得るために走り回る必要があります。あなたが最高のコミュニケーターであり、すべての話をする代わりに、もっと楽しい仕事をやめることをいとわないなら、あなたにもっと力を。
関係する開発者が関与し、（理想的には）能力がある場合、それは必ずしも悪い考えではありません。
私はこれの参照を見つけるのに苦労しています（しかし、今後も調べます）が、私が正しく思い出した場合、アジャイル企業はこれを行います-彼らは「チームリーダー」のタイトルを毎回または他の事前定義された時間にローテーションします限目。これにより、開発者の関与が促進され、開発者を開発からその役割に恒久的に移行させることなく、チーム管理/外部コミュニケーションの一部を実行する機会がすべての人に与えられます。
いくつかの欠点には、情報の損失の可能性（これはさまざまな方法で軽減できます）と「悪い」リーダーシップの可能性の高さが含まれます。また、チームのビジョン/方向性を維持することが難しい場合もあります。ただし、全員がこのアプローチを採用しており、チームメンバーがそのようなシステムを機能させることに知識と関心を持っている場合は、一見の価値があります。
回転する場合は、プロジェクト中に回転しないでください。特定のプロジェクトの各ポジションで誰が最も適切であるかに基づいて、さまざまなプロジェクトのさまざまな人々にさまざまな役割を割り当てることには、本質的に問題はありません。しかし、仕事を遂行するのが彼の名簿にいるときだからと言って、ジョーを「リードプログラマー」にしないでください。彼はそれに熟練していないかもしれません、彼は仕事を望んでいないかもしれません。
時間に基づいてリード開発者を交代させることは悪い考えです。
誰もが優れた開発者であるということは、誰もが優れたリーダーであることを意味しません。そして、優れたリーダーであるということは、このプログラムのリーダーにふさわしいという意味ではありません。
開発者に割り当てられたミッションの重要性は異なると思いますし、各開発者のリーダーシップは異なります。投票を行うようにマネージャーにアドバイスできると思います。最高の候補者に1人が2人を投票し、最も多くの票を獲得した人がリーダー開発者である必要があります
私は Jonathan Khoo に同意する傾向があります。リード開発者を回転させることは悪い考えである可能性があります。一般に、大規模なプロジェクトの場合、プロジェクトの責任者である1人の技術リーダーがいて、その人は、システム全体のさまざまな問題について話し合うために、複数のコンポーネントリードから報告を受けます。
ただし、ジョナサンが言及しなかった重要な点の1つは、テクニカルリーダーが、プロジェクトの他のメンバーにはない高度な組織的知識も開発することです。テクニカルリードを回転させることにより、誰かがその位置に回転するたびに、その知識を発展させる必要があります。さらに、リードは、エンドユーザーとの（より大規模な）会議のいくつかに理想的に参加する必要があるため、プロジェクト外の顧客との関係を築きます。
技術的なリードを持つことは良いことですが、それらを回転させてみると、それなしでより良い結果が得られることがあります。
私はまず、誰がどのくらいの期間、この人の役割を決定する必要があると思います。
また、これによって残りの作業方法が大幅に変わるかどうか、およびパフォーマンスが低下するかどうかを判断する必要もあります。一人ではなく、あなたのコードのすべての行を「承認」する必要があります。
チームメンバーごとに異なる特定の役割を与えることができます。マネージャーと他の人とのコミュニケーションが最も得意な人は、そのための特定の役割を与えられるかもしれませんが、それは彼らが「リード開発者」であるという意味ではなく、技術的にも、または最高でもない人かもしれませんコードレビューを行います。
チームが表面的にはフラットである一方で、ISリーダーがすでに彼らの中にいること、そして彼ら全員がすでにそれを知っていることを、私は喜んで賭けたいと思います。
組織図は、人々が実際に働いている方法をほとんど反映していません。 「フラットチーム」のような特に理想的なグラフ。
組織がフラットな場合は、すべての開発者に要件とソリューション分析（RSA）トレーニングを実施して、正式なプロセスに従うように依頼します。次に、プロジェクトに複数の専門家（SME）を割り当て、すべてのソリューションに対して文書化されたプロセスを取得できます。
また、マネージャーは技術者ではないと述べたので、その個人は依然としてRSAプロセスを推進し、コミュニケーションを促進することができます。特定のSMEをプロジェクトごとのリードとして割り当てて、円滑化を支援し、個々のスキルセットを構築することもできます。
開発チームが匿名で投票しないのはなぜですか？私は優先投票を使用します。
- チームの中から誰かを選んでチームを率いることができます。
- あなたの上司は、このポジションを取るために別の経験豊富な人を雇うことができます
追伸ローテーションは良い考えではないと思います。その人はコミュニケーションのスキルがあり、チームの管理に優れた経験が必要です。
あなたの質問が示唆するように、チーム全体が意思決定に責任を負います。私はあなたが同じようにそれを保つことができると思います。ただし、チーム外の当局に連絡して報告する場合は、チーム内でTeam Co-Ordinatorを選択できます。彼/彼女の責任は非技術的なすべてを含みます。すべての技術的な側面について、チームはあなたが今行っているのと同じ方法で座って話し合う必要があります。あなたがどんな決定をしても、Co-Ordinatorを介して外部の世界に伝えられます。この位置は、時間ベースの方法で簡単に回転できます。
もう1つのアプローチは、経験レベル>同じプロジェクトでの経験>同じ会社での経験に基づいてリードデベロッパーを持つことです。また、必要に応じて、フェーズごとに位置を回転させることができます。理想的には、各開発フェーズに独自の一連の要件と成果物があり、それらをミニプロジェクトとして計画して取り組むことができます。フェーズごとに異なるリードを持つことで、回転による悪影響のほとんどすべてを最小限に抑えることができます。
回転するリード開発者を置く代わりに、回転するプロジェクトリーダー、つまりxプロジェクトを完成させるために最も知識と理解を持っている人を置きます。
リードデベロッパーは通常プロモーションであり、獲得する必要があります。
ただし、リーダーシップスキルのトレーニングと育成を支援するには、さまざまなプロジェクトの責任者をローテーションし、彼らがどれだけうまくやったかを明確に測定します。
十分に大きな船に船長がいるのと同じように、チームリーダーがいるはずです。
マネージャーがその役割を果たせない、または果たせない場合、開発者の1人がその役割を任命されなければなりません。
最初に、開発チーム内ですべての技術的な決定を下すことができて、どれほど幸運であるかをまとめて理解する必要があると思います。技術的な気まぐれを課すミクロ管理階層の負担に苦しんでいるチームがいくつあるか、その結果、一貫性のない選択、互換性の悪夢、開発者の不満が生じることがよくあります...
あなたが言及する開発リードの利点では、実際に技術的スキルの面で優れた人が実際にいれば、それらのいくつか（組織化された技術ガイダンス...）はすでに起こっているはずです。これが事実である場合、その人をリード開発者にすることで、あなたが現在得ているものよりもどのようにしてより良い結果を出すことができるのか、私にはわかりません。そのようなチームメンバーがあなたのチームに存在しない場合、技術的な権限をanyの人に正式に与えることが、議論や集団的決定よりも良い結果につながることはわかりません。
組織のリーダー、つまりデンマーク人が言うコーディネーターを設立することには、より多くの価値があると思います。マネージャーではなく、上司ではなく、集団的意思決定プロセスを組織し、チームのスポークスパーソン、外部へのインターフェースとして行動する人物。あなたがそのように行くなら、回転は前述の問題-給与の違い、嫉妬...を避けるために良い考えです。
時々、リーダーであることは他の何かよりもむしろ重い責任です。誰かが選択に対して責任を負う必要があります。それが、他の誰もそれをしたくないときに社会が機能する方法です。
チームがリーダーを交代させたいという事実は、誰もが自分の行動に対して責任を負うことができると感じており、誰にも恩恵を与えたくないと感じていることを意味するかもしれません。誰もがチームの成功を望んでいます。
このような場合、難しい決断があるときは、その決断に投票してください。他の人と話すための代表が必要なときは、最高のコミュニケーションスキルを持つ人を選んでください。