すばやく -これは、顧客がアーティストを選択する前に（最も重要な質問に答える準備がまだできていないため、別のアーティスト）ことを意味します。
正確に -これは、ToRの承認後に発表された可能性のあるプロジェクトの実際のコストに十分近いことを意味します（開発に費やされた正確な時間量が既にわかっている場合は、プロジェクト後にさらに良い）。
そして最後に、 TKなしではどういう意味ですか？ TKなしのプロジェクトが実際にないことは明らかです（「そこに行く、どこにあるか、それを持って、何を知らないのか」というスタイル）。 もう1つ、顧客がこのTKをどのような形で提供しているか。
私の経験に基づいて、以下を区別できます。
技術仕様のレベル
レベル0
顧客は、少なくとも作業明細書に類似した何かを提供することはできません。 彼は、「演劇学校向けのCRMを開発する」または「 kakoy-to-site.comのようなことを行いますが、わずかな変更を加える」というフレーズでタスクを策定します。 おそらく、このフレーズには作業量を評価するための適切な量の情報が含まれていると思われるため、サービスのコストをすぐに指定する準備ができていないことは驚くべきことです。
レベル1
顧客は「TK」という言葉を、手作業またはExcelで描いたいくつかのプロトタイプ写真と呼びます。 Excelのプロトタイプは、私の専門分野（データベースとCRM）の注文の機能であり、顧客のニーズを理解するという問題をある程度解決することを明確にする価値があります。 他の場合では、プロトタイプ自体の品質は高いかもしれませんが、本質は同じままです-これらは小さな説明を含む単なる写真ですが、何がどのように機能するかについての詳細な説明はありません。 TKレベル1の反対バージョンも可能です-機能ブロックの簡単な説明で、どのように見えるべきかを示すものはありません。
レベル2
参照用語はかなり詳細な形式で存在します-画面のプロトタイプ、データ構造の説明、インターフェースの各要素のロジックがありますが、いくつかのあいまいさが残っています-開発されたシステムの同じ機能を異なる方法で解釈する能力。 たとえば、「マネージャーには注文のみが表示される」というフレーズの背後に隠されているものは何ですか？ 彼が作成した注文は？ または彼に割り当てられましたか？ または、このマネージャーが担当する顧客の注文はありますか？ これは、顧客との対話でのみ確認できます。
TKにはこのようなレベルと別の問題があります。 顧客は、システムのロジックだけでなく、このロジックの実装方法（使用するテクノロジー、適用するアルゴリズム）についてのアイデアも詳しく説明していることがあります。 これらの要件は何らかの方法で正当化される場合があります（たとえば、顧客はシステムを独立してサポートし続けることを計画しているため、自分に馴染みのある技術のみを使用することを希望します）。頭に浮かんだ最初のものを書いた。 この時点を明確にしないと、元の問題がはるかに簡単に解決されるという事実にもかかわらず、提案されたスキームを実装しようとして時間を浪費する危険があります。
レベル3
想像できる最高レベル。 原則として、これはTORの詳細を慎重に検討し、すべての論争のある問題を特定し、最終バージョンについて顧客と合意した後に達成されます。 やれやれ！ この場合でも、リラックスしてはいけません。開発中または試運転中はいつでも、顧客は自分にとって取るに足りないように思われるかもしれませんが、実際にはシステムの根本的な変更が必要になる場合があります。 または、一部の機能は顧客によって暗示されている場合がありますが、「それは明らか」であるため、作業明細書に明示的に規定されていません。
問題は、多くの場合、最初またはゼロレベルのTKしか持たず、同時に顧客がコストと条件に名前を付けるように要求することです。
このような条件でプロジェクトを評価する方法は？
目的のプロジェクトを取得するには、 適切な価格をすばやく指定できる必要があります。 どの価格が正しいと考えられますか？
一方で、コストよりも低くするべきではありません。そうでなければ、プロジェクトに取り組むことは意味がありません。 もちろん、この規則には例外があるかもしれません。 たとえば、フリーランスの仕事でキャリアをスタートし、評判とポートフォリオで仕事をするとき、あなたにとって重要なのは価格ではなく、「カルマにプラス」を得る機会です。 しかし、私たちは現在このオプションを検討していません-私たちはまだプラスとして機能するビジネスについて話していると仮定します。
一方、他の入札者がはるかに低い価格を提示した場合、価格が高いと顧客を怖がらせることができます。 例外もあります。 顧客が既にあなたとの共同作業に前向きな経験があり、適切な価格を設定していることを知っていて、この価格でタスクを効率的かつ期限内に完了できれば、おそらくより高いコストであなたを選択します ただし、この場合、顧客はあなたに直接連絡する可能性が高いため、競争力のある選択に参加する必要はありません。
したがって、開発コストをカバーするプロジェクトコストを設定する必要があります。 この場合、価格は他のパフォーマーのオファーとほぼ同じレベルになるか、（より高いことが判明した場合は）正しく実証できるはずです。
仕事の評価の段階でどのような間違いを犯す可能性がありますか（私の経験から）：
1. TORが正確な評価（レベル0または1）には短すぎる場合は、顧客に質問を明確にして質問に取り掛かり、夢中になりすぎます。 TKの議論は無期限に続く可能性があります。 この場合、顧客はまず第一に疲れる-なぜあなたが質問に答えるのか、それがまだ分からない場合、あなたは請負業者として選ばれるのか？ 第二に、豊富な質問はそのような問題を解決する経験の不足を意味するように思われます。
2.幸運で、参照条件が非常に詳細な場合（レベル2または3）、説明されているすべての詳細を考慮してプロジェクトを評価します。 タスクを取り、作業の段階を強調します。各段階は、評価しやすい小さな理解可能なタスクに分割されます。 その結果、プロジェクトの最も正確な評価を取得する必要があります-これには十分な情報があります。 ただし、このアプローチでは、評価が正確であるだけでなく高速であることも忘れられます。 TKの細部をすべて評価している間、顧客はあなたが彼について忘れたことを感じています。彼に手紙を書いたり、質問したり、具体的なことを何も提供したりしないでください。 そして、最終的に彼にプロジェクトの準備ができた評価を与えると、彼はすでにパフォーマー（それほど長くは考えていなかった）を見つけ、すべての努力が無駄になったことが判明するかもしれません。
3.他のパフォーマーによって提供される価格がすでにわかっている場合、それらに導かれ、より高い価格を提供することを恐れます。 この場合、注文を受け取ることもありますが、損失を出して注文する必要があります。これが必要ですか？
4. TORを見て、まだ開発されていないこのシステムを改善する方法を見つけた場合、顧客はプロジェクトの実施中にほぼ確実に生じるニーズをすぐに考慮することを提案します。 間違いは、あなたに明らかな詳細が顧客に見えないか、重要ではないかもしれないことであり、彼はあなたの懸念を追加料金で不必要な機能を課したいという欲求と見なします。
プロジェクトを今すぐ評価するにはどうすればよいですか：
まず、プロジェクトの主要な機能ブロックを詳細なしで定義します。 原則として、同じ方向のプロジェクトのこのようなブロックは非常に似ています。 たとえば、CRMには、顧客ベース、注文、マネージャー、権利の制限などがあります。 これらのブロックは、特定のフィールドセット、アクション実行時の動作が異なりますが、おおよその作業量は同じです。 プロジェクトの作業プロセスでは、まずすべての機能ブロックで計画された作業に時間を費やし、それから（時間が残っている場合）顧客の要望に応えることができます。 設定時間が終了すると、「作業明細書に明記されていることのみを行う」という合意を顧客に指摘します。 原則として、顧客は作業が完了したことに同意します。本当に希望を実現したい場合は、別途支払われる作業の次の段階に同意します。
メインブロックを特定した後、 潜在的な問題領域を特定します。説明されている機能はあいまいです。 これらは、「SMS配信システムとの統合」などのフレーズです。 ある場合には、そのようなフレーズは「どうにかして、私は気にしない」を意味するかもしれません。また、「私にとって完璧なSMS配信システムを選択し、市場で利用可能なすべてのシステムの比較分析によってあなたの選択を正当化する」ことを意味するかもしれません。 そのような場合、意味をすぐに明らかにするか、そのようなブロックを解決するためにより多くの時間とそれに応じてお金をかける方が良いです。
そして最後に、プロジェクトに原則として簡単に解決できるタスクがあるが、まだ関連する経験がない場合は、そのような問題を解決する方法をすでに知っているという前提でそれらを評価します。 そうすれば、コストは他のパフォーマーのコストよりも高くなく、そのような問題を解決する方法を研究するために費やした余分な時間は、将来への投資と見なすことができます。 もちろん、プロジェクトにはそのような「成長のためのスペース」が多すぎてはならないことを理解する必要があります。
おわりに
プロジェクトを大きなブロックで評価し、同時に潜在的に危険な詳細を確認する機能は、経験とともにもたらされることは明らかです。 まず第一に、2つのルールに従うだけで十分です。
常にあなたの主な目標を思い出してください
目標がこの特定の命令を必ず受ける場合、明らかに自分にとって不利な条件に同意する準備をしてください。 目標が十分な努力を獲得することである場合、必要に応じて価格を正当化する準備をしつつ、プロジェクトの評価に最小限の労力と時間を費やすことを学びます。 そして、合理的な方法でさえ、あなたの価格が合わない人たちと、後悔せずに去ります。
前もって顧客の不当な主張から身を守る
作業中に開発の複雑さ（および、それに応じてコスト）を大幅に増加させるニュアンスが明らかになる可能性があると仮定した場合、合意された金額については作業明細書に明示的に記載されていることのみを行うことをすぐに顧客に通知します後で議論する準備ができています。