何とどのように
参照条件はプロジェクトの一部にすぎません。 スタートアップであろうと、既存の製品内の新しいサービスであろうと。
いずれにせよ、TKは顧客および請負業者の空想を、実装に適切かつ可能な形で提示する必要があります。 開発方法論について話すとき、小規模または大規模プロジェクトの場合、TKをTKに分割すべきではありません。 これは常に深刻なドキュメントであり、技術的なタスクの開発者（そしてもちろんマネージャー）が責任を負うことになります。
技術仕様の開発段階
1.予備的概要/タスク研究
原則として、顧客が望んでいるものの一時的なアイデアがあります-簡単な形で、「ウィッシュリスト」、TKとの手紙。 主題分野を研究し、質問のリストを作成します。
会社、市場、顧客、競合他社に関する情報を収集します。 表示された情報は、顧客のビジネスを理解するのに役立ち、その結果、顧客の目に浮かび上がります。
2.会議を開催する
常に特定の質問リストを作成し、ゆっくりと顧客からすべてを見つけます。
アンケートとして会議を開催しないでください。顧客は尋問を受けて孤立する可能性があります。 「プロジェクトについて教えてください。プロジェクトから何を期待していますか」から始めてください。 顧客はリラックスし、多くのことを話します。その間、あなたはあなたのビジョンと理解と一致したメモを取ります。
質問の横に回答を記録し、それらを読み直してください。
回答を受け取っていない場合（顧客が質問に抽象的に回答し、結果として回答がない場合）、言い回しを変更して再度質問します。 たとえば、「私はこのような機能をそのように想像しています...あなたを正しく理解していますか？ これはあなたのビジョンに合っていますか？」
どんなに予想外であっても、質問することを恐れないでください。 特定のビジネスでは多くのことが明白なので、言及するのを忘れることがあります。
3.コンセプト開発
コンセプトには通常、将来のTKの簡単な論文が含まれます。
- 目標と目的;
- 予定
- 役割
- 構造;
- 内容
- 機能のリスト（サービスの形式で-簡単に）。
- コンセプトには、プロジェクトの勝ち方を理解するために、ビジネスアイデアの詳細な説明が含まれることがあります。
常にコンセプト-将来のプロジェクトのスケッチを作成します。 多くの場合、これによりリスクを軽減できるだけでなく、あなたと顧客の両方にすべてのiにドットを付けることができます。
4.要件の明確化
コンセプトの承認後、不足している要件を明確にし、形式化します。 ToRの要件を修正し、それらを説明付き（およびできればインターフェース付き）既製のブロックに形成します。 顧客は、説明されている要件がグラフィックに付随していると、自分が望むものについての情報を理解しやすくなります。
TKの開発について、顧客のコメントに応じてドキュメントを追加および変更するたびに、何度か繰り返します。
すべてが明確で明白なように見えても、正しく理解できるかどうか質問する必要があります。 これにより、多くの時間と神経が削減されます。 簡単なニュースについても、「公開の頻度」、更新者、ニュースに掲載できる資料などの概念があることを忘れないでください。 このような質問への回答から、ページの構造と情報の優先度は根本的に変わる可能性があります。
5. TKの承認
顧客は2つのタイプに分けられます-TKに真剣ではなく、「私が言うように、とにかく後でやる」と思う人と、TKに可能性と不可能性を合わせようとする人。 プロジェクトで優れた作業成果物を作成することが重要です。 過剰はありません。
プロジェクトをステージに分割するための引数の例：「まず、基本的な機能を備えた適切な作業バージョンを実装し、次に追加機能を改良して発明します。 しかし、あなたが説明した機会に、私たちは最初に置かれました。」
誰が製品を使用するかを常に考えてみてください。 ユーザーにすべての可能性を提供することは可能ですが、利便性を損なったり、実装時間を損なったりします。
困難と回避方法
1.期限を守れない
時々、文書を書くいわゆるミューズがないことがあります。 座って、面白い本を読んで、面白い番組や漫画を見てください。 ネットサーフィンする必要はありません。 本や見たものからの新しい感情は、想像力を大いに発達させ、力とインスピレーションを与えます。 最終日まですべてを延期しないでください。
プロジェクトの期限と能力について誤った考えを与えないでください。作業計画で承認の期限を定めてください。 プロジェクトに割り当てられる時間を計画します。タスクの日数をスケジュールし、開発されたスケジュールに従います。
2.作業の価格条件スコープ
どのタスクにも期限と価格があると常に考えてください。 これらの意味から抽象化せずにソリューションを提案することが重要です。
3.フィードバック
常に手紙や電話に返信してください。 顧客があなたにフィードバックすることが重要です。 彼は、紛争、質問、説明が生じたとき、電話または書面で回答を得ることができることを確信しなければなりません。
4.同意したすべてを修正してください。
会話または対面でお客様に送信された顧客のすべての希望は、手紙で確認し、実行する項目をリストします。 上記の実行のタイミングを声に出してください。
顧客が1日に15通の手紙を願い事とともに送る場合は、1通の手紙で願い事を収集するように依頼します。 そのため、通信で一部の情報が失われるリスクを軽減し、変更に時間を費やす必要があります。
5.結果を提示する
多くのアイデアは、正しい説明で提出されなかったために拒否されます。 たとえば、顧客が一方向で機能を実装したいが、これに同意しない場合、バージョンを開発し、それを正当化し、実装のアイデアを説明し、ソリューションの利点について話します。
お客様の希望どおりにしないでください。 原則として、この場合の最悪のオプションは受け入れられます。
ちょっとしたお勧め
技術的なタスクの作成に初めて取り組む場合は、ルールに従ってください。 たとえば、ルールは次のようになります。
メンタルカード
マインドマップテクニック。 メンタルマップでTKを開発します。 プロセスの本質は、最初に将来のプロジェクトを図の形で描くことです。 製品をエンティティ、概念に分割します。 同時に、ツリーの各段落で3〜4語を超えないようにしてください。 同様のスキームは、プロジェクトのすべての参加者によってすぐに読み取られ、ツリーを簡単に修正および補足できます。 そのようなマップを開発するための多くのプログラムがあります。
バージョンとファイル名
ファイルに正しく名前を付けます。 たとえば、プロジェクトの名前（エンコード済みまたは全体）を指定できます。 各バージョンファイルの名前を入力します。 これにより、最後にどのファイルがわかりやすくなります。
経験から、次の形式の名前とバージョンを作成すると便利です。
NameProject.0.1.doc 、
NameProjectはプロジェクトの名前で、
0-クライアントに送信されたバージョン。 0の場合-社内（部門）での作業中に送信されなかったことを意味します。
1-社内で作成したバージョン（部門）。
たとえば、ToRでさらに作業しながら、バージョン0.1をクライアントに送信しました。 バージョン0.2は変更であるため作成しますが、すでに社内または社内の会社です。 クライアントからコメントを取得し、さらに新しいバージョン1.3を作成します。
いくつかのドキュメント（たとえば、概念、TK）がある場合は、ドキュメント名にドキュメントタイプ-NameProject.Concept.0.1を追加します。
構造
明確なTK構造を持っている。 情報を収集し、ドキュメントを作成するときは、それに従ってください。 顧客の期待に応じて、技術的なタスクテンプレートを選択するための4つの選択肢があります。 GOST、IEEE、企業テンプレート、独自のテンプレート（またはあなたが働いている会社のテンプレート）を指定できます。
書式設定
優れたドキュメントとは、有能で正しく実行されたドキュメントです。 整形式のドキュメントは読みやすく、何十ものスタイル、さまざまなデザインの多くのテキストブロックがないためです。
結論
新しいテンプレート、説明形式をお試しください。 あなたは、有能で優れたソリューションを提供することでビジネス上の問題を解決できる人です。 製品のユーザーをより便利にすることができる人（便利で論理的なインターフェースのため）。 最終製品はあなたの努力の結果であるため、自分自身とあなたの時間を高く評価してください。