分析する前に、請求金額とソフトウェア開発プロジェクトにかかる時間を知るにはどうすればよいですか？
ソフトウェア開発では、通常、要件が満たされる分析フェーズが行われ、ユーザーインターフェイスが設計されます（UIを備えたソフトウェア用）。将来のタスクのために。しかし、通常、いくつかの会社で気づきましたが、分析フェーズはプロジェクトがすでに販売された後に行われます。しかし、少なくとも複雑なソフトウェア製品の場合、プロジェクトの計画や簡単な分析だけで、予算（より多くの利益）と時間を交渉する方法を知りません。それは通常、ソフトウェア開発契約が行われる方法ですか？それとも単に悪い習慣ですか？共有できる場合、クライアントとの最初の交渉の予算と時間をどのように見積もるか。
ソフトウェアプロジェクトを特別なものにする1つは、いったんすべてを完全に分析した後になると、基本的にその作業は完了です。もちろん、あなたが仕事を得るかどうかがはっきりしない限り、これをする余裕はありません。
したがって、通常はリスクを冒して、ほとんど知識のない見積もりを行う必要があります。多くの場合、要件の複雑さを、大まかな見積もりを得るためにすでに行ったプロジェクトと比較することができます。
リスクを軽減する方法はいくつかあります。
分析と仕様を個別のプロジェクトとして扱い、詳細な仕様とプロトタイプを出力として扱うように顧客に説得します。次に、顧客からフィードバックを得て、実装を見積もります。これはまだ滝に非常に近いですが、見積もりが予算を超える場合、いくつかの追加オプションを提供します
重要度の低い要件を削除してスコープを調整します。
顧客がプロジェクトを中止することを決定した場合でも、これまでに行ったことに対する報酬は支払われます。
顧客には、他の誰かに実装を任せるオプションがあります。
アジャイル開発方法を使用して、小さな反復で続行します。前のイテレーションが終了し、顧客からフィードバックを得る前に、イテレーションを計画および推定しないでください。
これらの方法のいずれかで進めるために、ウォーターフォール/固定予算の考え方を持つ顧客を説得するのは難しい場合があることに同意します。
他の人が言ったように、それは少なくとも部分的に当て推量ですが、あなたの当ては（できれば広範囲にわたる）以前の経験に基づいているはずです。完全に無知のままで、それでも興味がある場合は、固定価格の契約ではなく、時間単位で仕事をすることを提案します。しかし、あなたが正しく行動すれば、固定価格は毎時よりもはるかに有利になる可能性があります（平均して3倍の球場を確保します）。さらに、最終的にはより多くの支払いをすることになりますが、クライアントはしばしば幸せになります。
しかし、もう1つ確かなことをお伝えします。当て推量は必要ありません。重要なプロジェクトでは、本番環境に切り替える前に、ユーザー/クライアント/その他が考えを変えたり、新しいアイデアなどを考えたりします。
一部の開発者は、この絶対に避けられない開発に非常に動揺します。しかし、それは本当に良いことです。完全なバカなクライアントだけが、機能仕様を読んだり、プロトタイプで遊んだり、ユーザーと話したり、座ったり考えたりするなどして、新しい/変更された/などのアイデアを持ちません。 。開発は、その性質上、動く目標です。怒らないでください、準備してください。
しかし、クライアントは、新しい/変更されたアイデアの追加の遅延とコストに備える必要があります。それらがすでに存在するか、または生活の事実を可能な限り穏やかに説明していることを確認してください。私はそのような会話を紹介する穏やかな言葉を持っています、ここであなたと共有します（他の人には言わないでください）：それは "[〜＃〜] ttt [〜＃〜]"の意味です[〜＃〜] t [〜＃〜]ヒンジ[〜＃〜] t [〜＃〜] ake [〜＃〜] t [〜 ＃〜] ime。とてもかわいいので、威圧的ではありませんが（笑って言ってください）、ディスカッションの最初に全体的なポイントを伝えるのに役立ちます。
そして、開発中、不可避の変更が要求された場合、最もデリケートな議論は、対応する契約変更（より多くのお金を意味する）を交渉しています。クライアントは必然的に、彼らが今求めているものが実際にすでに元の契約にどうあるかを説明することから始めます。時間の約20％は議論の余地があります。それらの時折の出来事を認識し、それらが発生したときにすぐに来る以上のものであることを確認してください。しかし、彼らが煙を吹いている時間の約80％（どこで知っているでしょうか）。しっかりしていて友好的でなければなりません。クライアントとの良好な関係がすべてです。すべて。すべて。そのため、私はこの段落を「最も慎重な議論」を強調することから始めました。あなたは支払いを受ける必要がありますが、クライアントにそれを怒らせることはできません。
必要な時間が割り当てられていない場合や、期限が迫っている場合などがあります。これらの場合、実際にはすべての場合において、機能仕様には「リリース2.0の計画された改訂」というタイトルの付いたセクションが必要です。実際、リリース1.0で計画していたものが最終的にそのセクションに含まれる場合があります。
作業を開始する前に何かを完全に分析することは、不可能ではないにしても非常に困難です。試みることは多くの費用がかかり、おそらく 分析麻痺 につながります。一方、まったく計画のないプロジェクトに取り組むことは災害のレシピです。一部の企業がどちらか一方の極端に向かって引き寄せられているように見える理由はわかりません。それは確かにソフトウェア開発からすべての喜びを奪います。
自分で時間とコストを見積もる経験がない場合は、開発チームの総合的な経験に頼ることができます。これは、最初の会議でクライアントに見積もりをしないことを意味します。
- 基本的な要件についてお客様と話し合います。 2つのリストをブレインストーミングします。バージョン1.0の要件と、Nice-to-havesです。
- 両方のリストを開発チーム、または少なくともより上級の開発者が実行します。
- グループとして、各項目の大まかな時間を見積もります。開発者は、いくつかの要件が非常に困難になるか、またはいくつかのウィッシュリストアイテムが取るに足らないものであると言うかもしれません。
- アイテムが他のアイテムに依存する可能性があるかどうかに注意してください。
- リストを顧客に提示し、彼らが支払う意思のあるアイテムを彼らに決定させます。
- リストアイテムを契約に組み込みます。