スケジュールのプレッシャーを理解できます。ユーザーは会社の生命線であるため、ユーザーを喜ばせたいと考えています。ただし、特定の変更により、今後すべてが簡単になることも事実です。残念ながら、私の組織の経営陣はそのような変化に対して本能的な抵抗を持ち、この抵抗は非常に強いため、長期的な改善の妨げになります。

たとえば、Appleは最近、iOSプログラム用の自動参照カウントを導入しました。これは、以前は使用する必要があった手動の保持/解放呼び出しを大幅に改善したものです。コードは記述しやすく、保守しやすいです。切り替え自体がクラッシュを引き起こす可能性があります。しかし、それらが解決されると、ランダムな奇妙なクラッシュの数は減少する可能性があります。

最近、上司に、自動参照カウントに切り替えたいと言いました。彼の応答は、目に見える改善に集中したかったということでした。この反応は、彼の上からの圧力、そしておそらくCEOからの圧力によって引き起こされた可能性があります。

同様の例がたくさんあります。一般的なスレッドは、何かを修正する必要があるが、修正の短期的な費用は短期的な利益を上回り、「短期」は「今後数週間以内」と定義されます。

状況をどのように処理すればよいですか？

編集：回答いただきありがとうございます。来てください。私の状況に関連しているため、マネージャーとCEOはどちらもプログラマーであることを明確にする必要があります。どうやら彼らのプログラマー側は他の圧力に圧倒されているようです。

あなたは本当に技術的な負債について話している。たぶん比metaはあなたのマネージャーを助けるでしょう。ソフトウェアの技術的負債の影響を、汚れたキッチンで調理することとよく比較します。流し台やカウンター、ストーブに汚れた皿が積まれていて、床にゴミがある場合、食事を作るのに時間がかかります。ただし、次の食事を準備する最速の方法は、混乱を回避することです。キッチンを掃除し、清潔に保つと、次の食事が遅れますが、それ以降の食事の配達は改善されます。そして、食堂の空腹の人が乱雑なキッチンを見ることができず、調理を始める前になぜ掃除したいのか理解できないのと同様に、経営者はコードの混乱を見ることができません。混乱を示すか、混乱によって引き起こされる品質の問題と遅延を示す必要があります。

緊急のタスクや重要なタスクについて話すこともできます。重要なタスクが完了していない場合、緊急のタスクには時間がかかり、費用がかかります。

あなたは、キャリアのある時点でどこでもプログラマーを悩ませている何かに出くわしました：このコードはリファクタリングする必要があり、そこにアーキテクチャ上の問題があり、このモジュールは維持できなくなりつつあります。あなたは直接目に見える利益のみをもたらす仕事に集中するように押されています。

その古典的なアイスバーグシークレットをもう一度。その秘密は、氷山が90％水中であるように、開発プロジェクトの大部分がそうであるという事実に関係しています。作業の90％はエンドユーザーには完全に見えなくなります。そのコードはエンドユーザーに影響を与えますが、管理者は、違いを見ることができず、すべてが正常に機能しているときに、メンテナンス/リリースおよび自動参照呼び出しをリファクタリングするのに6時間費やした理由を思い浮かべるのに苦労します。

この問題に関してあなたが持って行くことができるいくつかの事実はここにあります。

• 管理者は、彼ら自身がプログラマーでない限り、Iceberg Secretを理解しません。
• これは無知の問題であり、悪意ではありません。CEOは良い製品を望んでいます。良い製品になるすべてを理解しているわけではありません。
• CEO（およびあなたの上司）は愚かではありません- なぜこれに時間を費やすべきか、および他のIcebergの問題について、いくつかの事実といくつかの具体的なデータを調べて準備してください。

忘れないでください-あなたは会社の男性（または女性）です。コードマンではありません。成功または失敗に既得権益を持つ企業向けにこの製品を開発しています。プロジェクトとプロジェクト提案にはこれを反映する必要があります。会社と製品に対する情熱を示し、知識を示し、上司とCEOに、あなたが彼らに来たときに彼らがあなたを信頼し、何かが必要だと言うべきであることを証明します。製品に価値を追加する（コピーを購入する人が増える）か、時間を節約する（製品が故障したときの怒りの少ない顧客）ことによって、収益にどのように貢献するかを示します。

