チーム内での対立の管理 – バランスを取るためのものですか、それとも不可欠なものですか?

エピグラフ：
むかしむかし、ハリネズミとこぐまが森で出会いました。
- こんにちは、ハリネズミ！
- こんにちは、リトルベア！
それで、一言一句、冗談ごとに、ハリネズミは子熊に顔を殴られました...

以下は、チームリーダーであり、RAS 製品開発ディレクターである Igor Marnat による、仕事の競合の詳細とそれらを管理するための可能な方法についてのディスカッションです。

私たちが職場で遭遇する対立のほとんどは、上記のエピグラフで説明されているのと同様のシナリオに従って発展します。 最初はお互いに非常に好意的な参加者が何人かいて、問題を解決しようとしているのですが、結局問題は解決されず、何らかの理由で議論の参加者間の関係が損なわれていることが判明します。

人生は多様であり、上記のシナリオには変化が生じます。 参加者間の関係が最初はあまり良好でない場合もあれば、直接的な解決策が必要な問題さえない場合もあります (エピグラフなど)。 場合によっては、議論の後も関係が開始前と同じままである場合もありますが、問題は最終的には解決されません。

仕事上の衝突の状況として定義できるすべての状況に共通するものは何ですか?



まず、XNUMXつ以上の側面があります。 これらの関係者は、組織内のさまざまな場所を占め、対等な関係（チーム内の同僚）にある場合もあれば、階層のさまざまなレベル（上司と部下）にある場合もあり、個人（従業員）またはグループ（組織間の対立の場合）になる場合もあります。従業員と XNUMX つまたは XNUMX つのチーム）など。 紛争の可能性とその解決の容易さは、参加者間の信頼レベルに大きく影響されます。 当事者がお互いのことをよく知っていればいるほど、信頼レベルが高くなり、合意に達する可能性が高くなります。 たとえば、対面でやり取りしたことがない分散チームのメンバーは、少なくとも数回対面でやり取りしたことがあるメンバーよりも、単純な仕事上の問題で衝突を経験する可能性が高くなります。 したがって、分散したチームで作業する場合、チーム メンバー全員が定期的に直接会うようにすることが非常に重要です。

第二に、職場で対立している状況では、当事者は、当事者の一方にとって、当事者双方にとって、または組織全体にとって重要な問題を解決する状況にあります。 同時に、状況の特殊性により、通常、当事者には十分な時間があり、それを解決するためのさまざまな方法（公式、非公式、会議、手紙、経営上の決定、チームの目標と計画の存在、階層構造などの事実）。 これは、組織内の仕事 (または仕事以外) の問題を解決する場合、たとえば「えー、子供、どこの地域の出身ですか?!」という重要な質問を解決する場合とは異なります。 路上で、またはエピグラフからの衝突。 仕事の問題を解決する場合、作業プロセスの質とチームの問題解決の文化が重要です。

第三に、（私たちの議論の観点から）紛争の決定要因は、プロセスの当事者がすべての当事者に適合する問題の解決策を独自に導き出すことができないという事実です。 この状況では、第三者、つまり外部の裁定者の介入が必要になります。 この点は議論の余地があるように思えるかもしれないが、本質的に、外部の仲裁者の介入なしに紛争状況が首尾よく解決され、問題が首尾よく解決され、当事者間の関係が悪化しなかったのであれば、これは私たちが努力すべき状況である。 。 おそらく私たちはそのような紛争についてすら知らないか、解決後に偶然知ることになるでしょう。 チームが独自に解決できる問題が多ければ多いほど、より効果的になります。

触れておく価値のある紛争のもう XNUMX つの特徴は、決定を下す際の感情の激しさです。 対立は必ずしも高い感情レベルと関連しているわけではありません。 本質的には紛争であるために、参加者は叫んだり腕を振ったりする必要はありません。 問題は解決されておらず、ある種の感情的な緊張が存在しており（おそらくそれが表面的には明確に表現されていない）、これは私たちが紛争の状況に直面していることを意味します。

