「例によるリード」が機能しない場合、何ができますか？[閉まっている]

私はもう2年近く大企業（8000人以上の従業員）で働いており、学習コースを終えた直後に採用されました。

ここの誰もが、しばしば非常にひどく設計されたハックに満ちたレガシーコードを毎日処理しなければなりません。最初は、物事をあまり批判しないように、目立たないようにしました。しかし、現状では、この状況に耐えることは非常に難しくなっており、私たちが使用するツールを改善/交換しようとする人は誰もいないようです。

より明確にするために：

• 廃止されたソース管理ツール（Visual SourceSafe）
• 完全な再構築のみをサポートするプレーンな古いメイクファイル
• .def すべての既存のアーキテクチャに対して手動で個別に維持する必要があるファイル
• モノリシックヘッダーファイルと非常に少数の異なるファイルを含むプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります）
• 「新しい」言語機能std::stringは使用しません（まあ、それほど新しいものではありませんが、私以外は使用していません）

数か月前に、新しいコンパイル環境を設計することで、それについて何かをすることにしました。インクリメンタルビルドを確実に動作させ、コンパイル時間を短縮し、構造化されたプロジェクトを改善し、.defファイルを自動生成することができました。さらに、GitとVisual SourceSafeの間のブリッジを作成しました。

いくつかの同僚や上司に自分の成果を見せましたが、誰も気にしないようでした。それらはすべて「まあ...人々は今それをそのようにするのに慣れています。なぜ私たちは物事を変えるのですか？」

私が提案した変更は、古いシステムから新しいシステムにソフトに移行できるように設計されたものです。それぞれの改善は個別に安全に適用できます。

同僚の何人かを変更に参加させようとさえしました。しかし、これまでのところ、成功していません。

あなたはすでに同様の状況に直面しましたか？「例によるリード」が機能しない場合、何ができますか？

頭を目指して：「例によるリード」は改善を念頭に置く必要がありますが、技術ではなく人々を対象とする必要があります。たぶん、あなたはテクノロジーの改善にあまりにも多くの時間を費やしたが、彼らの頭の中で起こっていることに十分な時間がない。新しいものに反対する理由を推進する要因について考えてください。多くの場合、彼らはリスクを恐れています。それらのリスクを特定し、それらに対する反論を見つけます。

新鮮な肉をつかむ：物事を変えたい従業員に勝つことは簡単です。それらを見るとすぐに気づきます。

腐った肉を避けてください：あなたのアイデアに共感しない人もいます。脇に置いておきます。

クリティカルマスに成長する：あなたのアイデアに共感する人を見つけましょう。1つずつ勝ちます。ある時点で、クリティカルマスに達すると、ますます多くの人が自発的にあなたの例に従うでしょう。

管理用語：管理者はより良いデザインには興味がありません。彼らの言語はお金と時間です。バグのためにどれだけの工数が浪費されているかを明確にしてください。バグに遭遇した不満のある顧客は有益ではないことを明確にしてください。新しい機能をどれだけ速く実装できるかを示します。マネージャーのために別の語彙を選択する必要があります。

それはすべてプロセスに関するものです。優れたテクノロジーは、優れたプログラマーやプログラムを作るものではありません。実行中のプロセスが適切であれば、時代遅れのテクノロジーでさえ良い結果につながります。努力と時間の浪費について考えてください。たぶんそれはテクノロジーではないかもしれませんが、プロセスの何かがひどく間違っています。ほとんどの場合、コミュニケーションの欠如です。

新しい会社を見つける：あなたはすでに多くのことをしました。あなたはまだ物事を改善しようとすることができますが、それを試してみたい期間と投資したい量を決定することもあなた次第です。心に留めておいてください：あなたが多くの改善を達成できない場合でも、あなたはあなたの努力から多くを学びます。ある時点で先に進む必要があります。

自分が間違っているかもしれないと考えるために立ち止まったことはありますか？

そのため、学校でデザインやパターンの本をいくつか読んだり、職場での比較的な時代遅れの慣行のように思えるようなものに不満を感じています。それらはおそらくより良いアイデアであり、新しいプロジェクトはこれらを念頭に置いて開始する必要がありますが、あなたはまったく異なるレベルにいるようです。

開発者を放牧することは、猫を群れようとするようなものです。彼らは本質的に自分の心を持ち、正しいかどうかに関係なく、物事を行う好ましい方法を持っています。ベストプラクティスを実施し、2人の開発者からなるチームを管理するのに十分な苦労がありますが、8000人の会社で働いています。

それは驚くほど膨大な数です。すべての開発者が会議をスケジュールする必要があり、パブリックカレンダーで不在時間を指定するという単純なプロセス変更でさえ、非常に複雑で困難なポリシーを全面的に実装することになります。また、ポリシーが全面的に受け入れられ、採用されることを確認するために、経営陣からの重要なプッシュが必要になります。