あなたはしません。

私はこの質問とそれに似たすべての質問を少し行き止まりだと思っています。人々に何かを「説得」することはできません。彼らがこのようなことをまだ知らないか、調査していなければ、彼らはひっくり返さないでしょう。それ以外の場合、データの量はそれらを納得させません。変化は内側から来なければなりません。馬を水に導くことはできますが、彼に飲ませることはできません。

希望する変更を次の技術的な見積もりに焼き込むと言います。アップルが導入したこの新しいフレームワークにアップグレードする必要があります。ロードマップにARCを使用しないでください。オプションはありません。ARCへの移行が唯一の方法です。

私は以前ここで同様の質問に答えたことがあるので、これは重複とみなされるかもしれません。基本的に、「リファクタリングの努力」を行うためにサインオフを取得するつもりはありません。コードクリーナーを作成する方法は、ボーイスカウトルールに従うことです。コードクリーナーは、到着したときよりもコードを離れるときに常に離れてください。

本当の借金を返済するのは、乗り越えられない仕事のように思えるかもしれません（または、散らかった家を掃除する）。秘Theは、「清潔な島」が見えるようになるまで、少しずつ改善することです。大きな勢いが得られると、チームの他の開発者が気づき始め、最終的にタスクに貢献します。

「おじ」ボブ・マーティンによるClean Coderを読むことをお勧めします。良いコードを書くことは仕事の一部です。あなたはあなたの仕事をする許可を求めません、あなたはただそれをします。

この性質の他の質問と同様に、管理者が理解できる数字を提供する必要があります。これらの改善を実装することでどれだけの時間を節約できるか、発生する「ランダムで奇妙なクラッシュ」の回数などを示す数値。

また、これらの改善を自分の時間（つまり、勤務時間外）に実装して、その後、経営陣にメリットを示すこともできます。経営陣があなたが伝えようとしていることを理解していないこと、および/または彼らがあなたにそれを試みるための時間を割り当てたくないことが明らかである場合にのみ、これを行います。

幸運を！

ビジネスケースを提示する

エンジニアの推奨事項がしばしば無視される多くの理由があります。ほとんどすべての理由に対処する最善の方法は、なぜそれを行うべきかというビジネスケースを提示することです。古典的な費用便益分析。これは説得力のある議論をするだけでなく、上司に上層部に持っていくための何かを与えます。

• 初期費用はいくらですか？
• 継続的な費用はいくらですか？
• 予想されるお金/時間の節約はどのようなもので、どこから来ているのですか？
• ROIが表示されるまでにどれくらいかかりますか？

ビジネスケースを行うときは、常にデータで引数をバックアップする必要があります。

• 開発が現在どのくらいの時間を費やして、これが除去または緩和する問題に対処していますか？
• これにより削除または軽減される問題に関連して、ユーザーからの苦情はいくつありますか？
• 他にどんな利点がありますか？

数字を並べて、大まかな、しかし単純な方程式にします。これにはXの費用がかかり、会社Yに利益をもたらします。

注：学問的に優れたアイデアを実装するのに法外な費用がかかっても驚かないでください。

この種の変更はリファクタリングのカテゴリに分類されます。アジャイルアプローチでは、推定する各ストーリーにAMPLEリファクタリング時間を組み込む必要があります。これがまさにその理由です。エンジニアを除けば、なぜあなたがこれをしたいのかを理解する人はいません。それは大丈夫です。正しくコーディングする方法を決定するのは彼らの仕事ではなく、あなた次第です。

そのため、次にやるべき作業があれば、これらの変更がその一部であることを確認してください。見積もりを提供している場合は、リファクタリングの見積もりに30％を追加してください。見積もりを提供していない場合は、作業の一部としてリファクタリングを行ってください。

それはあなたを遅くするかもしれません-まあ、それはそれを見る方法ではありません、それを見る方法はあなたの現在の速度が幻想であるということです、本質的にあなたはチェーンを通り過ぎているという嘘です、あなたは実際にはこの作業のため、やらなければならないことがわかっているため、少し遅くなります。

