何年もの間、彼らのチームが製品革新に欠け、プロジェクト管理方法論を使用せず、悪いソフトウェア開発プラクティスを維持していた場合、開発者として何をすべきか？[閉まっている]

何年も変更されておらず、最終的に製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、特定の例があり、同じ状況で複数回見たり、経験したことがあり、これらの問題に対処する最善の解決策が会社を辞めることだと思う場合は、回答をサポートしてください。重要なのは、特にこの問題に関する複数の専門家が最終的なルートがルートAであることを示す場合、この質問には本当に答えがあるということです。

私は、多くの開発者が同じような状況にあったことを知っています。これは、企業が市場で第1位から最後に、あるいは市場から外れてしまう主な理由の1つです。この投稿の回答が、同様の障害に直面している他の開発者の助けになることを願っています。小規模または大規模な開発チームでは、通常これが発生します。

• 一部の開発者は気にせず、フローを採​​用することを決め、多くのコードをそのまま残し、開発プロセスをそのままにすることを好むようです。
• 他の人は変化に飽きて辞任し、別の会社に移動します。
• 他の人は話をすることを恐れて静かに過ごすことを好むようです。
• 時には非常に少数の開発者またはたった1人の開発者が製品の改善について意見を表明し、クライアント、ユーザー、およびチームのコーディングのベストプラクティスとその利点に従うことの重要性をチームに伝えます。これらのタイプの開発者は通常、会社が提供するメリットが非常に少ないソフトウェア会社や製品に多くの可能性があるなどの理由により、チームに留まることを決定します。

私たちのチームの製品は、製品の傘を持っているため、会社が収益を得る場所のほんの一部です（この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、雇用を創出する継続的な特許訴訟はありません）不安定）。ここ数年、他の開発者の経験からこれまでに学んだことと、私の経験では、開発チームを本当に知るには、数日でも数週間ではなく、数か月かかるということです。チームがあなたを雇いたい、またはあなたを必要とする場合、面接プロセス中。彼らはすべてを素晴らしい音にし、あなたが聞きたいことをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コードの内部を掘り始めて、完全なSDLCプロセスに移行するときの現実は異なります。これは、開発者として、あなたが仕事に就いたことの現実を見始めたときです。この現実により、ある会社から別の会社に移動したいと思うのは難しくなります。なぜなら、あなたが移動する会社が良いか悪いかを知るのは難しいからです。はい、Glassdoorのレビューなどを読むことができますが、HRからではなく、実際のオンラインレビューの数はどれくらいですか？

マネージャーは最初から常に変化に抵抗しており、以前の開発者は何年も同じことをしてきたことを考慮して、以下に概説する問題に取り組む最良の方法は何でしょうか？

• 長年にわたる製品革新の欠如：製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に作られたように見えます。一部のユーザーは、製品が使いやすくも直感的でもないと不満を述べ、他の人は、Gmailのようなアプリに使用され、同様の機能がないために製品を使用するときにイライラすることを述べています。ここでの主な問題は、開発者として製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると（ユーザーフレンドリまたは直感的に）、マネージャーがパニックして、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスを行うのに慣れているなどの理由で」削除するように求められます。あなたは、変化、改善、革新に対する抵抗のポイントを得たと思います（開発者としてあなたが利益の強い議論を提供したとしても、マネージャーは変化に対して開かれていません）。同社はこの分野でいくつかの競合他社を抱えていますが（そのうちのいくつかの製品ははるかに競争力があります）、何とかして現在の顧客を何年も維持しています。

• プロジェクト管理の調整の欠如：この結果、一部のプロジェクトがバグで遅れて配信され、一部のクライアントから苦情が寄せられたり（クライアントからもバグが報告されたり）、プロジェクトの配信前に予算が早すぎたりするなど。いくつかのプロジェクト調整のヒントとアイデアが、プロジェクトと実行するタスクの進捗を追跡するために定期的に使用されています。

