リスク回避環境で半厳格なリリーススケジュールを提唱するにはどうすればよいですか？

最近、私はますます私はこの職業で私の最もイライラすると士気を殺す経験の一つとして記述する必要がありますどのように悩まされてきた：を有するリリースに座ってテストされている、再テストし、上演、およびすべての意図について目的は出荷/展開する準備ができています。

単なる筋金入りのコーダーではなく、万能のソリューションガイとして、適切な変更管理の必要性を理解し、提唱さえしています。しかし最近、私たちの拠点をカバーすることと時間通りに出荷することとの間の微妙なバランスがすべて崩れ、私はそれを健全なものに戻すことにほとんど成功していませんでした。

私は、リスク回避管理を説得するのに役立つ説得力のある議論を探しています：

1. 開発チームは独自のリリーススケジュールを設定できる（またはする必要があります）-当然のことながら（1〜3か月は、Fortune 500の最大の企業を除くすべての企業にとって保守的なものです）。

2. ソフトウェアリリースは重要なマイルストーンであり、無頓着に扱うべきではありません。言い換えれば、不必要な遅延/停止は非常に破壊的であり、いくつかの重要なビジネス上の問題に対する最後の手段としてのみ考慮されるべきです。そして

3. 関係者が関与することを望んでいる（または要求している）外部（非開発/非IT）エンティティは、特に計画された出荷前の1週間前など、リリーススケジュールを満たすために開発チームと協力する責任があります日付（つまり、ユーザーのテスト/ステージング）。

上記は経験に基づいて私に当てはまる主張ですが、私は今それを証明しなければならない立場にあるようです-そのようなものが存在する場合、私はここで少し肉の何かを求めています。

固定（または半柔軟な）リリースサイクルのアイデアを経営者に「販売」しなければならなかった人は、どの議論/戦略が効果的で説得力があり、何がそうでないかについていくつかの指針を与えることができますか？明らかなスケジュールの競合と埋没費用は別として、「企業」の設定であっても、出荷が実際に重要であると主張するのに役立つハードデータ/証拠はありますか？

代わりに、スケジュールの柔軟性（週/月の期間であっても）がスケジュールどおりに出荷するよりも重要である理由について建設的な議論を聞くことができます。今私が信じるのは難しいが、彼らは私が知らないことを知っているかもしれない。

_{リリースを段階的に行っていることに注意してください。これは、実動を除くすべての段階を経て行われました。商用バグトラッカーを使用して問題を追跡し、このリリースに割り当てられたすべての問題（100％の問題）は終了しました。信じがたいことであり、それが本当に正確なポイントです-100％、機能が完全で、十分にテストされ、関係者によって承認されたリリースが、原因不明の理由で経営陣によって遅れることは意味がありませんが、それが起こったのは、それが何が起こっているのか、それが解決すべき問題です。}

Joel Spolskyは、ソフトウェア開発チームは資本（お金）を実用的なソフトウェアに変換するためのスキームであると言います。正直なところ、あなたの質問から、あなたのチームはそれが得意であるように思われます。あなたは妥当な金額の投資でまともなソフトウェアを手に入れています。

もちろん、次のステップはソフトウェアを稼働させることです。あなたの会社がそうすることを選択するまで、彼らが彼らの設備投資のリターンを収穫する方法はありません。棚に置いてすぐに展開できるソフトウェアは、ストックルームの在庫のようなものです。コストは削減され、会社の資本金はすでに使われています。機会費用もあります。あなたのグループは、他の何かではなくこのプロジェクトを行うことを選択しました。

さらに、棚に置かれた新しく開発されたソフトウェアの価値は、レストランの冷蔵庫に座っているチーズの箱の価値のようなものです。それはゆっくり腐ります。競合他社が追いつくため、その価値は低下します。また、開発者が他のことに移行するにつれて、新しいソフトウェアをサービスに投入することがより難しく、より危険になるため、それは低下します。棚に数年置いた後、実際には価値がないかもしれません。その場合、会社は開発に投資した資本を破棄することを選択しました。会社の所有者である株主は、これについて不満を抱く可能性があります。

