サイトの参照条件

UPD： 参照条件の例による記事の続き

少し前まで、ハブに2つの記事がありました（ 参照条件と TKが必要な理由に よると、 私はすでに知っています！ ）技術的なタスクに専念しました。 どちらの記事も私を興奮させたが、それを控えめに言って困惑させた。特に記事「参照条件に従って」。 私の意見では、これは一般に有害な記事であり、TKの本質の誤解につながります。 この点で、私はこの問題に関する私の意見を表明したいと思います。 これらすべてについては説明しません。 割り当て、トピックは広すぎるが、私はサイトでTKについて話すことができると思います。

以下で説明する技術的なタスクの説明は、GOSTを改めて説明するものではなく、その創造的な処理であり、苦い経験が十分に反映されています。 以下で説明するTKへのアプローチは、サイト構築のすべての側面を網羅しているわけではありませんが、一般的な方向性を示しています。

ほとんどのサイトは、小規模および非常に小規模なプロジェクト（人月単位の規模）に起因する可能性があります。 このようなプロジェクトはサイズが小さいため、ウォーターフォールモデルを使用して簡単に考え出して実装できます。開発のすべての段階で怠laにならないだけで十分です（作業明細書の作成からプロジェクトの進行まで）。 これらのプロジェクトに柔軟な開発方法論を適用することは意味がありませんが、優れた技術仕様を適用することは理にかなっています。 ウォーターフォールモデルに該当しないサイトでは、以下に説明するアプローチを使用しないでください。

1. TKの必要性の正当化

そして、なぜあなたはサイトでTKを必要としますか？ 顧客は、「次のサイトが必要です。製品カタログ、バスケット、注文フォーム、配送、地図上にあります、私たちについて、フィードバック」。 明確ではないものは何ですか？ 異常なことは何もありません、すべては普通であり、日常的です。

開発者は何をする必要があるかを明確に理解しており、彼の理解では次のように行う必要があります。




作業の最後に顧客からデザインが届き、それを表示すると、顧客がタスクをわずかに異なる方法で理解していることが明らかになります。 そしてそのように：



そして、開発者が自分の結論に基づいて作成し、顧客に公開した作業量（および、それに応じてプロジェクトのタイミングとコスト）の初期評価は、顧客が実際に望んでいるものとは異なることがわかります。

ある画像を別の画像から「減算」して、いわば差分を作成すると、顧客の期待と開発者の計画に違いが生じます。 そして、この違いは非常に重要です。



そして、ここでは対立があります。そこでは、法の各当事者が合意した価格に対して期待したものを受け取っていないので、顧客は彼を「投げ」ようとしています。 請負業者は彼が注文ですべてを正確に行ったと信じており、「ウィッシュリスト」の残りはそれを「投げる」試みです。 この競合はさまざまな方法で解決できます。顧客が現状を受け入れるか、開発者がすべてを無料で終了するか、両方の当事者が相互に譲歩します。 しかし、いずれにせよ、犠牲者がいます。

そのため、技術的なタスクのタスクは、顧客と請負業者という2つの側面の表現の違いを最小限に抑えることです。 良いTKは少しの違いを与え、悪いTKは大きな違いを与えます。

ただし、非常に重要なポイントがあります：それら。 タスクはdiffをゼロにすべきではなく、できません！ 理由を説明します。

diffとTKの両方に価値があり、その価値は単なるお金よりも広く理解される必要があります。 これは、お金、時間、費やされた神経、壊れた関係などです。
diffのコストは、最初は条件付けられていない改善のコストであり、TKのコストは実際にはTKのコストです。 参照の詳細および詳細な用語は、コストが高くなりますが、差分の規模とコストは低くなり、逆も同様です。