そもそも紛争状況に介入する必要があるのでしょうか、それとも、解決を自然に任せて問題が自然に解決するのを待ったほうが良いのでしょうか? する必要があります。 紛争を完全に解決することが常にあなたの力や能力にあるわけではありませんが、どのような状況でも、どのような規模の紛争でも、あなたは大人の立場を取ることができ、それによって周囲のさらに数人の人々を紛争に巻き込み、紛争による悪影響を軽減することができます。紛争を解決し、その解決に貢献します。

紛争状況の例をいくつか見る前に、すべての紛争に共通する重要な点をいくつか見てみましょう。

紛争を解決するときは、争いの内側ではなく上に立つこと（これを「メタポジションを取る」とも言います）、つまり、解決プロセスにおいてどちらかの当事者にならないことが重要です。 そうしないと、外部の仲裁人に決定を支援してもらうことは、一方の当事者の立場を強化して他方の当事者に不利益をもたらすだけです。 決定を下すときは、当事者全員が「買った」と言うように、それが道徳的に受け入れられることが重要です。 そのため、たとえ両当事者が下された決定に満足していなかったとしても、少なくともその決定を実行することに心から同意したのです。 彼らが言うように、同意せずにコミットできることです。 そうでなければ、紛争は単にその様相を変えるだけであり、くすぶっていた火は泥炭沼の下に残り、ある時点で必然的に再び燃え上がるだろう。

XNUMX 番目の点は、XNUMX 番目の点と部分的に関係しますが、紛争の解決に参加することをすでに決定している場合は、コミュニケーションと状況の研究の観点から、可能な限り真剣にそれを受け止めてください。 各当事者と個人的に話し合います。 まず、それぞれを個別に説明します。 メールで満足しないでください。 分散チームの場合は、少なくともビデオリンクを介して話します。 伝聞や目撃情報に満足してはいけません。 ストーリーを理解し、双方が何を望んでいるのか、なぜそれを望んでいるのか、何を期待しているのか、以前にこの問題を解決しようとしたことがあるか、解決されなかった場合に何が起こるのか、どのような解決策を考えているのか、両国の立場をどのように想像しているのか。相手はどう思うか、正しいか間違っているかなど。 誰もが正しいと仮定して、広い心で考えられるすべての文脈を頭の中にロードしてください。 あなたは葛藤の内側にいるのではなく、葛藤の外側にいて、メタポジションの中にいます。 コンテキストが投稿スレッドでのみ利用可能な場合は、少なくともその全体とそれに関連するスレッドとドキュメントを読んでください。 読み終わった後も、声を出して話してください。 メールには書かれていない重要な内容が届くことはほぼ確実です。

XNUMX 番目の重要な点は、コミュニケーションへの一般的なアプローチです。 これらは普通のことであり、宇宙的なものではありませんが、非常に重要です。 私たちは時間を節約しようとはせず、参加者全員と話し合い、その人を批判しませんが、その人の行動がもたらす結果を考慮します（「あなたは無礼だ」ではなく、「おそらく彼らは不快に思うかもしれません）」このこと」）、私たちは面目を保つ機会を与え、列の前ではなく直接会って議論を行います。

競合は通常、XNUMX つの理由のいずれかによって発生します。 XNUMX つ目は、紛争時にその人が大人の立場にあるか、子供の立場にあるかに関係します (これについては後述します)。 これは彼の感情的な成熟、つまり感情を管理する能力によるものです（ちなみに、これは必ずしも彼の年齢とは関係ありません）。 XNUMX 番目に多い理由は、作業プロセスの不完全さです。これにより、責任が参加者間で分散され、関係者の期待が相互に不透明になり、プロセスにおける役割があいまいになる、グレーゾーンの状況が生じます。

したがって、紛争 (およびその他の問題) を解決する際、マネージャーは XNUMX つの観点を念頭に置く必要があります。短期 - 問題/紛争を現時点で解決するため、中期 - 別の紛争が発生する可能性を最小限に抑えるためです。同じ理由で、そして長期的には、チームメンバーに大人の文化を育むためです。

