✡️ 🛣️ 🔎 サイトにとって「良い」TKとは何ですか？ 💃🏿 🙌🏼 👝

ロシア語を話す著者が書いたロシア語のサイトやプログラムの設計に関する驚くほど少ない資料を思い出すことができます。これは、主に輸出志向の開発（オフショア）と、わが国での情報製品の作成における大量の経験の欠如によって促進されています。

この記事が、Webサイト開発のために高品質のドキュメントをコンパイルする問題を経験した開発者やITマネージャーに役立つことを願っています。汚染された紙以外のものは、少なくとも有用なものであるという文書。

入門

なぜサイトで技術的な割り当て（TOR）を行うのですか？

どのような開発方法論を使用する場合でも、サイトの規模に関係なく、「作業をいつ終了するか、実際に終了したことをどのように理解するか」という質問に直面します。そのため、どのサイトも一般的な問題です。エンドポイントは誰にも見えません。一方では、プロジェクトマネージャーがプロジェクトの最終ビジョンを持っている必要があります。しかし、最終製品がマネージャーのイメージと一致するが、クライアントの期待と一致しない場合はどうでしょうか？また、プロジェクト3でマネージャーが変更された場合は？

パーキンソンの法則の結果は「90」です：

コードの最初の90％は開発時間の90％を占めます。 コードの残りの10％は、開発時間の2番目の90％を占めます。

A.クーパーの本「患者の手による精神科病院」から。

TKは単なる要件のリストではなく、ドキュメントです。契約が組織的および金銭的関係のプロセスを支配する場合、TKは開発プロセスと最終結果を規制します。

この場合、サイトが大きいか小さいかは関係ありません。期待の不一致の問題は、費やしたお金の量に関係なく発生する可能性がありますが、結果のみが異なる場合があります。

この記事の内容は何ですか。

この記事では、サイトでTKを作成するプロセスで役立つ可能性のあるものと、確実に望ましいものについて説明します。しかし、この記事は設計ドキュメントの書き方についてではありません。最終的に、デザイナーの主なタスクは、クールなドキュメントを書くことではなく、サイトをデザインすることです。良い文書は、開発のすべての参加者に対するアプローチと敬意を反映したものにすぎません。

制限を追加します。

TKの作成について話すときはいつでも、もちろん、カスケード開発手法を意味します。他のオプション（極端なプログラミングなど）の場合、他のドキュメントがコンパイルされ、多くの場合異なる原則に基づいています。これは時間です。

小規模および大規模なサイトでTKを共有する価値があります。これらは2つです。小規模プロジェクトと大規模プロジェクトの違いは、出力ドキュメントの量ではなく、開発プロセスにあります。プロジェクトチームに4人しかいない場合、誰もが長い間お互いを知っているので、形式主義がないと仮定できます。複数の「部門」が開発に携わっており、プロジェクトチームが10人以上の（無限に）従業員で構成されている場合、このプロセスのみがこの大群を管理できます。このプロセスは形式化を引き起こし、形式主義はドキュメントの形式にマークを残します。

実際、ドキュメントの厚さは、プロジェクトのサイズよりもプロセスの複雑さに大きく依存します。

最も難しい道をたどります。

TKが質問に答えます

TKは、最初にいくつかの開発参加者向けに作成されます。

プロジェクト開発者（デザイナーおよびプログラマー）。
プロジェクトマネージャー。
お客様
官僚（彼らはプロジェクトに参加しないかもしれませんが、彼らも頼りにしなければなりません）。

与えられた参加者のグループを振り返ってみると、TKはまず彼らの質問に答えるべきであると仮定することができます。理想的には、開発プロセス中の問題を取り除くために、カスケード方式のすべてのプロジェクト前のドキュメントが作成されます。

それで、TKはどんな質問に答えますか。

このサイトは誰のために作成されたのですか？

