ソフトウェア製品の管理において、人々がベンダーを憎むのを防ぐために避けなければならないことは何ですか?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/20790

質問

a 前の質問 なぜ人々がマイクロソフトを憎むのかについて。これは、同じ一般的なラインに沿ってやや建設的な質問の試みです。これはより広く、より狭いです。 Microsoftだけでなく、一般的なソフトウェアベンダーに関するものであることにより、より一般的です。ソフトウェア製品の管理のみを扱うことで狭くなります。

したがって、個々のソフトウェア製品を管理する際に、個々の製品だけでなく、会社全体が肯定的な観点から尊重/好かれている/見られることを保証する際に、どのような手順をとるべきですか(および/または避けるべき)。

役に立ちましたか?

解決

最も重要なのは、明らかに高品質の製品を提供することです。

その他の輸入トピック:

  • 正直。とにかく、真実が遅かれ早かれ出てくるときに嘘をつかないでください。
  • 信頼性。締め切りを遵守します。
  • 可用性。メールを返信して、電話を受け取ります。
  • 協力する意欲。顧客が必要とするものを作るために最も近い競合他社と協力することを意味する場合は、それを行い、それを専門的に行います。最初に顧客を傷つける汚いトリックはありません。

私のリストの最後の項目は、おそらくMSがそのような悪い評判を得たものです(ただし、その点で今でははるかに優れていると思います)。そして、中小企業がそうするとき、それはさらに悪いことです。

他のヒント

2つから始まる非網羅的なリストは、あなたの製品を宣伝するために邪魔にならない、本当に情熱的な顧客を作成するのに大いに役立つことができます。

  • レスポンシブで敬意を表するサポートモデル。速くて顧客に良いサポートを与えるようなものはありません。理想的には直接応答モデルです。誰でも尋ねることができ、誰でも質問に答えることができる掲示板サイトのようなコミュニティサポートモデルがあっても、それをモデレートしてサポートスタッフとシードすることが役立ちます。顧客サービスに関する古い格言 - 誰かに良い顧客サービスを提供し、彼らはそれについて一人に伝えるかもしれません。彼らに貧弱な顧客サービスを与えると、彼らは10人に伝えます。ウェブの世界では、10人が今や何度も増えています。

  • 優れたデザインを使用する - あなたは人々を喜ばせることを目指したいです。これには、エンジニアリングだけでなく設計が必要です。顧客の声を聞き、肩を見守り、プロトタイピングをし、リリースされた製品の継続的な改善が必要です。

私が追加する他の2人:

  • 品質 - うん、バグ数にしっかりと蓋をしておくと、固体になるまで放出しません。フィーチャーの過負荷を備えたフレーク状の製品ではなく、固体製品に焦点を当てています。 Web 1.0の狂乱の間に、大規模なベンダーは、Webサイトを開発する際に実際の品質プロセスなしでソフトウェアを反復的に開発できることがどれほど素晴らしいかを発表しました。その頃、私は彼らの新しいサイトの1つを試してみましたが、すぐに私を壊しました。リリース前にテストがなかったことは明らかでした。あなたの同盟国を苛立たせ、新しい顧客を背負わせる良い方法。

  • 人々がソフトウェアを使用する方法に適したライセンスモデル。人々は支払う必要があることを知っていますが、あなたがあなたのポリシーに必要な柔軟性を反映することができれば、それはすべての人のために働きます。例:複数のコンピューター、または作業およびホームコンピューターを使用できるシートごとのライセンス。多くの人が複数のコンピューターを持っているからです。

- アレックス

嫌われるいくつかの方法:

ビジネス製品のマーケティングと販売の際には、購入権限を使用する必要のない人を目指してください。そうすれば、使いやすさを心配する必要はありません。

理想的には、価格設定は混乱し、不合理でなければなりません。明確に区別されていない機能を備えた複数のバージョンがあります。理想的には、1つまたは2つの特に望ましい機能を価格スケールで高く持っているので、人々は、使用しない多くのことに対して大きな支払いをしなければならないと感じます。

十分なパワーがある場合は、ソフトウェアの後のバージョンを前任者と完全に互換性がなく、アップグレード割引を提供しないでください。余分なポイントについては、人々が慣れている機能を削除します。

実際には機能しない機能を宣伝します。製品を十分に制御している場合は、多かれ少なかれ強制アップグレードでそれらの一部を削除します。