私たちにはそれぞれ、およそ XNUMX 歳か XNUMX 歳のインナーチャイルドがいます。 彼は仕事中はほとんどの時間寝ていますが、時々起きて仕事をコントロールします。 子供には子供自身の優先順位があります。 彼にとって、ここは彼のサンドボックスであり、母親は彼をもっと愛しており、彼のマシンは最高である（デザインは最高であり、彼のプログラムは最高である...）と主張することが重要です。 紛争の状況では、子供はおもちゃを押したり、足を踏み鳴らしたり、ヘラを鳴らしたりすることはできますが、大人の問題 (ソリューション アーキテクチャ、自動テストへのアプローチ、リリース日など) を解決することはできず、利益の観点から考えません。チームのために。 葛藤を抱えている子どもは、大人に電話するように頼むことで励まし、慰め、寝かしつけることができます。 対立した状況で議論を始める前に、話している相手が子供ではなく大人であること、そしてあなた自身が大人の立場にあることを確認してください。 現時点でのあなたの正直な目標が、深刻な問題を解決することであるなら、あなたは大人の立場にいます。 足を踏み鳴らして肩甲骨にヒビを入れることが目的なら、これは子供じみた姿勢です。 インナーチャイルドをベッドに寝かせて大人に電話するか、話し合いのスケジュールを変更してください。 人は感情的に決断を下し、それを合理的に正当化する理由を探します。 子どもの優先順位に基づいて子どもが下した決定は最適なものではありません。

紛争時の行動に加えて、子供または大人の立場は、人が自ら引き受ける準備ができている責任のレベルによっても特徴付けられます。 私が何度か会ったことがあるプログラマーの子供じみた立場は、その極端な現れとして次のようなものです。「私はコードを書き、レビューのために送りました。私の仕事は終わりました。」 レビュー担当者がレビューして承認し、QA がチェックして、問題があれば私に知らせてくれます。 奇妙なことに、かなり成熟した経験豊富な人でも、このように行動することがあります。 もう一方の端は、その人が、自分のコードが動作すること、テストでカバーされていること、個人的にチェックされていること、レビューに合格していることを確認する責任があると考えていることです (必要に応じて、レビュー担当者に ping を送信したり、問題について話し合ったりしても問題ありません)音声など) が抑制されている場合、必要に応じて QA がサポートを提供し、テスト シナリオが説明されます。 通常の場合、プログラマーは成人の末端に近いところからスタートするか、経験を積むにつれてそこに移ります (チーム内で適切な文化が培われている場合)。 極端な場合には、彼は通常は子供じみた立場を取りながら仕事を続けますが、その後、彼とチームは定期的に問題や衝突を抱えます。

チーム内に正しく成熟した文化を育むことは、どのマネージャーにとっても重要な仕事です。 長い時間と毎日の努力が必要ですが、結果にはそれだけの価値があります。 チーム文化に影響を与える方法は XNUMX つあります。XNUMX つは模範を示すこと (必ず従うことになります。チームは常にリーダーに注目します)、もう XNUMX つは正しい行動について話し合い、報酬を与えることです。 ここでも難解で堅苦しいものは何もありません。ただ、問題について議論するときに、ここで何かを行うことができたかもしれないことに気づき、それが正しく決定されたときに気づいたことを強調し、賞賛し、リリースレビュー中にメモするなどです。

単純なものから複雑なものまで、いくつかの典型的な競合状況を考えてみましょう。

仕事の問題に関係のない衝突

職場では、仕事の問題とは関係のない衝突が起こることがよくあります。 それらの発生と解決のしやすさは、通常、参加者の心の知能レベルや成熟度に直接関係しており、作業プロセスの完璧か不完全さには関係ありません。