サイトは、顧客と顧客のために作成されます。これらは、将来のプロジェクトのベースユーザーです。

最良の選択肢は、参照条件で、サイトのすべてのユーザー（内部および外部）を記述する場合です。この説明には、マーケティング、人口統計、ソーシャルデータ、潜在的なユーザーの目標と目的、将来のサイトの要件が含まれる場合があります。

顧客とユーザーのタスクはどのように解決されますか？

実際、この質問に答えない場合、作業指示書の執筆は事務処理として認識できます。これは根本的かつ重要な問題です。別の記事がそれに捧げられるかもしれないので、私たちは今のところそれについて詳細に説明しません。

プロジェクトの作成はどうなりますか？

上で書いたように、TK（およびおそらく別のドキュメント）がプロジェクト開発プロセスを説明することがあります。これは、会社が採用しているものとは異なる開発方法論に従ってサイトを開発できることを考慮する場合、絶対に必要です。通常、どのドキュメントにも記述されていません。 ISOの標準化の夢を思い通りに苦しめることはできますが、細心の注意を払う顧客に何を見せるべきでしょうか？

GOSTによると、別のセクション「システム開発の段階」が提供されています。このセクションでは、プロセスを詳細に説明し、マイルストーンを設定することはできません。

出口で何が受け入れられますか？

TKは開発を開始し、それに終止符を打ちます。

理想的には、お客様と一緒にTKのすべてのポイントにアクセスし、受信したシステムを確認して、1週間後に「Uf-f。彼らはすべてをしたようだ。」

「TKは完了した作業を検証する手段です。」-このフレーズは、TKの多くの紹介で記録されています。

プロジェクトのさらなる立ち上げには何が必要ですか？

これは、顧客が適切な方法で回答する必要がある質問です。これはすでにコンサルティングされていますが、場合によっては設計プロセスで実行する必要があります。ジョブの数、必要なソフトウェアとハードウェアなどを計画する必要があります。

TKの構成

特定の明確な構造の形でTKの構成を説明するか、何がそこにあるべきかを話すだけで、決定を下すのに1時間かかりました。 TKのすべてを思い出して、このドキュメントの構造は多くの要因に応じて頻繁に変更されるため、構造を明確に示すことはスーツの選択に関する悪いアドバイスに似ているという結論に達しました。あなたがどこに行くのかさえ知らずに、あなたは夜のために何かを着るように助言されると想像してください。

一般的な情報

ToRの最初の部分には、ドキュメントとプロジェクト全体に関する紹介と一般情報が含まれています。序文は、一生に一度書く必要があります。原則として、非常に多くの抽象的なフレーズがそこに書かれているので、新しいプロジェクトではそれぞれ、数語を修正するだけで済みます。

一般的な情報は次のとおりです。

顧客と請負業者に関する情報。

各側の責任者の必須表示。開発のベースとなる文書が示されています。原則として、同様の文書は契約書です。現在のドキュメントのステータスとプライバシー。
プロジェクトの目的。

それは示されています：受け取った製品は何のために使用されます。
作成の目標とリソースが解決しなければならないタスク。

一方では、これはかなり短いセクションですが、精緻化の重要性の観点から最初の場所を占めています。目標と目的が明確かつ計り知れないほど設定されていない場合、それらに従うことは非常に困難です。
プロジェクトの対象者の説明。

適切で正しいサイトを開発するための重要な情報。オーディエンスに関する情報を正しく収集する必要があるだけでなく、この情報を使用できることがさらに重要であることは明らかです。

オーディエンスの説明には、マーケティング担当者が大好きな情報（人口統計、ニーズ、セグメンテーションなど）だけでなく、デザイナーやデザイナーに役立つ情報（ユーザーが解決するタスク、サイトでの作業の目標、ユーザーを引き付けるもの）も含める必要があります。アラン・クーパーは、サイトのオーディエンスを顔のない大衆としてではなく、キャラクターを抜き出し、特定の人々の集合的なイメージを記述することを推奨しています。
用語と定義 。