いくつかのバグ、好ましくは断続的なバグを残します。何かが起こった場合、それがあなたのせいではない理由を考えてください。あなたの不平を言っている顧客のストーンウォール。または、実際に製品の使いやすさを低下させる修正を考え出します。

品質管理は、顧客満足度を必要とする企業向けです。潜在的なベータテスターがたくさんあります。それらを使用してください。フィードバックを与えなくてもレポートが表示されます。それらの多くは次のバージョンで修正できます(わずかな非互換性、アップグレード価格、機能の削除については上記を参照)。

ユーザーのコンピューターを台無しにします。 DRMはここで素晴らしいです。特に、事前にそれについて誰にも話さない場合(特にあなたの製品のようなものでDRMを期待しない場合)。

著作権侵害対策は素晴らしいです。検出アルゴリズムには多くの誤検知があることを確認してください。誤検知を修正するための便利なまたは簡単な方法が必要ではありません。

とんでもないことを主張する長い混乱を招くオウラは、今日は一般的です。それらを嫌うためには、そこに何か面倒なものを埋めて、その後それを強制しなければなりません。

ドキュメントはWimps用です。ドキュメントからいくつかの重要なことを行う方法を理解することは事実上不可能であることを確認してください。 (残念ながら、これは時間とともにあまりにも一般的になりすぎて、本当に効果的ではありません。)

厄介なドキュメントと申請手順を必要とするリベートは良いです。最近の多くの領収書は、時間の経過とともにフェードする方法で印刷されているため、元の領収書を必要とし、それらを処理するのに十分な時間をかけることで多くのお金を節約できることを忘れないでください。

ここでは、ar慢でよく知られている反競争的慣行が常に役立ちます。

(私がどの提案を念頭に置いて書いたか、またはどちらの提案が、どちらを個人的にも苦しんでいるかを推測するためのポイントはありません。)

1)高品質の製品を作成します
2)顧客を理解する
3)一貫性を維持します

オープンで明確な方法での価格 - これには、初期購入価格だけでなく、アップグレード、追加機能またはモジュール、サポート、コンサルタント、トレーニング、その他の関連コストが含まれます。

安くする必要はありません。好きなように積極的に価格を設定できますが、価格に関して何よりもクライアントを混乱させる私の経験の1つのことは、エキストラと彼らがより多くのお金を持っているという考えです彼らが購入した今、彼らから不当に抽出されました。

未知のコストはお金に関するものではなく、人々の評判に関するものです。購入した人は、プロジェクトの予算を立てたときに、彼らの評判の一部をラインに置いています。余分な費用がお金の価値であっても、彼らが彼らの上司に戻ってより多くのお金を求めなければならないとき、あなたは彼らが彼らが台無しにしたことを公に認めさせ、彼らはあなたを憎むでしょう。

ソフトウェア会社を前向きな光に留めることは、トランザクションの両側に関係します。

会社は:

  1. 選択したフィールドで目的に最も適したコードを継続的に提供します
  2. 顧客のフィードバックに基づいて行動することで、改善に継続的に努力していると思われます
  3. 公平であると思われます

顧客は:

  1. 彼らがうまく/ひどくやっていることを会社にフィードバックを提供する
  2. 応答に対する彼らの期待に合理的であること

これらの簡単なルールから、多くの良いことが自然に続きます。問題は、市場の力と競争がそれが何であるかであり、彼らに固執することは悪夢です。

あなたがニュースで多くの露出を伴うMicrosoft、Google、またはFacebookのような大企業であるとき、あなたは人々があなたを憎むのを防ぐことはできません。それは不可能だ。

あなたがもっといるほど 成功, 、あなたがもっといるほど 嫌い.

ベンダーは、と呼ばれるメトリックを作成する必要があります hatemeter 彼らの成功を測定するために! ;)

そのため、起業家の最大の品質の1つは、それを理解して処理できることです。さらに重要なことは、悪いフィードバックを使用して製品を改善することです(フィードバックは興味深いものです)。

ベンダーが直面しなければならない本当の挑戦は憎しみではありませんが、 無関心.

編集: :これはとても面白いと思いました Webサイト. 。これにより、誰もがさまざまな人気のある企業や製品について意見を述べることができます。投票額は低すぎて結果を関連させるには低すぎますが、興味深い投票者はその理由を説明する必要があります。私はあなたにコメントを発見し、自分で判断して人間の性質は複雑です。

私が使用した商業ソフトウェアの角度からこれについて説明しましょう。