典型的な例: 誰かが洗濯機やシャワーをあまり頻繁に使わず、他の人はそれを好まない、誰かが息苦しく、他の人は窓を開けると風が当たる、誰かがうるさすぎる、他の人は仕事をするために沈黙を必要とする、すぐ。 この種の紛争の解決を遅らせたり、そのまま放置したりしないことが賢明です。 それらは自然に解決されず、毎日の仕事から気が散り、チーム内の雰囲気を悪化させます。 幸いなことに、問題を解決するのは通常は大きな問題ではありません。衛生面を軽視する同僚と落ち着いて（もちろん一対一で）話したり、静寂や涼しさを好む人に快適な座席を用意したり、吸音ヘッドフォンを購入したり、パーティションを設置したりするだけです。 、など。

私が仕事中に何度か遭遇したもう一つの例は、チームメンバーの心理的な不一致です。 何らかの理由で、人々は一緒に働くことができず、すべての交流はスキャンダルで終わります。 場合によっては、人々が何らかの差し迫った問題（通常は政治的）に関して両極端な意見を持っていて、それを仕事以外で放っておく方法がわからないという事実が原因である場合があります。 彼らにお互いを容認したり、行動を変えたりするよう説得するのは、かなり無駄な作業です。 私が遭遇した唯一の例外は、オープンな認識を持つ若い同僚であり、彼らの行動は定期的な会話を通じて徐々に変えることができます。 通常、問題は、メンバーを異なるチームに分けるか、少なくとも仕事で重複する機会をごくまれに設けることでうまく解決されます。

上記のすべての状況において、参加者全員と個人的に話し、状況について話し合い、この場合に問題があると思うかどうかを尋ね、解決策は何だと思うかを尋ね、この計画の作成に参加者が確実に参加できるようにする価値があります。決断。

業務プロセスの最適化（先ほどの中期的な視点）という観点からは、あまりできることはなく、最適化のポイントは、人を配置するのではなく、チーム編成時に相性を考慮することだけです。誰が衝突するかを事前に一緒にします。

チーム文化の観点から見ると、人々がチームと同僚を尊重し、独自に問題を解決する方法を知っている成熟した文化を持つチームでは、そのような状況はあまり発生しません。 さらに、信頼レベルが高く、長期間一緒に働いたり、仕事以外で頻繁にコミュニケーションをとったりするチームでは、このような対立ははるかに簡単に (多くの場合自動的に) 解決されます。

仕事上の問題に関連した衝突:

このような対立は通常、感情的（参加者の一人が大人の立場にないという事実）と作業プロセス自体の不完全さの両方の理由が同時に発生して引き起こされます。 おそらく、私が遭遇した最も一般的なタイプの競合は、開発者間のコード レビューまたはアーキテクチャに関する議論中の競合です。

ここでは XNUMX つの典型的なケースを取り上げます。

1) 最初のケースでは、開発者は同僚からコードレビューを得ることができません。 パッチはレビューのために送信されますが、何も起こりません。 一見すると、両者の間に明らかな対立はありませんが、よく考えてみると、これはかなりの対立です。 仕事の問題は解決されておらず、当事者の一方（レビューを待っている）は明らかな不快感を感じています。 このケースの極端なサブタイプは、コミュニティまたは別のチームでの開発ですが、レビュー担当者は読み込みやその他の状況により、この特定のコードに興味がなく、レビュー要求にまったく注意を払わない可能性があり、外部の裁定者がいる可能性があります。 (双方に共通のマネージャー) ) が存在しない可能性があります。

このような状況に役立つ解決策のアプローチは、まさに長期的な視点、つまり大人の文化に関連しています。 まず、スマートなアクティビティが機能します。 レビューにぶら下がっているコードがレビュー担当者自身の注目を集めるとは期待しないでください。 査読者が彼に気づくよう手助けする必要があります。 ピンガニの数人がシンカペについて質問し、ディスカッションに参加します。 明らかに、輸入は助けになるよりも害を及ぼす可能性が高いため、常識を働かせる必要があります。 次に、事前準備がうまく機能します。 何が起こっているのか、なぜこのコードが必要なのかをチームが理解しており、設計が全員で事前に議論され合意されていれば、人々はそのようなコードに注意を払い、それを仕事に受け入れる可能性が高くなります。 第三に、権威が機能します。 レビューを受けたい場合は、自分でたくさんのレビューをしてください。 実際のチェック、実際のテスト、有益なコメントを含む、質の高いレビューを行います。 あなたのニックネームがチーム内でよく知られている場合、あなたのコードが注目される可能性が高くなります。

