チーム内の開発者間の競合を処理する方法は?[閉まっている]


26

これはすべてのチームで起こっています。

何らかの理由で、チーム内で競合が発生し、全体的な動機と生産性に影響します。

その一般的な問題を解決するために推奨されるアプローチは何ですか?

  • チームの一部は依存性注入の実装を望んでおり、もう一方は時間の無駄だと考えています。
  • 一部の開発者は、チームの残りの部分が開発を遅くしていると考えています(これにより、スケジュールが遅れる理由が説明されます)
  • 1人以上の開発者間の個人的な非互換性
  • ある開発者が別の開発者と話すことを拒否する(明白な理由なしに)

4
質問は現状のままで良いと思います。違いは、質問がプログラマーと関係がない場合、私たちは反対することができるのに対して、質問がプログラマーに関係するが、他のものにも関係する場合、私は問題を見ないということです。このサイトで受け入れられるプログラミングの多くのものは、他の多くのトピックや分野にも適用できます。
ジャサリアン

1
競合には多くの種類があり、それぞれに独自の対処方法があります。もっと具体的に教えてください。
オタク

3
@David-サイト自体の基準は、プログラミングに関する質問です。どこにも関係ないとは言わない。開発者という用語を入れ替えると、答えが似ているからといって別の質問をしていることになりますが、同じ質問にはなりません。3 + 3とは何ですか?6.昆虫には何本の足がありますか?6. 2つの質問は完全に異なりますが、答えは同じです。開発者は、たとえば緊急サービスチームのメンバーとは完全に社会的に異なる場合があります。両方に競合があり、両方に競合を解決する異なる方法があります。
ジャサリアン

1
@Pierre:通知、コメント、またはより良い場所を得る機会なしに、この質問を今すぐ終了することを希望しますか?この質問は、オフィスの仕事に関するものです。
マニエロ

1
この質問は職場の関係に関するものであるため、トピック外のようです。例はプログラマーに関するものであり、言及されている競合の一部はプログラミングに関連していますが、核となるのは、グループの人々をどのようにうまく連携させるかです。
ブライアンオークリー

回答:


26

私は2年間10人のチームで対立することなく(タッチウッドで)運が良かったかもしれませんし、何か正しいことをしているかもしれません。競合を処理する最良の方法は、競合を長期間存在させないことです。あなたが説教できるいくつかのコアバリューがあります。

  1. チームスピリット
  2. すべての公平性(報酬/報酬)
  3. 感謝している
  4. 認識、責任を与える
  5. 自由を与える
  6. チームより大きくないことを人々に知らせます
  7. チームが失敗した場合、個人的な成功は何の意味もありません
  8. 人に個人的に添付する
  9. 与えるつもりのないニンジンを見せない
  10. チームを台無しにする可能性のある人を雇うことはありません
  11. より頻繁に通信するなど
  12. 誰かが仕事を超えたときはいつでも感謝します
  13. パフォーマンスに関する定期的なフィードバックを行い、できれば毎月の予想を設定してください。
  14. 子供のように振る舞うことを人々に知らせてください。

これらはすべて、いずれかから保護された努力をします。

ソフトウェアはほとんどチームゲームであり、個人の才能は一般的に短命です。あなたの例で行くと:

  1. 依存性注入を使用することにしました。期間。それが最良の方法であるかどうかを確認します。そうでない場合、あなたはチョコレートを手に入れます:-)協力するまで、このことを実現させましょう
  2. チームの残りの人があなたを遅くしているなら、あなたは彼らがそれをより速くするのを手伝います。私はあなたが良いことを知っています。
  3. 両方に話しかけて、環境を台無しにしていると伝えます。何も機能しない場合は、どちらかまたは両方を削除します。

私が非常に効果的だと思うことの1つは、「私たちは良いチームです」と「私たちは孤独なチームです」を繰り返すことです。


11
1000の賛成票を差し上げます。チームの競合は、マネージャーの責任です。貧しいマネージャーがいなかった多くの対立があるチームに参加したことはありません。あなたが言ったように、最善の方法は、競合が長く存在しないことを確認することです。あまりにも多くのマネージャーは、紛争を解決することで人々を混乱させることを恐れています。結果として、彼らはより多くの人々をより長い間混​​乱させ、生産性により大きな影響を与えます。人々を敬意を持って扱い、チームの他の人々を敬意を持って扱わない人を容認しないことが明らかな場合、紛争の多くはなくなります。あなたは働きがいのある人のようです。
HLGEM

1
+1非常に良い答えです!しかし、マネージャーとして、完璧なチームが存在しないこと、そして常にある程度の対立があることを頭の後ろに持っていなければなりません。それが人間の本性です!
アミールRezaei

「すべての公平性(報酬/報酬)」開示せずにこれを行うにはどうすればよいでしょうか?
デン

11

それは明らかに対立に依存します。複数のフレーバーがあります。

  • 宗教的な議論(「なぜスペースの代わりにタブを使用し続けるのですか?!?」)

この場合に明確にするポイントは、原則として、どちらが正しいかは問題ではなく、実際にはチーム全体が同じアプローチを使用することがはるかに重要であるということです。それを少数意見保持者に説明します(そして、それは必ずしも正しい決定ではなく、血を引くほど重要ではないことを強調してください)。これの縮退したケースは、たとえば、ソース管理の使用またはコードレビューへの提出を拒否する開発者です。これは管理上の問題であり、正直なところ、不正な開発者を手放さずに解決する方法を知りません。

  • 個人的な議論(「私はあなたが好きじゃない」)