柔軟性が多すぎる - これは重要です。柔軟性を提供したいというあなたの欲求が、ほとんどの人が望む機能の設計をあきらめることを意味します。ユーザーが実際に使用するのが好きな「柔軟な」製品を使用したことがありません。彼らはあなたの設計エラーを修正する方法を見つけたくない。よく知られているベンダーからの「柔軟な」プロジェクト管理ソフトウェアがあります。それは非常に柔軟で、プロジェクトを要求したクライアントのためのフィールドのようなものを持っていません(クライアントがプロジェクトをソートする必要がない数万ドルのコストのある製品を必要とする製品を必要とするのに十分な企業がいくつありますか?それはゼロになります。)。アイデアやインシデントをプロジェクトに変換するとき、情報は自動的にプロジェクトに移動することはなく、開発者が実際にシステムを設計しなかったため、必要なものや非常に迷惑なものについての詳細を検索することはできません。とても「柔軟」でした。フィールドを追加してからすべてのフォームを修正しようとする複雑さは、これらのフィールドを確認できるようにすることを意味します。時間。一般に、システムがより柔軟になるほど、より多くの人々がそれを憎むでしょう。

データベースに固有の可能性のあるより良いパフォーマンスコードを書き込む代わりに、データベースニュートラルになりたいことによるパフォーマンスの考慮不足。

数百人の同時ユーザーとデータベースに大きなデータセットがある環境でのテストの欠如。小さなデータセットでは正常に機能するデータベースクエリは、多くの場合、大きなデータベースに対して不可能です。よく知られているコールセンターソフトウェアプログラムを持っていたコールセンターで働いていましたが、ある画面から次の画面に移動するには10分かかる可能性があります。コールテイカーとユーザーの両方がこれをどれだけ気に入ったか想像できます。最も一般的なエラーは、データベースのタイムアウトでした。

変更のために変更。すべてを実行する方法を再配置する新しいバージョンの何かを取得すること以外にユーザーを悩ませるものはありませんが、必要な機能や必要な機能を追加しません(Office 2007と追加したがっかりしたリボンと削除したメニュー構造を参照)。日々の年、2年に依存しているものを再学習する必要はありませんが、ほとんどのユーザーもそうではありません。問題をよりよく解決するために新しい技術を学ぶことは1つのことであり、GUIを再アレンジして、すでにやり方を知っているすべてのことを見つけることができないようにすることは別のことです。

顧客サービス。問題がある場合は、特にソフトウェアに膨大な金額を支払った場合は、迅速に、費用がかかりすぎずに修正するのを手伝ってほしいです。

途方もなくバグのようなソフトウェア。さあ、私は通常の方法で一般的なタスクを実行することを破ることができないはずです。あなたはこのようなものをテストしましたね。インストールでバグにぶつかったとき、または製品を使用して最初の数日間にヒットすると、特に態度があります。最後のバージョンでうまく機能したものが機能しなくなった場合、さらに迷惑です。確かにすべてのコードにはバグがありますが、最も明白なコードは出荷前に飼いならされるべきです。

今、それを正しく行う会社に関して - 私はレッドゲートがその会社であることを提出します。彼らのものはただ機能します、それは私の側でそれを使用するために多くのトラブルなしですべきだと言うことをします、それは速く、彼らの顧客サービスは素晴らしいです。私が知っているほとんどすべての経験豊富なSQL Server DBAは、ツールを購入することをお勧めします。

貧弱なドキュメントとそれを改善したいという欲求はありません - 私は現在、データベースの定義や図を提供できないソフトウェアベンダーと協力しています。彼らは「ウォーキングデータ辞書」であるため、実際に開発者の1人に電話することを推奨しました。今、私は彼らが彼のアプリケーションを改善したり、バグを修正していないのかを知っています。彼らは顧客のテーブルにあるものを説明するのに忙しすぎています。

編集:今、私は彼らがこのデータベースを文書化しなかった理由を知っています:

  1. タイプに基づいてフィールド名の命名規則があります:dt = date、s = string/varchar、d = float
  2. 一意のキーのみが一意のクラスターインデックスはありません。
  3. テーブルに制約はありません。
  4. ストアドプロシージャのほとんどには以下が含まれています。
  5. すべての重要なフィールドは文字列タイプです(問題の最小)
  6. カーソルは豊富です!
  7. 彼らはコメントとバージョンのパッチを数えましたが、それはそれについてです。
ライセンス: CC-BY-SA帰属
所属していません softwareengineering.stackexchange
scroll top