ワークフローの観点から見ると、ここで考えられる改善とは、開発者とチームの目標 (他の人をレビューする、コミュニティに手紙を書く、コードにアーキテクチャの説明、ドキュメント、テストを添付する、開発者とのディスカッションに参加する) を達成するのを助けることを目的とした正しい優先順位付けです。コミュニティなど）、パッチがキュー内に長時間滞留するのを防ぎます。

2) コードまたは設計のレビュー中によくある XNUMX 番目の競合ケースは、技術的な問題、コーディング スタイル、ツールの選択に関する見解の相違です。 この場合に非常に重要なのは、同じチームに属している参加者間の信頼レベル、そして一緒に働いた経験です。 参加者の一人が子供っぽい立場をとり、対話者が彼に伝えたいことを聞こうとしない場合、行き詰まりが発生します。 多くの場合、相手が提案したアプローチと最初に提案したアプローチの両方がうまく機能する可能性があり、どちらを選択するかは原理的に問題ではありません。

ある日、私のチームのプログラマー (パシャと呼びましょう) が、パッケージ展開システムに変更を加えたパッチを準備しました。このパッチは、隣の部門の同僚によって開発およびサポートされました。 そのうちの XNUMX 人 (Igor) は、パッケージをデプロイするときに Linux サービスをどのように構成する必要があるかについて、独自の強い意見を持っていました。 この意見はパッチで提案されたアプローチとは異なり、同意できませんでした。 いつものように締め切りは迫っており、何らかの決定を下す必要があり、どちらかが大人の立場に立つ必要がありました。 パシャは、どちらのアプローチにも生存権があることを認識していましたが、自分の選択肢を通過させたかったのです。 どちらのオプションも XNUMX 番目のオプションも、明らかな技術的な利点はありませんでした。

私たちの議論は次のようなものでした（もちろん、非常に概略的に言えば、会話はXNUMX分続きました）。

- パシャ、数日以内に機能をフリーズします。 すべてをまとめて、できるだけ早くテストを開始することが重要です。 どうすればイゴールを乗り越えられるでしょうか？
— 彼は別の方法でサービスを設定したいと考えており、私のためにそこにコメントを貼り付けました...
- それで、大きな変更、大騒ぎは何ですか?
- いいえ、数時間の作業はありますが、最終的には違いはなく、どちらでも機能します。なぜこれが必要ですか? うまくいくものを作ったので、それを受け入れましょう。
- 聞いて、どれくらいこのことについて話し合っているのですか?
- はい、XNUMX週間半前から時間を計測しています。
- ええと...すでに XNUMX 週​​間半かかった問題を数時間で解決できますが、それはできませんか?
- そうですね、でもイゴールには私が挫折したと思われたくないんです...
- 聞いてください、あなたにとって、心の中での決断とともに釈放を発表することと、イゴールを殺すことのどちらがより重要ですか? それをブロックすることはできますが、リリースで飛び抜ける可能性は十分にあります。
- そうですね... もちろん、イーゴリの鼻を拭くのはクールでしょうが、まあ、リリースの方が重要です、私も同意します。
- イゴールが何を考えているかはあなたにとって本当に重要ですか? 正直に言うと、彼はまったく気にしていません。ただ、自分が担当する事柄のさまざまな場所で統一されたアプローチを望んでいます。
- そうですね、コメントで彼が求めているとおりにして、テストを始めましょう。
- ありがとう、パシャ！ イゴレクの方が年上ですが、お二人の中ではあなたの方が成熟していると確信していました :)

問題は解決され、リリースは予定通りにリリースされ、パシャはあまり不満を感じませんでした。 彼自身が解決策を提案し、それを実行しました。 イゴールは概ね満足していました。なぜなら... 彼の意見は考慮され、彼らは彼の提案どおりに行動しました。

