ユーザーにはすぐには見えない改善に価値を見出せない経営者への対処
スケジュールのプレッシャーが理解できます。ユーザーは会社の生命線なので、ユーザーを喜ばせたいと思っています。ただし、特定の変更によって将来すべてが容易になることも事実です。残念ながら、私の組織の経営陣はそのような変化に対して本能的に抵抗し、この抵抗は非常に強いので、長期的な改善の邪魔になります。
たとえば、Apple iOSプログラムの自動参照カウントが最近導入されました。これは、以前に使用しなければならなかった手動の保持/解放呼び出しを大幅に改善したものです。コードの記述と保守が容易です。切り替え自体がいくつかのクラッシュを引き起こす可能性がありますが、それらが解決されると、ランダムな奇妙なクラッシュの数は減少する可能性があります。
私は最近、自動参照カウントに切り替えたいと上司に話しました。彼の反応は彼が目に見える改善に集中したかったということでした。この反応は、彼が彼の上から得ている圧力によって駆動された可能性があります-おそらくCEOからの権利です。
同様の例がたくさんあります。よくあることは、何かを修正する必要があるということですが、修正の短期的なコストは短期的な利益を上回ります。「短期」は「今後数週間以内」と定義されます。
どのように対処すればよいですか？
編集：応答をありがとう。来てください。それは私の状況に関連しているので、私のマネージャーとCEOはどちらもプログラマーであることを明確にする必要があります。どうやら彼らのプログラマー側は他の圧力に圧倒されています。
あなたは本当に 技術的負債 について話している。多分比喩はあなたのマネージャーを助けるでしょう。ソフトウェアの技術的負債の影響を、汚れたキッチンでの調理と比較することがよくあります。流し台やカウンター、ストーブに汚れた食器が山積みになっていて、床にゴミが入っていると、料理に時間がかかります。ただし、次の食事を準備する最も早い方法は、混乱を回避することです。キッチンを掃除して清潔に保つと、次の食事が遅れますが、その後のすべての食事の配達が改善されます。そして、食堂の空腹の人が乱雑なキッチンを見ることができず、なぜ料理を始める前に片付けたいのか理解できないのと同じように、経営陣はコードの混乱を見ることができません。混乱を示すか、混乱によって引き起こされる品質の問題と遅延を示す必要があります。
おそらく、緊急のタスクや重要なタスクについて話すこともできます。重要なタスクが実行されない場合、緊急のタスクは時間がかかり、コストが高くなります。
プログラマーを悩ませている何かをキャリアのある時点で偶然見つけました：このコードはリファクタリングする必要があり、そこにアーキテクチャ上の問題があります、これモジュールのメンテナンスが困難になるなどです。しかし、組織の現在の文化のため、直接目に見えるメリットしか得られない作業に集中するように強いられています。
その古典的な 氷山の秘密 その秘密は、氷山が水中で90％であるのと同じように、any開発プロジェクトの大部分であるという事実に関係しています：90％の作業はエンドユーザーから完全に見えなくなります。そのコードはエンドユーザーに影響をもたらしますが、管理者は、維持/解放および自動参照呼び出しを6時間リファクタリングして、見えない場合になぜリファクタリングしたのかを理解するのに苦労しています。すべての違いとすべてがうまく機能しています。
この問題に関して、あなたが持ち帰ることができるいくつかの事実を以下に示します。
- 管理者は、彼ら自身がプログラマーでない限り、氷山の秘密を理解するつもりはありません。
- これは無知の問題であり、悪意ではありません。 CEOは優れた製品を求めています。彼は、優れた製品になるすべてを理解していません。
- CEO（および直属の上司）は愚かではありません。これに時間を費やす必要がある理由やその他の氷山問題について、いくつかの事実と具体的なデータを調査して準備します。
忘れないでください-あなたは会社の男性（または女性）です。 コードマンではない。あなたは成功または失敗に既得権を持っている会社のためにこの製品を開発しています-あなたのプロジェクトとプロジェクト提案はこれを反映するべきです。会社と製品への情熱を示し、知識を示し、上司やCEOに、あなたが彼らに来て、何かが必要だと言ったときに信頼してもらうべきであることを証明します。製品に付加価値を与える（コピーを購入する人が増える）か、時間を節約する（製品が故障したときに怒っている顧客が減る）かによって、収益にどのように貢献するかを説明します。
あなたはしません。
私はこの質問とそれのようなすべての質問を行き止まりのように見えます。どんな人でも「納得」させることはできません。彼らがこのようなことをまだ認識していないか、調査していない場合、チャンスを与えていない可能性があります。そして、そうでなければ、データ量はそれらを説得しません。変化は内から来なければなりません。馬を水に導くことはできますが、彼に飲ませることはできません。
私はあなたの次の技術的な見積もりにあなたの望ましい変化を焼き込めると言います。 Appleが導入されました。ロードマップにARCを使用しないようにしないでください。オプションはありません。ARCへの移行が唯一の方法です。仕方。
私は以前にここで同様の質問に答えたことがあるので、これは重複と見なされる可能性があります。基本的に、「リファクタリング作業」を行うためのサインオフを取得することはありません。コードクリーナーを作成する方法は、ボーイスカウトのルールに従うことです。到着したときよりも、コードを離れるときは常にコードクリーナーをそのままにしてください。
本当の借金を返済するのと同じように、乗り越えられない仕事（または乱雑な家の掃除）のように見えます。トリックは、「清潔な島」が見えるまで、少しずつ良くすることです。大きな勢いがつくと、チームの他の開発者が気づき始め、最終的にはタスクに貢献します。
「おじさん」ボブ・マーティンの Clean Coder を読むことをお勧めします。良いコードを書くことはあなたの仕事の一部です。あなたは自分の仕事をする許可を求めないで、あなたはそれをします。
ビジネスケースの提示
エンジニアの推奨がしばしば無視される理由はたくさんあります。ほとんどすべての理由に対処する最良の方法は、それを行うべき理由のビジネスケースを提示することです。古典的な費用便益分析。これは説得力のある議論をするだけでなく、上司に上層部に何かを与えることにもなります。
- 初期費用はいくらですか？
- 継続的なコストはいくらですか？
- 予想されるお金/時間の節約はどのくらいですか？
- ROIが表示されるまでにはどのくらいかかりますか？
ビジネスケースを行うときは、常にデータを使用して引数をバックアップする必要があります。
- これにより、開発で問題の解決に費やされている時間はどれくらいですか？
- これにより削除または軽減される問題に関連して、ユーザーからの苦情がいくつありますか？
- 他にどのようなメリットがありますか？
数字を並べて、大まかですが単純な方程式にします。それにはXの費用がかかり、Y社に利益がもたらされます。
注：学問的に優れたアイデアを実装するのに法外な費用がかかっても驚かないでください。
この種の他の質問と同様に、経営陣が理解できる数値を提供する必要があります。これらの改善を実装することでどれだけの時間を節約できるか、「ランダムな奇妙なクラッシュ」が少なくなるかなどを示す数値。クラッシュはエンドユーザーに表示され、それらを防ぐために実行されたすべてのことはビジネスに役立つことを納得させます。
また、これらの改善を自分の時間（つまり、勤務時間外）に実装して、後で管理者にメリットを示すこともできます。経営者があなたが伝えようとしていることを理解していないこと、および/または彼らがあなたにそれを試みるために時間を割り当てたくないことを明確にしている場合にのみ、私はこれを行います。
幸運を！
この種の変更は、リファクタリングのカテゴリに分類されます。アジャイルアプローチは、見積もる各ストーリーにAMPLEリファクタリング時間を組み込む必要があるということです。これがまさにその理由です。エンジニアを除いて、なぜあなたがこれをしたいのか誰も理解しないでしょう、それは大丈夫です、正しくコーディングする方法を決定するのは彼らの仕事ではなく、あなた次第です。
したがって、次にやるべき作業がある場合は、これらの変更がその一部であることを確認してください。見積もりを提供する場合は、リファクタリングの見積もりに30％を追加してください。見積もりを提供しない場合は、作業の一部としてリファクタリングを実行してください。
それはあなたを遅くするかもしれません-ええ、それはそれを見る方法ではありません、それを見る方法はあなたの現在の速度が幻想であるということです、本質的にあなたがチェーンを通り過ぎているという嘘です、あなたは実際にあなたが知っているこの仕事のために少し遅くなる必要があります。
コンクリートを基礎として使用しなかった場合、おそらくより迅速に家を建てることができます-それらは顧客にとっては見栄えが良いでしょう-しかし、顧客が基礎の必要性を認識していなくても、ビルダーはする必要があります。 （これは実際には興味深い並行処理です。なぜならビルダーは常に彼らがすべきことを知っていることをするわけではないことが判明しているため、強制するための法律を渡す必要があるということです-同じ問題に直面していても、ソフトウェア開発を管理する法律はありません。決定し、しばしば間違った決定をする...）
あなたはあなたがあなたのマネージャーとCEOが両方ともプログラマーである幸運なことにあなたは言及します。だから彼らはおそらくdoが技術的負債とは何かを理解しています。
事実に基づいて状況を解決しようとすることで状況を処理する必要があります。つまり、あなたができないが技術的にならないという実際の可能性がありますあなたが望む改善（事実はそのように迷惑になることがあります）。
あなたの仕事は、あなたが被る特定の技術的負債を返済することの費用と利益を彼らが理解することを確実にすることです。彼らの仕事は、リソースを最大限に活用することが、それを完済することなのか、それとも何か他のことをすることなのかを決定することです。
コードにかかわっていない人々が「隠された」ものを改善することの利点を見るのが難しいのと同じように、利点がビジネスの領域にいくらか生じたとき、プログラマーが目に見えるコード変更の利点を見るのは難しいかもしれません」開発者から隠された」。
目に見える機能が技術的負債を支払うよりも時間の価値がある理由を経営陣が説明できるのはいいことですが、実際には、とにかく決断するのはあなたの仕事ではありません。だから、あなたにそれを説明することはあなたを幸せに保つことを除いてビジネスに多くをすることはありません。そして、ある意味で、そうするように主張することは、彼らが自分の仕事をすることを信頼することではありません。彼らがあなたをマイクロ管理するときにそれが気に入らない場合は、理解する必要があります。
したがって、すべての技術的負債の状態と、それを無視することと支払うことのコストとメリットを彼らに認識させ続ける限り、あなたはあなたの仕事を終えました。あなたが本当に信用管理を行わない場合を除いて、その場合、対処する必要のあるまったく別の問題となるはるかに大きな問題があります。
多分これは答えではありませんが、私が犯した間違いに基づく応答です。また、私がここで読んだいくつかの哲学との不一致。
- プログラマーが最もよく知っているという信念に屈しないでください。
- 正直に言う。進むにつれてリファクタリングしますが、自分の目的のために嘘をついたり見積もりを埋めたりしないでください。
- あなたはコードを所有していません。リードによって承認されていない作業を行わないでください。
- あなたは何かについて正しいかもしれません。あなたは間違っているかもしれません...しかし、あなたはあなたがするために支払われたものをすべきです。
しかし、確かに物事を改善するために与えられた優れたアドバイスに従ってください。
あなたは明らかに先のとがった髪のボス（PHB）のために働いています。彼はもうプログラムしません。もしそうなら、彼はおそらく本当に上手くいかなかったでしょう（ただし、「const correctness」や「segmentation fault」などの語句を入れて、みんなが自分の縞模様を獲得していることを知っているようにしています）-それが彼が管理のために選ばれた方法です。
PHBは機能を提供するため、CEO（実際にはモホークを持っている）はPHBを気に入っています。彼が誇らしげにすべてのスプリントは、新しいティックボックス（少し位置がずれて、あいまいなラベルが付いている）、きらめくアイコン（まだどの環境でも動作していないが、Citrixでは8ビットカラー）、およびフォーム（競合状態によりランダムにクラッシュする）を示しています別注のxmlバリアントベースのC実装ローカルデータベースでは、開発チームの誰も触れませんでした。これは、10年前の古いガード開発者の伝説の1つによって書かれ、5文字が必要かどうかにかかわらず、5文字の名前のマクロですべてを実行するためです。しない）。
実際に「作業ビット」を実行するプログラマー（ホワイトボードに円を描いたり、叫んだり、ミニチュアバッテンブルクを食べたりするなどの実際の作業がすべて行われた後に不便に発生するビットを知っています）は、sane =システムを維持するのに10人の男が10日間かかって手入れのされていないジャングルをハッキングするのにかかる時間は、テストを含めて1〜2人日になるでしょう。しかし、システムを本来の状態に戻すにはsaneには6か月の真にハードな作業が必要で、明らかな外部報酬はほとんどありません。
PHBは、6か月以内に、フックまたはクルックによって、30〜40の新しいfeaturesをアプリケーションに取り込むことができることを知っています。販売担当者（実際に販売しているものを手に入れているマジシャンである必要があります）新規購入やアップグレードを誘惑するために使用されます。
ただし、PHBに会費を与えるには、これらのティックボックスとフォームがないと、売上が停滞または減少する可能性があり、競合他社が市場シェアを獲得する可能性があります。
私がたどり着いた結論は、泥沼から抜け出す唯一の方法は、ソフトウェアをどのようにすべきかというあなたのビジョンを共有し、その哲学に忠実に固執する少数の人々と一緒に新しいスタートアップで働くことです（私はまだそこに到達するために取り組んでいます！）
他の回答で言及されていない別の隠されたコストがあります。つまり、優れたエンジニアは、説明されている種類の環境に留まる傾向があります。最終的には、リファクタリングへの野心または能力を持つ人は誰でも会社を辞め、それから事態は非常に悪い方法になり、おそらく修正できなくなります。残念ながら、傲慢（「私はあなたの最高のプログラマーの1人です」）と強引なジャーク（「私がやりたいことをやらなければ、私は去ります」）に出会わないと、マネージャーにこれを伝えることはできません。ただし、再就職のステータスにならないように、面接では必ずそのことを説明してください。
あなたはどちらも正しいですし、どちらも間違っています。そのため、これらの問題は長く続き、ハードな感情を生み出します。
上記の理由が明確に述べられている理由：経営陣はお金で考えている。さらに具体的には、収益。彼らにとって、コストはあるが顧客に直接見えないものは収入をもたらさないので、それは悪い計画です。
あなたのビジョンも正しいです。それは顧客にとっては良いですが、長期的には。あなたの行動は、短期的な計画と比較して、将来さらに大きな収入を生み出すかもしれません。
あなたはマネージャーではなく、あなたは収入の直接の責任者ではありません（もちろん私は仮定します）。したがって、あなたは彼らの問題と混同している（それが管理にとってそれがどのように感じられるか）そしてあなたはあなたの仕事に焦点を合わせていない：ソフトウェアをさらに拡張すること。
すべての難しい、明確な言葉ですが、通信エラーから、ほとんどの問題が発生するのはそのためです。あなたはどちらも同じことを望んでいますが、短期的な決定は異なる方法で行われます。すべては、開発者がマネージャーと比較して異なるOutlookを持っているためです。
この問題をどのように解決しますか？あなたは多くの問題についてお互いに十分にコミュニケーションし、理解します。それが最も可能性の高い顧客エンゲージメントと満足度の焦点になります。
安定した将来の証明方法でこの問題を解決するには、古いコードのバグ修正のコストを測定することに同意します。古いソフトウェアでの作業にさらにかかる時間と、新しいコードベースでの作業時間を測定します。
これを証明するには、たとえば、この非常に単純なことを実行できます。バージョン管理でソフトウェアを分岐します。最初に管理者が望むことを行うので、その機能を作成します。あなたはこれを行いますが、合意はあなたが別の方法を示す時間を得ることです。次に、新しいブランチで同じことを行いますが、最初に、解消したい問題を修正します。次に、ソリューションも開発します。
これで同じソリューションができましたが、完全に異なる方法で開発されました。それからケースを作成し、安定性、必要なコードの量、コード自体などの管理情報を含むソリューションを隣同士に配置します。
さあ、コーヒーを片手に見てみましょう。誰が正しいのかではなく、会社の両方向の影響をどう考えているのかを検討します。それは本当に便利な会議を作成します。それはあなたと両方が必要とする雰囲気を生成しないので、より悪い議論ではありません。それはあなたの製品を良くすることにはなりません。
すべての分野と業界にわたるビジネスの共通言語はお金です。説明している問題はプログラミングの問題ではなく、ビジネスの問題です。ビジネスの提案に適切に対応したい場合は、ビジネスの言語でそれを組み立てる必要があります。つまり、すべてのコストとメリットを含む代替プロジェクト計画を提示できる必要があります。
機会費用、ROI（投資収益率）、NPV（正味現在価値）などについて学ぶ必要があります。これを行うのにMBAは必要ありませんが、人件費、諸経費、収益の可能性など、利用できない可能性のあるデータにアクセスする必要があります。明確な数値を使用して、あるパスが別のパスよりも多くの価値を提供するという明確な主張をすることができれば、経営陣から十分な注意を引くことになります。
コードレビューがある場合は、ARCを使用してコードを改善し、マネージャーに割り当てる必要があることを記載したテクニカルチケットを作成します。
彼を納得させる。あなたが行った同様の技術的拡張のいくつかの小さな例と、プロジェクトに対するその利点を彼に説明してください。
あなたは経営陣が喜んで購入する唯一の方法でそれらの変更を販売しなければなりません：
ユーザー向けの機能を見つけて、管理者がそれを持っている必要があるだけでなく、コードのいくつかの低レベルの改善なしでは実行できないようにすることが説得力がある。
会社がクライアントが付加価値として認識するものを提供することに開発を集中させることは、あなたの上司の仕事です。この認識を変える可能性のある2つの要因があります。
- クライアントのリクエストに応じるためにはどのくらい時間がかかりますか？
- 言うときに配達しますか？
ほとんどの場合、3週間で配達するが4週間かかると言うよりも、6週間で5週間で配達すると言うでしょう.
管理と拡張が容易な現在のコードベースを使用することで、より迅速に提供し、予測可能性を高めることができます。バグ修正に時間をかけすぎると、新しい機能を追加するために利用できるリソースが少なくなります。コードの修正に費やされたリソースの量と、機能の約束についてどれだけ正確かを評価します。 （上司の理念の下で）現在のコードのコストが高すぎるかどうかを判断するこの1つの方法。
管理の慣性のために、私たちの手に渡りそうになった20億ドルのチャンスについてお話します。
一部のお客様は、お客様の声に耳を傾け、お客様が何を望んでいるかを理解するという意味を持っています。それは常に彼が求めていることではありませんが、あなたが顧客と会話する立場にあれば、最終的に彼が何を望んでいるのかを相互に理解するようになります。 （その後、彼は明示的にそれを要求し始めることができます。）
とはいえ、顧客との会話を誰が持つべきかを理解することが重要です。あなたは通常、これを行ういくつかの主要な設計者と一緒にビジネス開発の人々を抱えています。競争がある場合は、顧客もこのような会話をしていると期待できます。
同時に、そうでない場合はあなたを打ち負かす競争があるので、開発者が彼らの分野で最新の状態を保つことが重要です。
私たちの状況では、既存の顧客がいて、古い技術に基づくやや効果的な製品があり、顧客は迅速なアップグレードを必要としていました。彼らが本当に必要とするのは完全な代替製品でしたが、当社の考え方では、これによりすぐに競争力が高まる一方、既存の製品を変更することで、お客様は法的に競争力を要求されることなく継続することができました。私たちの経営陣は、彼らがこの市場を所有していると考えていました。問題は、既存の製品構造がアップグレードするのに十分な柔軟性を持っていなかったため、アップグレード要求に対応できないことでした。
顧客は焦り、競合する情報源と会話を始めました。私たちはその市場の「所有権」と数十億ドルの収益を失いました。しかし、市場が私たちを競争力のある地位に追いやったら、経営陣は廃業するか競争するしかありませんでした。 （最終的に障害となったもののほとんどは解雇されました。）私たちは競争し、最も細い糸でビジネスを取り戻すことができました。
私は最初に、この機会が私たちの手にほとんど通じなかったと言いました。私が述べた収益のために、ビジネスを取り戻しました。最初は顧客の懸念に適応する準備ができていたなら、実際の競争はなかっただろう。
私が提案している要点は次のとおりです。個人の能力において常に最先端を維持するようにしてください。常に柔軟性があり、顧客のニーズにすばやく対応できる製品を開発してください。このように考えない会社で長く働きすぎると、衰退し、個人のモチベーションが低下します。私はそれが起こるのを見てきました。
何らかの理由で製品を改善するアイデアがある場合は、次の質問を自問してみてください。-これは、顧客が望んでいることですか？製品開発についての考えを顧客の声と照らし合わせて検証できますか？私の会社は顧客のニーズに対応できる立場にありますか？もしそうなら、どうですか？ -あなたは、あなたの製品開発提案に関して説得力のある主張をする立場にあるべきです。
私が非常に小さなチームの新しい開発者だったとき、私の自由時間にこの種の改善をたくさん行いました。楽しかった;夜、妻と一緒にリビングルームに座りながら、ログオンして興味深い新しいテクニックを試しました。私はより上級の開発者になり、それからより大きなチームのマネージャーになる必要があったので、私の自由時間がなくなりました。機能と重要な修正を行うためだけに、余分な時間を費やしていました。誰もがそれがどれほど重要であるかを知っていたとしても、その定期的なハウスキーピング作業に誰かの時間を費やすことを正当化することは本当に困難になりました。
上司は、メンテナンスコストを抑え、将来の成長コストを削減し、有能な開発チームを従事させ続けるなど、それがどれほど重要であるかを説明する必要はありません。そうした場合、大きな問題が発生します。しかし、彼らが必要とするのは計画です。それは今、彼らがあらゆる種類の計画、スケジュール、ロードマップ、約束、そして「機能追加」側のプレッシャーを持っていると推測しているからです。
あなたが試すことができる1つのことは、文書化された計画を立てることです。それをリリースに結び付けることができるか、または新しい機能の終了基準にできるかどうかを確認してください。 「参照カウントのやり直しに時間をかける」というリクエストは上司の承認が難しいかもしれませんが、4週間後の5日間のブロックをスケジュールする方が簡単かもしれません。ただし、基本的には、新機能が計画およびスケジュールされていることがわかります。それを模倣するか、「内部」部分を注入してみてください。
その種類のものに割り当てられた5％の時間を要求することから始め、次に、独自のテクノロジーロードマップの優先順位を徐々に構築し、それぞれについてビジネスケース、ROI、リスクレベルなどを正当化することを続けます。すぐに上司の課題を味わうことになるでしょう。時間よりも多くの優れたアイデアをすぐに見つけることができるからです。
幸運を！