大規模なソフトウェアプログラム（200人のエンジニア）が、機能を測定するときに人々に環境を修正させるための戦略は何ですか？
私は金融サービスの大規模なソフトウェアプログラムに取り組んでいます。 （15人のプロジェクトマネージャー、20人の技術リーダー、15人の環境、150人の技術者）。
私たちは、開発環境では頻繁にダウンしている何百ものシステム（保険、請求書支払い、投資信託、保険、税務報告、株式取引など）への銀行全体の統合を多数行っています。環境チームは存在しますが、基本的にはシステム管理者であり、Java Leadが問題の根本原因を特定して修正するための支援を必要とします。
以前に取り組んだ小規模なチーム（投資基金システム）では、単一のPMが本番環境に至るまで一連の環境を所有し、特定の障害を取り除く責任があります）制作に至るまですべての機能を備えています。
この大規模なプログラムでは、プロジェクトマネージャーはこの責任から抜け出すパターンを持っています。修正環境でのそれらのためのポイントはありません。さらに、技術リードは、機能を出荷していない何かに取り組んだことで非難されます。
テスターは3分の1の時間でシステムにログインできないため、テストマネージャーは手を挙げます。
さて、私が質問に言い表した方法は、「人々が測定される方法を良く変える！まぁ！このインセンティブを生み出す、人々が測定される具体的な方法を明確に述べることができれば、私はそれを聞きたいと思っています。残念ながら、物事はそれほど単純ではありません。プロジェクトマネージャーはソフトウェアの出荷に専念し、カンバンボードは全員の使用率の出荷ストーリーを表示するため、出荷される使用率とストーリーポイントを最大化するインセンティブがあります。
これで、情報ラジエーターを利用してすべてのストーリーをブロックされたものとして表示できますが、その状況で返される答えは、「それを他の誰かの問題にする、」の代わりに「時間をかけて解を見つけ、それが二度と起こらないように修正します。」
別の議論は、この種のものはそれ自身を整理するということです。痛みを感じる人は問題を解決するために時間を費やす必要があります。興味深いことに、これは、利用率を下げるためにPM）によって叩かれるのを止めません。
私はそれをプログラムのトップに持ち込み、シンプルな「ウォッシュアップロスターシステム」を提供することを検討しています。これにより、1週間に1日、1組のPM/Tech Leadが環境を修正します。これに関して私が持っていたフィードバックは、プログラムの責任者がこれらの問題を無視するか、または「あなた-これを廃止する！」という短期的な運用上の責任を解雇するのに便利だと感じていることです。問題について戦略的に考える代わりに。トップに立つのは、基本的に火遊びです。
テストマネージャーのところに行って、プログラムの責任者と話をするように依頼すると、「プログラムの責任者は、戦略的思想家ではなく運用者です。体系的または中期的な修正には関心がありません。」
私の現在の考えは、ダウンしている環境に関連する書き込みレートコストについてテストマネージャーから同意を得て、それを自動可用性レポートにリンクすることです。 （システムのさまざまな部分のアップとダウンのグラフを示すレポートがあります）。このようにして、修正するコストと修正しないコストについて議論することができます。問題は、それが人々を財政的に悪く見えるようにすることに依存しているので、これが反応を誘惑しているということです。
私の質問は：人々が機能で測定されているときに人々に環境を修正させるための大規模なソフトウェアプログラム（200人のエンジニア）の戦略は何ですか？
編集：これまでのフィードバックは非常に建設的で役立つものでした。ありがとうございます。環境問題とは何かという疑問が提起されました。これらには以下が含まれますが、これらに限定されません。
- プライマリ統合および顧客のWebサーバーがメモリ不足です
- プライマリ統合Webサーバーがキャッシュをロードしていません
- プライマリ統合Webサーバーが起動に失敗し、ログインページが表示されていません
- プライマリー統合Webサーバーが、Tivoliアクセス管理システムのシステムの外にあります
- 複数の衛星システムの1つがダウンしています（メール、明細書、手数料、株式取引、ユーザー設定、1日の終わり）
- プライマリデータベースがダウンしているか、実行速度が遅い
広い意味では、システムの変化率は、同じ問題が発生するのではなく、新しい問題である可能性が高いほど高くなっています。
誰かがこれらを体系化し、それらの発生を測定することを提案しました。 Wikiで問題と根本原因をリストしたいくつかの「軽量ランブック」イニシアチブに進みました。より有毒なPMは、これを使用率の失敗と見なします。
役に立った人が完了の定義について質問しました。現在、これはDEV/QAテストに合格するソフトウェアとして定義されています。 （つまり、SITテストフェーズ、UATテストフェーズ、およびパフォーマンステストフェーズの前）。
どのような問題に直面しているかによります。 「環境の修正」はややあいまいであり、問題を説明する際の精度の欠如自体が解決するのが難しい理由である可能性があります。問題が不明な場合は、修正の責任者も不明です。
知覚された問題を、再現手順などを使用して具体的に説明された問題に分割する必要があります。次に、他のすべての開発タスクと同様に、優先順位付けされ、スケジュールされた問題を取得します。問題がQAの大規模なダウンタイムを引き起こす場合、ダウンタイムはかなりコストがかかるため、修正の優先順位を付けるのは簡単です。 （少なくとも管理が半分合理的である場合。そうでない場合、組織にはこのフォーラムの範囲外の管理上の問題があります。）
ダウンタイムが頻繁にバグを導入するソフトウェアリリースに起因する場合は、「完了の定義」を再定義する必要があります。開発環境をクラッシュさせる機能は「完了」していません。
あなたの例を見ると、それは[〜＃〜] qa [〜＃〜]がここにあなたの友達である（またはそうでなければならない！）何らかの理由で開発環境がダウンしているか応答しない場合、機能はnotをQAで受け入れる必要があります。開発が機能主導の場合、QAが受け入れる前に機能が提供されたと見なされないため、誰もがこれらの問題を修正するインセンティブを持っています。
ポイントの2つは特別な考慮を要求します：
データベースが遅い。データベースは機能しているが遅い場合、QAが機能を受け入れる必要があるかどうかは明らかではありません。ここでは、システムのパフォーマンスの受け入れ基準を定義する必要があります。例えば。 「[OK]ボタンを押してから2秒以内に応答画面が表示されます。」.
外部システムがダウンしています。まあ、それを制御することはできません。 SLAを調べて、強制的に問題を修正できることを確認する必要があります。それが繰り返し発生する問題である場合は、代替策を見つけるか、システムのフォールトトレランスを強化する必要があります。
私が見た中で最高の戦略は昔ながらのものです。
OP部門を雇い、サーバーを稼働させ続けることを彼らの仕事にします。
確かに、これは開発者がすべてをしなければならない、そしてしたいスタートアップでは機能しません。しかし、それは、コードを書くだけの「作業単位」の開発者を雇いたいと考えている大規模なシステムを持つ大企業で非常にうまく機能します。
代替案は、開発/テスト環境の診断と修正を行う全仕事の退屈な上級開発者になってしまうようです。