大きなドキュメントでは、マーケティングの専門家や大規模な幹部がめったに理解できないような膨大な数の用語やスラング表現を使用できます。彼らはこのドキュメントを読むことができるので、それらの定義のリストを提供することが最善です。私はこのリストが私の人生で少なくとも一度は読まれたことを期待して楽しまないが、いつでもそれを参照することができる。

このドキュメントの一般的な入門部分には、設計時に始めた場所に関する情報が含まれています。もちろん、顧客の専門家に質問する過程で、情報は一桁以上蓄積されますが、誰もそれを読むことに興味はありません。

この情報は、プロジェクトの範囲内で収集されます。

プロジェクト範囲

あなたが家から離れてそれを見るために向きを変えると、遠くからは構造の詳細を区別することができなくなります。窓を数えることはできますが、それらの素材を理解することはできません。建築を賞賛することはできます（もちろん、すべての家が「賞賛する」ことはできません）。ドア。

プロジェクトの範囲はほぼ同じです。この章を読んだ後は、開発プロセスで何が得られるかを全員が知っておく必要がありますが、詳細については絶対に触れないでください。「ユーザー登録」はサイトで機能することを書きますが、それがどのように配置されるか、またはユーザーが入力する必要があるフィールドを正確に書きません。

いずれにせよ、プロジェクトはフレームワークレベルの設計に合格するため、書き留めることは不要です。さらに、開発者側と顧客側の両方の大きなシェフは、長い間読むのを好みませんが、起こっているすべてのことを知っているのが好きです。このセクションはそれらを含めて書かれるべきです。

プロジェクトのフレームワークは、サイトで作業するユーザーのシナリオの形式で記述され、一般的な機能とインターフェイスとの相互作用を説明します。

情報アーキテクチャとインターフェース

サイトの情報アーキテクチャ（IA）に特化したセクションは、よく知られている標準によって標準化されていません（著者はまだこれらに精通していません）。しかし、サイトを開発した人なら誰でも、IAがサイトを開発するために知っておくべきほとんどの主要なものであることを理解しています。 IAは、サイトの外観とユーザーとの連携方法を決定します。

IAを説明するには、上から下に説明する必要があります。

サイト構造。これらは、いわゆる高レベルのプロトタイプです。
ページテンプレート。サイトのインターフェースを直接説明する低レベルのプロトタイプ。
コンテンツの説明。サイトの各ページのコンテンツの表形式の説明。

サイト構造

サイトマップは、よく知られている表記法の1つであるVisioまたはGarrettでグラフィカルに実行されます。この場合、結果の構造は将来の使用に最も明白で便利なので、サイトマップを描くことをお勧めします。一方では、サイトマップをリスト形式で書く方がはるかに簡単に思えるかもしれませんが、サイトのさまざまな領域の相互のつながりについて考えると、知らないうちに紙の上に小さな正方形を書き始めます。

Visioを使用して表記法を使用してサイト構造を描画する方法については、記事全体が記述されているため、これについては説明しません。ただし、記事は英語で書かれていますが、簡単に使用できます。

サイトマップ上の個々のページに番号を割り当てることを忘れないでください。これは、コンテンツの説明の段階で必要になります。

サイトマップを描画する際の便利なヒント：

場所をspareしまないでください。ブロックが互いに分離されるように配置してください。これにより、マップが読みやすくなります。
挽かないでください。原則として、4本のピンで印刷されたテキストを読むことは可能ですが、これはすでに憎しみの理由です。
ページの「正方形」を互いに相対的に整列させ、一列に並べます。これにより、ページのネストレベルの認識が向上します。
線を交差させないでください。通信回線の多数の交差点を避けるようにしてください。それらが交差する場合、それらは上下に「スキップ」する必要があります。大学で機能図を描いた人は誰でも私を理解するでしょう。
カードに署名します。カード自体と個々のブロックに署名します。これにより、今後の混乱が少なくなります。
ファイルをより頻繁に保存します。控えめですが、あなたはそれについて覚えておく必要があります。 Visioプログラム開発者の親sをもう一度思い出すべきではありません。実際、彼らは何のせいでもありません。