開発者として理解しなければならないことが1つあります。あなたのソフトウェアは本当に、あなたが提案しているリリースサイクルの終わりに展開する準備ができていますか？それは準備ができていますか、それともあなたの会社が生産に投入するためにもっと多くの仕事とお金がありますか？あなたの会社は、ソフトウェアを展開するために必要なサーバーとソフトウェアのライセンスを所有していますか？作業成果物には展開計画が含まれていますか？エンドユーザーはトレーニングを受けていますか？生産データは変換されていますか？新しいソフトウェアに会社のビジネス方法の変更が含まれる場合、会社はその変更を行う準備ができていますか？新しいものが古いものと同様に機能することを確認するために、物事を並行して実行するためのスキームを作成しましたか？

これらすべてのロールアウトコストは、ソフトウェアを開発するだけのコストを簡単に削減できます。賢明なプロジェクト管理チームは、そのすべてを計画、予算、スケジュールするために最善を尽くします。あなたはその仕事をしましたか？経営陣に明確にしましたか？そうでない場合、ロールアウトを遅くするのが賢明である可能性があります。

最新のアジャイルソフトウェアのロールアウトスケジュールが、会社の他の部分が期待する変化のペースと同期していない可能性があります。エンドユーザー、つまり利害関係者は、チームがそれを生み出すことができる速度で変更を吸収できない場合があります。

管理チームが機能していない可能性もあります。あなたのチームは、会社の他の人が望まない何かを開発しましたか？あなたの新しいものは、あなたのセールスまたはプロダクションチームの一体を脅かしていますか？もしそうなら、一部の幹部は、展開するにはリスクが高すぎると言って魚雷を投下している可能性があります。あなたが最高経営責任者でない限り、あなたはそれについて何もすることができません。

あなたは、タイムリーなソフトウェアの展開について説得力のある議論を求めました。説得力のある議論が1つあります。投資収益率です。同社はこのソフトウェアに投資することを選択しましたが、現在、ソフトウェアが棚でゆっくりと腐敗しているため、投資を無駄にしています。

タイムリーな展開の第2の議論は、チームの士気です。急いで待つのは、クリエイティブな開発者が良い仕事をするように動機付ける良い方法ではありません。チームが仕事に就くのに満足していない場合、チームを失う可能性があります。

まず、このビデオをご覧ください。

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

エグゼクティブサマリー：

時間通りに、予算通りに出荷する方法は次のとおりです。時間切れまたはお金が足りなくなったら、出荷します。 それでおしまい。

ほとんどのプロジェクトが予定どおりに出荷されない理由は、誰かが「ちょうどもう1つの機能または修正」をリリースに挿入するためです。最も不足しており、今、あなたはスクランブルする必要があります。これはスラッシングと呼ばれます。これは、出荷しない限り、人々が製品を吸い取ると言うことを心配する必要がないからです。

スラッシングを解決する方法は、人々に製品開発サイクルの最後ではなく、最初にそれを強制することです。

明らかな理由により、リリース日の直前の数週間に製品を変更することは非常に混乱を招きます。これは、変更が新機能、ソフトウェア開発プロセスの変更、または開発スケジュールに含まれていない長年のバグを修正しようとする場合に当てはまります。

開発サイクルの後半で誰かが修正や変更のために私に来たとき、私は常に彼らにこう尋ねます。

お金の動機付けが必要な場合、これは次のとおりです。研究では、ソフトウェアライフサイクルの後半で機能または修正の実装を待つほど、コストが高くなることが証明されています。 指数関数的に。 これを証明するのは難しくありません。

あなたはあなたが直面している問題を明確に説明しましたが、マネージャーがこのように振る舞っている理由について私は不明瞭です。明確にできますか？たとえば、展開の準備ができていると信じていますが、だれが同意しますか？彼らは元政府のボーロクラートですか