二つの極端な場合、それらを考慮する場合。 単純にタスクはありません。 一般的に、写真ホスティングを行い、顧客がオンラインストアを望んでいた場合、diffはプロジェクト全体と等しくなり、そのコストはプロジェクトのコストと等しくなります（写真ホスティングを破棄してストアを作成する必要があります）。 さらに、TKのコストはゼロです。 もう1つの極端な例は、技術的なタスクが完成したプロジェクト自体である場合です。 それは完全に詳細です、すなわち コード、変数、CSSスタイルの行。 この場合、diffはゼロで、TKのコストはプロジェクトのコストに等しくなります（TKはすでに実装されているため）。 そして、これらの両極端の間には現実があり、このグラフに反映されています。



青い線はTKのコストであり、ディテールの増加とともに増加し、赤い線はdiffのコストであり、逆にディテールの増加とともにその値は減少します。

青い線は、TKの総コストと作業終了時に発生する変更を示しています。 グラフからわかるように、この合計コストには最小値があります。 つまり ある時点から、TKを完成させるよりも、作業の最後に顧客のウィッシュリストを修正する方が安くなります。

したがって、重要な結論： TKはプロジェクトを適切に説明する必要がありますが、それ以上のことはありません 。

以下で説明するアプローチは、最適レベルに近い詳細レベルでTKを主張するだけです。

2.その中にあるべきものとそうでないもの。 文言

参照条件は、実行する作業を管理する文書、合意の一部（印鑑や署名との合意、または口頭による合意であってもかまいません）です。 ToRに記述されているすべてのものは、客観的な評価の可能性を考慮すべきです。 つまり 特定の作業項目が完了したかどうかを判断できる客観的な基準が必要です。

これに基づいて、技術的なタスクでは設計について話すべきではないことがわかりました。 とにかく、タスクは技術的であり、芸術的ではありません。 デザインは、自分が好きなものの客観的な評価には役立たず、他の人は好きではありません。また、デザインが良いかどうかを判断できる客観的な基準はありません。

「緑色で、それは木になる」というタスクのステートメントを使用したデザインの実装は、悪い仕事であり、傑作になる可能性があります（特に悲しいことに、両方のオプションは顧客にとって快適ではないかもしれません）。 要するに、設計を説明する客観的な基準が満たされると、結果が悪くなる可能性があります。

一般的に、TKはあなたと顧客が同意しなかったように書かれるべきであり、あなたの論争はそれらのテキストに基づいて法廷で解決されます。 割り当て。 また、作業明細書には、「顧客が好むデザインを作成する」と書かれています。 審査員は「顧客、デザインが好きですか？」と尋ねます。 顧客：「いいえ、あなたの名誉！」 裁判官：「請負業者、私は参照条件を遵守しなかったため、シベリアで2年間の除雪を授与します！」

言葉遣いは「閉じた」ものでなければなりません。 作業の境界を明確に示します。 TKでは「管理者は快適であるべき」と書くことはできません。 利便性は主観的な要因であり、一部の人にとっては便利であり、他の人にとっては便利であり、紛争の場合には誰が正しいかを確立するのは困難です。 「管理者は便利であるべき」という言葉は、「管理者リストに列の並べ替えとフィルタリングを追加する」という無限の変更につながる可能性があります。 これがないと便利ではありません。 また、Excelから商品を読み込んで、一度に1つずつ追加するのは便利ではありません。」

「規定されていないことはすべて、請負業者の裁量で行われます」-この声明の厳しさにも関わらず、このフレーズはToRに存在する必要があります。 それはタスクの本質に由来します。顧客は特定の製品を入手したいのですが、最終結果がどのように達成されるかを示すことはできず、示すべきでもありません。 このアイテムは、作業の深さへの干渉から保護します（顧客がコード内の関数に名前を付ける方法や使用するパッケージを伝えるのに十分ではありませんでした）が、顧客のウィッシュリストを作成する能力も無効にします。 私の意見では、それが良識の範囲を超えるまで、ウィッシュリストで顧客に会う価値があります。 忍耐が破られると、このアイテムは私たちにとって便利になります。 歌が言うように：「私たちは平和な人々ですが、装甲列車はサイディングにあります。」 （「合意されていないことは、パフォーマーの裁量による」という言葉です。仕事の声明の最後に固執することをお勧めします。最初は敵意に会うことができます。しかし、仕事の声明が正常であり、フレーズが最後にある場合、彼らはそれに反対しません）

