組織の既存のポリシーを変更するにはどうすればよいですか？

DevOpsの変革を望んでいる組織には、変更に関心のある問題とポリシーがあると思います。この関心は、トップマネージャー、ミドルマネージャー、またはボトムアップからも発生します。この変化を妨げる最大の要因の1つは、他の人々に変化を起こさせることです。

たとえば、多くの場合、アジャイルなどの「新しい」アイデアをプッシュすることは失敗することがよくあります。人々は変化に抵抗します、そしてそれは良いことが起こるのを止める壁のようです。しかし、良いことが起こるように委任されています。

DevOps変革を開始する組織の従業員に影響を与えるには、どのような方法を使用できますか？特に動作することが判明している特定のテクニックと方法。特定のas-inより多くのエンジニアリング、少ない手振れ。

プロセスによって、フォローする人が変わることを理解する必要があります。人々がプロセスを学び、内面化し、より良くなると、特定の問題を解決する方法を学ぶ方法が変わります。類似した一連のプロセスは、人が問題のカテゴリを解決するために使用する考え方に相互に補強し、最終的に、新しい問題の決定と新しい解決策を導く一連の値を形成します。

プロセスを変更しても、マインドセットを変更せずに、値に対してさらに重要な場合は、人は新しいプロセスを元のプロセスと同じ値、マインドセット、または同じソリューションに準拠するように単純に適合させます。ある時点で、この立場にあるこの人を、得られた考え方から離婚したり、根本的な価値観を変更したりすることはできません。

変更を行うには、次の2つのオプションがあります。

1. すでに適切な価値観と考え方を持っている人を連れてきて、最善のシナリオでは、あなたの助けなしに従う必要があるプロセスを理解してください。
2. 最近採用された、新しい採用、または組織内の別のチームからの異動のいずれかで、新しい従業員を引き入れて力を与え、新しいプロセスで彼を訓練し、新しい考え方を植え付け、新しい価値のセットが出現することを期待します。

変更がローカルである場合は、保持する必要があるグローバルな会社全体の価値をその人物がすでに共有しているため、内部転送を選択することができます。より大きな変更の場合、新鮮な視点を持ち、変更しようとしている可能性のある全社的な価値観を共有しないように、外部から誰かを取り込む必要があります。

重要な部分は、人、チーム、またはビジネスユニットがプロセスを実行できるようにして、古いチーム、他のチーム、または会社の残りの部分から隔離することです。このような変更エージェントを上記の管理から隔離することは非常に難しいため、変更がさらに大きくなる場合は、多くの場合、管理チェーンを最後までたどるか、またはその最上部から来る必要があります。

注：経営陣のサポートがなければ、チームだけに変更をもたらすことは困難です。あなたのチームの内部でさえ、他の人がすでに自分のやり方で設定されている場合は困難です。新しい会社の新しいチームにとって、成功したエバンジェリストは、単にリーダーであるか、他の人が従うべき抵抗が最も少ない経路を作成するだけで、経営陣のサポートがなくても、形成ポリシーに影響を与えることがよくあります。しかし、確立された会社では、上記を参照してください。

チームをハックする

組織に変化をもたらすことは困難です。人々には習慣があり、変化に抵抗し、現状に慣れていることがよくあります。変更をもたらすために、順不同で、使用できるツールをいくつか紹介します。

1. DevOpsが解決する問題を他の人に体験させます。多くの場合、DevOpsの利点は、チームによって理論的なレベルでのみ理解されています。展開中に発生する問題のほとんどは、残りの開発チームや管理者が経験することはほとんどありません。これを修正するには、問題が発生したときに積極的に発言し、チームが継続的インテグレーションソリューションを使用していた場合にこの問題が発生しなかったことを説明します。もう1つの可能性は、開発者が自分でコードを修正するのではなく、デプロイメント中にコードが引き起こした問題を修正するように開発者に依頼することです。

2. リーダーを見つける。彼らが経営者であろうと、グループで最も人気のある/指揮官であろうと、人々はリーダーに従うのが一般的です。DevOpsカルチャーに移行したいという願望を持って、これらのリーダーを参加させ、ベストプラクティスを使用したり、推奨したりする方法を公開する方法を考案します。

3. 信頼を築く。以前に1〜2回同意した後の方が同意する可能性が高くなります。理想的には、文化を変えることなくできる小さな改善を見つけ、その成功に基づいて構築することができます。ただし、それが選択肢でない場合は、簡単な質問をし、簡単な提案を提供して、「はい」と言うか、あなたに同意する習慣をつけさせます。

4. 自分を繰り返すことを恥じないでください。繰り返しが機能し、最終的には沈み込みます。チームがDevOpsを使用していた場合、どれほど素晴らしいことになるかを可能な限り言及します。ただし、これは、チーム内で最初に信頼を築いた場合にのみ機能します。

5. それを楽しいものにします。DevOps状況の概念実証を作成することが許可されている場合は、レポートと通知にかわいい絵文字と明るい色を使用してください。ビルドが失敗したときに面白いgifを投稿します。更新に迷惑をかけないようにしてください。