コンクリートを基礎として使用しなかった場合は、おそらくより迅速に家を建てることができました-そして、顧客にとっては見た目は良くなりますが-顧客が基礎の必要性を認識していなくても、ビルダーする必要がある。（これは実際に興味深い類似点です。なぜなら、ビルダーは常に自分がすべきことを知っていることをしているわけではないため、強制的に法律を制定する必要があることが判明しているからです。決定を下し、しばしば間違った決定をする...

あなたはマネージャーとCEOが両方ともプログラマーであるほど幸運だと言います。そこで、彼らはおそらくない技術的負債が何であるかを理解しています。

事実に基づいて状況を解決しようとすることで、状況を処理する必要があります。つまり、最終的に必要な技術的改善を行わない可能性があります（事実はそのように迷惑な場合があります）。

あなたの仕事は、彼らがあなたが被る特定の技術的負債を完済することのコストと利益を彼らに理解させることです。彼らの仕事は、リソースを最大限に活用することが、それを完済することなのか、それとも何か他のことをするのかを決定することです。

コードに関与していない人が「隠された」ものを改善することの利点を理解するのが難しいのと同じように、ビジネスの領域に利益がいくらか生じると、目に見えるコード変更の利点をプログラマが見るのが難しくなる可能性があります。開発者から隠されています。

技術的な負債を支払うよりも、目に見える機能があなたの時間の価値がある理由を管理者が説明できればいいのですが、それでも決定を下すのはあなたの仕事ではありません。したがって、あなたにそれを説明することは、あなたを幸せにしておくことを除いて、ビジネスにとってあまり役に立たない。そして、ある意味で、彼らがそうすることを主張することは、彼らが彼らの仕事をすることを信頼していない。彼らがあなたをマイクロ管理するときにそれが気に入らないのであれば、あなたは理解する必要があります。

したがって、すべての技術的負債の状況と、それを無視することと支払うことの費用と便益を彼らに認識させ続ける限り、あなたは仕事をしました。本当に経営者が彼らの仕事をすることを信用していない場合を除き、その場合、あなたは対処すべき他の質問となるはるかに大きな問題を抱えています。

たぶんこれは答えではなく、私が犯した間違いに基づいた応答です。また、私がここで読んだ哲学のいくつかとの不一致。

• プログラマーが最もよく知っているという信念に惑わされないでください。
• 正直に言ってください。あなたが進むにつれてリファクタリングしますが、嘘をつかないで、あなた自身の目的のために見積もりを埋めます。
• あなたはコードを所有していません。リードによって承認されていない作業を行わないでください。
• あなたは何かについて正しいかもしれません。あなたは間違っているかもしれません...しかし、あなたはあなたがするために支払われていることをするべきです。

しかし、物事の改善に関して与えられた優れたアドバイスに従ってください。

あなたは明らかに先のとがった上司（PHB）で働いています。彼はもうプログラミングをしていませんし、もしそうならおそらく彼は本当に良くなかったでしょう（しかし、彼は「コンストの正しさ」や「セグメンテーションフォールト」のようなフレーズをドロップするのが好きです。 ）-それは彼が管理のために選ばれた方法です。

PHBは機能を提供するため、CEO（実質的にモホーク族の人）はPHBが好きです。彼は誇らしげに、新しい目盛りボックス（わずかに位置がずれ、あいまいなラベル）、キラキラしたアイコン（Citrixでは8ビットカラー以外の環境ではまだ動作していません）、およびフォーム（競合状態によりランダムにクラッシュする）を誇らしげに示しています特注のXMLバリアントベースのC実装ローカルデータベースでは、10年前の古いガードデベロッパーの伝説の1人によって書かれたため、開発チームの誰も手を触れませんでした。ない）。

実際に「仕事ビット」（あなたは、ホワイトボード上で円を描く叫び、そしてミニチュアBattenburgsを食べるようにすべての実際の作業が行われているという不都合た後、たまたまそのビットを知っている）を行うプログラマが知っている中、その正気直前に撮ったシステム作業メンテナンスされていないジャングルから10人で10日間労力を費やしてハックすると、おそらくテストを含めて1〜2人日になります。しかし、システムを正常な状態に戻すには、6か月間の真のハードワークが必要であり、明らかな外部報酬はほとんどありません。

