「手本によるリード」が機能しない場合、何ができますか？
私は大企業（8000人以上の従業員）で約2年働いており、勉強コースを終えた直後に採用されました。
ここの誰もが、しばしば非常に良く設計されておらず、ハックでいっぱいのレガシーコードに毎日対処しなければなりません。最初は目立たないようにして、物事をあまり批判しないようにしました。しかし、現状では、現状を維持することは非常に困難になり、私たちが使用するツールを改善/交換する意思は誰にもないようです。
より明確にするために：
- 時代遅れのソース管理ツール（Visual SourceSafe）
- 完全な再構築のみをサポートする単純な古いmakefile
.defファイルは、既存のすべてのアーキテクチャーに対して手動で個別に保守する必要があります- モノリシックヘッダーファイルと異なるファイルが非常に少ないプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります）
- 「新しい」言語機能を使用しない（まあ
std::stringはそれほど新しいものではありませんが、私以外は誰も使用していません）
私は、数か月前に、新しいコンパイル環境を設計することによって、それについて何かをすることに決めました。インクリメンタルビルドを確実に機能させることができ、コンパイル時間を短縮し、構造化プロジェクトを改善し、自動.defファイルの生成。 GitとVisual SourceSafeとの間のブリッジも作成しました。
私はいくつかの同僚や上司に私の成果を見せましたが、それは誰も気にしていないようなものでした。それらはすべて「まあ...今では人々はそのようにそれをするのに慣れています。なぜ私たちは物事を変えるのですか？」
私が提案した変更は、古いシステムから新しいシステムにソフトに移行できるように設計されています。それぞれの改善は、個別に安全に適用できます。
私は同僚の何人かを変更に関与させようとしました。しかし、これまでのところ、成功していません。
あなたはすでに同じような状況に直面しましたか？ 「模範を示す」が機能しない場合、何ができますか？
頭を狙う：「例によって主導」は改善を念頭に置く必要がありますが、テクノロジーを使用していない人々を対象とする必要があります。テクノロジーの改善に時間をかけすぎたのかもしれませんが、彼らの頭の中で起こっていることに十分な時間をかけていません。新しいことに反対する理由を説明する要因について考えます。多くの場合、彼らはリスクを恐れているだけです。それらのリスクを特定し、それらに対する反論を見つけます。
新鮮な肉をつかむ：物事を変えたい従業員に勝つ方が簡単です。それらを見るとすぐに気づきます。
腐った肉を避けてください：アイデアに共感しない人もいます。脇に置いておきます。
クリティカルマスに成長する：あなたのアイデアに共感する人を見つけましょう。一つずつ勝ちます。ある時点でクリティカルマスに達した場合、自発的にあなたの例に従う人がますます増えます。
管理語彙：管理者はより良い設計に興味がありません。彼らの言葉はお金と時間です。バグのためにどれだけの人時間を無駄にしているかを明確にします。バグに遭遇した満足していない顧客は利益を上げないことを明確にしてください。新しい機能をどれだけ速く実装できるかを示します。管理者用に別の語彙を選択する必要があります。
それはすべてプロセスについてです：より優れた技術は、より優れたプログラマーやプログラムを生み出しません。優れた実行プロセスがある場合、古いテクノロジーでも良い結果をもたらします。努力と時間の無駄を考えてください。多分それは技術ではありませんが、プロセスの何かがひどく間違っています。ほとんどの場合、それはコミュニケーションの欠如です。
新しい会社を探す：すでに多くのことを行っています。あなたはまだ物事を改善しようとすることができますが、あなたがそれを試したい期間とあなたが投資したいどのくらいのエネルギーを決めるかはあなた次第です。心に留めておいてください：たとえ多くの改善を達成できなくても、あなたの努力から多くを学ぶでしょう。いつか先に進む必要があります。
あなたは自分が間違っているかもしれないと考えるために立ち止まったことはありますか？
したがって、学校でいくつかのデザインとパターンの本を読んで、あなたはあなたが働いているところの比較的時代遅れの慣習のように見えるものに権利を奪われています。間違いなくそれらはおそらくより良いアイデアであり、新しいプロジェクトはこれらを念頭に置いて開始する必要がありますが、あなたは完全に異なるレベルにいるようです。
開発者の群れは猫を群れにしようとするようなものであり、彼らは本質的に自分自身の心を持っており、正しいかどうかにかかわらず、物事を行う好ましい方法を持っています。私はベストプラクティスを適用し、2人の開発者のチームを管理するのに十分な時間を費やしていますが、8000名の会社で働いています。
それは驚くほど膨大な数です。すべての開発者が会議をスケジュールする必要があることを示す単純なプロセス変更でさえ、パブリックカレンダーに不在時間を設けることは、全体的に実装するのが非常に複雑で難しいポリシーになります。また、方針が全面的に受け入れられ、採用されることを確実にするために、経営陣からの大幅なプッシュが必要になります。
あなたはそれを考えていないかもしれませんが、モノリシックから複数のヘッダーファイルへの移動、またはSourceSafeからGitへのバージョン管理の移動と同じくらい単純なものには、関係者全員の多大な労力と投資が必要です。それには以下が必要です：
重要な管理サポート
全社的な受け入れ
すべての開発者が新しいイニシアチブを通知するために会議時間に投資する（会議には人件費、人件費には費用がかかる）
愚かな開発者でさえ彼らが何をしているのかを確実にするためにトレーニングを計画して確立する必要があります
1時間のトレーニングを想定したとしても、8000人の開発者を対象にして、1時間あたり50ユーロ=トレーニング費用400000ユーロ。これは、私の1つのソフトウェア開発チームが1年間で給与、ソフトウェア、ハードウェアの予算を組むよりも多額の資金です。それはあなたが提案している例外的な投資です。
しかし、「生産性の向上によって節約できる時間をすべて考えてください」と言っています。確かにそうですが、かなりの投資はかなりのリスクであるため、私が承認する前に、あなたがこれについて正しいことを確認することをお勧めします。シニアの誰もあなたを支えていないのなら、私は費用を正当化することはできません。最終的には効率が悪いかもしれませんが、一貫性があり、社内全体で8000人の開発者がいるため、一貫性が最も重要です。
これを行うには、複数の上級レベルの人々からのサインオフが必要であり、開発者の損失から非効率までを測定する方法を正確かつ客観的に見つける必要があります。その時間はドルに相当し、ドルと政治のみがこの戦いに勝利するのに役立ちます。
あなたが説明したことは、「模範を示す」のようには聞こえません。提案をしたために拒否されたようです。例を挙げてリードするには、あなたのやり方が優れていることをshow人に伝える必要があります。あなたが挙げた問題のうち、自分自身の変更を自分で使い始めることができる3つを見つけました。
完全な再構築のみをサポートする単純な古いmakefile。
ローカルで独自のメイクファイルを作成し、それらを使用してどれだけ効率的に作業できるかを示します。
モノリシックヘッダーファイルと異なるファイルが非常に少ないプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります）
既存のものを（ビルドを壊さずに）触ったときに分解するか、新しいコードを書くときに小さなヘッダーファイルを導入します。人々が彼らと働き始めると、彼らは複製が必要ないことに気付くでしょう。
「新しい」言語機能は使用しません（std :: stringはそれほど新しいものではありませんが、私以外は誰も使用していません）
古いコードに触れたり、新しいコードを導入したりするたびに、新しい言語機能を導入し続けます。物事を簡素化していることを確認してください。これに落胆しないでください。私たちのほとんどは怠惰です。新しい言語機能により物事が簡単になることがわかった場合は、それを採用します。
数か月後、他の開発者があなたの改善を採用し始めたら、ソース管理システムのアップグレードのようなより根本的な変更について上司に再度アプローチできます。ただし、他の開発者が確実にメリットを享受できるようにする必要があります。これに取り組む1つの方法は、少数の開発者しか活動していない小さなプロジェクトでGitを試すことを提案することです。そうすれば、見慣れないシステムへの本格的な移行ではなく、評価としてそれを宣伝できます。
最後に、数か月間試しても、会社の状況を改善することに誰も興味がないようであれば、それが自分に適しているかどうかを本当に検討する必要があります。
ライオネルバレットに加えて（私はほとんど同意します）、抵抗への考えられる動機も考慮してください。
- 実際のプロセスのコストを評価する
- それはあなたのようになるので、プロセスのコストを評価します
だけでなく：
- の観点から変更のコストを評価します
- 誰にとっても新しい環境をセットアップするために使うお金
- 新しいモードに慣れるように全員を訓練するために費やす時間（あなたにとっては簡単かもしれませんが、あなたが何をしているのかを知らない人にとってはそれほど簡単ではありません）
- 無停止で変更を管理するために必要な経過時間。
私は容疑者がいます：あなたの会社には、年齢と文化の観点から、あなたのような人（== --- ==）がどれくらいいますか（私は「学校」と「学校のタイプ」 「）？今後2/3年以内にあなたのような人が何人雇われると予想され、何人が組織で引退するか、彼らの役割を変えますか？
私の疑いは、あなたが会社を変えるほどの力を持っていない立場にいることです。そのような状況では、会社があなたを変えるか、またはあなたを「追放」します（ある意味では、それはあなたが去りたいというあなた自身の願望になります）、もしそうでなければ可能より多くの時間待機します。
しかし、会社が私があなたに言った追加のコストが節約され、人々の自然な置き換えが起こるのを待つことによって変更プロセスが自然に起こることを可能にすることができると評価しているかもしれません。あなたはあなたの後ろに（まだ）何もないのであなたはあなたが見ることができないプロセスの始まりにいます。
この時点では、Joel記事への参照を追加することしかできません Gruntのみの場合に物事を成し遂げる 。セクションは次のとおりです。
戦略1ただやる
戦略2ウイルスマーケティングの力を利用する
戦略3ポケットオブエクセレンスを作成する
戦略4ボゾスを無力化する
戦略5中断から逃れる
戦略6がかけがえのないものになる
記事は「変化はあなたから始めなければならない」と要約します。
悲しいことに人々はわだちに行き詰まり、「それは機能し、誰もがそれを大丈夫に使用し、なぜそれを変えるのか」という考え方を発達させます。
文句を言うだけでなく、代わりに実用的なソリューションを開発することで、正しい方向に進んでいるので、今は賛同が必要です。
直属のラインマネージャー（またはテクニカルリード）を紹介します。興味がない場合、変更管理やイノベーションを担当する人はいますか？
しかし、潜在的には、あなたの考えや仕事は無視され、状況はそのままです。
あなたの上司を味方につけるような方法であなたのケースを述べる必要があります。ところで、この種の変更はテクニカルディレクターまたはプロジェクトマネージャーによって提案されているため、プロジェクトにコミットする必要があります。 （代替ルートとして、技術監査を提案することができます。部外者はあなたと同じことを言う可能性がありますが、より重要になります。）
これまでのところ、彼は変更の必要性を認識していません、それは彼にとって化粧品の変更のように見えます：開発者のファンシーを満たすことを除いて明白な利点なしではコストがかかります。彼にとって重要なことは、お金の流れと安定したチームの2つだけです。技術はブラックボックスであり、機能する場合はそれで十分です。
最初のお金、あなたは現在の設定が彼にお金をかけていることを証明する必要があります。開発者の1時間あたりのコストと、コンパイル時間を何時間短縮することで彼を節約できますか？計算する。また、現在のコードパイプラインのリスクに関する記事や証言をまとめ、彼に恐ろしい数を示します。「SourceSafe/Bad Coding Practicesにより、当社は$ XXXKを失いました」。
2番目のチームでは、上司が自分のやり方を変えたくない古い不機嫌なプログラマーに悩まされているかもしれません。最初のポイントが確立された場合は、この問題の解決策も提案する必要があります。あなたは何人ですか？現在のコーディングパイプラインはビザンチンであるため、誰かを置き換えることは難しいことを強調することは興味深いかもしれません。チームを更新する計画を提案する必要があります。業界のベストプラクティスを学び、新しいルールに従っていることを確認します。
最後に、マイルストーンとリソース割り当てを使用して、小さなプロジェクトに分割されたコードベースを変更する計画を提案する必要があります。実際、あなたはプロジェクトマネージャーとして自分自身を売り、堅実なコードパイプラインを持つために変更を必須としています。
あなたは物事をうまく行うと信じている組織で働いていますか？効率と革新は成功と収益性につながる;それとも、収益の追求、そして売上の維持に集中することが成功のテナントなのでしょうか？
あなたが説明しているように振る舞う企業は、技術的に定着しています。競争の激しい市場では、個人とイノベーションに焦点を当てた企業と競争することはできません。
あなたがあなたがあなたがそうであると言う人であるならば、あなたはあなたの精神を尊重し、報いるどこかで働きます。最終的には、長年の解決後、上司が採用するのと同じ哲学を妥協するようになります。ハードワーク、インスピレーション、創造性、進歩を評価する他の場所（おそらく小規模な組織）で働きます。
リスクを冒さずにすぐにこれを行うと、最終的には落ち着き、現在のピアグループでは哲学的に反対されているため、好奇心と創造性を養うことができなくなります。
卓越性は態度と世界観です。
この経験から、何を避けるべきかを知る洞察が得られたことを知ってください。自己満足と保護主義に鋭意目を向け、それを早期に発見できるようにします。
次のインタビューでは、「従業員からどのような革新がもたらされるのか」、「個人の創造性から何が変わったのか」、「このチームにどのような才能をもたらすことができるのか」、「組織の成功を後押しするもの」などの質問をします。 ？ "、"あなたの組織はどのようにして継続的に技術革新を受け入れていますか？ "...このような質問への答えは非常に語っています。多くの組織にはビジョンがないか、ビジョンを作成した組織がなくなっており、組織は会計士によって運営されています。テクノロジーディレクターにインタビューしている場合-彼が組織をテクノロジー企業として見ているかどうかを尋ねてください。