サンプルサイトマップ。

通常、サイトマップは[アプリケーション]セクションに配置します。原則として、それは非常に大きいため、TKの中央に配置するのは非現実的になります。

ページテンプレート

サイトマップレベルでは、各ページは紙の上の「正方形」のみを表しています。デザイナー、レイアウトデザイナー、プログラマーにとって、これはサイトを開発するのに十分ではありません。また、サイトのページ上の情報ブロックと機能の存在と場所を知る必要があります。したがって、サイトテンプレートに進みます。理想的には、各ボックスは個々のページの概要に合わせて詳細化する必要があります。これはプロトタイピングサイトです。プロトタイピングの使用は、開発会社で受け入れられている作業スキームに依存しますが、これは顧客にとって非常に安価になっていることを認識する価値があります。

簡略化するために、サイトマップの後に説明する多くのサイトインターフェイステンプレートが区別されます。

テンプレートの説明は3つの部分で構成されています。

テンプレートの列挙。主な種類のページが特定され、その使用方法が説明されています。
サンプルテンプレート。メインブロック。情報の再現性を減らすために、ページのメインブロックが説明されています。
リストに従った各テンプレートの説明。テンプレートは、任意のグラフィックパッケージ（Adobe Illustrator、Adobe InDesign、MS Visioなど）で描画され、簡単な説明で補足されます。

免責事項 ：サイトインターフェイステンプレートは、サイトが実行されるソフトウェアシステムのテンプレートと混同しないでください。インターフェイステンプレートは、サイトの設計に十分なサンプルページ数を記述します。

インターフェイステンプレート（ワイヤフレーム）の説明を含むTKからのUターンの例。

内容説明

仕事の中で最も長く退屈な部分。コンテンツの説明には、サイトのすべてのページのリストと、各ページに配置されたテキスト、写真などの正確な表示を含める必要があります。また、このページに使用されるテンプレートも示します（上記を参照）。これにはテーブルを使用することをお勧めします。

TKを書いている時点で、サイト上のコンテンツが何であるかを自信を持って知ることができるとは限りません。情報ページの正確な数、グラフィック情報の配置、このセクションが最も正確な説明を提供すると仮定しないでください。多くの場合、そうではありません。ただし、この段階で必要なコンテンツを説明すると、それに基づいてプロジェクトマネージャーはコンテンツ配信計画を作成し、サイトに送信されるこの情報の量を評価できます。クライアントは常に、準備と編集に必要なもののリストを目の前に持っています。

コンテンツの適切な説明は、サイトを立ち上げ、情報を入力する段階で計画された作業を保証します。

機能的

参照条件でのサイトの機能の説明は、重要なセクションの1つです。これは、e-コマース、オンラインサービスなど、ソフトウェア作業の割合が高いサイトに特に当てはまります。

機能の説明の良い例は、GOSTによって与えられます。プログラムサイトで開発された機能を説明するときは、標準に従うことをお勧めします。以下を説明する必要があります：一般的なシステム、サブシステムとモジュールの一般的な機能、サブシステムとモジュールの相互の関係、そして最後に、モジュールのすべての機能の列挙とそれらの動作の多少の詳細な説明。モジュールごとに、プログラムで作成または使用されるオブジェクトをペイントする必要があります。

データベースの構造、予備作業アルゴリズムを記述することもできますが、技術的なタスク自体はこれを必要としません。 GOSTによれば、そのような詳細は、さらなる文書で説明されるべきです：概要と技術プロジェクト。