考えられないかもしれませんが、モノリシックから複数のヘッダーファイルへの移動や、SourceSafeからGitへのバージョン管理の移動などの単純な作業には、関係者全員の多大な努力と投資が必要です。以下が必要です。

• 重要な管理サポート

• 全社的な受け入れ

• すべての開発者が新しいイニシアチブを通知するための会議時間の投資（会議には工数がかかり、工数には費用がかかります）

• 最も愚かな開発者でさえ自分が何をしているかを確実にするために、トレーニングを計画して確立する必要があります。

• 1時間のトレーニングであっても、8000人の開発者x 50ユーロ/時間= 400,000ユーロのトレーニング費用。これは、1つのソフトウェア開発チームが給与、ソフトウェア、およびハードウェアのために丸1年で予算を組むよりも多くのお金です。それはあなたが提案している例外的な投資です。

しかし、あなたは言っています、「生産性の向上によって節約できるすべての時間を考えてください」。当然ですが、多額の投資は重大なリスクですので、サインオフする前に、これについてあなたが正しいことを確信しておくべきです。年配の男性が誰もあなたを支持していないなら、その費用を正当化することはできません。最終的には非効率かもしれませんが、一貫性があり、全社で8000人の開発者がいるため、一貫性が最も重要です。

これを行うには、複数の上級レベルの人々からサインオフする必要があり、開発者の非効率な時間を測定する方法を正確かつ客観的に見つける必要があります。その時間はドルに相当し、ドルと政治だけがこの戦いに勝つのに役立ちます。

あなたが説明したことは、私にとって「例によるリード」のように聞こえません。あなたが提案をして拒否されたように聞こえます。例を挙げてリードするには、あなたのやり方がより良いことを人々に示す必要があります。あなたがリストした問題のうち、あなた自身の変更を自分で使い始めることができる3つを見ます。

完全な再構築のみをサポートするプレーンな古いメイクファイル。

独自のメイクファイルをローカルで作成し、それらを使用してどれだけ効率的に作業できるかを示します。

モノリシックヘッダーファイルと非常に少数の異なるファイルを含むプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります）

（ビルドを壊すことなく）それらに触れるときに既存のものを分割するか、新しいコードを記述するときに小さなヘッダーファイルを導入します。人々が彼らと協力し始めると、彼らは彼らが複製を必要としないことに気付くでしょう。

「新しい」言語機能を使用しない（std :: stringはそれほど新しいものではありませんが、私以外は使用していません）

古いコードに触れるか、新しいコードを導入するたびに、新しい言語機能の導入を続けてください。物事を単純化していることを確認してください。これに落胆しないでください。私たちのほとんどは怠け者です。新しい言語機能が物事を簡単にすることがわかったら、それを採用します。

数か月後、他の開発者が改善点の採用を開始した場合、ソース管理システムのアップグレードなど、より根本的な変更について上司に再度連絡することができます。ただし、他の開発者にメリットが見られるようにする必要があります。そうしないと、メリットが得られません。アプローチする1つの方法は、少数の開発者のみが活動している小さなプロジェクトでGitを試すことを提案することです。そうすれば、見慣れないシステムへの本格的な移行ではなく、評価として宣伝できます。

最後に、数か月間試してみても、会社での仕事の改善に誰も興味がないと思われる場合は、自分に合っているかどうかを本当に検討する必要があります。

ライオネル・バレットに加えて（私はほとんど同意します）、抵抗への可能性のある動機も考慮してください。

• 実際のプロセスのコストを評価する
• プロセスのコストを評価します

だけでなく：

• 期間の変更のコストを評価する
  • 誰でも新しい環境をセットアップするために使うお金
  • 新しいモードに慣れるように全員を訓練するために費やす時間
  • 変更を中断せずに管理するために必要な経過時間。

私は疑いがあります：あなたの会社には、あなたのような人々が年齢と文化の面で何人いますか（私は「学校」と「学校のタイプ」）？あなたのような人が今後2/3年以内に何人雇用されると予想されますか。また、何人が退職し、組織での役割を変更しますか。

私の容疑者は、あなたが会社を変えるのに十分な力がない立場にいるということです。その状況では、あなたがもっと時間を待つことができないなら、会社はあなたを変えるか、あなたを「追放する」でしょう（ある意味、それは去りたいというあなた自身の願いになるでしょう）。

しかし、会社が、あなたが言った追加費用を節約できると評価しているかもしれません。人々の自然な交替が起こるのを待つことによって、変更プロセスが自発的に起こることを可能にします。あなたはあなたの背後に何も（まだ）ないので、あなたが見ることができないプロセスのちょうど始まりにいます。

この時点で、Joel Articleへの参照を追加することはできません。セクションには以下が含まれます。

戦略1

戦略2ウイルスマーケティングの力を活用する

