彼らのチームが何年もの間製品の革新に欠けていて、プロジェクト管理方法論を使用しておらず、悪いソフトウェア開発プラクティスを維持しているときに、開発者として何をすべきか？
何年も変更されておらず、最終的には製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、具体的な例があり、同じ状況で複数回見たことがある場合、これらの問題に対処する最善の解決策は退職することであると考えている場合は、回答をサポートしてください。重要なのは、この質問には本当に答えがあり、特にその主題に関する複数の専門家が最終的に最適なルートがルートAであると示している場合です。
多くの開発者が同じような状況にあった、またはそうなったことを知っています。これが、企業が市場で第1位であったことから、市場で最後になり、場合によっては市場から外れることになる主な理由の1つです。うまくいけば、この投稿の回答が同様の障害に直面している他の開発者を助けることになるでしょう。小規模または大規模な開発チームでは、通常これが発生します。
- 一部の開発者は、気にせず、フローに進むことを決定し、多くのコードをそのままにして、開発プロセスをそのままにしておくことを好むようです。
- 変わらないことに飽き飽きして辞任して別の会社に移る人もいます。
- 他の人は話すことを恐れて、静かにいることを好むようです、
- 時には、ごく少数の開発者または1人の開発者が製品の改善のために声を上げようとし、チームに、コーディングのベストプラクティスに従うこと、およびクライアント、ユーザー、チームにとってそうすることの利点をいかに重要であるかを伝えます。これらのタイプの開発者は、通常、会社が提供するメリットが非常に少ないソフトウェア会社、または製品に多くの可能性があるなどの理由により、チームにとどまることを決定します。
私たちのチームの製品は、製品の傘があるため、会社が収益を得る場所のほんの一部です（この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、一定の特許訴訟はなく、雇用を生み出しています。不安定）。ここ数年の間に私が他の開発者の経験から学んだことと、私の経験は、開発チームを本当に知るためには、数日または数週間ではなく数か月かかるということです。面接プロセス中に、チームがあなたを雇いたい場合、またはあなたを必要としている場合;彼らはすべてを素晴らしい音にし、あなたが聞きたいものをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コード内を掘り下げ、完全なSDLCプロセスに移行するときは、現実は異なります。これは、開発者として、あなたが入った仕事の現実を見始めるときです。この現実は、ある会社から別の会社に移動することを難しくします。なぜなら、移動先の会社が良いか悪いかを知ることは難しいからです。はい、Glassdoorのレビューなどを読むことはできますが、HRからではなく、実際にオンラインのレビューがいくつありますか。
最初からマネージャーが常に変化に抵抗し、以前の開発者が同じことを何年も続けてきたことを考えると、以下に概説する問題に取り組むための最良の方法は何でしょうか？
長年の製品革新の欠如：製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に製造されたように見えます。一部のユーザーは、製品がユーザーフレンドリーでも直感的でもないことに不満を抱いており、他のユーザーは、Gmailなどのアプリに慣れていて、同様の機能がないために製品を使用するときに不満を感じると述べています。ここでの主な問題は、開発者が製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると（よりユーザーフレンドリーまたは直感的に）、マネージャーがパニックになり、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスをそのように実行することに慣れている」などの理由で、マネージャーから削除するように求められます。変更に対する抵抗のポイントを得たと思いますが、改善と革新（開発者としてあなたが利益の強力な議論を提供するときでさえ、マネージャーは変更に対してオープンではありません）。同社はこの分野でいくつかの競合他社を抱えています（そのうちのいくつかの製品ははるかに競争力があります）が、同社は何とか現在の顧客を何年も維持しています。
プロジェクト管理の調整の欠如：この結果、一部のプロジェクトが遅れて配信され、バグや一部のクライアントが不満を抱く（クライアントもバグを報告する）か、プロジェクトを配信する前に予算が速すぎます。いくつかのプロジェクト調整のヒントとアイデアは、プロジェクトの進捗状況と実行するタスクを追跡するために定期的に使用されています。
悪いソフトウェア開発慣行：すべてではないにしてもほとんどのファイルでコードの臭いが見られる、ドキュメントがない、コードの冗長性、同じファイルにフロントエンド層とバックエンドが混在している、古い開発ツール、実際のテスト環境もテストツールもない（コピーして貼り付けるだけ）開発環境から本番環境にファイルを送信し、手動でテストして、問題がないことを確認し、リリースします）。チームがコードの開発に2つのIDEのみを使用し、ソース管理は開発環境でのみ利用できるため、私が開発およびテストに使用する開発ツールのほとんどは、チームでは不明です。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、「あなたが去れば、誰がそのコードを保守するのですか？それをそのままにしましょう」という理由で、マネージャーはそれを好みません。離れて別の会社に移動しました。
要約すると、他の会社の多くの開発者にも同様の状況が発生すると確信していますが、状況が異なるため、開発者は（仕事の便宜、仕事の柔軟性、会社のメリット、またはより良い機会が到着していないからです）。私が知っている完璧な会社はありませんが、開発者としてこれらのすべての問題に対してどのように行動し、アプローチして、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変化を促進しますか（多くの年の開発経験またはほんの数）？ 私はこれが投稿が長いことを知っていますが、より有用なフィードバックを得る可能性を高めるために、追加の詳細を提供することを優先しました。
あなたのすべてのフィードバックと時間に感謝します
マーティンファウラーの引用が関連しています。「組織を変更することも、組織を変更することもできます。」組織を変更する（別の組織で作業する）のではなく、組織を変更する（それを改善する）ことを明らかに決定した場合、いくつかの提案を次に示します。
まず、あなたの行動方針の多くは、権力構造と政治の詳細に依存しています。ソフトウェア開発マネージャーは1人ですか、それとも複数ですか？複数ある場合、変化を嫌わない人はいますか？ソフトウェア開発者は何人ですか？開発者は変更に興味がありますか？その場合、管理者の承認がなくても行えるはずの変更がいくつかあります。 （ファウラーが示唆しているように リファクタリング 、あなたは経営者に伝える必要さえないかもしれません。あなたはソフトウェアをできる限り開発するために雇われていると思われます。そのため、より良い方法がある場合は、それを実行してください。）
第二に、経営陣が行っていることには正当な理由があるかもしれないことを覚えておいてください。あなたはソフトウェア開発者です。あなたの仕事は、優れたソフトウェアを開発し、そのための優れた手法を知ることです。経営者の仕事は、あなたの視野を超えている可能性のある全体像とビジネス上の考慮事項を理解することです。ビジネスの考慮事項（イノベーションの欠如、納期の遅れ、顧客からの苦情などに関する懸念）が間違っていても、経営陣がどこから来ているのかを理解することで、彼らの言葉でコミュニケーションがとれ、緩和されます。彼らの懸念など。
3番目（および関連）、ビジネスの言語を話せることを確認してください。企業は（正しい）優れたソフトウェア開発手法に直接関係していません。企業は顧客のニーズに応え、利益を上げることに関心を持っています。 （そして、多くの企業は明らかに利益を上げるために必要最小限のサービスを提供します。）悪いソフトウェア開発実践と革新の欠如が会社の利益または長期にどのように害を及ぼすかを説明できれば、変化を促進するのにより効果的になります。健康。
第四に、企業文化を一般労働者の立場から変えることは非常に困難です。ジェームズショア（アジャイルコンサルタントおよび著者）は、 Change Diary を書いて、そうするための彼自身の努力を説明しました。全体を読むことを強くお勧めします。いくつかの関連ポイント：
- すべてを一度に変更しようとしないでください。最大の問題点を見つけて、そこから始めましょう。変更がこれらの問題点にどのように対処するかを確認するのを手伝って、全員を参加させる。
- 他人の視点を理解する。ショアは、彼（ショア）が変更がプロジェクトマネージャーにどのように影響するかを検討しなかったため、ソフトウェア開発の観点から彼が押していた変更がプロジェクトマネージャーにどのように抵抗されたかについて語っています。
- 最終的には、 いくつか ほとんどの変更を自分で促している場合でも、上位からのサポート。ショアは彼の チャンピオン について話します（「私と一緒に仕事をする人で、私よりも影響力があり、私がするのと同じように一般的に考えている人」）。
明白な短い答えは、会社を辞めることです。他の人はすでに去っており、あなたの上司は進行を妨げる積極的な障害です。その位置に留まると、ゆっくりと衰退します（士気とスキルの両方で）。新しい仕事を見つけることは必ずしも簡単ではありませんが、この場合は必要です。
会社を辞めないことを選択した場合に備えて（質問の最初の行はそれを与えました）：
あなたの上司には上司がいますか？もしそうなら、その上司は製品をどのように見ていますか？あなたも（あえて言ってもいいですか？）上司の頭を越えて上司に近づくことができますか？技術的な詳細で彼を悩ませるのではなく、会社内で成長することに興味と熱意を表明してください。収益に測定可能な影響を与える改善のための具体的なアイデアを提示します。あなたは障害物の下から昇進するかもしれません。
ただし注意してください-きしむホイールにはグリースが塗られているものもあれば、交換されているものもあります。あなたはあなたのマネージャーにあなたを強く嫌います。彼はwillこれについて聞いて、そして彼はwill上司にあなたについて不親切なことを言います。注意深く踏みますが、覚えておいてください-リスクも報酬もありません。
発生する可能性のある最悪の事態は、とにかく新しい仕事を探すことです。
現金牛について学ぶ時が来たようです。 here および here に移動します。 Growth Share Matrix を見てください。 GSMは、キャッシュカウが良い状態である理由に関する追加情報を提供します。
この場合は、Investopedia（2番目のリンク）がおそらく最も良い引用です。
- キャッシュカウは、投資資本をほとんど必要とせず、企業内の他の部門に割り当てることができるキャッシュフローを永続的に提供します。これらのキャッシュジェネレーターは、自分のお金を使って市場で株を買い戻したり、株主に配当を支払うこともできます。
お気づきのように、現金牛のプロジェクトに参加することにはいくつかの利点があります。
- 安定しています
- ある程度の新規開発が保証されています
- 取り組むには常にバグ修正作業があります。
また、ご指摘のとおり、これらのプロジェクトにはいくつかの欠点があります。
- それは安定していて、コードベースはあまり引き渡さない
- 新しいテクノロジーは一般に無視されます（ボルトオンするには高すぎる）
- そして、物事は...古くなります。
私はかつて、あなたが提起したものと同様の不満がたくさんあるプロジェクトに取り組みました。当時、コードベースに関する懸念を上司と共有したことをはっきりと覚えています。彼の洞察は特に啓発的ではなかったので、私はそれを共有しません。しかし、私はそのプロジェクトを開始し、正直なところ、それは私が見た中でより優れたプロジェクトの1つでした。いいえ、派手ではありませんでした。はい、締め切りに間に合いませんでした。はい、そこから数人の死の行進を行いました。いいえ、コードテクノロジーはそれほど革新的ではありませんでしたが、いくつかの驚くべきソリューションを生成しました。
問題は私です。コードベースが生き残るために本当に必要なものを理解するのに十分な視点がありませんでした。イノベーションが実際にどこで発生しているかを知る経験はありませんでした。その現金牛プロジェクトに適切なレベルの資金がどのようなものであるかを規定する市場の基礎を理解していませんでした。
これを、ビジネスがどのように機能し、製品をビジネスのニーズに適合させるスキルを向上させることができるかをより深く理解するための学習機会として見ることをお勧めします。仕事は派手ではないかもしれませんが、学習の可能性が高く、それらのスキルはあなたのキャリアの後半にあなたを立たせるでしょう。企業レベルの開発の大部分は、今述べたすべての制約を中心に展開します。コードは悪臭を放ちます。すでに脱出していた締め切りを封じ込めるために、物事はその場で平手打ちされた。多くの開発者は変更に抵抗しています。
ある時点で、プロジェクトから移動します。あなたが持ち去ることができるレッスンは、レッスンを作る本当のキャリアになることができます。
あなたのマネージャーはおそらく変化に抵抗します。なぜなら彼は（ビジネスの）価値が実践を変えることに気づいていないからです。開発チームに求められたことは最終的に完了し、クライアントの不満は、より良い結果を保証するために世話をしたり、何かをしたりできる人には及ばないため、ビジネスには本当の問題はありません。それか、企業は現在の状況を不可避として受け入れるようになった。
開発慣行を変更する場合は、現状が不可避であることを彼らに示す必要があります。そして、聞かれる唯一の方法は、現在の状況が製品のコストをどのように増やしているかを示すビジネスケースを構築し、別の状況での収益の可能性を抑えることです。
そのビジネスケースを構築するには、このソフトウェアの製品マネージャーと話し合う必要があります。プロダクトマネージャーとは、ビジネスバリューに基づいて開発するアイテムの優先順位を決定する人です。製品マネージャーは、より優れたソフトウェアをより迅速に構築できることのメリットとビジネス価値を（（== --- ==）で確認できるものでなければなりません）（そして私は開発チームが担当するものと同じではないことを願っています。）
ビジネスケースでは、以下のビジネス収益にどのような影響があるかを説明する必要があります。
- （まだ）実装されていない機能で、実装すると、より多くの顧客を生み出したり、より多くの顧客を維持したりするもの。
- 顧客の不満を引き起こし、顧客の消耗につながる不適切に実装された機能。
また、ビジネスケースでは、現在の開発手法が、非常に必要な機能の開発の速度とコストにどのように影響しているかを示す必要があります。
- 最も単純な変更を行うのにかかる時間。
- 新機能の開発と他の機能の付随的な損傷の両方の結果として導入されたバグの数。
- 新機能の実装に費やせないこれらのバグの修正にどれだけの時間がかかるか。
- これらのバグが原因で生成されるサポートコールの数と、これらのコールに費やす必要のあるサポートスタッフの数。
そしてもちろん、より良い開発手法の採用がこれらの数値にどのように影響するかを示す必要があります。
おそらく、ソフトウェアの（主要な）部分の（主要な）書き換えの必要性に直面しています。そうでない場合でも、 正気を失わずに根本的な書き換えを生き残る方法 は、これらの種類のプロジェクトへのアプローチ方法の必読です。
最後の注意：プロダクトマネージャーがこれらすべてに興味がない場合、あなたは迷っています：ジャンプ出荷。
これは直接的な解決策がなく、本当に難しい問題だと思います。ここにあなたがしようとするかもしれないことに関するいくつかのアイデアがあります：
Fear of Change物事をより良く変えるというテーマで、経営者が変化を恐れる理由がわかります。人々は特定の方法で物事に慣れており、それを変更するとユーザーは反抗するでしょう（たぶん）。変化は恐ろしいものであり、通常、完了する前に多くの思考と研究が必要です。必要なのは、これがより良く、ユーザーがそれを望んでいることを示すデータです。 gmailといえば、「Google Labs」のようなものを検討して、ユーザーが新しい機能を有効/無効にして、ユーザーに試してもらうことができます。次に、これに関連するいくつかのデータ収集をフックして、変更をバックアップします。
ソフトウェア開発プロセスの変更ここでも変更は困難です。より良い方法があると言うので、人々は変更するだけではありません。このシナリオでは、私が最も推奨するのは、模範を示すことです。あなたが彼らにしてほしいように物事を行い、それがどれほど優れているかを人々に示しましょう。また、これが重要です。自分の考えを共有する他の人を見つける必要があります。あなたが数人を乗せることができるならば、それはあなたの大義を大いに助けるでしょう。いくつかの結果を表示できたら、これらの変更をより広くすることについて管理にアプローチできます。トップダウンと草の根の努力が実際に変更を行うのに役立つことがわかりました。
また、ツール側では、コストがかかり、新しいツールの結果を常に測定できるとは限らないため、これらのアップグレードや変更を恐れています。ここでの私のお勧めは、あなた自身のツールを作ることです。あなたがあなた自身のものを作るならば、あなたはあなた自身の時間を節約し、より良い仕事をするでしょう。うまくいけば、人々は気づき始めて、それらも使いたいと思うでしょう。
経営の変化これは難しいことであり、結果を生み出し、彼らの意見を評価してもらう人であることを除いて、それをどのように行うかはわかりません。あなたの意見が評価されると、人々は耳を傾けるようになるかもしれませんし、そうでないかもしれません。
最後に、変更は難しく、時間がかかることを忘れないでください。そこにぶら下がって、小さなものから始めて構築してください。