PHBは、6か月でフックまたは詐欺師によって、30人または40人の新しい機能をアプリケーションに追加して、営業担当者（実際に販売しているものを考えると魔術師でなければならない）が新しい購入やアップグレードを誘惑できることを知っています。

ただし、PHBに会費を支払うには、これらのチェックボックスとフォームの販売が停滞または低下する可能性があり、競合他社が市場シェアを獲得する可能性があります。

私が思いついた結論は、泥沼から抜け出す唯一の方法は、新しいスタートアップで働くことであり、ソフトウェアをどのようにすべきかというあなたのビジョンを共有し、その哲学に固執することです（私はまだそこに着くまで取り組んでいます！）

他の回答で言及されていない別の隠れたコストがあります。つまり、優れたエンジニアは、説明されているタイプの環境に残される傾向があります。最終的には、野心やリファクタリング能力を持つ人が退職し、その後物事は非常に悪い方法で、おそらく修正不可能になります。残念なことに、manager慢な人（「私はあなたの最高のプログラマーの1人」）や強引なジャーク（「やりたいことをやらないなら辞めます」）に出会わない限り、これをマネージャーに伝えることはできません。ただし、再就職のステータスにならないようにするために、出口インタビューで忘れずに言及してください。

あなたはどちらも正しいし、どちらも間違っている。だからこそ、これらの問題は長い間存続し、ハードな感情を生み出す。

理由は上で明確に述べられています：経営者はお金で考えます。またはさらに具体的には収益です。彼らにとっては、コストはあるが顧客への直接的な可視性がないものは収益を上げないので、それは悪い計画です。

あなたのビジョンも正しい：それは顧客にとっては良いが、長期的にはそうだろう。あなたの行動は、短期計画と比較して、将来さらに大きな収益を生み出す可能性があります。

あなたはマネジャーではなく、あなたが収入に直接責任を負うものでもありません（もちろんそう思います）。したがって、あなたは彼らの問題と混同しており（それが経営者にとってどのように感じているか）、あなたは自分の仕事に集中しておらず、ソフトウェアをさらに拡張しています。

すべての難しい、明確な言葉ですが、それが通信エラーからほとんどの問題が発生する方法です。どちらも同じことを望んでいますが、短期的な決定は異なっています。すべては、開発者がマネージャーと比較して異なる見通しを持っているためです。

この問題をどのように解決しますか？多くの問題について、お互いに十分にコミュニケーションを取り、理解します。それが顧客エンゲージメントと満足度に焦点を当てる可能性が最も高いでしょう。

安定した将来の証明方法でこの問題を解決するには、古いコードでバグ修正のコストを測定するという点で同意します。古いソフトウェアで作業するのにさらにかかる時間と、新しいコードベースでどのようになるかを測定します。

これを証明するために、たとえばこの非常に簡単なことを行うことができます。バージョン管理でソフトウェアを分岐させます。最初に管理者が望んでいることを行い、その機能を作成します。あなたはこれを行いますが、別の方法を示す時間を得ることに同意します。次に、新しいブランチで同じことを行いますが、最初に取り除く必要がある問題を修正します。次に、ソリューションも開発します。

これで同じソリューションが得られましたが、まったく異なる方法で開発されました。それからケースを作成し、安定性、必要なコードの量、コード自体などの管理情報を含むソリューションを隣り合わせに配置します。

さあ、コーヒーを手に取って、だれが正しいのかを議論するのではなく、会社の両方向の影響について議論するのではなく、見てみましょう。それは、あなたとあなたの両方が必要とする雰囲気を生まないので、本当に有益でより悪い議論ではない会議を作成します。それはあなたの製品を良くするものではありません。

コードレビューがある場合は、ARCを使用してコードを改善する必要があることを示すテクニカルチケットを作成し、マネージャーに割り当てます。

彼を説得してください。あなたが行った同様の技術的強化のいくつかの小さな例を彼に説明し、プロジェクトへの利点を説明します。

これらの変更は、経営陣が購入する意思がある唯一の方法で販売する必要があります。

管理者が必要なだけの魅力的なユーザー向け機能を見つけてください。ただし、コードの低レベルの改善がなければ不可能です。

会社がクライアントが付加価値として認識しているものを提供することに開発を集中させることは、上司の仕事です。この認識を変える可能性のある要因は2つあります。