これは、能力対欲望のアライメントの問題によく似ています。解放する意欲はありますが、能力（権限）ではなく、権限を持つ人には欲求がありません。

あなたは彼らが欲求を欠いている理由を見つける必要があります-それはマーケティング上の理由です（もう1年間古いバージョンを搾乳している間それを保ちます）、それは恐怖/自信ですか（バグがある場合、それは私たちを悪く見せます、費用がかかります....、リソースの不足（配送/梱包/ PRの費用を支払う余裕はありません）、それはあなたのいくつかの不明瞭なシンクが貧しい過剰利益に陥り、彼らがあなたがお金を稼ぐことを望まない場合ですそれは聞こえるほど愚かではありません）。

また、関係者間の軽微な敬意もあると考えられるため、合理的な大人の議論は行われていません。

申し訳ありません-あなたが求めている具体的な答えではありませんが、いくつかのことを考えてください。

最初に考慮すべきことは、あなたのリリースが高リスクにならないようにすることです。

理想的には、変更リクエストには、問題が発生した場合に以前のバージョンにロールバックする方法に関する指示を含む、リスク軽減のようなセクションが必要です。リスクに関しては、事前のテストでは、変更をロールバックする簡単なオプションを代用することはできません。

• ^{リスク回避の環境では、不可逆的な変更を無痛にする方法を想像することはできません。
  リリースの多く/ほとんどがこのカテゴリに該当する場合、アーキテクチャを再検討する必要があります。}

解放していないの危険性は、あなたが開発チームのスケジュールは真剣に扱われることをしたい場合は、露出しています。

リリースが本番/サポートの問題と停止の修正を提供している場合、これらをリストし、アップグレードしない限り本番はこれらを繰り返すリスクがあることを指摘することで、これは非常に簡単です。

開発チームがリリーススリッページと戦うために利用できる本当に効果的な手段は、リリースしないリスクが時間の経過とともに増加することを確認することです。これは、固定されたスケジュールで実行される内部リリースで実現でき、生産上の問題に対するソリューションの「累積」リストを提供します。

• 簡単に言えば、リリースをブロックしてXXいる人は、N本番の問題が未解決のままになるリスクがあることに注意する必要があるだけでなく、その週（または月）後にXX+1承認キューでリリースされ、ブロックされることをブロックする必要がありますN+M生産上の問題の種類が未解決のままになるリスクが発生します。これは、開発XX+2チームが提供する「内部」リリースにも当てはまります。

上記の方法は、本質的に、アプリケーションの更新と運用上の問題をより明確かつ明確に結び付けます。

そのため、本番問題のエスカレーションにより多く関与することが予想されます。これらを、より厳密なスケジュールされた更新のビジョンを促進する機会として使用できます。自分でエスカレーションをトリガーして、希望するアプローチを採用するプロセスをスピードアップすることもできます。

• ^{「...アプリケーションを新しいバージョン（XXまたはそれ以降）にアップグレードすることをお勧めします。現在環境にデプロイされているもの（XX-2）は非常に古く、現在のコードベースの背後にある2つのメジャーリリースです。ログに深く隠されており、解読不能なガベージは明確な失敗の説明ではなくアプリケーションによってクライアントに報告されます-ユーザーとサポート
   
  は、非常に単純な問題の調査に時間を浪費します」特定の本番インシデントに関連します。その後すぐに、「利害関係者」が開発チームに連絡して、リリースを追跡する方法と、環境への展開を支援する方法を尋ねました。ああ、彼らもすぐにアップグレードしましたXX-2バージョンも。:)}

生産のエスカレーションが発生した場合、ビジョンを迅速かつ明確に提示する準備ができています。

