かつて技術文書に興味があり、ネイティブインターネットのオープンスペースでこのような興味深い標準を見つけました。 標準は単純ではありませんが、GOSTです。 もちろん、Webサイトのドキュメントを準備するために特別に作成されたものではありませんが、中程度の複雑さのサイトに対してかなり深刻な技術タスク(以下TKと呼びます)を作成するには十分です。 巧みなアプローチで、インターネットテクノロジーに関連するドキュメントの準備にそれらを使用できると思います。
私が最初に注目したいのは、規格の公式性です。 この場合のトピックに最適なのは次のとおりです。
• 「自動化されたシステムの作成に関する条件」(GOST 34.602-89) -あらゆる種類のソフトウェアを操作するための容量の多いもの。サイトのドキュメントの作成に関してドキュメントを非常に空間的にしますが、TKのコンパイルの優れた普遍的なドキュメントの基礎として機能します。
• 「参照期間。コンテンツと登録の要件」(GOST 19.201-78) -サイトの技術仕様の登録により適しています。私の意見では、以前のGOSTの短縮バージョンであり、より便利です。 実際には、TK全体の既成のセクションセットです。
次のように、ペアで使用すると便利です。 最初の(GOST 34.602-89)には、TKのタイトルと最後のシートの形式があり、法的力を持たせるためにドキュメント全体を作成する方法があります。2番目(GOST 19.201-78)には、TKを作成するまさに原理が記述されています。 2番目のGOSTのポイントとそのシーケンスにより、TKを作成するための計画として使用できます。
叙情的な余談として、私は定期的に発生する1つの質問に注意を喚起したい-TK、顧客または請負業者を提供する必要がありますか? 多くのパフォーマーは、顧客からのTKなしで作業することは不可能であると考えています。多くの顧客はTKを書くことを拒否します。「これは私たちの仕事ではありません。 この場合、両当事者は間違っています。 私の意見では、TKの設計自体は請負業者が実行する必要がありますが、顧客の要望を考慮に入れる必要があります。 つまり、TORのコンパイル作業は共同で行う必要があります。 相互に転送することはできません。 理想的には、中立の領域で会い、論争のある問題をすべてホットコーヒーですぐに解決することが最善です。 これにより、顧客と請負業者の両方にとって多くの時間を節約できます。 TKの段落が何を意味していたかを知る必要はなく、リラックスした雰囲気の中ですべての問題をすぐに解決します。 その結果、両方が勝ちます-顧客は、請負業者がそれを正しく理解したことを冷静にし、請負業者は、顧客が不可能を望んだときにすぐにオプションを除外することができます。 すぐに、すべての期限とその他のニュアンスを規定することが可能になります。
個人的な会議の可能性がない場合、顧客はすべての希望を書面でエグゼキューターに転送することができます-エグゼキューターと顧客は、Skype、ICQ、電子メールまたは電話を介して通信するプロセスで疑わしい点をすでに修正し、論争のある問題を一緒に解決し、ドキュメントを最終的な形にする両方に適しています。
もちろん、署名文書によって正しく作成および認証されることが、署名した両当事者のセキュリティの鍵であることを忘れてはなりません。