「これは単なる小さなアプリケーションになります」という旧式のアプローチ方法は？ええ、その通り？

私はこれに何度も遭遇しましたが、ここではやや誇張された最悪のシナリオがあります。

クライアントは、「この小さなタスクを実行するために、この小さなモジュールを作成してもらえますか」と言います。
私：「問題ない」。

そのため、予算や制約などに基づいて、設計の一部をスキップし、すぐに飛び込み、汗をかかないようにします。

次に、別のモジュールを要求します。そしてもう一つ。そしていくつかの機能強化。そして、これはすべて、長年にわたって非常にゆっくりと起こります。そして、あなたがそれを知る前に、あなたは恐ろしく設計されたこのモンスターアプリケーションを持っています。

何か小さなことをするように頼まれたらどうしますか？それが成長し続けるかどうかはわかりません...クライアントが追加を要求し続けるなら（そして、どちらもしません）。

結局のところ、それは単なる小さなアプリケーションであるため、オーバーアーキテクトすることはできません。あなたが言うなら（私はすべての声を知っているということで） -o-the-lineセキュリティと懸念の分離。実際、このことを本当に素晴らしいものにする、依存性注入ツールを使用してみましょう。

彼らは「そうだ」と言い、他の誰かに行きます。

予算、時間、認識は、アプリケーション自体の設計と同じくらい重要です。

これにどのようにアプローチする必要がありますか？

質問は、「小さなアプリケーションのように見えるものの最終結果に関するすべての情報が得られない場合、アーキテクチャおよび設計の決定を早期に行うことを完全に回避する（または軽減する）方法」後で不適切ですか？

私はこれらの多くに出くわしましたが、私が普段やっていることはまさにあなたがやったことで、すぐに飛び込んでそれをやり遂げることです。

彼らがもっと戻ってきたとき、それは彼らのビジネスモデルが機能していることを意味し、彼らはもう少し投資したいと思うべきです。そのとき、私は彼らを座らせ（通常は複雑さに応じて3番目のモジュール）、悪い知らせを伝えます。

私はテーブルの上にすべてを置き、最新のモジュールを含む全体をやり直すことを申し出て、どれくらいの費用がかかるかを彼に伝えます。通常、開始時にステッカーショックが発生しますが、良好な仕事上の関係があり、自分のスタッフが機能していれば、大きな問題にはなりません。

ただし、次の3つのことを理解してください。

1. 彼らが本当に完全な書き換えに煩わされたくないのであれば、あなたはまだ3番目のモジュールをするでしょう。さらに数時間かかる場合があります。将来的に書き換えを行うことを本当に検討する必要があることを思い出させてください。待ち時間が長いほどコストが高くなります。

2. 他の誰かにそれをやらせるには、彼らにもっと費用がかかるでしょう。新しい人は、自分のニーズと癖を最小限に理解してすべてを再設計する必要があります。これは、余分な書き換え時間と、彼がうまくやらないリスクを意味します。

3. あなたが手っ取り早く金を稼ごうとしていないこと。物事は再設計が必要です。

ところで、もしあなたの請求習慣が今の半分、終わったときの半分のようなものなら、あなたは彼らに延長支払い条件を提供することを検討するかもしれません。今すぐ半分に変更し、作業する期間にわたって残高を分割します。予算に問題がある場合は、ピンチを減らすことができます。

ただ彼を小さなアプリにして、それに対する報酬を得てください。

私の経験では、顧客がもっと欲しい場合に備えて、最初に本当に必要な時間よりも多くの時間を投資することは魅力的です。しかし、あなたはそれをする際にエフォードに重みをつけなければなりません（あなたはそれに対してお金をもらえますか）対これらすべての追加の変更が実際に起こる可能性。1年後にアプリ全体が完全に置き換えられる可能性があります。

そして、初期のアーキテクチャに時間をかけることで、あなたは自分に好意を持っていると感じるかもしれません。しかし、実際には、他のモジュールを安くすることで、顧客に有利に働きます。

成功するモジュールごとに顧客にもう少し請求し、最初のプロジェクトを段階的にリファクタリングしますが、常に顧客のニーズに合わせます。

以前の回答は良いですし、正直なところ、おそらく何をするでしょう。とはいえ、このアプローチには、顧客が望むもの（および仕事を上陸させたいという願望）の仮定に基づいて、顧客に適切に属する決定を下すという点で少し不安です。

私は、顧客に正直であり、選択肢を与えることである必要があると感じることは避けられません。1.これを迅速に（比較的）安く実行できるようになりました。それは素晴らしいことです-それは動作します-しかし、将来の機能強化は少しずつ少しずつコストがかかります。新しい機能を追加する必要がある場合、長期的には費用を節約できます。

理想的には、時間と費用の概算を与えることができます-そうでなければ会話がアカデミックになりすぎる可能性があります-しかし、これらの数字に到達するのも手間がかかることを感謝します。少なくとも、以前のプロジェクトの観点から議論を組み立てることで、顧客の生活が楽になります（そして、顧客の生活を楽にすることが最優先事項です:-)）

良好な協力関係を築くために他の人から寄せられたコメントが注目されますが、そのプロセスを自分で正直に始めることができます。顧客があなたがその会話さえすることができない種類であるならば、今はあなたがこの仕事をどれくらい必要とするかを自問する時であるかもしれません...

これらの「反復」のそれぞれを個別のプロジェクトとして扱います。各小さなモジュールまたは追加が完了したら、これらのプロジェクトを閉じる必要があります。その後、彼らが何か他のものを望むとき、書類を下書きします。そして時間が経つにつれて、ソフトウェアはより高価になります...つまり、小さなプロジェクトごとに追加料金を請求することになります。

これは、LONGGGGGGプロジェクトではなく、1つの見方です。

アーキテクチャと設計の決定を早期に行うことをどのように回避（または軽減）しますか？

できません。プログラマーは超能力者ではありません。単純なことを予測したり、UIの改善を確認したりすることはできますが、後でクライアントが望むかもしれないとは知らないことを超えて実際にコーディングすることはできません（そこに狂気が見えますか？）。

あなたの質問は、ビジネスプロセスがあると述べましたが、それらが良いプロセスかどうかはわかりません。以下にいくつかのポインタを示します。

• 書面および予算で署名されたすべての変更と追加を要求します。
  • お支払いする請求書があるため
  • 文章と署名部分は、彼らが本当に欲しいものであることを確認し、クライアントがプロジェクトの途中で心を変える軽薄なものの90％を削減します

生い茂った製品

それは私たち全員に起こります。最初から再構築することは通常、ひどい考えです。特に将来再構築されることを考えると、特にそうです。

代わりに、ユーザーが要求した変更について契約します。各機能に余分な時間を追加します。元の時間を使用してその機能を使用し、余分な時間を使用してアーキテクチャ全体を改善します。目標は、1つの契約でアーキテクチャを完全に「修正」することではなく、代わりに徐々に時間をかけてチップを削減することです。

本当に重要な部分に焦点を合わせて、コードの反復を反復ごとにゆっくりと改善します。