カスタマイズをクライアントに販売しようとしている営業担当者と Bean カウンターがいますが、これは問題ありません。しかし、私が多額の見積もりを返送するような複雑な変更依頼が来ると、彼らは混乱します。多くの場合、彼らは「なぜ別の列を追加できないのですか?」と私に言い返してきます。別の言い方をすると、クライアントごとに十数個のカスタム列を意味します。
これまでのところ、「データベースを適切に正規化しようとしている」ということしか言えませんが、これは彼らにとって何の意味もありません。私は、各クライアントが独自のカスタム フィールドのセットを定義できるテーブルのシステムを作成できると伝えましたが、もちろん、「数列を追加するだけ」よりも時間と費用がかかります。そしてもちろん、彼らもケーキを食べたいと思っています。
では、どうすれば彼らに理解してもらえるでしょうか？
私は、各クライアントが独自のカスタム フィールド セットを定義できるテーブルのシステムを作成できると伝えましたが、もちろん、「数列を追加するだけ」よりも時間と費用がかかります。
カスタマイズ性は明らかに需要の多い機能であるため、このオプションを上司にプッシュする必要があると思います. クライアントごとに個別にカスタマイズされた (一般化された制限されたカスタマイズ可能性ではなく) システムは、個々のクライアントごとにパッチと更新を作成する必要があることを強調します (ロールアウト時間が長くなり、コストが高くなります)。標準化されていないインストールは、ヘルプデスク チケットのクローズに時間がかかることを意味します (クライアントの不満とコストの増加につながります)。等
言い換えれば、彼らのソリューションのコストがあなたのソリューションのコストをはるかに上回ることを示すことによって、長期的な利益のために短期的な痛みを売ります。
営業担当者は、販売を行うことに集中しています。それが彼らのコミッションを得るものです。彼らはその後に何が起こるかを気にしません。ただし、ボスはコストに重点を置いています。上司に販売すれば、上司は営業担当者に販売できます。
私が見つけた最良の方法は、彼らが求めているものから新しい機能を作成する方法を示すことです.2、3のカスタマイズされた列だけでは追加できません. 特に誰かに請求できる場合は、カスタマイズよりも機能の方が優れています。
技術的な話に入る前に、あなたの側にとって良いビジネスケースを作るようにしてください。
ああ..少しの知識は危険なことです。
これを試してください：
あなた：どの会社に売れなかったのですか？
営業： Acme Industries、OCP Corp、何とか何とか何とか
あなた： ええと....どうしてもう2、3回電話をかけられないのですか？
もちろん、その答えは、販売はそれほど単純ではないということです。ソフトウェア開発もそうではありません。彼らがアーキテクチャとメンテナンスに関して何時間もの説明を本当に望んでいない限り、私は彼らがソフトウェア開発者としてのあなたの判断を信頼することを提案します。
これがここでの問題です、信頼してください。これらの発言をすることによって、彼らがあなたの能力に対する信頼の欠如を示していることを彼らに説明する必要があります。
設計が不十分なデータベースは、長期的には次のことを意味することを彼らに伝えることができます。
彼らがデータを取得するのにもっと時間がかかります - 彼らは本当に待って待っていますか?
レポートを生成するためのクエリを設計するのは難しく、時間がかかります。また、明日そのクエリが必要になった場合、まだ作業中であることを伝えたいですか?
エラーが発生しやすいクエリが作成される可能性が高くなり、維持するのは悪夢になります。
彼らが営業担当者や豆売り場であれば、万能ドル（ポンド、ユーロなど）を確実に理解しているでしょう。これらの余分な列を維持するために費やされた時間が、売上の増加に見合っていないことを証明できますか?
ここでは十分に注意して、自分の主張が理にかなっていることを確認してください。私はこれまで、自分のかなり小さなドメイン モデルを醜くしたくないという理由で、カスタマイズを行うことに抵抗を感じていました。それは、保守が本当に難しいからです。適切な分析は、カスタマイズに抵抗している理由を判断するのに役立ちます。
覚えておいてください - 肝心なのは、ビジネスを続けるためにはクライアントを満足させ続ける必要があるということです. 私たち思慮深い開発者は、物事を保守可能でシンプルなものにするために、そのことを見失うことがあります。
Googleの「技術的負債」; 結果を見せてください。
カスタマイズとともに製品を販売するビジネスをしている場合、製品は、販売するたびにビルドをフォークすることなく、カスタマイズをサポートする必要があります。
あなたはそれを説明しようとしたように聞こえますが、役に立ちませんでした。代わりに、1 つのテーブルに「適切な方法でカスタマイズ」を追加するコストを見積もってみてください。たとえば、さまざまなカスタマイズを含む製品の半ダースのバージョンを維持し、それらのバグを修正します。私の予想では、統一されたコードベースとスキーマを持つことで、彼らはすぐにお金を稼げることに気付くでしょう。そして、気が狂わない開発者。
人々が車を作った後、以前よりも速く走り、より多くのことを行うモデルが必要な場合、通常は別のエンジンを追加しないことを伝えます.
問題は、「データベースを適切に正規化しようとしている」というのは、ほぼ確実に間違った答えだということです。
焦点を最終目標に戻さなければなりません。その最終目標を達成する最善の方法 (おそらく複数のリリースで) と、短期的および長期的にどのような費用がかかるかです。回答で技術的負債について言及しているのを見たことがありますが、コストの見積もりではそれらの要因を考慮する必要があります。
「別の列を追加するだけですか？」というのは悪い考えではないかもしれません。あなたは本当にビジネスケース全体を与えていません。一方、彼らは無知な技術的な質問であなたの否定的な回答に異議を唱えました。彼らは「いいえ」と聞くのを好まなかったので、それはあなたが要件を理解するのを助けることの核心にはなりません. （問題の元の文が何であったか知りたいです。）
データベースを正規化することは技術的な問題であり、システムが満たさなければならない要件には関係ありません。保守性などの特定の特性を持つシステムを提供するために使用するシステム設計の原則です。しかし、ユーザーのニーズを満たしていない保守可能なシステムの価値はゼロですが、ユーザーのニーズを満たしている保守不可能なシステムの価値はゼロではありません (メンテナンスのコストがそれを超える可能性があります。これはビジネス上の問題です)。EAV やその他のメカニズムが必要かどうかも重要ではありません。システムの複雑さやコストが増加するだけです。
要件が高すぎて実装できない場合、それはビジネス ケースの一部です。これらのテーブルがモデル化するアーキテクチャやエンティティの種類について十分に説明していません。100 人のクライアントがいるとします。特定のエンティティの列に重複がある場合があります。クライアントの 95% は、オプションの請求先住所やミドルネームの列をまったく使用しませんが、これらの列が省略されているわけではありません。それだけでなく、多くの場合、オリジナルのデザインになっています! または、これが Products テーブルで、すべてのクライアントが多くの特別な列を必要とし、重複がない場合は、代わりにユーザー定義のフィールド システム (EAV/XML/タグ - 設計は要件に一致する必要があります) が必要になる場合があります。まとまりのあるシステム設計を維持します。
ビジネスが技術的負債の議論を無視することはめったにありません。特に、提案されたソリューションがユーザーのニーズを満たすことが示され、柔軟性がセールス ポイントになる場合はなおさらです。私が見つけたのは、解決策の選択肢をできる限り迅速かつ徹底的に提示することで、解決策の選択肢をできるだけ迅速かつ徹底的に提示した方が、企業は多くの場合、何かを実行できない理由やコストを説明するのに時間をかけずに好むということです。午後と実際に仕事を終わらせます。
私はこれを自分で試したことはありませんが、考えたことはあります。法制度との類似性を考えてみてください。法律の抜け穴が存在するのは、立法者が怠惰な手口でシステムにパッチを当てようとするためです。ソフトウェアに相当するものは、バグ、セキュリティ ホールなどです。これらの問題を回避する唯一の方法は、慎重な計画とハードワークです。
開発時間にどれだけの費用がかかるかを彼らに理解させます。この変更には1人か2人の開発者の時間が必要ですか？テストはどうですか？複雑な要求のコストが高くなると、会社全体の仕事の負担が減ります。アカウント/プロジェクトマネージャーは、これらのタイプのリクエストをバッファリングするのが仕事の仲介者である必要があります。
技術的な用語で彼らに説明することはできません。比喩が必要です。可能であれば、話している相手に合わせて調整してください。彼/彼女が車好きなら、エンジンの改造について考えてもらいます。トーラスに 3 つの異なるモーターを提供したり、オンデマンドでカスタム改造したりすると、フォードはいくらかかりますか?
彼らがその比較を受け入れると、たとえそれを完全に理解していなくても、比喩が適用される理由を理解し始めることができます.
彼らがあなたのやり方でそれを見るのを助ける別の素晴らしい方法があります-彼らのやり方でそれを見るために少し時間をかけてください. 給料が顧客が望むものを提供することにかかっている場合、エンジニアリングのプロペラヘッドがあなたに言うことは気にしません. カスタマイズの要求が多い場合は、可能な限り、それらのカスタマイズを提供するためのアーキテクチャおよび戦略的アプローチを検討する必要があります。
...各クライアントが独自のカスタムフィールドのセットを定義できるテーブルのシステムを作成できると彼らに言いますが、もちろんそれはより多くの時間とお金がかかります...。
ある種の汎用データモデルを構築したいようですか？エンティティ属性値...？
これらの汎用モデルは非常に低速であることが多く、適切にインデックスを作成できず、クエリオプティマイザを混乱させます。多くの場合、いくつかの列を追加する方がよいでしょう。
一般的な道を進む前に、非常に徹底的なベンチマークを実行してください。
たぶんそれはdbベンダーに依存しますが、Oracleを使用する場合は、entity-attribute-value-roadの上に「いくつかの列を追加するだけ」の道路をお勧めします。
tuinstoel の提案を拡張するには (一般的なエンティティ属性値構造を避ける): 私は通常、この構造を軽い使用に適していますが、過剰な (それが何を意味するにせよ) 使用は、前述のようにパフォーマンスを低下させます。このような構造は適切に索引付けできません。私はそのようなシステムの 1 つを作成し、サポートしました。それぞれが 10 ～ 100 個のキーを持つ 50,000 個の "エンティティ" を持つようになるまでには、ミッドレンジ ハードウェアでも低速でした)。
ただし、これらは非常に便利で、実装がかなり簡単です。したがって、顧客ごとに多くの任意の「追加フィールド」を追加する必要がある場合は、最も理にかなっています。
別の可能なオプションは、クライアントが独自の目的で使用する適切なテーブルに未使用の汎用列を追加することです。一部のエンタープライズ アプリケーションはまさにこれを行います。Sales テーブルには CUSTCODE01 から CUSTCODE10 までの列が 10 個から 20 個ある場合があり、アプリケーションの展開ごとに異なる完全にカスタムの方法で使用できます。
これは一見恐ろしく見えるかもしれませんが、幸せな媒体かもしれません. a) 「列を追加するだけ」でアプリケーションや開発プロセスを中断したり、b) 遅くなる可能性のある一般的なシステムを実装したりすることなく、顧客ごとにカスタマイズする余地がかなりあります。ただし、限られた量の柔軟さしか得られず、自己文書化された列名がありません (ただし、列の説明は必要に応じてカスタマイズできます)。
この問題は、図書館と比較して説明できます。多くの本があります。小さいものと大きいもの、薄いものと厚いもの、それは誰もが想像することでしょう。より多くの情報をどこかに保存したい場合は、いくつかの単一ページを拡大するよりも、新しいページをいくつか本に追加する方が簡単です.本に他のページよりも大きなページがいくつかある場合、これはあまり堅牢ではなく、どのように見つけますかコンテンツのインデックスにエントリがない場合、この情報は? おそらく、新しい追加情報を別のブック、つまり特定の構造を持つ新しいブックに格納する方がよいでしょう。図書館のすべての内容が 1 冊の分厚い本に書かれているとしたら、どのように情報を得ることができるか想像してみてください。あなたが欲しいものを見つけて本を元の場所に戻すまで、他の誰も何も見つけることができません... この巨大な本を運ぶことができれば.
言及された人々は、データベースのアーキテクチャを理解する必要はありませんが、あなたを信頼する必要があります。そして、データベースのこの大きな穴に情報を投げ込み、必要なときにいつでも情報を取り戻すことができるように、それを整理します - 迅速かつ確実に。