大規模なサイトを開発する場合、サイトの外部部分と内部部分のすべての機能を説明するために長時間座っている必要がある場合があります。一部の開発者は、このような詳細化に反対しています。彼らは、「クライアントが理解できるように」機能を表面的に記述する必要があると考えています。ナンセンス！経験から言えば、不必要な詳細はありません。プロジェクトで問題が発生した場合、両側のプロジェクトマネージャーはまれなレターイーターになります！彼らは自分の主張を証明しようとしてTKを上下に引きます。したがって、TKの機能が一般的な用語で記述されている場合、クライアントは引き続き必要なことを強制します。

必要条件

プロジェクトの要件または環境へのプロジェクトについては、別のセクションを作成する必要があります。サイトの技術仕様に記載できる要件：

システムの技術要件。
スタッフの要件;
信頼性要件;
人間工学と技術美学の要件;
不正アクセスから情報を保護するための要件。
事故の場合の情報の安全性に関する要件。
担保の種類の要件。
ソフトウェア要件;
情報サポートの要件;
技術的手段の要件;

また、いくつかの特定の要件がある場合があります。

すべての要件を明確に策定し、プロジェクト開発のあらゆる側面を忘れないようにしてください。

もちろん、小さなプロジェクトでは、上記のすべての要件を書き留める必要はありません。そのため、たとえば、多くの場合、Webサイトにスタッフがまったくいないため、このようなセクションはスキップされます。

その他

プロジェクト管理のプロセスでは、参照条件の範囲を超える状況が発生することに気付くかもしれません。何かを逃したか、以前は予測できなかった緊急事態が発生した可能性があります。これはすべて、ドキュメントをさらに発展させ、新しい情報を導入するのに役立ち、顧客とのコミュニケーションに使用し、問題を解決するのに役立ちます。

次は？

TKはコンパイルされ、署名され、作業に入りました。次は？彼との仕事はこの段階で終わりますか？いや

プロジェクトは、事前に計画されたパスに沿っているとは限りません。私たちは何かを改善し、変化させ、しばしば顧客の要求を変えようとします。参照条件は、タブレットではなくドキュメントです。プロジェクト要件の変更に伴い、参照条件も変更する必要があります。通常、これは、変更のリストを含む追加のドキュメントで行われます。当然、実際に必要な場合にのみコンパイルされますが、実際にはまれです。

また、TKの詳細な調査の過程で、開発プロセスのすべての参加者がプロジェクトの作業プロセスでエラーを見つけることに注意してください。大きなドキュメントのエラー数は、そのボリュームに直接比例し、書き込みに費やした時間に反比例します。なぜなら時間は常に十分ではないため、TORでエラーが発生することが予想されます。

乾燥した残留物。

この記事は1年以上前に書いたものです。かなりの時間が経過しましたが、この間、1つの大きなTKを作成していません。しかし、提供された情報を読んだ後、私はここに書かれているすべてに同意しました。そのため、サイトの優れたTKには次のものが含まれている必要があります。

ドキュメントとそのコンパイラに関する一般情報。
サイトの目標と目的。
サイトユーザーの説明、彼らの目標と目的。
プロジェクトの範囲。
サイトの情報アーキテクチャ（IA）：サイトマップ、テンプレート、インターフェイスの説明。
サイトコンテンツの説明。
サイトの機能の説明。
必要に応じて、プロセスの説明とマイルストーン。
サイトを開発し、受け取った作業を検証するときのあらゆる種類の要件のリスト。

この情報が幅広い読者に役立つことを願っています。

便利なリンク：

Yuri Shilyaev 、 サイトデザイナー、コンサルタント。

Articsインターネットソリューションの ミンスクオフィスのディレクター 。

オリジナル： yuri.shilyaev.com/archives/2007/03/21/356/chto-takoe-%c2%abhoroshee%c2%bb-tz-na-sayt.html

サイトにとって「良い」TKとは何ですか？

入門