これを軽減する方法は本当にありません。彼らの両方に、口論は受け入れられないこと、そして彼らが同じチームの生産的なメンバーになるつもりなら彼らの個人的なgrみをドアでチェックする必要があることを明確にしてください(これはあなたがマネージャーであるかどうかに関係なく;仲間が十分に確信している場合、驚くほど影響力があります)。それがうまくいかない場合は、組織図でそれらを分割して、彼らの専門的/物理的な近接性を減らすか、自分から机を離してください。

  • 技術的議論

これと他の競合タイプとの主な違いは、おそらく正しい答えがあるということです。通常、開発者が所有するコードとその動作方法に関係します(場合によっては、より大きなアーキテクチャ上の議論になります)。ここで重要なことは、正しい答えがあったとしても、おそらくあなたはそれを知らないということです。あなたができる最善のことは、それが明確な議論であることを確認するために調停し、どちらかの側が確信できることを願っています。繰り返しますが、彼らはあなたに報告するかどうかに関わらずこれを行うことができますが、あなたが仲間であれば、たとえあなたが彼らに結論をもたらしたとしても、彼らはマネージャーに遊びをやり直すかもしれません。


5

第三者の公平な調停者に紛争当事者の両方に座らせ、彼らにそれを話させてください。

調停人が問題を抱えている人が話しやすい人であるが、彼らがまだ尊敬していて、話しかけない場合に役立ちます


2

彼らが成熟して行動できず、両方を解任して専門家、おそらく請負業者/誰かフリーランスになることができない場合は?


2

私の経験では、この性質のほとんどの対立は性格の衝突に帰着します。それらのいくつかは他の要素を持っていますが、最も一般的には、これらは意見の相違の手段として使用されているだけなので、彼らが議論している問題を解決したとしても、それは他の何かが現れるまでの時間の問題です。

私のアドバイス:

1)最初のことは、対立が両者にひどく反映していることと、勝者と敗者ではなく、程度の異なる2人の敗者がいることを両方に明確にすることです。

2)両者にプロフェッショナルな態度で行動することを期待していることを明確にしてください。彼らはお互いを好む必要はありませんが、市民的で効率的で組織化されていなければなりません。それが彼らの毎年の評価とレビューに反映されていることを確認してください-チームメイトとの付き合いができないことは彼らのパフォーマンスの重要な問題です。

3)お互いの問題に耳を傾け、必要に応じて同情的であると同時に、この分野での失敗を指摘し、誰が正しいか誰が間違っているかについての長い議論や判断に引き込まれないようにします。上記の95%のケースで述べたように(残りの5%は懲戒問題として適切に対処する必要がある本物のいじめなどです)、彼らは両方間違っており、彼らはそれを理解する必要があります。

4)可能な限り、それらを簡単に分離できるようにします。私は一般的に、人々を一緒に投げることがそれをかき立てる以上のことをすることを見つけません。彼らが「和解」しようとするなら、とにかくそれは起こります、そして、彼らがお互いの顔に絶えずないとき、私は起こる可能性が高いと思います。


1

あなたは彼らに「テクオフ」で戦わせる必要があります。それぞれの側は部品の箱を手に入れます。

それがうまくいかない場合は、マチェーテの戦い、またはチェーンソーの戦いを試してみてください。


チェーンソー。すべてのソフトウェアエンジニアがDOOMをプレイしているので、私たちはすべてチェーンソーの専門家です。肉を見つける。
アダムクロスランド

@アダムクロスランドROFL
Muad'Dib

1

TKIは、いくつかの問題を解決する方法のアイデアである可能性がある競合を解決するためのいくつかの異なる手法を特定します。フレームワークを使用するかどうかなど、いくつかの正当な問題がありますが、これは、それを解決する1つの方法として何かに投票するチームによって、またはある種のマネージャーのような高位に進むことによって処理できます。特定の裁定を得るためにプロジェクトマネージャーまたはビジネスアナリストに行くことで処理するのが最適な要件の解釈に紛争が発生する場合があります。すべてには何も含まれていないと言います。

性格の対立が多い場合、問題はそれぞれが問題をどれだけよく知っているか、そしてこれが続く場合に何がなされるかということになる。これは、「皆さんがこれを解決できない場合、少なくとも1人のユーザーを削除することで解決します」という考え方ほど、怠idleな脅威ではありません。もちろん、これは受動的攻撃的な行動や他の子供っぽいがらくたの可能性を運んでいますが、これは、機知に富んだ人々が敵意を解決するために伝統的な武器を使用しない方法に入ったときに起こることです。 「Mean Girls」には、この種の振る舞いのいくつかの例がありますが、ちょっとした参考になります。


1

私は管理のベビーシッターの側面に耐えることができるとは思わない。私は彼らに、死との決闘でそれを解決するように言うでしょう。


申し訳ありませんが、この答えは-1です:
オタク

1
決闘は、それがマチェットまたはチェーンソーを含む限り、良いです:)
Muad'Dib

赤ちゃんが座っているように感じることができる日があることを理解するために+1。
ジョンホプキンス

1

「チーム契約」が便利だとわかりました。

チームメンバーが共同で開発する必要があります。高いところから落ちた場合は機能しません。

ただし、チームがすでに戦っている場合は少し遅れます。

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