テクニカルライターの仕事は、私のお気に入りのロシアのテクニカルライターに捧げられています。ソフトウェア製品のドキュメント、基本的にはすべての種類のユーザーマニュアルを作成するためです。ドキュメントの作成は簡単ではありません。多くのアプローチと実践があります。たとえば、研究および生産企業のテクニカルライターは、GOSTまたはその他の国内基準に従って作成することがよくあります。彼らの目標は、製品を正確かつ正確に説明することです。また、国際企業のテクニカルライターは、スタイルガイド(Microsoft Manual of Styleなど)に従って作成します。この場合の目標は、製品がどのように機能するかをユーザーに伝えることです。ここでは、焦点が製品からリーダーに移っています。
私はさまざまな場所で、さまざまなルールとポリシーで技術ライターを務めてきました。振り返ってみると、研究機関でもテキストをエンドユーザーに向け直すことができ、ドキュメントはこれから恩恵を受けると言えます。しかし、GOSTでは彼らはそれについて書いていません。また、スタイルガイドは、第一に英語で、第二に、NPP、KBなどの国内オフィスでは宣伝されていません。したがって、明らかに情報が不足しています。私はそれを埋めようとします。
Yandex、Google、Microsoft、Apple製品のドックは、設計エンジニアが作成した昔ながらのドキュメントとどのように異なりますか?
古典的なエンジニアは、製品がGOSTと受け入れられている用語に従って、可能な限り完全かつ正確に記述されるように記述します。さらに、GOSTの用語と定義の多くは古く、ドキュメントをまったく着色していません。しかし、これはコンストラクターにとっては問題ではありません。ユーザーがテキストを理解しやすいかどうかは誰も考えていません。しかし、人々のために作られたドックは異なります。それらは理解しやすい言語で書かれており、ユーザーの興味を考慮に入れています。優先順位の問題。
著者のこれらの優先順位と目標は、どのドキュメントを取得するかに大きく影響します。実生活でどのように見えるかを例で見てみましょう。
| 設計アプローチ | ユーザー指向
|
|
|---|---|---|
| 用語の単純さ
|
マウスのLMBクリックでフォルダアイコンをクリックします。
|
.
|
|
|
20- , , . .
|
, , . |
|
|
. «». , . «».
|
. |
| , . . , , .
|
, . , .
|
|
|
|
. – , .
|
: , , .. , .
|
|
|
: , , , , .
|
, . , . , , .
– . – . , . |
あなたが文書を見ることが起こります、そしてそれらはすでに道徳的に時代遅れです。1950年代のトラクターのマニュアルを読むようなものです。どういうわけかそれらをより関連性のあるものにする必要がありますが、それは不可能のようです。実際、何でも可能です。次の記事では、膨大な古いドキュメントのセットから、軽くて理解しやすい最新のドックに正確に移行する方法を段階的に分析します。表の各ポイントを個別の記事で分析します。
ネタバレ
簡単なことではありません。