クライアントからの「更新以来…」という質問にどのように対応しますか？[閉まっている]

更新以来、人々は「更新X、Y、およびZが遅くて、悪い状態で、クラッシュするたびに」と電話し、言い続けています。

これは、更新の夜明け以来ずっと発生しています。

人々は何を期待していますか？ガンマはベータの後にあり、ガンマテストは常にユーザーをThe Incredible Hulksに変えます...

おそらくあなたはこれをクライアントから聞いたことがないでしょう、おそらくあなたは大学にいるか、5人か6人以上に非難を広めることができるFLOSS開発者です、おそらくあなたはあなたのコードをユニットテストします、おそらくあなたはそのような興味深い状況ではありません顧客が実際にあなたに今日のパッチをリリースする正確な時刻を要求するように電話します（Microsoftにそれをしたいと思います）、またはあなたはたぶんあなたがちょうど新しいを出荷した私のようなビスケットの息子です更新して帰宅し、明日仕事に戻るのが怖いです。

とにかく、yaは私よりも賢いでしょう。「あなたはあなたのソフトウェアをより悪くしているので、あなたは悪いプログラマーでなければならない」に囲まれた批判をどのように表現しますか？

デプロイするたびにこれが発生する場合、開発プロセスに重大な欠陥がある可能性があります。私は問題を引き起こしているいくつかのことを疑います。

1. 本番と（ほぼ）同じサイズのデータ​​ベースに対して開発しますか？そうでない場合、小さなデータセットで問題のないクエリは多くの場合、大きなデータセットを持つ犬であるため、常にこれらの問題が発生します。
2. QAでテストをロードしますか？1人のユーザーのテストでうまく機能するのは、1000人のユーザーが同時に物事を行おうとする場合の反応とは大きく異なります。
3. ユーザーの認識が間違っていると思い、文句を言うのは愚かであるかのように扱いますか？もしそうなら、あなたの態度は彼らを減らさないより多くの苦情を引き起こしています。
4. あなたはテストの良い仕事をしていますか？変更の影響を受けないかどうかを確認するために、変更されていない機能を回帰テストしますか？製品が製品にヒットするまでにかかる時間も気になりますか？
5. 給与計算の実行時に会計システムに変更を展開するとき、または変更を陽気に展開するとき、ユーザーにとって良い時期であることに注意を払い、ユーザーがスローダウンで怒っている理由を疑問に思いますか？
6. devとprodの間に環境の違いがありますか？オペレーティングシステムまたはデータベースバージョンの厄介な違いが、このような問題を引き起こすこともあります。多くの場合、prod、一部の機器、オペレーティングシステム、datを備えた同じデータベースが可能な限りprodデータに近いステージング環境を用意することをお勧めします。これは、展開のテストに使用されます。このサーバーで最初に実行し、tehnに何人かのユーザーまたはテスターに​​アクセスして、いくつかのテストを実行させます。
7. 展開プロセスはどの程度良好ですか？手順をよく見逃していますか？展開しているブランチにどのコードが含まれているかが明確であるため、開発者以外の誰かが実行できますか？構成管理チームができたときにコードのデプロイがずっと良くなり、「おっと」の変更を行うprodとbabysitに座る権利が誰もありませんでした。ビルドを自動化すると、非常に役立ちます。QAに進み、最初にステージングし、デプレーションの問題が解決するはずだったので、誰がprodに行く必要があるかを推測するべきではありません。データベースの変更をスクリプト化することも重要です。それらはスクリプトとソース管理にあるはずなので、誰かが覚えておく必要なくビルドプロセスでそれらを取得できます。ああ、そうです、列Bの長さを50から241に変更する必要があります。

「あなたはあなたのソフトウェアをより悪くしているので、あなたは悪いプログラマーでなければならない」に囲まれた批判をどのように表現しますか？

しかし、そのような批判はほとんど正当化されます。新しいリリースは以前のものより悪くないはずですが、私たちが知っているように、実際にはそれはしばしばそうであり、それは私たちが作ったからです。

間違いを犯すのは人間であり、誰もが「悪いプログラマー」になるわけではないので、批判を個人的に受け止めてはいけません（とにかく非同僚からの専門的な批判を真剣に受けとることはありません）。問題を報告してくださったお客様に感謝し、できるだけ早く修正してください。優れたプログラマーとしてのあなたの仕事です。

仕事では、クライアントと直接やり取りすることはあまりないので、個人的なプロジェクトの仕事からこの質問に答える必要があります。私は、人々が自分のゲームを構築するために使用できるゲームエンジンを書いています。まだプレアルファ版ですが、興味のあるユーザーが何人かいて、バグが出ることがあります。

ユーザーからこのようなレポートを受け取ったら、個人的なタッチを使用しようとします。私はバグを紹介するつもりはありませんでしたが、バグを自分のエンジンで体験してもらいたいので、それを信じさせる必要があります。まず、話ができるようにIMハンドルを取得します。ユーザーにプロジェクトについて尋ね、コピーを取得しようとします。これにより、複製が非常に簡単になります。グリッチが発生したときに彼らが何をしていたかを尋ねます。その間、デバッガーでエンジンを開いて、話している間にこの問題に注目しています。

例外の場合、通常は非常に簡単です。問題を再現すると、デバッガーがそれを取得し、完全なスタックトレースでエラーの場所に直接移動します。何が起こっているのかは明らかです。パフォーマンスが遅い場合や動作が正しくない場合は、少し時間がかかる場合があります。しかし、ほとんどの場合、最初の20分以内に修正を準備できます。私はそれを圧縮し、テストするために彼らに送ります。「わかりました、私はそれを得たと思います。これがあなたの終わりに働くかどうか見てください？