技術 タスクとは、顧客が私たちに提供するドキュメントです（私たちがそれを書くことは問題ではありません。ある意味では、このタスクは技術的なタスクであり、タスクは顧客から請負業者、つまり私たちに与えられます）。 そして、このことから、TORには何をすべきかを示す文言が必要であることがわかります（「サイトに含めるべき」、「機会があるべき」など）。 あるTKで、「あれこれあれこれあれ」という形式の文言が間違った文言であることがわかりました。これは顧客に行われることを何らかの通知するものですが、ドキュメントは「通知」ではなく「タスク」と呼ばれます。

3. TKのセクション

3.1一般的な言葉

このセクションは最新です。 サードパーティのプログラマーにTKを提供する必要があるという事実から進んでください。そうすることで、プロジェクトが引き渡されるまで常に連絡を取り合うことができなくなります。 つまり プログラマーはTKを取る必要があり、単一の質問をするべきではありません。最初に尋ねられる質問は、「サイトについてはどうですか、私たちは何をしますか？」です。

3.2運用。 約束

要するに、運用上の目的は、サイトがもたらすメリットです。 一般的に、ほとんどの場合、利益はお金に帰着し​​ます（サイトが何らかの形で商業に結びついていて、それらのほとんどが存在する場合）、セクションでは、サイトの運用目的はお金を稼ぐことであると書くことに常に自分自身を制限することができますが、私たちはそれほど冷笑的ではありません。 「お金を稼ぐ」直前に、一歩先に停止しましょう。 オンラインストアの場合、これは商品の販売（そこからお金を受け取る）、ディスカウントサイトの場合、顧客と売り手、またはサービスプロバイダーをドッキングし（これからお金の割合を得るため）、名刺のウェブサイトの場合、インターネット上で広告されます（受け取るには広告が必要です）お金）など

3.3機能

このアイテムはすでにポイントに近づいています。 前の段落で説明した利益を得るための技術的な意味の短いリストを以下に示します。 たとえば、オンラインストアの場合、これは商品のカタログ、注文バスケット、配送、返品、会社に関する情報を含むページです。

非常に多くの場合、誇らしげなタイトル「参照条件」を持つドキュメントは、上記の3つのポイントを含むフリーランスのサイトで公開されます。 ただし、実際には、これはTKの紹介にすぎません。

3.4用語と定義

このセクションは、顧客と請負業者が同じことについて話しているという自信を与えます。
条件は2つの側面から「入力」できます。たとえば、お客様からお客様へ、ホスティングおよびSMTPサーバーとは何か、お客様からお客様へと説明します。

2番目のケースでは、原則として、サブジェクトエリアに固有の用語を記述する必要はありませんが、プロジェクトの実装に関連するものではありません。 たとえば、帆船用のスペアパーツを販売する店では、ステイセールやケーブルなどの条件を付けないでください。 ここで、顧客が使用する用語を解読し、それらに意味を入れる必要がありますが、これは私たちによって誤解される可能性があります。 いくつかの簡単な言葉ですが、この文脈では、特別な意味を持ちます。 たとえば、顧客は「サイトのセッションには100人のtugriksがかかります」と言います。 「サイトとのセッション」というフレーズ-説明の候補。 この用語は、サイトに入ってから終了するまでの時間、またはユーザーがお金を使い果たすまでの作業期間を意味する場合があります。 つまり 「作業セッション」とは何かを正確に知る必要があります。 このような単純な用語を誤解すると、実際の問題が発生する可能性があります。

3.5データとリスト

TKの重要なセクション。 彼の心を言うことができます。 これは最も冗長ではありませんが、TKの最も重要で難しい点です。 必要に応じて行われれば、タスクの作成者は何をする必要があるかを確実に理解できます。 このアイテムの存在は、作成される製品に非常に強い制限を課します。 このアイテムだけでも、TKの半分以上が「重く」なると思います。

データ

