21

クライアントが 2 週間ごとに新しい機能を要求するフリーランスの Web アプリケーション プロジェクトがあります。今後の機能の要件を予測することはできません。したがって、クライアントが新しい機能を要求すると、次のいずれかが発生する可能性があります。

  1. 既存のプラットフォームと互換性があるため、機能を簡単に実装できます

  2. プラットフォームの基盤の大部分を書き直さなければならないため、機能を実装するのは困難です

  3. クライアントは、既存のプラットフォームに対して実装するにはコストがかかりすぎるため、リクエストを取り下げます

プロジェクトの開始時、約 6 か月間、システムが小さくて機敏だったため、すべての機能要求がカテゴリ 1) に分類されました。しかし、過去 6 か月間、ほとんどの機能の実装はカテゴリ 2 に分類されました)。システムは成熟しているため、新しいモジュールを追加するたびにリファクタリングとテストを行う必要があります。さらに、以前は機能していたものを壊し、修正していることに気づきました (これに対して報酬はありません)。

クライアントは、私が新機能を実装するための時間と費用に不満を表明し始めています. 彼らにとって、機能要求の多くは、6 か月前に要求した機能と同じ規模です。たとえば、クライアントは、「昨年はチケット システムを構築するのに 1 週​​間かかったとしたら、今日イベント登録システムを構築するのに 1 か月かかるのはなぜですか? イベント登録システムはチケット システムよりもはるかに単純です。 1週間しかかかりません!」このシナリオのため、機能要求はすぐにカテゴリ 3 に分類されるのではないかと心配しています)。実際、私はプロジェクトをサポートするために何時間もボランティア活動を行っているため、すでに多くの費用を自分で負担しています。

何かをするのにかかる時間を正直に話すと、クライアントはしばしばショックを受けます。クライアントは常に私の見積もりをプロジェクトの初期の月と比較します。成熟した Web アプリケーションを開発、維持、サポートするために実際にかかる費用に対して、彼らは準備ができていないと思います。

フルタイムの会社で給与を計算していたとき、マネージャーは私の見積もりをより受け入れてくれ、予想外の事態に備えて数字を埋めるように勧めさえしました. クライアントが同じように考えるように調整する方法はありますか?

この Web プロジェクトにあまりコストをかけずに作業を続ける方法について、誰かアドバイスをいただけますか?

追加情報- 私はフルタイムで 1 年しかフリーランスとして働いていません。私はまだハイエンドのクライアントを持っていませんが、ゆっくりとそこに到達しています. 時間が経つにつれて、より質の高いクライアントを獲得しています。

4

4 に答える 4

10

アーキテクチャに技術的負債があるように思えます。変化に対して脆い。さらに、適切なタイミングでテストを行っているかどうかも明確ではありません。テストを記述するのに最適な時期は、コードを記述する前であり、テストがコードの実行可能な仕様として機能するようにします。

堅牢なアーキテクチャは、クラス間の分離を促進することで変更を促進する必要があります。これにより、新しい機能が追加されたときの変更の伝播が制限されます。健全な結合よりも多くの結合があるように聞こえますが、コードを見ずにそれを判断することはほとんど不可能です。症状についての説明を読んでいるだけです。

このような場合は、基盤となるアーキテクチャの改善に時間を費やす価値があるかもしれません。基礎となるシステムがクライアントの要件に適合しなくなったこと、および将来の変更をより迅速かつ安価に行えるように、今しばらく時間がかかる必要があることを、クライアントに率直に伝えてください。これのいくつかはあなたのせいである可能性があります-もしそうなら、それについても正直に言ってください. 新しい機能をサポートするために必要なアーキテクチャの変更をクライアントが選択することを期待するのは、不合理だとは思いません。ただし、それが部分的に経験不足の結果である場合は、コストの一部を自分で食べて、それを学習経験と見なすことができます. そうしないと顧客を失う可能性がある場合は、とにかくこれを行うことをお勧めします。

于 2010-03-22T02:50:20.250 に答える
6

最近、自分でフリーランスの仕事をしていて(別の分野ですが)、契約に2つのことを組み込みました。a) フレームワークに大きな (私の意見では) 追加/変更が加えられた場合、それぞれが個別の納品要件と費用を伴う個別のプロジェクトとしてカウントされます。b) 適切なレベルのドキュメントを提供して、私の「見積もり」に満足できなかったので、他の人を試すことができました。

1 人のクライアントにオプション b を 1 回試してもらいました。彼らはかなり早く戻ってきました。

于 2010-03-22T02:40:39.270 に答える
2

この 2つの記事を見てください。

于 2010-03-22T02:52:00.620 に答える
1

この Web プロジェクトにあまりコストをかけずに作業を続ける方法について、誰かアドバイスをいただけますか?

透明性とコミュニケーションは最高のツールです。以前は 1 週間かかっていたことが、今では 3 週間かかっている理由をクライアントが理解できない場合は、より適切に説明できる必要があります。クライアントの専門分野によっては、たとえば、モデル T フレームでプリウスを組み立てようとしたり、母音のないタイプライターで戦争と平和を書こうとしたりして、彼らに共鳴する比喩を見つけることができるかもしれません。正直な見積もりを恥じたり、いじめられたりしないでください。そして、あなたのプロセスや直面している障害について、できる限り多くのことを顧客と共有してください。

技術的負債の問題に関しては、これが根底にある問題であることに同意しますが、TDD は、広範なテスト カバレッジが許す頻繁なリファクタリングと同様に、あなたを遠くまで連れて行ってくれます。すべての変更を簡単に許可する設計を考え、テストとリファクタリングを使用して段階的にその設計に取り組みます。機能はすべて既に支払われているため、そのコストを負担する必要があるかもしれません。ただし、将来を見据えて、リファクタリングのコストを見積もりに含めてください。これをパディングと考えないでください。パディングは (ほぼ間違いなく) 不誠実です。将来の変更に対応するためにコードの設計を維持することは、あなたの仕事の誠実な要件です。

于 2010-03-23T15:02:51.963 に答える