顧客からの「もう少しフィールドを追加できます」タイプのリクエストを処理する方法は？

非常に一般的には、1人の顧客のみが必要とするフィールドの機能要求があります。これは、せいぜい、アプリケーションのコードを乱雑にします。多くの場合、フィールドを追加してから数か月後にデータベースを調べると、実際には余分なフィールドさえ使用していないことがわかります。また、非常に古いアプリケーションであるため、単一のフィールドを追加するには、複数のコード変更、レポートの変更、およびフィールドを表示する必要のない他の顧客に影響を与えないようにする必要があります。

• 顧客がこれらの機能要求を実際に必要としていることをどのように確認できますか？

• 「本当に必要ない」と丁寧に言うには？

現在、特定の機能のリクエストに対して課金を開始しています。（以前は、機能要求は通常無料でした）他にできることはありますか？

彼らは追加機能にお金を払っていますか？もしそうなら、彼らがそれらを使用しているかどうかは本当にあなたのビジネスではありません。彼らが支払うものを彼らに与えてください。ただし、そうでない場合は、追加収入なしで機能を追加し続けるかどうかを判断するのはあなたのリーダーシップ次第です。

同様の状況があります。私たちが扱う方法は、「これは必要ない」と言う自由を私たちに与える信頼ベースの関係を構築することです。それには時間がかかり、忍耐が必要であり、あなたはたくさん話をし、昼食や他の退屈な仕事をする準備をしなければなりません。これらの退屈な会議は、あなたが本当に重要な機能の作成に集中できる長期的には、自分自身のためにお金を払うでしょう。

話すことはまた、彼らが求めていることが本当に重要であるかどうかを確認させます。

「本当に必要なのか」になれないと思います。顧客との議論。個人的に、「これによりあなたの会社はより多くのお金を稼ぐことができますか？」しかし、問題の事実は、一部のマネージャーは、何らかの理由でそれを追跡することを望んでおり、彼らは彼らの方法を取得することに慣れています。やりたくない場合は、「いいえ」と言うか、そのような多額の料金を請求して、要求を思いとどまらせます。

アプリケーションがより多くの顧客フィールドを簡単に処理できるようにする方法の検討を開始します。

1. 既存のフィールドを利用するために、レポートとフォームのラベルを顧客が設定できるようにします。
2. 汎用フィールド（String12）を既存または追加のカスタムフィールドテーブルに追加します。
3. これがすべてデータ入力によって処理され、テーブルに新しい列を作成する必要のないユーザー定義のフィールドシステムを使用します（これがヘルプと呼ばれるものを思い出せません）。

既存の顧客がシステムを成長させていることに気付くかもしれません。業界は変化しつつあるため、新しい要件が浮上しています。

申し訳ありませんが、利益ではなく純粋に技術的な理由で顧客が望むものを提供できない場合は、ペースを上げる必要があります。新規参入者がより多くの分野で市場に参入することは難しくないので、それを起こさないでください。

しばらくウィンドウの反対側から見ると、最後の仕事で、エンドユーザーが任意のエンティティ/テーブルに「カスタム」列を追加できるERPシステムにさらされました。私との簡単なやり取りから、1対1のマッピングで2番目のテーブルに列を動的に追加しているように見えました。例えば：

静的列を持つWIDGETテーブル：

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• 等

ユーザー定義可能な列を持つWIDGETCUSTOMテーブル：

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• 等

WIDGET_ID列はそれらを結び付けることができます。ウィジェットを編集しているときに追加のフィールドが自動的に表示され、動的レポートに追加したり、ウィジェットで検索したりすることもできます。データベースは引き続きそれらを追跡し、必要に応じてそれらの列にインデックスを付けることができるため、かなり効率的でした。

プログラミングの観点から見ると、正気を保つ方法がわかります。すべての顧客が独自のカスタム列を持つことができますが、これらのカスタム列はコアロジックに干渉しません。

機能の「リクエスト」は、まさにリクエストです。彼らが要求している場合は、それでコードベースを「乱雑にする」ことが会社にとってどれだけ価値があるかを決める必要があります。それが風土病の問題になった場合、それを抑えることができますが、彼らがあなたが求めているものまたはそれに近いものを喜んで支払い、それがあちこちのいくつかの機能であるなら、私はお金で行くと言います。