1. クライアントのリクエストを配信するのにどれくらい時間がかかりますか？
2. あなたが意志を言うときに配達しますか？

ほとんどの場合、3週間で4週間かかると言うよりも、5週間で5週間かかると言います。

管理と拡張が容易な現在のコードベースを使用すると、より迅速に配信し、予測可能性を高めることができます。バグの修正にあまりにも多くの時間を費やしている場合、新しい機能を追加するために利用できるリソースが少なくなります。コードの修正に費やされたリソースの量と、機能約束の正確さを評価します。現在のコード（上司の哲学の下）が高すぎるかどうかを判断する1つの方法です。

経営のinertia性のために、私たちの手にすり抜けそうになった20億ドルの機会についてお話ししましょう。

私たちの中には、顧客の声に耳を傾けるポイントがあります。つまり、顧客が何を望んでいるかを理解することです。常に彼が求めるものではありませんが、あなたが顧客と会話する立場にあるなら、あなたは最終的に彼が望むものを相互理解するようになります。（その後、彼はそれを明示的に求め始めることができます。）

そうは言っても、顧客との会話を誰が行うべきかを理解することは重要です。通常、これを行う主要なデザイナーと一緒に、ビジネス開発スタッフがいます。競争がある場合は、顧客もこの会話をしていると予想できます。

同時に、開発者がそれぞれの分野で最新の状態を保つことが重要です。そうでない場合は、競争が発生するためです。

私たちの状況では、既存の顧客と古いテクノロジーに基づいたやや効果的な製品があり、顧客は迅速なアップグレードが必要でした。彼らが本当に必要としていたのは完全な代替製品でしたが、当社の考え方は、これにより私たちはすぐに競争力のある地位に追い込まれるということでしたが、既存の製品を変更すると、法的に競争力を要求することなく顧客が私たちを続けることができました。私たちの経営陣は、彼らがこの市場を所有していると考えました。問題は、既存の製品構造がアップグレードに十分な柔軟性を備えていなかったため、アップグレード要求に対応できなかったことです。

顧客は短気になり、競合するソースと会話を始めました。その市場の「所有権」と20億ドルの収益を失いました。しかし、いったん市場が私たちを競争力のある地位に追い込むと、経営陣は廃業するか競争するしかありませんでした。（ロードブロッキングだったもののほとんどは最終的に解雇されました。）私たちは競争し、最も細いスレッドでビジネスを奪還することができました。

私は最初に、この機会が私たちの手にほとんどすり抜けたと言いました。私が言及した収益のために、私たちはビジネスを取り戻しました。最初の段階で顧客の懸念に適応する準備ができていれば、本当の競争はなかっただろう。

私が提供していることはこれです：あなたの個人的な能力において常に最先端を保つようにしてください。常に柔軟性があり、顧客のニーズにすばやく適応できる製品を開発してください。このように考えていない会社で長く働きすぎると、あなたは萎縮し、あなたの個人的なモチベーションは低下します。私はそれが起こるのを見てきました。

何らかの理由で製品を改善するアイデアがある場合は、次の質問を自問してください。-これは顧客が望んでいると思いますか？製品開発に関する私の考えを顧客の声に対して検証できますか？私の会社は顧客のニーズに対応できる立場にありますか？もしそうなら、どのように？-そうすれば、製品開発の提案に関して説得力のあるケースを作成することができます。

すべての分野と産業にまたがるビジネスの共通言語はお金です。説明している問題は、プログラミングの問題ではなく、ビジネスの問題です。ビジネスの提案に対して適切な回答を得るには、ビジネスの言語でそれを組み立てる必要があります。つまり、すべてのコストと利点を含む代替プロジェクト計画を提示できる必要があります。

機会費用、ROI（投資収益率）、NPV（正味現在価値）などのことを学ぶ必要があります。これを行うためにMBAは必要ありませんが、人件費、間接費、収益の可能性など、利用できないデータにアクセスする必要があります。1つのパスがハードナンバーを使用して別のパスよりも多くの価値を提供するという明確な議論を行うことができる場合、管理者から十分な注意を得ることができます。

