私がコメントを受け取っている質問は次のとおりです。
ソフトウェアリリースの増加は、効率の向上にどのように役立ちますか?
ソフトウェアリリースの頻度を増やしてもエンドユーザーとその企業に利益がもたらされない場合、なぜこれらのリリースをすべて作成するのに時間を無駄にするのでしょうか!
まず、業界の現実を説明します。
造船およびオフショア産業プロジェクトでは、作業が時間通りに完了しない場合、重大な罰則を持つことができる非常に厳しいプロジェクトスケジュールによって駆動されます。 会社の種類(設計代理店、造船所など)によって、建造物の種類(船舶、船舶の構造など)は、プロジェクトの期間と罰則が異なります。
これらの企業のベスト プラクティスは、マイルストーン間でのみソフトウェアを更新し、プロジェクトの途中ではなく、ソフトウェアを更新することです。 私は以前の記事で言及しているにもかかわらず、私はこの戦略に100%同意しますが、利益と更新のリスクは、最近の更新に向けてより傾いています。 しかし、プロジェクトの途中では、リスクはマイルストーン/プロジェクト間の移行時よりも3倍大きくなるため、追加のリスクは通常、常に新しいリリースの利点を上回ると思います。
これは、ソフトウェア製品の更新のウィンドウが数間隔に短縮されるということです。 この時点で最も機能豊富なソフトウェアバージョンを持つことは、このウィンドウが再び存在する前に、数ヶ月、おそらく1年になる可能性があるため重要です。 リリースサイクルが粗い場合は、ソフトウェアの1ヶ月または1年前のバージョンを実装する必要がある可能性が高くなります。 これにより、新しいバージョンの効率が低下する機会コストが発生します。
私がこれのために持っている最良のたとえは、あなたのタブレットをアップグレードするあなたのウィンドウが最新バージョンのリリースの数週間前だったと想像することです。 あなたはすぐにタブレットの古いバージョンになるには購入する必要があります。
私のポイントを説明し続けるために、例を通して作業することができます。 ソフトウェアのリリース スケジュールが年に 1 回 (4 月) で、その年 (5 月と 10 月) に更新する機会が 2 つあるとします。
5月には、A – Hの改善からなる4月に利用可能な最新のリリースに更新するオプションがあります。10月には新しいリリースはありませんので、5月に更新したリリースに固執します。
今、ソフトウェアのリリースがより頻繁であると仮定します。
5 月には、前のシナリオと同じ機能強化を使用して最新リリースに更新できます。 ただし、10 月の時間枠内には、追加の改善が加わったリリースに更新できます。
もう 1 つの利点 – リリースごとの機能が少ない
直感に反するように聞こえるかもしれませんが、更新の間隔が減るほど頻繁に更新できるようになりました。 これは、新しい機能が発見され、ワークフローで採用される可能性が高くなります。 私はShipConstructorの古いリリースの中には、250以上の新機能と改善があり、リストを読む人はほとんどいないと思います。 ユーザーが新しい改善点を知らない場合、SSIに時間を無駄にしていると考えます。 小規模で頻繁なリリースは、ユーザーがワークフローを使用して組み込む方が管理しやすくなっています。
閉会の挨拶
プロジェクトをルールするクライアントスケジュールに基づいて、ジョブまたはマイルストーン間に開始が存在するまで、最新のリリースを使用できなくなります。 より小さく、より頻繁な更新により、クライアントは、プロジェクトのスケジュールがそれを可能にしたときにShipConstructorをアップグレードする機会を持っています。 これにより、最新の改善点にアクセスし、次のプロジェクトで使用できるようになります。