「1000語の代わりに」ということわざにあるように、このトピックについてSkypeで毎回4〜5時間伝道することはすでに退屈であり、「技術的割り当て」の定義に長年にわたり傾倒する世界的な傾向は、何年もかけてますます強まっています。
問題
実際には、特定の形式があり、用語の明確でわかりやすい定義がある場合、すべての操作と、自分のブリーフ、プロトタイプ、発明されたアンケート、説明、および着信アプリケーションのみに対するその置換は、少なくともその場で見えますプロフェッショナルではない。 したがって、私たちの概念の科学的な定義から、私たちは始めます：
参照条件-技術オブジェクト（製品）の設計のソースドキュメント。 TKは、開発されたオブジェクトの主な目的、その技術的特性、品質指標、技術的および経済的要件、文書作成の必要な段階（設計、技術、ソフトウェアなど）およびその構成、ならびに特別な要件の実装に関する規定を確立します。 参照条件は法的文書であり、設計作業のために顧客と請負業者の間の契約にアプリケーションがどのように含まれるか、およびその基礎となります：目的、目的、原則、期待される結果、期限など、作業の順序と条件を決定します。 つまり、特定の作業項目が完了したかどうかを判断できる客観的な基準が必要です。 TKの文言のすべての変更、追加、および明確化は、必然的に顧客と合意され、顧客によって承認されます。 設計上の問題を解決する過程でソースデータの不正確性または不正確性が見つかった場合、開発に関与する各当事者の罪悪感の程度、およびこれに関連して発生した損失の分配を判断する必要が生じるため、これも必要です。 情報技術の分野における用語としての参照条件は、ソフトウェア製品、情報システム、ウェブサイト、ポータル、または他のITサービスを開発、実装、または統合する開発者のタスクを設定するために必要な包括的な情報を含む法的に重要な文書です。
わかりやすい言葉に翻訳します
1）技術的な割り当て-タスクを設定します。 だから、プロトタイプ、スケッチ、テスト、設計プロジェクトの前に行かなければなりません。なぜなら、マインドマップ、データフロー図、アーキテクチャ-これはすでにタスクの遂行であり、これが質問に対する答えです。 そして、質問自体がまだすべての関係者によって尋ねられ、定式化され、署名される前に、答えは演prior的に間違っているでしょうか？ したがって、プロジェクトの作業の開始は問題の声明であり、それを解決するための多数のオプションのスケッチのけいれん的な検索ではありません。
2）実際には、新しいものも最初の段落から論理的に続きます-TKテキスト自体は、「目標とタスク」の章で始まり、世界のエントロピーを高めるこの次の試みが追求するビジネス目標を明確に明確にしなければなりません。 問題を解決しない目的のないタスクは何も達成せず、「退屈から」行われます。それは公式には技術的なタスクとは見なされず、その時点から「プレーンペーパー」の状態になります。
3）提案された設計コンセプトまたはインタラクティブなプロトタイプ、あるいはすぐに使用できるサイトでさえ、上記のビジネス上の問題を解決するかどうかをどのように理解しますか？ 何もする必要はありません。定義に戻る必要があります。「決定...期待される結果と期限。 つまり、特定の作業項目が完了したかどうかを判断する客観的な基準が必要です。」 つまり、ルーブル、秒、トンキロ、または摂氏の明確な測定可能な指標なしでは、TKは存在できません。 ブリーフは、プロトタイプまたは不合理な紙でさえあり得ますが、技術的な課題ではありません。
このことから、これらの同じ指標を採用、測定し、当事者が手を振ったりプロジェクトをやり直したりする場合、このTORには必ず「承認と評価の手順」の章がなければならないと結論付けます。
4）委託条件は、顧客の事業開発戦略と市場セグメントの分析とともに、顧客の全体的な事業計画と必ず一致している必要があります。 これらすべてが、適切な目標を設定し、正確なメトリックを導き出し、最終的な情報製品を適切に受け入れることを可能にします。 顧客向けのビジネスプランが存在しない場合、参照条件の専門的でない実装が自動的に保証されます。
アウトソースされたスタジオは、所有者よりもビジネスの目標と測定可能なパフォーマンスをよく知っていますか？ 明らかに、いいえ。これは、正しいTORが請負業者の従業員ではなく、顧客の代表者によって書かれるべきであることを意味します。 不条理なのは、パフォーマーが自分でタスクを設定するとき、彼はそれを自分で評価する方法を考え出し、最終的に、彼自身が仕事の最終マークを設定するということです。 理想的には、そのような「自分でできる」アクティビティはすべきではありませんが、これは実際にどこでも起こることです。その結果、技術的な割り当てはプロジェクトに必要な支援を提供しません。 しないでください。
5）完成したTKを修正するたびに費用がかかります。 「あなたのプロジェクトの憲法」を自由にそして無限に支配することは不可能です。当事者の一人が心を変えた、十分な睡眠をとらなかった、突然保存した、などの理由だけです。 TKの各変更の価格も、関連する章で事前に明記する必要があります。
ちなみに、理論上も同様に、デザインを編集したり、ページや機能のリストを変更したりするたびに、この変更を行う前に明確な価格を支払う必要があります。 個人的には、承認されたTKのどのバージョンもプロジェクトの総予算の30％で評価することをお勧めしますが、それ以外の方法でも可能です。
TKでは、開発の条件と総予算、および既存のすべてのリソースと制限のリストを事前に示すだけでよいことに言及する価値はありますか？ 「いいえ、それはあまりにも明白です。」
だから：私たちは何をしていますか？ 何のために？ 彼らが何をしたかをどのように理解しますか？ 各ピボットはいくらですか？ -紙に書かれたこれらすべての質問に対する答えは、最も失敗したプロジェクトでさえも引き出すことができる「銀の弾丸」です。
セキュリティの質問
そして、ここで私は顧客から最もよくある質問への回答をリストします：
1）では、公式のGOSTを書いて技術課題を書くことはできますか？ -はい、少しでも。
2）そして、テクニカルタスクには、必要なページの説明、ボタンの数、使用するライブラリ、ガイドラインなどが含まれていません。 -それはTK自体にはありませんが、アプリケーションでは、もちろんこれらすべてを上記の目標、制限、達成された結果をさらに評価する方法で調整できます。 少なくともすべての将来のコンテンツ、少なくとも典型的なキャラクターの説明を投稿してください-しかし、問題の明確な声明ではなく、その後に投稿してください。
3）それでそんなことは必要ないの？ -おそらく、世界中の何千人もの人々が出生から盲目で完全に生きているように、おそらく今日何千ものサイトが完全にTKなしで作られています。 しかし、自分がどこに動いているかを見たい場合、意識的に意思決定を行い、結果を独立して評価したい場合、TKなしではできません。
4）あなたとWikipediaは、TKは顧客によって作成されたと書いています。 しかし、どうすればいいかわからない\時間がない\自分でやりたくない どうする？ -TKの開発を、あなたのビジネス、そのタスク、対象読者とニーズに完全に精通していると同時に、Web開発のすべての段階を完全に認識している第三者に提供します。 この第三者は一種の「ウェブ公証人」となります。つまり、請負業者が必要な指標を過小評価したり、時間を遅らせたりすることはなく、顧客は達成可能な指標を設定し、最終的な承認時に作成された製品を主観的に評価せず、以前に記録されたものを変更します要件。
5）そして、TKが合法的な文書である場合、アウトソーサーを訴えることができます。 -文書が正しく作成されている場合、その達成度を評価するための目標と方法論が示されています。 文書が当事者によって署名され、契約書に記載されている場合（技術タスク自体は契約書ではありません）-もちろんできます。 しかし、通常のブリーフ、プロトタイプ、アートクリエイティブレイアウト、FLの安全な取り引きでは、もはやありません。
6）彼らは、作業が何らかのスクラムまたはアジャイルに従って実行されることを教えてくれます。 つまり、古風なTKはもう必要ありません。 そうですか？ -自分の判断：彼らはあなたに理解できない言葉を与え、何かをはっきりと隠します、そして今、不慣れな用語に基づいて、彼らは合法的に有能で目標とメトリックで満たされた文書を放棄することを提案します。 アジャイル自体は、「年末までに少なくとも10,000回訪問する」、「1か月でサイトからの注文25件以上に達する」などの目標を設定することはできません。これは、会議を開催して過失の従業員を再編成する方法にすぎません。 何回も振り返ります：「しかし、あなたはあなたの目にほこりを入れますか？」 事実、プロのTKは新しいスクラムを傷つけることはできませんが、手助けする必要があります。