特定のリリーススリッページの責任者を選択して追跡することは、役に立つと思います。基本的に、「計画的なリリースが行われなかったという事実に誰が責任を負うのか」などの質問に迅速かつ明確に答えられる必要があります。あなたが準備ができていない場合、彼らは抵抗が最も少ない道を選択し、あなたに責任を置くかもしれません。別の回答へのコメントで指摘されているように、「経営者があなたを保護しようとしているお湯に浸かることができます。」

最後になりましたが、少なくとも

時間がかかります

（おそらくすでにそれを知っていますが、明示的に述べる価値があります）

何を見てすることは、「危険ですから、姿勢変化として記述することができます解放するために、」危険ですし、「解放することはありません」。態度の変化が一晩で起こることはめったにありません。シフトを完了するには忍耐が必要な場合があります。

あなたの質問に大きな疑問符がかかっています。それがあなたの会社がソフトウェアをリリースしたくない理由です。常にリスク回避の単純なケースではありません。多くの場合、他の原因が存在し、それらは管理上の高みから引き継がれないことがよくあります。あなたへの私の質問は、「あなたは上司と一緒に座って、なぜ製品リリースが延期されているのか彼に尋ねましたか？」です。

リスクの管理と回避には大きな違いがあります。製品のリリースを遅らせるための法的またはマーケティング上の理由があるかもしれません。それは、経営陣と開発チームの間の信頼の問題かもしれません。この製品は、顧客が数か月前に求めていたものであったとしても、顧客のニーズに合わない場合があります。それは、どこかで遅延のために責任をシフトしようとしている間、製品の出荷前に何かを完了するために必要な第三者による遅延でさえ、真剣にカバーしている経営者のケースでさえありえます。数十のシナリオを思いつくことができました。開発者は、明らかにされていない方程式の反対側を理解することなく、リスク回避を想定することが非常に多くあります。反対に、それは単に自己満足、企業内の個人間の対立、

いずれの場合も、製品リリースの遅延の理由に関する詳細情報を入手し、その情報を使用して、できるだけ早く製品をリリースするためのケースを作成することが重要です。はい、それは非常にイライラする可能性がありますが、上司との対立や燃え尽きを危険にさらすことなく、これらの状況に対処する他の方法があります。同様の状況で、私自身が情報を収集し、これまでの進捗を文書化し、さらに悪化した場合は、プロジェクトを棚上げして別の場所に移りました。プロジェクトをリリースに向けて軌道に乗せることができたのは、通常、提起した質問に対するフィードバックとして受け取った情報に基づいて、健全なビジネスケースを作成した結果です。製品を出荷すべきだと経営者に納得させることができなかった場合、私は、単にプロジェクトが完了し、経営陣によるリリース承認を待っているケースとして出荷することをためらうことを文書化しました。その後、管理者が承認し、理解したものとして文書に署名するようにします。そうすることで、後で非リリースで私を責めようとする場合に自分の尻が覆われます。

配送遅延が後であなたに非難されることを避けるために、あなたは常にあなたのIとTを交差させる必要があります（また、あなたがよく稼がれた潰瘍のアイデアが好きでない限り、そのような問題に過度に感情的に縛られることを避けることも重要です。特定の専門的な離婚の状況を見ると、問題からの距離を効果的に「距離」に置いているため、解決策が見つかることがあります。ケースを作成できない場合は、しばらくスライドさせる必要がありますが、そもそもケースを作成するためには、専門的に切り離されているように見え、密接に関連している情報に基づいて議論する必要がありますあなたの会社とその内部の仕組み。

私がちょうどあなたに役立つかもしれないと考えた他の何かは、おそらくリーンソフトウェア開発を読んで、あなたの会社の状況に関連するかもしれない貴重な何かがあるかどうか、特に最初のいくつかの章で見ることです。私は、できるだけ早く配達するという問題を議論し、遅延コストに関連する何かを持っているのは第4章だったと思います。

リリースを販売する最も簡単で効果的な方法は、準備ができたらしばらくツールをダウンさせることです。他のことをして、新しいプロジェクトを開始し、既存のプロジェクトのバグに取り組みます。それがドアを送り出すまで、これにこれ以上何もしないでください。