• 悪いソフトウェア開発プラクティス：コードの臭いは、すべてではないにしてもほとんどのファイルに見られ、ドキュメント、コードの冗長性、フロントエンド層とバックエンドが同じファイルに混在している、古い開発ツール、実際のテスト環境もテストツールもありません（コピーアンドペーストのみ）開発環境から本番環境へのファイルを作成してから、手動でテストして問題が発生していないことを確認してリリースします）。チームがコード開発とソース管理に2つのIDEのみを使用しているため、チームが知らないところで開発とテストに使用する開発ツールのほとんどは、開発環境でのみ使用できます。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、マネージャーは「あなたが去ったら、そのコードを維持するのは誰ですか？、そのままにしておきましょう」という理由でそれを好まない去り、別の会社に移った。

要約すると、他の会社の多くの開発者にも同様の状況が起こると確信していますが、状況が異なるため、開発者は（仕事の都合、仕事の柔軟性、会社の利益、またはより良い機会が届いていないという理由だけで）。私が知っている完璧な会社はありませんが、開発者としてあなたがどのように行動し、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変更を促進するためにこれらの問題に対処しますか？長年の開発経験またはほんの数年）？これは投稿が長いことは知っていますが、より有用なフィードバックを得る可能性を高めるために、詳細を追加することを好みました。

フィードバックと時間をありがとうございました

マーティン・ファウラーの引用は関連性があります：「あなたはあなたの組織を変えるか、あなたの組織を変えることができます。」組織を変更する（別の組織で作業する）のではなく、組織を変更する（改善する）ことを明らかにしたことを考えると、いくつかの提案があります。

まず、あなたの行動の多くは、権力構造と職場の政治に関する詳細に依存しています。ソフトウェア開発マネージャーは1人ですか、それとも複数ですか？複数ある場合、変更を嫌う人はいませんか？ソフトウェア開発者は何人いますか？開発者は変化に興味がありますか？その場合、管理者の承認がなくても変更できるいくつかの変更があります。（リファクタリングでFowlerが示唆しているように、経営陣に伝える必要さえないかもしれません。ソフトウェアをできる限り開発するために雇われていると思われます。

第二に、経営陣は彼らが何をしているのかについて正当な理由があるかもしれないことに留意してください。あなたはソフトウェア開発者です。あなたの仕事は、優れたソフトウェアを開発し、そのための優れたテクニックを知ることです。経営陣の仕事は、全体像を超えた大きな問題とビジネス上の考慮事項を理解することです。あなたが正解で、ビジネス上の考慮事項（イノベーションの欠如、納期の遅れ、顧客からの苦情など）について彼らが間違っている場合でも、経営陣がどこから来ているのかを理解することは、彼らの言葉でコミュニケーションを取り、軽減するのに役立ちます彼らの懸念など。

3番目（および関連）、ビジネスの言語を話せることを確認します。ビジネスは（当然）優れたソフトウェア開発プラクティスに直接関係していません。企業は顧客のニーズに応え、利益を上げることに関心があります。（そして、多くの企業が利益を得るために可能な限り最小限のニーズに応えることは明らかです。）ソフトウェア開発の慣行が悪く、イノベーションがないと企業の利益や長期的な影響がどのように損なわれるかを説明できれば、変化をより効果的に促進できます健康。

第4に、会社の文化を一般従業員の立場から変えることは非常に困難です。James Shore（アジャイルコンサルタントおよび著者）は、それを行うための彼自身の努力を説明するChange Diaryを書きました。すべてを読むことを強くお勧めします。関連するポイント：

• 一度にすべてを変更しようとしないでください。最大の問題点を見つけて、そこから始めましょう。あなたの変更がそれらの痛みのポイントにどのように対処しているかを彼らが助けるのを助けて、全員を乗せてください。
• 他人の視点を理解する。Shoreは、ソフトウェア開発の観点からプッシュしている変更がプロジェクトマネージャーによってどのように抵抗されたかについて話します。なぜなら、彼（Shore）は、変更がプロジェクトマネージャーにどのように影響するかを考慮できなかったためです。
• 最終的に、あなたが必要になりますいくつかの変更内容を自分のほとんどを促すている場合でも、高いアップからの支援を。ショアは彼のチャンピオンについて話します（「私と一緒に仕事をしている人で、私よりも影響力があり、一般的に私と同じ考え方をしている人」）。