本質的に同じ競合のもう XNUMX つのタイプは、プロジェクト、特に分散チームにおける技術ソリューション/ライブラリ/アプローチの間の選択です。 C/C++ を使用すると位置づけられていたプロジェクトの XNUMX つでは、プロジェクトの技術管理が STL (Standard Template Library) の使用に断固として反対していることが判明しました。 これは開発を簡素化する標準言語ライブラリであり、私たちのチームはこれに非常に慣れています。 このプロジェクトは C++ よりも C にはるかに近いことが判明しましたが、チームはあまり刺激を受けませんでした。 運営は最善を尽くして、本当に素晴らしいプラスプレイヤーを採用しました。 同時に、チームのアメリカ人部分は、エンジニアもマネージャーも、会社で長く働いており、現状に慣れており、すべてに満足していました。 チームのロシア側はごく最近、数週間以内に集められました（私も含めて）。 チームのロシア側は、開発に対する通常のアプローチを断固として放棄したくありませんでした。

XNUMX つの大陸間で終わりのない書面による議論が始まり、プログラマーからプログラマー、マネージャーへと、グループ メールや個人メールで XNUMX つまたは XNUMX つの画面に文字が飛び交いました。 いつものことですが、この長さの手紙は、著者とその熱烈な支持者以外には誰も読まれませんでした。 チャットは緊張できしむ音を立て、STL の技術的利点、STL がどれほど十分にテストされているか、どれほど安全であるか、そして一般的に、STL がある生活がいかに素晴らしいか、そして STL がない生活がどれほど恐ろしいかについて、さまざまな方向にマルチスクリーンの考えが飛び交いました。 。

これはかなり長い間続き、最終的に、私たちは問題の技術的な側面について議論していたが、実際には問題は技術的なものではなかったことに気づきました。 問題は、STL の長所や短所、あるいは STL なしでの作業の困難さではありません。 問題はかなり組織的なものです。 私たちが必要としていたのは、私たちが働いていた会社がどのように機能しているかを理解することだけでした。 私たちの誰も、これまでそのような会社で働いた経験がありませんでした。 問題は、コードが開発されて運用環境にリリースされた後、サポートは他のチームや他の国のまったく別の人々によって処理されたということでした。 (合計で) 数万人のエンジニアからなるこの巨大なエンジニアリング チームは、完全に基本的な最小限の、いわば最小限の技術的手段しか余裕がありませんでした。 社内で定められた技術基準を物理的に超えたものは、将来的にはサポートできなくなります。 チームのレベルは、最も弱いメンバーのレベルによって決まります。 理解した上で 本当のモチベーション チームのアメリカ側の行動により、この問題は議題から外され、私たちは協力して会社が採用した標準を使用して製品の開発とリリースに成功しました。 この場合、手紙やチャットはうまく機能せず、共通点を見つけるまでには数回の旅行と多くの個人的なコミュニケーションが必要でした。

ワークフローの観点から見ると、この特定のケースでは、使用されるツール、その要件、新しいツールを追加する際の制限、およびそのような制限の正当性の説明があると役立ちます。 このような文書は、「ソフトウェア開発管理者向けハンドブック」の「再利用戦略と開発環境」の段落に記載されている文書にほぼ対応しています。 米航空宇宙局（NASA）。 古いものであるにもかかわらず、この種のソフトウェア開発のすべての主要な活動と計画段階が完全に説明されています。 このようなドキュメントがあると、製品でどのコンポーネントやアプローチを使用できるか、またその理由について議論することが非常に簡単になります。

文化的な観点から見ると、明らかに、より成熟した立場であり、当事者は同僚の行動の本当の動機を聞いて理解しようとし、個人のエゴではなくプロジェクトとチームの優先順位に基づいて行動します。 、競合はより簡単かつ迅速に解決されます。

技術的解決策の選択をめぐる別の紛争でも、一方の当事者の動機を理解するのにかなりの時間がかかりましたが (これは非常に珍しいケースでした)、動機が明確になった後は、解決策は明らかでした。