このセクションには、プロジェクトで使用されるエンティティのリストが含まれています。 これは、MVCフレームワークに関しては、データベースまたはモデルのテーブルの記述に非常に近いです。 たとえば、サイトにニュースがあります。 ニュースとは？ 軍の定義が言うように、茂みは一箇所から突き出た枝と葉の集まりです。 したがって、ニュースは、タイトル、テキスト、および発行日の組み合わせです。 この定義は何のためですか？ TKのすべてのように-何をすべきかを明確にし、ウィッシュリストから安全にする。

エンティティの属性を列挙することで、気付かないままにしておくと、合併症を引き起こす可能性のあるささいなことに気付くことができます。

たとえば、同じニュース：

• 見出し
• テキスト
• 発行日

作業の過程で、ニュースの発表（ニュースのリストに表示される短いテキスト）を忘れていることが判明したとします。 追加することは問題ではありません。「テキスト」タイプの「お知らせ」フィールドをテーブルに追加し、ニュースを作成/編集する際に追加の入力フィールドを追加する必要があります。 改良は簡単です。

そして、今度は、「ニュースカテゴリ」属性を追加するのを忘れていたことがわかります。 アナウンスメントの場合のように、データベーステーブルに1つのフィールドを追加するだけでは不十分です。 別のエンティティ、カテゴリテーブル、およびニュースカテゴリを管理するための管理パネルの対応するセクションを追加する必要があります。 プロジェクトの評価中に気付かれないこれらのタイプのポイントは、誤った結果をもたらし、その結果、期限の失敗につながります。 そして、このような問題を特定できるのはTORのこの段落です。 つまり TKを作成する段階では、作業のプロセスよりも「カテゴリ」が不足していることに注意することをお勧めします。

リスト

Capが示唆するように、ニュースはニュースであり、ニュースリストはニュースリストです。
なぜそれを説明するのですか？ メインページに「最新のニュース」を表示する必要があるとします。 ここに最新のニュースがあります、これはまさにそのようなリストです。 そして、「最新ニュース」とは何ですか？ これはすでにさまざまな方法で理解できます。最新の5つのニュース、または過去24時間のニュースでしょうか。 上記の例は単純で、プロジェクトを送信するときに修正するのは安価です。 しかし、もっと深刻なケースがあります。

たとえば、顧客が自分のサイトに、自分のブログなどの集合的なブログを望む場合 また、1つの記事が表示されるページの横に「類似の記事」のリストが必要です。 関連記事とは何ですか？ この問題には、個別の議論と説明が必要です。 そして、このリストに注意を払うことなく、私たちはすでにかなり深刻なリスクを冒しています。 つまり ここでは、記事の類似性を判断するためのアルゴリズムを詳細に説明する必要があります。 タイムラインを評価する段階でこの点をスキップすると、かなり見逃す可能性があります。

3.6説明ページ

すべてのページの説明とそのページの内容を記載したセクション。 ほとんどの場合、これはかなり短い説明です。 データとリストへの参照を使用できます。 たとえば、「ページには最新ニュースのリストが表示されます。」 ニュースとは何か、私たちはすでに最新のニュースについても説明しています。 必要に応じて、すべてのニュースデータが表示されるのではなく、名前とアナウンスのみが表示されることを明確にすることができます。

ここでは、表示されるものだけでなく、どのように表示するかを説明するのが適切です。 「ニュースのタイトルは赤い文字で表示されます」ではなく、デザインを説明しているという意味ではなく、「左側に、ユーザー名とパスワードの入力を求めるウィンドウがポップアップ表示されます」という意味です。 または、次のように：「[コメントを送信]ボタンをクリックすると、AJAXを使用して、リロードせずにコメントがページに表示されます。」

ここにページのコンテンツを記述する必要がありますか？ いいえ、必要ありません。 技術的なタスクを書いています。 カタログの説明では、カタログ内のすべての製品を説明していませんか？ 私たちの仕事は、顧客が独立してコンテンツをページに記入できる機能を説明することです。 エグゼキューターがサイトにコンテンツを入力する予定がある場合は、別のドキュメントに入れることをお勧めします。