明らかに短い答えは、会社を辞めることです。他の人たちはすでに去っていて、あなたのマネージャーは進行を妨げる積極的な障害です。その位置にとどまると、ゆっくりと衰退します（士気とスキルの両方で）。新しい仕事を見つけるのは必ずしも簡単ではありませんが、この場合は必要です。

会社を辞めないことを選択した場合に備えて（質問の最初の行でそれを明かしました）：

上司はいますか？もしそうなら、その上司は製品をどのように見ていますか？あなたは（あえて言うまでもありませんが）あなたの上司の頭を越えて上司に近づくことができますか？技術的な詳細を彼に言わないで、会社内で成長することに興味と熱意を表明するだけです。収益に測定可能な影響を与える改善のための具体的なアイデアを提示します。あなたは障害の下から昇進するかもしれません。

ただし、警告音が鳴ります-きしむ音がするホイールもあれば、交換されるものもあります。あなたはあなたの上司にあなたを強く嫌うでしょう。彼はこれについて聞いて、上司にあなたについて不親切なことを言うでしょう。慎重に踏みますが、覚えておいてください-リスクも報酬もありません。

起こりうる最悪の事態は、新しい仕事を探しているということです。

キャッシュカウについて学習する時が来たようですね。こことここに行く。そして、Growth Share Matrixをご覧ください。GSMは、キャッシュカウが良い状態である理由に関する追加情報を提供します。

この場合、Investopedia（2番目のリンク）がおそらく最高の引用を持っています。

1. キャッシュカウは投資資金をほとんど必要とせず、企業内の他の部門に割り当てられる正のキャッシュフローを永続的に提供します。これらの現金ジェネレーターは、市場で株式を買い戻したり、株主に配当を支払ったりするためにお金を使うこともあります。

あなたが述べたように、現金牛プロジェクトにいることにはいくつかの利点があります。

• 安定しています
• 適度な新規開発が保証されます
• 取り組むには常にバグ修正作業があります。

また、ご指摘のとおり、これらのプロジェクトにはいくつかの欠点があります。

• それは安定しており、コードベースはあまりひっくり返りません
• 通常、新しいテクノロジーは無視されます（ボルトで固定するには高すぎます）
• そして物事は...古くなってしまいます。

私はかつてあなたが提起したものと同様の多くの不満を抱えたプロジェクトに取り組んだことがあります。当時、上司とコードベースに関する懸念を共有したことをはっきりと覚えています。彼の洞察は特に啓発的ではなかったので、私はそれを共有しません。しかし、私はプロジェクトを突き出して、真実が言われました、それは私が見たより良いプロジェクトの1つでした。いいえ、派手ではありませんでした。はい、締め切りに間に合いませんでした。はい、私はそこからいくつかの死の行進を準備しました。いいえ、コードテクノロジーはそれほど革新的ではありませんでしたが、いくつかの素晴らしいソリューションを生み出しました。

問題は私だった。コードベースが生き残るために本当に必要なものを理解するのに十分な視点を持っていませんでした。イノベーションが本当に起こっているのかを知る経験はありませんでした。私は、その現金牛プロジェクトの資金調達の適切なレベルを決定する市場の基礎を理解していませんでした。

これを、ビジネスのしくみと、製品をビジネスのニーズに適応させるスキルを向上させる方法をよりよく理解するための学習の機会とみなすことをお勧めします。仕事は派手ではないかもしれませんが、学習の可能性は高く、それらのスキルはあなたのキャリアの後半であなたをしっかりと支えます。企業レベルの開発の大部分は、先ほど述べたすべての制約を中心に展開します。コードは悪臭を放ちます。すでに逃げた期限を含めるために、物事は所定の位置に平手打ちされました。多くの開発者は変化に抵抗しています。

ある時点で、プロジェクトから先に進みます。あなたがあなたと一緒に取ることができるレッスンは、レッスンを作る本当のキャリアでありえます。

あなたのマネージャーはおそらく、変化することに抵抗があります。なぜなら、彼はプラクティスを変えることは（ビジネス）価値がないと見ているからです。開発チームに求められたことが最終的に行われ、クライアントの苦情がより良い結果を確実にするために何かをするか、またはできる人に届かないため、ビジネスは実際の問題を認識しません。それまたはビジネスのいずれかが、現状を避けられないものとして受け入れるようになりました。