状況は次のとおりです。約 20 人のチームに新しい開発者が現れました。彼を Stas と呼びます。 当時、チームとしてのコミュニケーションの標準ツールは Skype でした。 後で判明したことですが、Stas はオープン スタンダードとオープン ソース ソフトウェアの大ファンで、ソースが公開されており、公開されているプロトコルを使用するツールとオペレーティング システムのみを使用していました。 Skype はこれらのツールの XNUMX つではありません。 私たちは、このアプローチの長所と短所、Skype の類似物をさまざまなオペレーティング システムで起動する試み、スタス氏が他の標準に切り替えるようチームを説得する試み、彼に直接メールで手紙を書くこと、電話で個人的に電話をかけることなどについて、多くの時間を費やして議論しました。電話を購入したり、Skype 専用の XNUMX 台目のコンピュータを購入したりするなどです。 最後に、この問題は本質的に技術的でも組織的なものではなく、むしろイデオロギー的であり、（スタスにとっては）宗教的であるとさえ言えるかもしれないことに私は気づきました。 最終的に Stas と Skype に接続したとしても (数か月かかりました)、その後の機器でも問題が再び発生するでしょう。 私にはスタスの世界観を変えるための実際的な手段はありませんでしたし、この環境で完璧に機能するチームの世界観を変えようとする理由もありませんでした。 その人と会社は、その世界観において単純に直交していました。 このような状況では、組織的な解決策が有効です。 私たちはスタスを別のチームに移籍させ、そこで彼はより有機的になりました。

私の意見では、この対立の原因は、特定の個人（妥協を許さない強い意見を持っている）の個人的な文化と会社の文化との間の齟齬であると考えています。 この場合、もちろん管理者のミスです。 彼をこの種のプロジェクトに参加させるのは当初間違っていた。 Stas は最終的にオープンソース ソフトウェア開発プロジェクトに移り、そこで優秀な成績を収めました。

開発者の幼稚な態度と作業プロセスの欠点の両方によって引き起こされる対立の良い例は、完了の定義がないため、開発者と QA チームが完了の準備に関して異なる期待を持っている状況です。機能は QA に転送されました。 開発者は、コードを書いてその機能を QA に投げ込むだけで十分だと信じていました。QA はそこで解決してくれるでしょう。 ちなみに、かなり成熟した経験豊富なプログラマーですが、それが彼の内部の品質の基準でした。 QA はこれに同意せず、QA が自分でチェックしたものを見せて説明するよう要求し、QA 用のテスト スクリプトを要求しました。 彼らは過去にこの開発者の機能に問題があったため、再び時間を無駄にしたくなかったのです。 ちなみに、彼らは正しかったです。この機能は実際には機能しませんでした。彼は QA に送信する前にコードをチェックしませんでした。

この状況を解決するために、私は彼に、すべてが実際に機能していることを見せてほしいと頼みました（機能しなかったため、修正する必要がありました）。私たちはチームと、そして QA の完了の定義について話し合いました（彼らはうまくいきませんでした）プロセスを官僚的にしすぎたくなかったので、書いています）、まあ、私たちはすぐにこの専門家と別れました（一般的に安心しました）。

ワークフローの観点から、この場合に考えられる改善点は、完了の定義の存在、各ユニット機能と統合テストのサポート要件、開発者が実行するテストの記述の存在です。 プロジェクトの XNUMX つでは、CI 中のテストによるコード カバレッジ レベルを測定し、パッチの追加後にカバレッジ レベルが低下した場合、テストは失敗としてマークされました。 新しいコードは、新しいテストがある場合にのみ追加できます。

