2月の初めは、春、夏、夏のコテージ、ベッド、大きな長いベッドについて考えるのに良い時期です。2月であるのは良いことなので、チームワークについて話しましょう。 本「アンナ・カレーニナ」のトルストイはどうですか？ 「幸せな家族はすべて同じです。不幸な家族はそれぞれ独自の方法で不幸です。」 誰もが善と悪についての独自の理解を持っています。 私の意見では、各チームまたは会社は、チーム内の関係と従業員へのリーダーシップの特定の特徴を持ち、それは人々の無意識の行動の特性の結果です。 これらの問題を隠すのは無意識の要因です。なぜなら 多くの場合、人が問題を認識しない場合、問題はそうではなく、そうではありません。 実際には、動作はチームまたは会社によって宣言されているものとは異なりますが、暗黙的に異なります。 会社で数ヶ月働いた後に初めて気付くことができます。 さまざまなIT企業の同様の問題を思い起こして、既存の問題の性質と解決策を見つける方法をすぐに理解できるような特性のリストを作成しました。
1.開発者は単なる別のリソースです
問題のタイプ：会社対 従業員
あるマネージャーは私に言った：「私はCEOとステークホルダーに報告します。 そして、あなたはただの開発者です。」 彼には大きな責任があり、開発者としての私にはそのような責任はありませんでした。 後に、彼は彼の指揮下にあった人々について彼自身の意見を持たず、単に彼の上司の考えを放送したことが判明しました。 そして、彼の上司は開発者と非常に密接に通信しませんでした。 その結果、管理は最小限であり、レポートのみが優先事項でした。 このため、人々に対する態度は、あたかもメカニズムの歯車であるかのようでした。 誰もが受け入れられた規範のおかげでこれを直接言うことはできませんでしたが、物事はそれ自身のために語りました。 あなたの目標は顔を失うので重要ではないことを誰もあなたに語りません。 しかし、同時に、誰もあなたの興味を考慮に入れません。 上司は、あなたがすべきこと、考え方、感じ方を正確に知っています。 見込み客について話し合うとき、聞きたい気持ちの良いことを伝えることができます。 しかし、実際の行動はこれに従わず、他の何かがより重要である理由が常にあります。 また、意見が分かれると、耳を傾けない、コミュニケーションが取れない、さらに悪いことに、プロジェクトに大きなリスクをもたらすと非難されます。 明らかに、あなたの上司は両方にとって有益な解決策を見つけることを拒否します。 彼にとって最も簡単な解決策はあなたであり、あなたが言ったことだけをします。 会社では、従業員に対するこの態度は高いレベルで維持されました。 その結果、スタッフの離職率が増加しました。 そして、多くの重要な人々（ 開発者と製品パートナー（eng。：製品所有者） ）が会社を去りました。
ヒント：相乗効果を探す
人々が自分の個人的な目標を持ち、会社が独自の目標を持っているのは普通です。 特に、それらは一致しませんが、どのくらいの人と会社が目標に分かれているかを理解することが重要です。 従業員との相乗効果を見つけると、人々が言われたことをするだけの場合と比較して、利益を増やします。
2.誰かがあなたの間違いを常に監視しています
問題のタイプ：マネージャー対 従業員
これは、職場の人々がチームメイトが率直に、そして敬意を持って問題について議論するのを助けようとするとき、正常です。 このサポートの雰囲気は、管理職の役割（チームリーダーまたはマネージャー）によって悪用された場合、破られます。 状況は意図せずに進行する場合があり、チームリーダーよりもマネージャーの参加で最も顕著になる場合があります。 たとえば、マネージャーがチームとして改善したいことを尋ねます。 あなたは、他の人と一緒に、Vasyaがもっと単体テストを書いてくれたらいいだろうと言っているのです。 マネージャーは、Vasyaと会うとき、非難をするかのように、ユニットテストを書かないと彼に言います。 この段落は、たとえばパフォーマンスレビューに関する段落である場合があります。 マネージャーの主張を見て、Vasyaは同僚から何が間違っているのかを見つけようとしますが、誰もがすべてがうまくいっていると言います。 同僚にとって、単体テストの問題はそうではないからです。 しかし、その瞬間に、自信は悪化し始めます。 Vasyaの場合、すべてが彼の後ろの誰かがマネージャーの目で彼を黒くしているように見えますが、目で彼に伝えません。 誰も特にそれを黒くしないという状況は悪いです。 それから悪化します マネージャーがこの問題を解決できない場合、そのような雰囲気では、チーム内の人々の不安が増大し、常に他の人に何かを証明させます。
ヒント：公開討議を主張する
ここで緊張するのはマネージャーです。 まず、すべての苦情が実際に問題であるとは限りません。 第二に、従業員の声に耳を傾けるべきです。なぜなら、 彼は同様の状況のヒントを与えるかもしれません。 そして第三に、マネージャーは他の人がいる場合にのみ問題について話すよう人々に勧めるべきです。 両者の理由と事実を考慮しなければなりません。
3.間違いのせいにする人が常にいる
問題の種類：チームと 従業員
エラー分析は一般的ですが、過去のエラーを常に思い出させることは正常ではありません。 失敗は、要件の欠如や知識の欠如、またはレビューコード、QA、UATなどの開発のさまざまな段階での連続した失敗が原因で発生する可能性があります。 この場合、間違えた1人に長時間注意を向けると、その人をからかうことは悪い影響を及ぼします。 この振る舞いがチームの標準である場合、チームの追放者が表示されることがあります。 この動作は通常、主要な役割の1つによってサポートされています。 チームの残りのメンバーは、単にリーダーのスタイルを調整して従います。 「上から」のサポートがない場合、この動作は長くなく、すぐに終了します。 もちろん、間違いを犯した人はそれについて知って、再び熊手を踏まないようにそれがどのように避けられるかを理解する必要があります。 しかし、それに固執しないでください。
ヒント：バグに集中するのをやめる
失敗の議論は、すべての結論が出された直後に終了する必要があります。 チームメイトは、このような状況でサポートを感じる必要があります。
4.チームは説明と計画なしでタスクを開始します
問題の種類：チームと 顧客
計画段階は重要であり、それを行うべきではないということは誰にもわかりません。 同時に、チームには説明のないタスクを延期する権限や経営陣からのサポートが不足している場合があります。 経営者は、彼らが非常に残念であると言うかもしれず、彼らが遅らせることができない契約を受け入れるようにした計画エラーを認めるかもしれません。 このような状況では、開発者は最終価格を支払う人です。 開発者は単に言われたことをするだけなので、経営陣は同じ間違いを何度も繰り返します。 同時に、問題は正式に認識されており、いつかはそれを修正する見込みがあるため、誰もが顔を合わせています。 作業中、開発者はタスクに何かが記述されていない状況に常に直面しています。 彼らはスケジュールに遅れを取り始め、急いでリーダーシップからの絶え間ないプレッシャーを感じ始めます。 その結果、開発者は常に極端です。
ヒント：自分ではなくチームを保護する
チームリーダーまたはマネージャーは、他のマネージャーや顧客からチームを保護する責任を負い、彼らの攻撃に抵抗し、チームのレベルまで責任を負わせてはなりません。 タスクの準備完了の定義は、マネージャーがタスクを十分に準備するのに役立ちます。 この場合、これは厳格なルールになるはずです。
5.回避策
問題の種類：プロセスと 従業員
鮮やかな形で、私はこの機能を1つの若い会社で見つけました。そこではプロセスが非常に速いペースで開発されました。 上司は、個人的な会話の中で、「プロセスはありますが、タスクをより早く完了するために、いつ移動する価値があるのかを理解する必要があります」と語りました。 これは事実です。プロセスをバイパスすることで、目標をより速く達成できる場合があり、必要な場合もあります。 しかし、ケースの50％でプロセスをバイパスする必要がある場合、プロセス自体は何らかの形式として認識され始めます。 この場合、プロセスがより多くの障害であることは明らかです。 一方、プロセスがなければ、管理者は、コントロールが不十分であり、開発者に対する信頼が欠如しているため、不安を感じます。 その結果、誰もが問題を理解しますが、官僚主義のためにプロセスを変更することは困難です（誰もが同意を必要とし、これは集会の集まりなどです）。 したがって、一部のマネージャーは、開発者が最善の動機に基づいてプロセスをバイパスすることを提案する場合があります。 しかし、これを提供することにより、開発者は脆弱な立場に置かれ、そのようなステップは人や状況に応じて異なると見なされる可能性があります。
ヒント：プロセスを簡単に実行する
プロセスやルールは必要ないかもしれません。 代わりに、異なる実行の可能性があることを行う方法に関する推奨事項のみが必要な場合があります。 まあ、または、場合によっては、標準プロセスをバイパスする公式プロセスを考えることができます。 しかし、この場合、より遅いプロセスが必要ですか？
似たようなものを見ましたか？ ケースのコメントを追加します。