さらに進むと、これが製品の絶え間ない問​​題であり、複数の顧客がこの種のカスタマイズを探している場合は、おそらくアプリのこれらの部分を再考し、顧客がこれを実行できるように柔軟にする時間ですアドホックレポート、柔軟なデータ収集などです。これらの煩わしさをセールスポイントに変えてみてください。「当社のストックデータモデルは十分ではありませんか？カスタマイズオプションをチェックしてください！あなたは自分でそれを行うことができます！」

この機能で何をしようとしているかを正確に特定し、それを構築するために推定時間を適用する必要があります。お客様が追加で問題のないフィールドが必要な場合は、請求を行います。私は顧客に、機能を構築した後に機能を追加したい場合はそれでいいと言いますが、場合によっては機能させるのに少し費用がかかります。

私はあなたが彼らがそれを使うかどうか気にする理由を理解するのに苦労しています。それは簡単です、あなたは彼らが望むものを構築し、あなたはそれに対して支払いを受けます。

コードベースの混乱？新しい機能で作業しているときにコードをリファクタリングする必要がある場合は、料金を請求してください。

「いくつかの追加フィールド」の追加など、追加を検討するいくつかの機能のリストを作成します。リストを顧客に表示し、どの顧客が最初に欲しいかについてフィードバックを求めます。リソースが限られており、一度にすべてを実行できないことを説明します。フィードバックを使用して、アプリケーションで使用する方向を決定します。

顧客はいくつかの余分なフィールドが実際にあると主張している場合はその重要な、あなたはまだそれらを追加していない上決定し、うまくいけば、顧客はまだあなたが代わりに実装している機能の利点を見ることができます。

何らかのプルシステムの恩恵を受ける可能性があるようです。次に実装する機能をユーザーが選択できるようにしますが、いつでも開発できる数を制限します。これにはかんばんボードが最適です。これにより、ユーザーに優先順位付けプロセスの所有権を与えることができます（責任が軽減され、ストレスが軽減されます）。ユーザーが次にどの機能を開発するかを決定することを余儀なくされ、他のリクエストが脇に置かれることを知っているなら、彼らは本当に必要なものを決定するためにもっと多くを投資するでしょう。

顧客に「オフィスでの1日」を体験してもらい、彼らが実際にソフトウェアをどのように使用しているかを確認するよう依頼する必要があると思います...待ってください。また、金メッキをしないでください。そのまま動作させます。ほとんどの企業は、うまく機能していてもitく見えることを気にしません。

リクエストを追跡します。大きな機能の設計/開発に着手したら、そのリリースに含める優先度の高いリクエストをいくつか選んでください。

リクエストの標準交渉システムを構築します。たぶん、fogbugzのようなバグ報告システムまたは機能要求システムに基づいたものです。顧客がリクエストを送信できるようにし、以下に基づいて優先順位を付けます。

• 機能の技術的実現可能性/コスト
• 機能リクエストは「有料」のものですか？それが契約にある、および/または彼らがそれを支払ったならば、それを入れてください
• 機能は「意味をなす」のでしょうか？これは少し芸術ですが、一般的に、十分な顧客が機能を要求した場合、無料で実装します。製品を改善し、次の顧客への販売をより簡単にする機会です。
• 未使用の有料サイクルがありますか？契約の一部としてメンテナンス/サポートの月間時間のセットを含める場合（数が非常に少ない場合でも行うことを強くお勧めします）、それらが慣れていない場合は、これらの種類の変更を行ってそれらを投げ始めます

顧客がアプリケーションの完全な所有権を持っている場合、彼らが尋ねることを行います。彼らに彼らのお金を吹き飛ばしましょう。それは彼らのものです。

ただし、そうでない場合は、これらの補助フィールドのソリューションに進み、コアデータモデルの外部にそれらを格納する必要があります。その後、データベースビューのようなものを使用して、この特定の顧客用の追加フィールドをマージできます。（保存されているデータの性質に応じて、補助ストアを実行する方法がいくつかあります。最も単純なのは、メインテーブルの一部のPKと同じ主キーを持つテーブルですが、使用時には非効率的ですフィールドの非常にまばらです。これは、インデックス作成などを必要とするフィールドの機能が必要な場合にのみ本当に問題になります。）

この段階でそれらを実装するのに十分なリソースがないという顧客の要求を先送りすることもできます。その時点で、あなたが望むものを安く実装することが可能になるとき（であなたの最善の見積もり）と言うロードマップを指すと本当に役立ちます。また、メタ機能はメインアプリケーションの主要な販売機能となるため、機能を安価にサポートできる状態にすることを優先する必要があります。