プロジェクトを間違った方向に進めていることを顧客に説明することはできません
新しいハードウェアのためにいくらかのお金を必要としているジュニア開発者である私は、フリーランスのウェブサイトの多くに出くわしました、そして本当にすぐに、私は私の最初の顧客を獲得しました。中小企業向けの完全なプロジェクト管理、CRM、およびシンプルな会計Webサイト。用語について話し合っているときに、インターンシップで過去2年間GAEプロジェクトに取り組んできたので、GAE/Python/Bootstrap/NDBを提案しました。支払い、条件、非開示について話し合い、プロジェクトへのアプローチを提供します（私が綿密に学んだことの道をたどりました）。
最初に3つのフェーズでバックエンドに取り組むことを提案します。
- 会社/ユーザーシステム+プロジェクト管理
- CRM
- 分析/単純会計（彼が後で追加した直感的な統合）
その後、UIの開発とテストを2週間行いました。
最初に、3つのフェーズすべてで開発してほしい機能は何ですかと彼に尋ねました。彼の返事は、私が彼に求めた文書を準備する時間がないということでした。それは私がばかげていると思い、私にそれを準備するように頼みました、そして彼はそれを編集します。もちろん、彼は編集をしませんでした。さて、彼が何を望んでいるのか明確な絵を持っていないクライアントの最初の兆候。
彼はテンプレートを購入し、いつテストを開始するかを尋ねました。そこで、2週間後にPMと会社/ユーザーのログインだけでアプリをデプロイしましたが、そのテンプレート以外のものはテストできないと言われました。文字通り、テーマのレプリカを作成しました。 、実際のテーマにあるもの（豪華な受信トレイ、カレンダーなど）は使用できないため
私は何でも自分に言い聞かせました。私が最初に採用したアプローチは、base.htmlとbase-nav.htmlを作成し、それらを他のテンプレートで拡張して、コードやその他のものを簡単にテストできるようにすることでした。私はこれをブートストラップ経由で作成しました。彼はそれをテストできないと繰り返した。
今、私はbase.htmlを作成するためにトリミングしなければならない4000行の長さのhtmlページで苦労しています。他のテンプレートで拡張します。テンプレートファイルで完全に整理されていないすべてのばかげた量の静的ファイルとテストしたい上司。彼は自分が何をテストしたいのかさえ知りません。
スクリーンショットを送信し、アプリをデプロイし、毎日チャットしましたが、最初にフロントエンドではなくバックエンドに焦点を当てるべきだと彼に納得させるには十分ではありません。
それは車を作るようなものです。最初にエンジンを作ってから外側をそれに合わせて調整するのではなく、最初に外側の部品を作ってエンジンを制限したいと考えています。
これに取り組み、解決するためのヒントはありますか？
テンプレート- http://www.keenthemes.com/preview/index.php?theme=metronic_admin
The Iceberg Secret、Revealed でのJoelのアドバイスを検討してください。テンプレートをバックエンドの実装状況とまったく同じように見栄えよくし、そのようなすべてのスクリーンショットと進捗レポートをこの方法で提供します。機能の欠落や破損の代わりに、ワイヤーフレーム、プレーンテキストのプレースホルダー、および同様の醜さを使用します。クライアントに「バックエンドを終了するのにX時間かかる」と言う代わりに、「これは醜いことはわかっています。この機能を正しく動作させるにはX時間かかります」と伝えます。
理想は、醜いプロトタイプを見ているときでも、クライアントがstillフローをテストすることです。モックアップ（正しく見える）とフローチャートでこれを回避できるかもしれませんが、クライアントがフローの検証を支援することを拒否した場合、あなたは運命にあるかもしれません。
もちろん、このアドバイスに従うには遅すぎます。
将来的には、事前に契約書を使用してクライアントとあなた自身の責任の概要を説明することを検討してください。これはあなたに何人かの顧客（主に難しい顧客）を失いますが、誰もが怒るポイントに到達することからあなたを守ります、あなたはあなたが期待した2倍の時間を費やしました、そしてあなたのクライアントは彼らを満足させなかったためにあなたに支払うことを拒否します。
これは正常です。顧客はこれとそれを行う何かを望んでいますが、これとそれを達成するための最良の方法を正確に確信していません。あなたは専門家です、彼らは彼らのビジョンの欠けている部分を埋めるためにあなたに頼っています。あなたは彼らが一緒に働くのに十分なものを与える必要があります。そうすれば彼らはそう言うことができます。そうです、それが私が望んでいたことです。通常、これは機能するUIプロトタイプの缶詰です。したがって、最も確実に、UIは絶対に最初に取り組むべきものでなければなりません。
また、顧客がプロジェクトのすべての詳細に密接に関与する時間がある、または彼らが彼らが望むものを正確に知っていると信じることは非常にナイーブです。それが彼らがあなたを雇った理由です。プロジェクトを推進します。彼らが忙しくてフィードバックを提供できない場合は、あなたが何をしているのかを伝え、後で変更が必要な場合は、次のように指摘します。「ここで定義されているようにユーザーインターフェイス画面を実装しています。COBによるコメントを確認して提供してください。 7月18日。」彼らがあなたに返事を返さなかった場合、私はそれを暗黙の承認とみなし、後で変更を加えると追加料金がかかります。
UIの確認について。通常、顧客がプロトタイプを試してフィードバックを提供することを期待するよりも、デモを提供するのが最善です。直接デモを行うことができない場合は、WebExセッションなどを手配してください。