開発プラクティスを変更する場合は、現状を避けることができないことを示す必要があります。そして、あなたが聞かれる唯一の方法は、現在の情勢がどのように製品のコストを使い果たしているかを示すビジネスケースを構築し、別の情勢が与えられると収益の可能性を抑えることです。

そのビジネスケースを作成するには、このソフトウェアのプロダクトマネージャーに相談する必要があります。プロダクトマネージャーは、アイテムが表すビジネス価値に基づいて開発されるアイテムの優先順位を決定する人です。プロダクトマネージャーは、より優れたソフトウェアをより迅速に構築できることの利点とビジネス上の価値を理解できる人です（そうあるべきです）。（そして、それが開発チームを担当しているものと同じではないことを願っています。）

このビジネスケースでは、次のビジネス収益に対する影響を検討する必要があります。

• （まだ）実装されていない機能で、実装された場合により多くの顧客を生成するか、より多くの顧客を保持します。
• 顧客の不満を生み、顧客の減少につながる不適切に実装された機能。

また、ビジネスケースでは、現在の開発手法が、多くの必要な機能の開発の速度とコストにどのように影響しているかを示す必要があります。

• 最も簡単な変更を加えるのにかかる時間。
• 新機能の開発の結果として導入されたバグの数。新機能と他の機能の付随的な損傷の両方。
• 新機能の実装に費やせないこれらのバグの修正にどのくらいの時間がかかりますか。
• これらのバグのために生成されるサポートコールの数と、これらのコールに費やす必要があるサポートスタッフの数。

そしてもちろん、より良い開発手法を採用することがこれらの数値にどのように影響するかを示す必要があります。

おそらく、ソフトウェアの（主要な）部分の（主要な）書き換えの必要性に直面しています。そうしなくても、正気を失わずにゼロから書き直す方法は、これらの種類のプロジェクトへのアプローチ方法で読む必要があります。

最後に、プロダクトマネージャーがこれらすべてに関心がない場合は、迷ってしまいます。ジャンプシップです。

これは、直接的な解決策がない、本当に難しい問題だと思います。あなたが何をしようとしているかについてのいくつかのアイデアを以下に示します。

変化の恐怖 より良く物事を変えるというテーマで、経営者が変化を恐れる理由を理解します。人々は特定の方法で物事に慣れており、それを変更するとユーザーは反乱します（多分）。変更は怖いものであり、通常、実行する前に多くの思考と研究が必要です。必要なのは、これがより優れており、ユーザーがそれを望んでいることを示すデータです。gmailと言えば、「Google Labs」のようなものを検討するかもしれません。そこでは、ユーザーが試してみることができるように、新機能を有効/無効にすることができます。次に、これに関連するいくつかのデータ収集を接続して、変更をバックアップします。

ソフトウェア開発プロセスの 変更ここでも、より良い方法があると言うので、人々が変化するのは難しいだけではありません。このシナリオで、私の一番の推奨事項は、例を挙げてリードすることだと思います。あなたがそれらをやりたいと思うように物事を行い、それがどれほど優れているかを人々に示します。また、これが重要です。あなたの考えを共有する他の人を見つける必要があります。数人の人を乗せることができれば、あなたの大義に大いに役立つでしょう。いくつかの結果を表示できるようになったら、これらの変更を広くすることについて管理にアプローチできます。トップダウンと草の根の努力は、実際に変更を加えるのに役立ちます。

また、ツール側では、コストがかかり、新しいツールの結果が常に測定できるとは限らないため、企業はこれらのアップグレード/変更を恐れています。ここでの私の推奨事項は、独自のツールを作成することです。自分で作れば、時間を節約し、より良い仕事をすることができます。うまくいけば、人々が気づき始めて、それを使いたいと思うでしょう。

管理の変更 これは難しいことであり、結果を生み出し、意見を評価される人物であることを別にすれば、どうすればよいかわかりません。あなたの意見が評価されると、人々は耳を傾け始めるかもしれませんし、耳を傾けないかもしれません。

最後に、変更は難しく、時間がかかることを忘れないでください。そこにハングアップし、小さく開始し、構築します。