人々がベンダーを嫌うのを防ぐために、ソフトウェア製品の管理におけるどのような間違いを避ける必要がありますか？
A 前の質問 なぜ人々がマイクロソフトを嫌うのかについては閉鎖されました。これは、同じ一般的な方針に沿った、やや建設的な質問への試みです。これは、しかし、より広く、より狭いです。それは、マイクロソフトだけでなく、一般的なソフトウェアベンダーについてであるということでより一般的です。ソフトウェア製品の管理のみを扱うことで、より狭くなります。
それでは、個々のソフトウェア製品を管理する際に、個々の製品だけでなく会社全体が前向きに尊重/評価/見られるようにするために、どのような手順を踏む（および/または回避する）必要がありますか？
最も重要なのは、明らかに高品質の製品を提供することです。
その他の重要なトピック：
- 正直。とにかく真実が遅かれ早かれ出てくるときに嘘をつかないでください。
- 信頼性。締め切りを守る。
- 可用性。メールに返信し、電話を取ります。
- 協力する意欲。最も近い競合他社と協力して顧客が必要とするものを作ることを意味する場合は、それを実行し、専門的に実行します。最初に顧客を傷つける汚いトリックはありません。
私のリストの最後の項目は、おそらくMSの評判が悪い理由です（ただし、その点では今でははるかに優れていると思います）。中小企業がそうするとき、それはさらに悪いことです。
完全ではないリスト。2つから始まり、本当に情熱的な顧客を作成するのに大いに役立ちます。顧客は、製品を宣伝するために邪魔になりません。
レスポンシブで敬意を表するサポートモデル。速くて顧客に良いサポートを提供することに勝るものはありません。理想的には直接応答モデル。誰でも質問でき、誰でも質問に答えられる掲示板サイトのようなコミュニティサポートモデルでも、モデレートしてサポートスタッフにシードすることは役に立ちます。カスタマーサービスについての古い格言-誰かに良いカスタマーサービスを与えると、彼らはそれについて一人に話すかもしれません。彼らに貧弱な顧客サービスを与えると彼らは10人に話します。今では10人が何倍にもなるウェブの世界。
良いデザインを使用して-あなたは人々を喜ばせることを目指したいです。これには、エンジニアリングだけでなく設計も必要です。顧客の話を聞き、肩越しに見守り、プロトタイピングを行い、リリースされた製品を継続的に改善します。
私が追加する他の2つ：
品質-うん、バグカウントをしっかりと覆い、しっかりするまでリリースしない。機能が過負荷のフレーク状の製品ではなく、堅実な製品に焦点を当てています。 Web 1.0の熱狂の最中に、ある大手ベンダーが、Webサイトを開発するときに実際の品質プロセスなしでソフトウェアを繰り返し開発できることの素晴らしさを発表したことを覚えています。その頃、私は彼らの新しいサイトの1つを試しましたが、ほとんどすぐに壊れました。リリース前にテストが行われていなかったことは明らかでした。味方を苛立たせ、新しい顧客を遠ざける良い方法です。
人々がソフトウェアをどのように使用するかについてうまく機能するライセンスモデル。人々は彼らが支払う必要があることを知っています、しかしあなたがあなたの政策に人々が必要とする柔軟性を反映することができれば、それは誰にとってもうまくいきます。例：複数のコンピューター、または職場と自宅のコンピューターを使用できるようにするシートごとのライセンス。多くの人が複数のコンピューターを持っているからです。
-アレックス
嫌われるいくつかの方法：
あなたのビジネス製品をマーケティングして販売するときは、それを使用する必要のない購入権限を持つ人々を目指してください。そうすれば、使いやすさを心配する必要はありません。
理想的には、価格設定は混乱を招き、不合理である必要があります。明確に区別されていない機能を備えた複数のバージョンがあります。理想的には、1つまたは2つの特に望ましい機能を価格スケールの上位に配置して、使用しない多くのことに多額の費用をかけなければならないと感じられるようにします。
十分なパワーがある場合は、ソフトウェアの新しいバージョンを以前のバージョンと完全に互換性のないものにし、アップグレード割引を提供しないでください。余分なポイントについては、人々が慣れているかもしれない機能を削除してください。
実際には機能しない機能を宣伝します。製品を十分に管理している場合は、多かれ少なかれ強制的なアップグレードでそれらの一部を削除します。
いくつかのバグ、できれば断続的なバグを残してください。何かが起こったとしても、それがあなたのせいではない理由を考え出してください。不平を言っている顧客をストーンウォールします。または、実際に製品を使いにくくする修正を考え出します。
品質管理は、顧客満足を求める企業向けです。あなたはそこにたくさんの潜在的なベータテスターを持っています：それらを使ってください。フィードバックをしなくてもレポートが届きます。次のバージョンでそれらの多くを修正できます（わずかな非互換性、アップグレード価格なし、機能の削除については上記を参照してください）。
ユーザーのコンピューターを台無しにします。ここでは、DRMは、特に事前に誰にも言わない場合（特に、製品のようなものでDRMを期待しない場合）に最適です。
著作権侵害対策は素晴らしいです。検出アルゴリズムに誤検知がたくさんあることを確認してください。誤検知を修正するための便利で簡単な方法を用意する必要はありません。
ばかげたことを主張する長く混乱しているEULAは、今日では当たり前のことです。それらに嫌われるためには、そこに厄介なものを埋めて、後でそれを強制する必要があります。
ドキュメントは弱虫用です。ドキュメントからいくつかの重要なことを行う方法を理解することは事実上不可能であることを確認してください。 （残念ながら、これは時間の経過とともに一般的になりすぎて、実際に効果を発揮できなくなりました。）
厄介な文書化と申請手続きを必要とするリベートは良いです。最近の多くの領収書は時間の経過とともに色あせて印刷されるため、元の領収書を要求し、それらを処理するのに十分な時間をかけることで、多くのお金を節約できます。
ここでは、傲慢さと広く公表されている反競争的慣行が常に役立ちます。
（私が企業を念頭に置いて書いた提案、さらにはどの提案、または私が個人的に苦しんだ提案を推測することには意味がありません。）
1）高品質の製品を作成する
2）顧客を理解する
3）一貫性を維持する
ソフトウェア会社を前向きに保つには、取引の両側が関係します。
会社は：
- 選択した分野の目的に最も適したコードを継続的に提供する
- 顧客のフィードバックに基づいて行動することにより、継続的に改善に努めているように見える
- 公平であると見られる
お客様は次のことを行う必要があります：
- 彼らがうまく/悪いことをしているというフィードバックを会社に提供する
- 応答に対する彼らの期待を合理的にする
これらの単純なルールから、多くの良いことが自然に続きます。問題は、市場の力と競争がそれ自体であり、それらに固執することは悪夢です。
オープンで明確な方法での価格-これには、初期購入価格だけでなく、アップグレード、追加機能またはモジュール、サポート、コンサルティング、トレーニング、およびその他の関連コストが含まれます。
あなたは安い必要はありません、あなたは好きなだけ積極的に価格を付けることができます、しかし価格に関して何よりもクライアントを混乱させる私の経験の1つのことは不明確な余分なものと彼らがより多くのお金を持っているという考えです彼らが購入したので、彼らから不当に抽出されました。
未知のコストはお金ではなく、人々の評判です。購入者は、プロジェクトの予算を立てるときに、評判の一部を強調しています。余分な費用がお金の価値であるとしても、あなたは彼らが上司に戻ってもっとお金を要求しなければならないとき、あなたは彼らが失敗したことを公に認めさせています、そして彼らはあなたを嫌うでしょう。
あなたがマイクロソフト、グーグル、フェイスブックのようなニュースで多くの露出を持っている大企業であるとき、あなたは人々があなたを嫌うのを防ぐことはできません。それは不可能だ。
あなたが成功するほど、あなたは嫌われる。
ベンダーは、成功を測定するためにhatemeterと呼ばれるメトリックを作成する必要があります。 ;）
だからこそ、起業家の最大の資質の1つは、それを理解して処理できることです。そしてさらに重要なことに、悪いフィードバックを使用して製品を改善します（フィードバックは興味深いものです）。
ベンダーが直面しなければならない本当の課題は憎しみではなく、無関心です。
[〜＃〜]編集[〜＃〜]：これは非常に興味深いと思いました ウェブサイト 。これにより、誰もがさまざまな人気のある企業や製品について意見を述べることができます。投票数が少なすぎて結果を適切なものにすることはできませんが、興味深い投票者はその理由を説明する必要があります。コメントを見つけて、自分で判断させてください。人間性は複雑です。
私が夢中になっている商用ソフトウェアの観点からこれについて話し合いましょう。
柔軟性が高すぎる-これは重要です。柔軟性を提供したいという願望が、ほとんどの人が望む機能の設計をあきらめることを意味させないでください。ユーザーが実際に使いたがっている「柔軟な」製品を使ったことがありません。彼らはあなたのデザインエラーを修正する方法を理解する必要はありません。有名なベンダーの「柔軟な」プロジェクト管理ソフトウェアがありますが、これは無名のままです。柔軟性が非常に高いため、プロジェクトをリクエストしたクライアントのフィールドのようなものはありません（数万ドルの製品を必要とするほど大きな企業が、クライアントごとにプロジェクトを並べ替える必要がないのはどれだけですか？それはゼロになります。）アイデアやインシデントをプロジェクトに変換しても、情報がプロジェクトに自動的に移動することはなく、開発者が実際にシステムを設計していなかったため、必要なものや必要な人の詳細を検索するのは非常に面倒です。とても「柔軟」でした。フィールドを追加してからすべてのフォームを修正してそれらのフィールドを確認できるようにすることの複雑さは、ほとんどの人が、製品が持っているとして販売されたすべての「優れた」機能のために製品を使用することをあきらめ、文書化するためにのみ使用することを意味します時間。一般に、システムの柔軟性が高いほど、より多くの人々がそれを嫌うでしょう。
データベース固有のパフォーマンスの高いコードを作成するのではなく、データベースに依存しないようにすることによる、パフォーマンスへの配慮の欠如。
数百人の同時ユーザーとデータベース内の大規模なデータセットがある環境でのテストの欠如。小さなデータセットで正常に機能するデータベースクエリは、大規模なデータベースでは不快感を与えることがよくあります。よく知られたコールセンターソフトウェアプログラムを持っていたコールセンターで働いていたのですが、ある画面から次の画面に移動するのに10分かかることがありました。コールテイカーとユーザーの両方がこれをどれだけ気に入ったか想像できます。最も一般的なエラーは、データベースのタイムアウトでした。
変更のために変更します。すべてを行う方法を再配置し、必要な機能を追加しない新しいバージョンを入手することほど、ユーザーを悩ませることはありません（Office 2007と、追加した安っぽいリボンと削除したメニュー構造を参照してください）。日々依存していることを1年か2年ごとに再学習する必要はなく、ほとんどのユーザーもそうしません。問題をよりよく解決するための新しい技術を学ぶことと、GUIを再配置して、すでに知っている方法をすべて見つけることができないようにすることは別のことです。
顧客サービス。問題が発生した場合、特にソフトウェアに多額の費用を支払った場合は、コストをかけずに迅速に修正できるように支援してください。
ばかばかしいほどバグのあるソフトウェア。さあ、私は通常の方法で一般的なタスクを実行してそれを壊すことができないはずです。あなたはこのようなものをテストしましたね？インストール時や製品の最初の数日間でバグが発生した場合は特に厄介です。前回のバージョンでうまく機能していたものが機能しなくなったときは、さらに厄介です。確かにすべてのコードにバグがあることはわかっていますが、最も明白なコードは出荷前に飼いならす必要があります。
さて、それを正しく行う会社についてですが、Red-Gateがその会社であることを提出します。彼らのものはうまく機能します、それはそれを使用するために私の側で多くの問題なしにそれがするべきであると言うことをします、それは速くそして彼らの顧客サービスは素晴らしいです。私が今まで知っていたほとんどすべての経験豊富なSQlServer dbaは、ツールの購入を推奨しています。
ドキュメントが貧弱で、改善したくない-私は現在、データベースの定義や図を提供できないソフトウェアベンダーと協力しています。彼らは「ウォーキングデータディクショナリ」であるため、実際には開発者の1人に電話することをお勧めしました。これで、なぜ彼らがアプリケーションを改善したりバグを修正したりしていないのかがわかります。彼らは顧客テーブルの内容を説明するのに忙しすぎます。
編集：今、私は彼らがこのデータベースを文書化しなかった理由を知っています：
- タイプに基づくフィールド名の命名規則があります：dt = date、s = string/varchar、d = float
- 一意のクラスター化インデックスのみの主キーはありません。
- テーブルに制約はありません。
- ほとんどのストアドプロシージャには次のものが含まれます。
- すべてのキーフィールドは文字列タイプです（問題が最も少ない）
- たくさんのカーソル！
- 彼らはパッチにコメントし、バージョン番号を付けましたが、それだけです。