パッチは顧客にとって悪い兆候ですか？[閉まっている]

オフィスでは、あまりにも頻繁にパッチをリリースしていた長い期間を抜け出しました。その期間の終わり近くに、私たちは平均して週にほぼ3つのパッチを実行していました。

これは開発者にとって非常にやる気を起こさせることに加えて、私は顧客がこれについてどう思うだろうかと思っていました。私は自分で質問をし、頻繁に更新されるソフトウェアを知らなかったと結論付けました。ただし、最も近いケースについては、パッチはかなり迅速に適用されるため、あまり気にしません。

これらのパッチを受け取った顧客は、互いに大きく異なります。他の人があまり気にしないパッチを本当に待っていた人もいましたが、全員同じパッチを手に入れました。顧客のソフトウェアを更新する時間は30秒未満なので、時間に関する問題はないと思います。ただし、ログアウトする必要があります。

より詳細に私の質問：更新プログラムを頻繁に受信者に「否定的な」メッセージを与えていますか？

もちろん、顧客に尋ねることはできますが、私はその立場にいるわけではなく、「眠っている犬を目覚めさせたい」とも思いません。

PS：質問を改善するためにできることがあれば、コメントを残してください。

コンピューティングの多くのものと同様に、それは依存します。パッチが新機能または改善に対する顧客の要求に対する応答である場合、会社は応答性があると見なされます。一方、パッチがバグレポートへの応答である場合、会社は無能であると見なされます。

顧客のソフトウェアをテストすることは、誰が何を言おうと、バグを検出する最も費用のかかる方法です。それは誤った経済です。あなたが得ていると思う自由な労働は、顧客サービスの努力、ソフトウェア開発のライフサイクルを壊し、顧客の信頼を失うことによって相殺される以上です。

いくつかのパッチを近距離でリリースすることは、会社にあまり反映されていないように感じます。開発者が無能であるか、経営陣が彼らが何をしているのかわからないということを、彼らが前もって十分に十分にテストしていないように常に感じさせます。

とはいえ、トークンの反対側は、いくつかのパッチを互いに近くにリリースすることは、同社が製品に対して積極的に取り組み、消費者向けに製品を改善し続けていることを示しているということです。

私は前者が消費者の観点からそれを最もよく見る方法であると思う傾向がありますが、彼らと直接話すことは（明らかに）最良の選択ですが、顧客ベース内で彼らがかもしれない問題を提起するでしょう最初は認識していませんでした。

ますます多くの企業がChromeの足跡をたどり、より頻繁に顧客をリリースしています。

短いリリースサイクルを実装するための前提条件は痛みのないアップグレードです-たとえば、クロムでは、アップグレードはアプリケーションの起動時にユーザーの介入なしで行われ、ユーザーがアプリケーションを常にオンにすると、マイナーフラグが表示されます都合の良い時間にアプリケーションを再起動するようにアドバイスすると、アプリケーションは再起動後に以前の状態に戻す努力をします。

この方法では、すべての更新を意識する必要がなく、機能リリースが頻繁に発生するため、バグ修正リリースも大歓迎です。

一方で、パッチが致命的なバグを目立たせてから来て、それらがクラスタになった場合、以前のものはバグの修正に失敗したか、より大きなバグを作成したため、顧客はそれを嗅ぐことを安心してください。これは、間違いなくベンダーの専門家としての評判にほとんど反映されず、ベンダーが認知しているソフトウェア標準を低下させます。継続的デリバリーは、効果的な単体テストと統合テストに大きく依存して成功を保証します。

「眠っている犬に嘘をつく」ために顧客と話さないことについては、これは間違った戦略だと思います。顧客は盲目ではなく、愚か者でもありません。顧客との良好なコミュニケーションは、彼らがあなたの優先事項であり、あなたが彼らの批判を受け入れていることだけを彼らに安心させることができると信じています。悪いリリースを数回配信していて、彼らが不満を言うのを聞いていない場合-あなたは間違いなく心配する必要があります-それは彼らが気付いていないということではなく、おそらくあなたのために代わりを見つけるのに忙しいだけです...

問題を検出した顧客向けのパッチは、明らかにできるだけ早くリリースする必要があることは明らかです。

大企業でソフトウェアを見て、他の顧客が定期的に定期的にこれらのパッチをサービスパックとして入手するというアプローチをとってきました。通常、パッチは顧客環境にインストールしてテストするのにある程度の労力を必要としますが、場合によっては、懸念している影響の可能性のある影響を軽減するために使用できます。

また、リポジトリまたはWebサイトでパッチを作成し、顧客が必要なパッチをダウンロードしてインストールできることを提唱する人もいます。これにより、顧客がどのパッチを持っているかを知ることで問題が発生する可能性があります。そのため、問題について問い合わせる場合は、実行しているコードを正確に判断する必要があります。その後、多くのパッチがバンドルされた「パック」がリリースされたときに、より大きな「パック」のいずれかにアップグレードするように人々に強制することができます。

例外はセキュリティパッチです。ワシントンを拠点とする大手ソフトウェア会社は、重要なセキュリティパッチをリリースする前に月の第3木曜日を待ってお湯に入ることで知られています。

Googleクロムは、非常に頻繁に自動更新することで問題を回避します。また、プログラムを循環させる必要があります（クロムを再起動するか、場合によってはログアウトします）。彼らは現在、ブラウザの通常の慣行を行っており、人々はもはやそれについて考えさえしません。しかし、誰もがGoogleになれるわけではありません。

SaaSアプリケーションは、バックグラウンドで更新を行うことにより、問題全体を回避します。

ただし、何よりも、継続的な統合を行ったり、新しいユーザーが要求する機能を頻繁に更新したりしない限り、リリース前に十分な量のテストを行うことを期待している時期にあると思います。顧客に会い、バグ修正の頻度について話すのが恥ずかしい場合は、おそらく十分なテストを行っていません。コードをリリースする前にどれだけのリスクを冒していたかをリリースしましたか。それが何であるかを知っている限り、非常に初期のバグのあるコードをリリースするという議論がありますが、既知の品質をよく理解する必要があると思います。つまり、品質を知るための時間を理解し、管理する必要があります。