しかし、現実の世界では、実際のリリースは他の誰かの問題です。あなたはそれを彼らに出荷し、それをリリースとして扱うべきです。ドアから出たら、出荷されます。彼らがただ座っているだけなら、それはあなたの問題ではありません（実際、それは素晴らしい、バグは報告されません！w00t！バグのないリリースのボーナスはずっとあります;））

とにかく、変更管理システムとリリースマネージャーが必要です。その後、それはすべて簡単です（変更管理を管理する必要がないため、ソース管理と展開ビルドが非常に必要です。組織化が必要ですが、組織化されている場合は簡単です）。

開発チームをあなたが説明する方法でビジネスを担当することは「良いこと」だと想像することはできません。それは実際の問題を覆い隠すかもしれません等。あなたは間違った（そして潜在的に悪い）理由でリリースする危険があります。

あなたの問題を理解しているなら、あなたはプロジェクトを完了し、あなたが会社の外に誰にも見せることのできない成果物を持っています。（これがそれを要約することを願っています、私はスレッド全体を読んで、私はそれに指を置くのに苦労しています）

やってみました：

1. 開発中に利害関係者として行動する顧客または顧客のセットの管理を依頼しますか？通常、中間リリースを取得してフィードバックを提供する1人の顧客を見つけることができます。彼らは解放する時が来たら、偉大な支持者になることができます。1人の顧客への「限定リリース」でさえ、動揺管理を支援するのに十分かもしれません
2. ポイントリリースを含むリリース計画の作成。つまり、3.4.1リリースは今日+ 1か月で計画されているため、今日3.4をリリースできます。これは、リリースケイデンスがこのメッセージに役立つと既に述べた良いアイデアと一緒です。
3. あなたの側でサポート、販売、またはマーケティングを受けてください。上位3つのサポートリクエストを解決する修正を組み込み、別の部門から同盟を結成できます。＃1のように顧客の利害関係者を獲得できない場合は、数人の営業担当者で試してください。営業会議で利用できるようにし、製品を持ち込みます。あなたが外出中に、あなたが製品を持っている営業担当者に（それがどんな状態であっても）見せて、彼らにあなたを引っ張ってもらう。

「なぜ経営陣はリリースに座るのか」についての他の質問に答えるために。企業はこれをSW以外の分野で常に行っていますが、これは前例のないことだと思います。たとえば、準備が整った新しいリリースがあり、すべてがテストされ、完了しています。しかし、古いバージョンはまだ競争によって置き換えられていません。競合他社が競合製品を古いバージョンでリリースすると、管理者は棚で待機しているバージョンをリリースし、市場を混乱させ、競合を後退させ、販売と市場リーダーとしての評判を維持します。リリースが早すぎると、あなたのロードマップをよりよく理解し、エンドゲームであなたを打ち負かそうとする競合他社に手を貸すことになります。

とは言っても...ハンロンのカミソリはおそらく正しい答えです:-)

その会社から離れて、彼らはソフトウェアを理解していません。しかし、真剣に、ソフトウェアはシステムを機能させるものであり、車を作っていると想像してください、車の工場は遅いですか？彼らは車のリリースを待っていますか？彼らはインクリメンタルで官僚的ですか？いいえ、彼らは可能な限り最速かつクリーンな方法で物事をしようとします。あなたには管理上の問題があり、管理の対立としてそれに取り組む必要があり、彼らの言葉でそれらを話してみてください。リスクの意味を尋ねてから、最小限に抑えてください。開発者の感情も重要です。彼らはあなたの介入によって下される決定に対処しなければならないからです。彼らは時間通りに出荷するためにすべてのナイターをやって幸せですか？賞品/罰則はどうなりますか？それでは、この問題に対する実際的なアプローチを少し極端に説明しますが、監査をお願いします。