正しいことをすれば時間を節約できると同僚に納得させる方法

私は最近、一握りのプログラマーと一緒に新しい会社で働き始めました。約70人の従業員を抱える中規模の会社ですが、IT部門の従業員数は9〜10人で、私の横には3人の「プログラマー」がいます。しかし、これらの人たちの経験は非常に限られており、非常に多くのことをやっています。たとえば、プロジェクトの1つはPHP Webサイトです。コードの大部分は20,000行のPHPコントローラーに保存され、PHPには〜6000行のJavaScriptが埋め込まれています。

私はあちこちで小さな提案をし続けていますが、誰も聞いていません。みんなが忙しすぎて私の提案を実行できないと言っています。事は、彼らはそんなに忙しくてはいけないし、物事が正しく行われていなければいけません。彼らはほとんどの時間を、壊れ続けるものの修理に費やしています。各プロジェクトが正しくビルドされていれば、自分ですべてを行うことができました。

これらの人やマネージャーに、物事を変える必要があること、そして物事を変えることで時間を節約できることを納得させるには、どのようなアプローチを取るべきでしょうか？同僚が説得しようとするのをスキップして、会社が正しいことを始めた場合に会社がたくさんのお金を節約する方法についてのビジネス上の提案で、マネージャーに直行しますか？

私は、単に気にかけないプログラマ以外の、ずさんな仕事の主な原因は、知識の不足であることがわかりました。残念ながら、多くの環境では、知識の欠如はオープンに議論されるのではなく、軽視されています。

プログラミングに関する議論、成長、および一般的な興奮を促進するために私が成功して使用したいくつかのテクニックは次のとおりです。

• 毎週開催されるブラウンバッグテクノロジーセッション（トピックについて調査して発表してもらいます）。
• ジュニアメンバーとシニアメンバー間の1日1回または毎週のメンタリングセッション。
• コードレビュー（学習を重視し、間違いを指摘しない）。

学習は伝染性です。学習を奨励する環境を育てると、より良い開発者が生まれるだけでなく、チームの他のメンバーに、彼らが給与を得る方法よりも大きな何かの一部であることを見せます。

あなたがシニアPHP開発者として雇われ、あなたの仕事は物事を修正することだとわかったら、今度は筋肉を曲げる時間をお勧めします。

私があなたの代わりにいたら、コードをよく調べて、何度も何度も間違いが起きているのを確認します。毎週ミーティング時間をブロックして、チームとこれらのことを検討します。指や名前を指さずに、そのタスクを適切に行う方法を示してください。

次に、修正の必要性を既に見ているので、リストを作成します。すばやく簡単に実行できる場合は、実行してください。それがあなたの人生をより簡単にしてくれるなら…それをしなさい。実行する必要があるすべてのことのリストを作成し、それらのチケットを作成し、人々がそれらを行うサイクルがあるときを確認します。誰かが問題領域のバグを修正している場合、適切に修正する方法を説明します。

大きな変更が必要な場合は、チームとステークホルダーと一緒に座って、オプションについて話し合います。

あなたが人々を助けるオープンドアポリシーを持っています。脅迫するのではなく、教育する人になります。いいえ、「この方法で行う必要があります」と、「この方法で行った方が良いでしょう」ということです。あなたが提案する方法でそれを行うことの利点と、それが行われた方法の欠点を説明してください。人々は、自分のやり方が間違っていると言われるのではなく、何かを学んだと感じたら、正しいやり方でそれをやろうとするでしょう。

問題に対する経営者の視点 欠陥の量に関して開発の時間を受け入れた場合、なぜそれを危険にさらすのでしょうか？長期的な利益が短期的な目標と矛盾する場合、通常は失われます。あなたは彼らに短い一歩を戻すように頼んでいます。彼らはこれが長い遅延を引き起こすと考えるかもしれません。あなたは彼らにそれが追加された利益と一緒にならないと確信させる必要があります。混乱していると思わない場合は、「修正」ごとに新しいバグをすぐに導入するのに時間がかかる理由を説明するように依頼します。

コードの品質は、多くの状況と状況に左右されます。営業、マーケティング、およびマネージャーは、納期に間に合わないということは、会社がメガミリオンのベンチャーキャピタル投資家への1ショットを逃すことを意味すると信じさせます。現実には、彼らは本当にこの機能を必要としないクライアントの1％に悪い知らせを伝えたくありません。私は極端で、通常はその中間に位置するため、開発者は実際の緊急事態を知る必要があります。そうすれば、時間をかけてやり直すよりも、時間をかけるように説得する方が簡単です。リスクを理解する必要があります。

素晴らしい小説のように、コードは最初はうまく書かれていませんが、残念ながらまだ頻繁に公開されています。コーディング標準の確立などの基本的なことから始めます。誰もが持っていますが、多くはあなたの状況のように、正式なものではなく、非常に厳しいものでもありません。「好きなことをしてください。」保守が非常に簡単な標準です。次のステップは、標準をどのように維持するかを決定することです。

あなたには大きな課題があります。おそらく、少数の優秀なプログラマーが、コードの品質を妥協したり技術的な負債に陥ったりすることのない程度にスキルと習慣を身に付けているかもしれませんが、エンジェル投資家が誰もが金持ちになると約束したときに何が起こるかを待ってください。

試してみて、プロトタイプ（プロジェクト全体が大きすぎる場合はいくつかのモジュール）を作成してください。次に、それをチームに提示/話し合います。例によって説得する方が簡単かもしれません。

このプロセスでは、いくつかのツール、ライブラリ、アプローチなどがあまり良くないことも発見するかもしれません。常に最初に評価し、後で使用するようチームに依頼してください。標準以下のツールに関する安価なマーケティングに注意してください。