私が非常に小さなチームの新しい開発者だったとき、空き時間にこの種の改善をたくさんしました。楽しかった; 妻と夜にリビングルームに座って、私はログオンして面白い新しいテクニックを試してみました。私はより上級の開発者になり、それからより大きなチームのマネージャーになったので、私の自由時間はなくなりました。機能と重要な修正を行うためだけに余分な時間を費やしていました。私たち全員がそれがどれほど重要かを知っていたとしても、その定期的なハウスキーピング作業に誰かの時間を費やすことを正当化することは本当に難しくなりました。

上司は、メンテナンスコストを抑え、将来の成長コストを削減し、才能のある開発チームを関与させ続けるなど、それがどれほど重要であるかを説明する必要はありません。ただし、彼らが必要とするのは計画です。なぜなら、彼らはあらゆる種類の計画、スケジュール、ロードマップ、約束、そして「機能追加」側へのプレッシャーを持っていると推測しているからです。

できることの1つは、文書化された計画を立てることです。リリースに結び付けることができるか、または新しい機能の終了基準に結びつけることができるかどうかを確認します。「参照カウントをやり直す」という要求は、上司にとって承認するのが難しい場合がありますが、4週間後の5日間のブロックをスケジュールする方が簡単な場合があります。基本的には、新しい機能が計画およびスケジュールされていることを確認し、それをまねようとするか、「内部」部分を挿入します。

その種のものに割り当てられる5％の時間を要求することから始めて、徐々に独自の技術ロードマップの優先順位を構築し、それぞれのビジネスケース、ROI、リスクレベルなどを正当化することから離れ続けます。すぐに、上司の挑戦を味わうことさえできるようになります。時間がないときよりも多くの素晴らしいアイデアがすぐに見つかるからです。

幸運を！

自動参照カウントのリクエストが拒否される理由は次のとおりです。

1. それは改善ではありません。hello worldよりも大きいものがあると、変更は間違った方向に進みます。あなたが変更を行う必要がある場合、それは常に間違った方向に向かっているという事実を変更するリファクタリングの量はありません。重要なのは、変更が十分に重要な場合に、新しい問題を引き起こすリスクに見合うだけの価値があるかどうかを知ることです。経営陣は、エンドユーザーがそれを見ることができない場合、リスクに見合う価値がないと明確に述べています。
2. 参照カウントは完全にクレイジーな機能です。既存の有名な会社が何らかの機能を実装しているのを見て、すぐに同じ機能が必要だと思いました。まあ、あなたのコードベースは、アップルが使用しているものとは完全に異なる可能性が非常に高いです。おそらく参照カウントは機能しないか、単に時間の無駄です。コードのいたるところに参照カウントプリミティブを展開する必要のない別の方法を見つける必要があります。おそらく、リカウント計画にはコードベースの数千の変更が必要ですが、それらの変更のほとんどは必要ありません。時間とお金を無駄にするだけです。
3. あなたは間違った問題を解決しています。管理者は通常、システムにどのような問題があるかを知っています。リファウンティングソリューションが解決しているいくつかの無関係なメモリリークの問題は、それらの1つではありません。コンピューターがメモリーを処理する方法に関する想像上の問題ではなく、実際の問題に焦点を当てます。
4. 実装に時間がかかりすぎる Appleは、プログラマーとマネージャーがほとんどいない、取るに足りないチームよりも少し大きい会社です。彼らは価格を支払うだけで大きな変化を遂げることができます。何かを実装するのに数百万を要する場合、それはピーナッツです。中小企業が同じことを行おうとすると、彼らはすぐにお金を使い果たしてしまいます。ソフトウェア開発はすでに非常に高価です。不要なコストを追加しても少しは助けにはなりません。メモリ管理などの無関係な機能が水門を開きます。承認後、プログラマの半数が独自の「改善」を実装することを望みます。それは終わりのない物語であり、会社は代わりに何か有用なことをしている可能性があります。

問題を処理するために使用できるいくつかの手順を次に示します。

1. 機能をドロップ
2. 本当の問題は何かを見つけます
3. 役に立つことを始めましょう
4. 時間の使い方を慎重に計画する
5. あなたの改善がどのようにお金をもたらしているかを知る
6. ほとんどの金額をもたらす機能のみを選択してください
7. ソフトウェア開発のプログラミングの側面はシステム全体のほんの一部にすぎないことを認識してください。それを改善することは決して価値のあることではありません