当然、このようなスケッチを各ページに追加することは非常にクールです。

テキストの説明がスケッチに描かれているものと競合しないことを保証することは価値があります。
つまり 図にニュースに「ニュースカテゴリ」があり、「データとリスト」セクションにニュースがない場合、これは問題です。 TKを勉強するとき、顧客はカテゴリが含まれるニュースサムネイルのある画像を正確に覚えている可能性が高く、完成したプロジェクトにカテゴリがない場合（ニュースのテキストの説明に従って）、動揺します。

文書のテキストで、テキストが主要であることを明示的に示すことは価値があるかもしれません。イラストは理解を容易にするためのものです。 この問題は議論の余地がありますが。

管理セクションと公開セクションが明確に分離されているサイトの場合、すべてのページを2つの大きなカテゴリ（公開セクションと管理セクション）にグループ化することは理にかなっています。 明確な分離がない場合は、各ページのアクセス権を指定する必要があります。

3.7信頼性要件

高負荷のサイトが計画されている場合、恥ずかしさがないように事前に言う価値があります。 負荷の高いサイトでは、サーバーのセットアップやコードの作成のために特定のアクションが必要になる場合があります。 また、プロジェクトの配信時にサイトが大きな負荷を保持する必要があることを見つけることは、状況の最適な開発ではありません。

信頼性のために、バックアップを構成する必要があることを別に言及する価値があります。 「さまざまなケースがあります」。すでに起こっているように、データベースを破壊する邪悪なハッカーや青い炎で燃え尽きるホストから安全な人はいません。

3.8ホスティング要件

たとえば、このような状況は明らかに発生する可能性があります。 私たちのWebスタジオは美しいWebサイトを作成しますが、Djangoのみに書き込みます。 顧客は私たちのサイトを見つけ、美しいデザインを見て注文しました。 サイトをホスティング、顧客の他の10サイト、そしてもちろんPHPに置きます。 そして、「しかし、私はPHPのすべての人がそうするだろうと思っていました...別のホスティングはありません。PHPでやり直す必要があります。」

このような明らかな問題に加えて、さらに微妙な問題があります。 たとえば、通常の操作にはcronが必要ですが、ホスティング業者は提供していません（私の実践では絶対に実際のケースです）。 または、共有ホスティングで動作できない特定のサイトは、VPSまたはVDSのみを必要とします。

これには、インタプリタ、ライブラリ、パッケージ、gem、ディスク容量、メモリ、smtp、pop、ftp、外部プログラムなど、プロジェクトにとって重要な要件が含まれている必要があります。

3.9コンテンツの塗りつぶし

この項目は、コンテンツの充填量を指定します。 少なくとも、お客様がサイトの運用を開始できるようにするコンテンツを作成する必要があります。 少なくとも、サイト管理者のアカウントを作成し、ユーザー名とパスワードを顧客に伝えます。

たとえば、以前に処理した500枚の写真をカタログにアップロードする必要がある場合は、ここで説明する必要があります。

このセクションの説明は、誰が500枚の写真を記入し、カタログに商品を記入すべきかについての異なる理解について警告しています。

3.10配送と受け入れ

仕事に対する支払いが発生する条件の説明。

たとえば、100％の支払い後に顧客のホスティングに転送するなどのオプションが可能です。 または、顧客のウェブサイトに移行してから1週間の慣らし運転を行った後の支払い。

ところで、100％の支払いは、バグ修正の終わりを意味するものではないと思います。 私の意見では、バグには生涯保証が与えられるべきであり、それらは常に無料で修正されるべきです。 ただし、この問題には他の見解もあると思います。

おわりに

もちろん、このTKはサイトのすべての側面をカバーしているわけではありませんが、非常に多くのプロジェクトにとっては適切な説明になります。

はい、このTKにはギャップがあります。たとえば、サイトにAPIが必要な場合の対処方法は示されていません。 ただし、適切な「データとリスト」セクションがあれば、この領域でToRを拡張するのは非常に簡単です。

批判、特にそのようなTKが適切でない場合の説明を聞いてうれしいです。