ほとんどの開発者（読む：ソフトウェア会社）はバグを修正せず、その速さで再リリースしないため、ほとんどの場合、応答は驚きと感謝の混合です。そして、それが実際に修正された場合、私は潜在的な批評家をファンに変えました。これは本当に良いテクニックです。もっと多くの開発者がそれを採用することを願っています。

私は個人的に問題を前向きに受け止めています。私は常に多くの顧客とやり取りしていますが、それでもコーディングをしています。

彼らが新しいリリースをダウンロードし、そのようなことを私に言うとき、私はいつもこのようなことを言う：

そのバグを報告してくれてありがとう。追加されたすべての新機能が一緒に導入されたのかもしれません。できるだけ早く修正します。

実際、顧客はあなたの上司です。あなたとの経験が悪い場合、それはあなたにとっても悪いです。

彼が正しくなくても、あなたは会社の一員として、あなたはこの機会を利用して次のことをすべきです。

• 彼から学び、製品に加えられる可能性のある改善点を収集します。
• 不幸な顧客を幸せな顧客に変えて、彼があなたのことを話します（あなたの上司を含む）
• あなたがやっていることを誇りに思う

詳細、詳細、詳細。彼らが何をしていたのか、いつ、具体的に尋ねます。それは何かかもしれないし、ジャスティン・ビーバーのビデオがYouTubeで公開されたばかりかもしれない。どちらの場合も、ログファイルは友達です。

また、彼らがそれに気づいた日付を尋ねます。特にエンタープライズショップでは、ユーザーはリリースがいつリリースされるかを知らず、何かが完了するのに長い時間がかかることを知り、今それについて不平を言っているだけです。

ジョブシャドウ。これを十分に強調することはできません。近くにユーザーがいる幸運な場合は、時間の経過とともにユーザーが動作するのを見てください。私はしばしば、明白な問題を無視し、決して報告しないことに気付きます。彼らはしばしば、何かが新しいことを知ったとき、または最初に問題に気づいたときにのみ文句を言います。

ステップ1は、これ（更新が他のものを破壊する）が正常ではないという考え方から来なければならないということです。更新によって、アプリの他の部分が壊れたり、遅くなったりしないようにしてください。それは大丈夫ではありません、それは予想されるべきではありません、そして、彼らがそれについて不平を言うとき、それはユーザーのせいではありません。それを防ぐために、できるだけ多くのテストを行う必要があります。それが起こるとき、あなたには問題があり、緊急の問題があります。

ステップ2は、自分が何をしたかを知る必要があるということです。あなたのソース管理システムはあなた、または何らかの作業追跡システムを助けることができるかもしれませんが、これらの苦情のいずれかを受け取った瞬間に「OK、私はこの表に列を追加し、計算するためにこのグリッドを変更しました新しい税、これら2つの新しいレポートを追加...」など。

ステップ3は、perfの問題とクラッシュをすばやく見つけた経験が必要であるため、どのようなものがそれらを引き起こす可能性があり、すぐに問題に到達できるかを知っていることです。この問題は発生しており、問題をすばやく見つけてパッチを入手する必要があります。レポートを変更しても、レポートを使用しないアプリの一部の速度が低下することはありません。現在、緊急モードになっているので、プロセスのアプリの別の部分を壊すことなく、間違いの場所と対処方法を把握する必要があります。

ステップ4は、これらのmiseriesのそれぞれについて、次回テストするレッスンを学習する必要があります。「10,000件のレコードがあると恐ろしい」ため、特定の構造に反対する「あの男」になります。

「これは正常です」という点についてもう少し説明します。外部顧客向けのアジャイルプロジェクトを（他のすべての作業の中でも）実行しています。現在、2、3年の間、ほぼ6週間ごとにリリースを行っています。そして、はい、リリースは分に予定されています。昨日の午前8時に1つだけを行いました。そして、ほぼ4〜5回のリリース（つまり、年に1〜2回）で何かがライブで中断します。そして、私たちは行動に飛び込み、できるだけ早くそれを正しくします。リリース前にテストおよびテストとテストを行いますが。次に、何が起こったかを伝えます。「6月のデプロイには、このフィールドを空白にする小さなバグがありましたが、その時点で値を使用していなかったため、気付くことはありませんでした。あなたが見たそのエラーメッセージ。バグを修正して、空白にならないようにし、不良レコードに値を入れて、それ以上爆発しないことを確認しました。または、「リリースのわずか2日前にあなたが懇願した緊急の変更は、私たちが考えもテストもしなかった結果をもたらしました。なぜ私たちが緊急の変更に抵抗するのかを覚えていますか？」私は、更新で悪化させたとしても悪いプログラマーではないかもしれませんが、確かに悪いことをしました。そして、私はそれを正しくする必要があります。私はアップデートで悪化させたとしても悪いプログラマーではないかもしれませんが、確かに悪いことをしました。そして、私はそれを正しくする必要があります。私はアップデートで悪化させたとしても悪いプログラマーではないかもしれませんが、確かに悪いことをしました。そして、私はそれを正しくする必要があります。

別の側面をカバーするために：

そうではないことが判明した場合、これを主張する顧客のリストを保持します。ソフトウェアはバグが多く、非常にバグが多い場合がありますが、多くのお客様は「アップデートから開始」とすぐに注意を喚起します。顧客が真実を語っている場合、これはすぐに見つけられる傾向があります。顧客が何度も偽リストに載っている場合、時間を無駄にしたくないので気にしません。

嘘をつくとプロセスが速くなると考えるには、どのような考え方が必要か想像できません。これらの人々は医師であるか医師と仕事をしており、医師に嘘をついたときに何が起こるかを十分に知っている必要があります。同じ原則が適用されます。