戦略3優れたポケットを作成する

戦略4 Bozosを無効化する

戦略5中断から逃れる

戦略6はかけがえのないものになる

この記事を「変化はあなたから始めなければならない」と要約します。

悲しいことに、人々はわだち掘れで立ち往生し、「それがうまくいく、誰もがそれを大丈夫、なぜそれを変えるのか」という精神性を発達させます。

文句を言うだけでなく、代わりとして実行可能なソリューションを開発することで、適切な方法で行ったので、今はバイインが必要です。

直属のラインマネージャー（またはテクニカルリード）を紹介します。興味がない場合、変更管理やイノベーションを担当している人はいますか？

ただし、潜在的に、あなたのアイデアや仕事は無視され、状況はそのままになります。

あなたはあなたの上司があなたの側に来るようにあなたのケースを述べる必要があります。ところで、この種の変更はテクニカルディレクターまたはプロジェクトマネージャーによって提案されているので、プロジェクトにコミットする必要があります。（別の方法として、技術監査を提案することができます。部外者はあなたと同じことを言う可能性がありますが、より重くなります。）

これまでのところ、彼は変更の必要性を認識しておらず、化粧品が彼に変わっているように見えます。彼にとって重要なのは、お金の流れと安定したチームの2つだけです。技術はブラックボックスであり、機能する場合はそれで十分です。

最初のお金、あなたは現在の設定が彼にお金をかけていることを証明する必要があります。開発者の1時間あたりのコストとコンパイル時間の短縮により、彼は何時間節約できますか？計算する。また、現在のコードパイプラインのリスクに関する記事または証言を編集して、「SourceSafe / Bad Coding Practicesにより、当社は$ XXXKを失いました」という恐ろしい数字を見せます。

次に、チーム、あなたの上司は、やり方を変えたくない古い不機嫌なコーダーで立ち往生しているかもしれません。最初のポイントが確立された場合、この問題の解決策も提案する必要があります。あなたは何人ですか？現在のコーディングパイプラインは奇妙であるため、誰かを置き換えるのは難しいことを強調するのは興味深いかもしれません。チームを更新する計画を提案する必要があります。業界のベストプラクティスを学び、新しいルールに従っていることを確認します。

最後に、マイルストーンとリソースの割り当てとともに、コードベースを小さなプロジェクトに分割する計画を提案する必要があります。実際、あなたはプロジェクトマネージャーとして自分自身を売り込んでおり、堅実なコードパイプラインを構築するために変更は必須です。

あなたは物事をうまくやっていると信じている組織で働いていますか？効率と革新は成功と収益性につながります; または、収益の追求、および販売の維持に集中することが成功のテナントであるか？

あなたのような振る舞いをする企業は、技術的に定着しています。競争の激しい市場では、個人と革新に焦点を合わせた企業と競争することはできません。

あなたがあなたがあなたであると言う人であるなら、あなたの精神を称え、報いる場所で働いてください。最終的には、何年も落ち着いてから、上司が受け入れるのと同じ哲学で妥協し始めます。ハードワーク、インスピレーション、創造性、進歩を重視する他の場所（おそらく小規模な組織）で仕事をします。

リスクを冒さずにすぐにこれを行うと、最終的に落ち着き、現在のピアグループでは哲学的に反対されているため、好奇心と創造性を養うことができなくなります。

卓越性は態度であり、世界観です。

この経験があなたに何を避けるべきかを知る洞察を与えたことを知ってください、あなたがそれを早期に発見できるように、自己満足と保護主義に鋭い目を保ってください。

次のインタビューでは、「従業員からどのようなイノベーションがもたらされるか」、「個人の創造性からもたらされる変化は何ですか？」、「このチームにどのような才能をもたらすことができますか？ 「」、「あなたの組織はどのように技術革新を継続的に受け入れていますか？」...このような質問に対する答えは非常に重要です。多くの組織はビジョンを持っていないか、ビジョンを作成した組織がなくなっており、組織は会計士によって運営されています。テクノロジーディレクターにインタビューする場合は、組織をテクノロジー企業と見なしているかどうかを彼に尋ねてください。

あなたが働いている環境が気に入らないなら、あなたは自分自身に傷をつけています。専門的に行うのと同じような興味と目標を持っている人に囲まれる必要があります。私は時々それが簡単だと言われることがありますが、数年を振り返り、時間を無駄にしたかのように感じる気持ちは、リスクを取ることを恐れるよりも悪いです。

別の方法として、特定の技術や方法論を使用するシステムまたは環境で開発したい場合、貢献できる仕事以外のプロジェクトを見つけることをお勧めします。少なくとも、両方のシステムでさまざまな作業を行うことで、自分がどこに属しているかを見つけながら、別のものに対するニーズを満たすことができます。

私にはあなたは水から魚だと思われます。海の体を見つけて泳ぎましょう！