もう XNUMX つの典型的な紛争は、作業プロセスの組織化に密接に関係しています。 私たちには製品、製品開発チーム、サポート チーム、そして顧客がいます。 お客様は製品に問題があり、サポートに問い合わせました。 サポートは問題を分析し、問題が製品にあることを理解し、問題を製品チームに転送します。 製品チームはリリースが近づいており、忙しい時期にあります。そのため、顧客からの問題のあるチケットが、割り当てられている開発者の他のチケットの中に紛れ込んでしまい、注目されずに数週間保留されてしまいます。 サポートは、開発者が顧客の問題に取り組んでいると考えています。 顧客は、問題が解決されることを期待して待っています。 実際にはまだ何も起こっていません。 数週間後、お客様はついに進捗状況に興味を持ち、サポートに状況がどうなっているか尋ねました。 サポートは開発を求めます。 開発者は震えながらチケットのリストを調べ、そこに顧客からのチケットを見つけます。 顧客からのチケットを読んだ彼は、問題を解決するのに十分な情報がないこと、そしてさらに多くのログとダンプが必要であることを理解しました。 サポートは顧客に追加情報を要求します。 そして顧客は、これまで誰も自分の問題に取り組んでいなかったことに気づきます。 そして雷が落ちる…

この状況では、競合の解決策自体は非常に明白かつ直線的です (製品を修正し、ドキュメントとテストを更新し、顧客をなだめ、ホットフィックスをリリースするなど)。 作業プロセスを分析し、XNUMX つのチーム間のやり取りを組織する責任があるのは誰か、そもそもなぜこの状況が可能になったのかを理解することが重要です。 プロセスの中で何を修正する必要があるかは明らかです。顧客からの通知なしに、誰かが全体像を積極的に監視する必要があります。 顧客からのチケットは、開発者からの他のチケットの中で目立つ必要があります。 サポートは、開発チームが現在チケットに取り組んでいるかどうかを確認する必要があります。そうでない場合は、いつ作業を開始できるか、いつ結果が期待できるかを確認する必要があります。 サポートと開発はチケットのステータスを定期的に連絡して話し合い、デバッグに必要な情報の収集は可能な限り自動化する必要があります。

戦争で敵が XNUMX つのユニット間の接続点を攻撃しようとするのと同じように、仕事でも最も繊細で脆弱な点は通常、チーム間の相互作用です。 サポートおよび開発マネージャーが十分な年齢であれば、プロセスを自分で修正できるでしょう。そうでない場合は、状況を修正できるマネージャーが介入するまで、プロセスは競合や問題を生成し続けることになります。

私がさまざまな企業で繰り返し見てきたもう XNUMX つの典型的な例は、ある製品が XNUMX つのチームによって作成され、その自動統合テストが第 XNUMX のチームによって作成され、その製品がすべて運用されるインフラストラクチャには第 XNUMX のチームが付属しているという状況です。チーム。 テストの実行時の問題は常に発生しますが、問題の原因は製品、テスト、インフラストラクチャの両方にある可能性があります。 通常、問題の初期分析、ファイルのバグ、製品のログの解析、テスト、インフラストラクチャなどを誰が実行するかを合意するのは困難です。 ここでの紛争は非常に頻繁に発生しており、同時に均一的です。 感情の激しさが高い場合、参加者は子供じみた立場に陥ることが多く、「なぜこれをいじらなければならないのか」「故障が多くなる」などの議論が次々と始まります。

ワークフローの観点から見ると、問題を解決するための具体的な手順は、チームの構成、テストや製品の種類などによって異なります。 プロジェクトの XNUMX つでは、チームが毎週 XNUMX つずつテストを監視する定期勤務を導入しました。 もう XNUMX つは、初期分析は常にテスト開発者によって行われましたが、分析は非常に基本的なもので、製品は非常に安定していたので、うまく機能しました。 重要なのは、プロセスが透明であり、すべての関係者にとって期待が明確であり、状況がすべての人にとって公平であると感じられるようにすることです。

組織内でも対立は問題ですか? チーム内で頻繁に (または単に定期的に) 対立が発生するのは悪い兆候ですか? 一般に、いいえ、成長や発展があり、ある種の力学がある場合、これまで解決されたことのない問題が発生し、それらを解決するときに紛争が発生する可能性があるからです。 これは、いくつかの領域に注意が必要であり、改善の余地があることを示しています。 競合が頻繁に発生したり、解決が困難であったり、時間がかかったりするのは問題です。 これはおそらく、作業プロセスの合理化が不十分であり、チームの成熟度が不十分であることを示しています。

出所： habr.com