パッチは顧客にとって悪い兆候ですか？
オフィスでは、あまりにも頻繁にパッチをリリースしていた長い期間から抜け出しました。その期間の終わり近くに、平均して週にほぼ3つのパッチを実行していました。
これは開発者にとって非常にやる気を起こさせただけでなく、顧客がこれについてどう思うかと思っていました。私は自分自身に質問し、頻繁に更新されるソフトウェアを知らなかったと結論付けました。しかし、パッチがすぐに適用されるので、最も近い場合には、私は本当に気にしません。
これらのパッチを受け取った顧客は互いに大きく異なります。他の人が実際に気にかけなかったパッチを本当に待っていた人もいましたが、彼ら全員が同じパッチを入手しました。お客様のソフトウェアを更新するまでの時間は30秒以内なので、時間的な問題はないと思います。ただし、ログアウトする必要があります。
だから私の質問の詳細：更新を受け取ると受信者に「否定的な」メッセージが頻繁に表示されますか？
もちろんお客様にお聞きすることもできますが、その立場ではなく、「眠っている犬を目覚めさせたい」とも思っていません。
PS：質問を改善するために私にできることがあれば、コメントを残してください。
コンピューティングにおける多くのことと同様に、それは状況によって異なります。パッチが新機能や改善に対する顧客の要求に対する応答である場合、会社は応答性があると見なされます。一方、パッチがバグレポートへの応答である場合、会社は無能であると見なされます。
顧客のソフトウェアをテストすることは、だれが何を言おうと、バグを検出するための断然最も高価な方法です。それは偽りの経済です。あなたが得ていると思う自由労働は、顧客サービスの努力、ソフトウェア開発ライフサイクルの破壊、そして顧客の信頼の喪失によって相殺される以上のものです。
複数のパッチを近接してリリースすることは、会社への反映が不十分だと感じています。それはいつも、彼らが十分に前から十分にテストしなかった、開発者が無能である、または経営陣が彼らが何をしているのか全くわからないような気がします。
とはいえ、トークンの反対側は、複数のパッチを互いに近づけてリリースすることで、同社が製品に対して積極的なアプローチをとり、消費者のために製品を改善し続けていることを示しています。
私は前者が消費者の観点からそれをほとんどの方法で見る方法であると感じる傾向がありますが、彼らと直接話すことが（明らかに）最良の選択ですが、顧客ベース内の問題を提起するかもしれません最初は気づかなかった。
ますます多くの企業がChromeの足跡をたどっており、顧客リリースがますます頻繁になっています。
短いリリースサイクルを実装するための前提条件は、痛みのないアップグレードです。たとえば、Chromeでは、アプリケーションの起動時にユーザーの介入なしにアップグレードが行われ、ユーザーがアプリケーションを常にオンにしておくと、マイナーフラグが表示されます。都合のよいときにアプリケーションを再起動するように彼にアドバイスし、アプリケーションは再起動後に彼を以前の状態に戻すよう努力します。
この方法は、すべての更新を意識する必要がないため、顧客を満足させます。機能のリリースは頻繁に行われるため、バグ修正リリースも同様に歓迎されます。
一方、以前のパッチがバグの修正に失敗したか、より大きなバグを作成したため、パッチが明白なショーストッパーバグの後に発生し、それらがクラスターで発生した場合、顧客は臭いを嗅ぐので安心してください。これは間違いなく、ベンダーの専門的な評判を十分に反映しておらず、ベンダーが認識しているソフトウェア標準を低下させます。 継続的デリバリー 効果的な単体テストと統合テストに大きく依存して、その成功を保証します。
お客様に「眠っている犬を嘘をつく」ように話さないという点では、これは間違った戦略だと思います。お客様は盲目ではなく、ばかではありません。顧客との良好なコミュニケーションは、彼らがあなたの優先事項であり、あなたが彼らの批判を受け入れていることを彼らに安心させるだけだと私は信じています。不良リリースを2、3回配信し、それらの不満が聞こえない場合-間違いなく心配する必要があります-彼らが気付かなかったということではありません。おそらく、彼らはあなたのために代わりを見つけるのに忙しいだけです...
問題を検出した顧客専用のパッチは、明らかにできるだけ早く公開する必要があります。
大企業のソフトウェアを見て、他の顧客がそれらのパッチを定期的にサービスパックとして定期的に入手するというアプローチをとっています。通常、パッチはお客様の環境にインストールしてテストするために多少の労力を要しますが、お客様の場合、懸念される影響の影響の可能性を減らすために使用することができます。
私はまた、顧客が希望するものをダウンロードしてインストールできるリポジトリまたはWebサイトにパッチを置くことを主張する人々を見てきました。これにより、顧客がどのパッチを持っているかを知ることで問題が発生する可能性があるため、問題が発生したときに顧客が実行しているコードを正確に判断する必要がありますが、追跡できるように注意してください。その後、多くのパッチをバンドルする1つの大きな「パック」がリリースされたときに、人々にその1つにアップグレードするように強制できます。
例外はセキュリティパッチです。ワシントンを本拠とする大規模なソフトウェア会社は、重要なセキュリティパッチをリリースする前に月の第3木曜日を待つことによって熱湯に入ることが知られており、ハッキングに関する情報が漏えいし、彼らの手にさらに大きな恥ずかしさを強いました。
Google chromeは、非常に頻繁に自動更新することで問題を回避します。また、プログラムを循環させる必要があります（Chromeを再起動するか、場合によってはログアウトします）。これで、ブラウザに対して通常の方法で人々はもはやそれについて考えさえしませんが、誰もがGoogleになることができるわけではありません。
SaaSアプリケーションは、バックグラウンドで更新を行うことで問題全体を回避します。
ただし、何よりも、継続的に統合したり、新しいユーザーが要求した機能を頻繁に更新したりしない限り、リリース前にかなりの量のテストを行ったと人々が期待している時期にいると思います。あなたの顧客に会って、バグ修正の頻度について話すのが恥ずかしい場合は、おそらく十分なテストを行っていません。コードをリリースする前に、どの程度のリスクを負っていましたか？それが何であるかを知っている限り、非常に早い段階でバグのあるコードをリリースすることについては議論がありますが、私はあなたの既知の品質を十分に理解する必要があると思います。つまり、品質を知るために時間を理解し、管理する必要があります。