製品を最もよく知っているのは誰だと思いますか？ PM、それともDM？ アナリスト？ インターフェイスデザイナーですか？ これらすべての質問に対する答えは、ノーと思われます。 少なくとも大規模プロジェクトの場合。 なんで？
もっと詳しく考えてみましょう。
チーフ。 彼は概念を説明します。 「青い色にしたいのですが、このボタンはすべてを減らします。 そして、Windows 8のように| iOS | そのアプリケーションで| 競合他社よりも優れています（不要なものを消す）。 そして、 明らかに 、赤ですべてを実行し、正方形に配置できるはずです。」
アナリスト。 彼は要件を書きます。 彼は製品に何を含めるべきかを知っています。 彼は主なシナリオがどのように機能するかを知っていますが、通常は実装の微妙な点には触れません。これにはインターフェイスデザイナーがいるからです。 そして、これはインターフェース設計者の仕事です。製品を美しく便利にすることです。 結局のところ、この製品は実際に使用するもののみで構成されており、80％はマーケティング資料、チェックマーク、競合他社との比較で構成されています。 アナリストは、自分の要件が何に変わったかの開発の終わりに非常に驚かされることさえあります。 結局のところ、ご存知のように、旅行中に犬は成長する可能性があります。
インターフェイスデザイナー（ID）。 要件に従ってインターフェース設計を描画します。 理想的な場合、プロジェクトは開発でガイドされる必要があるほとんど唯一のドキュメントです。 要件から取られた技術仕様の一部ですか。 しかし、これは理想的な世界でのみ起こります。 現実の世界では、デザイナーインターフェイスはさまざまな例外的なケースやエラーを処理しません。 これはプログラマーが行う必要があります。 もちろん、彼は困難な状況でIDを調べますが、通常は自分で簡単なIDを調べます。
プロジェクトマネージャー（PM）。 チームが失敗し始めると、彼は到着し、なぜ緑色の赤い線を引くことができないのかを鋭い声で尋ねます。 そして、開発者から受け取った情報を繰り返し明確にし、複製します。「破損した電話」を介して行われます。 したがって、PMは通常、製品の問題のある部分に精通しており、これらすべてについて独自の具体的な見通しを持っています。 ただし、プロジェクトの参加者はすべての問題について特定の見方をします。 しかし、PMについて何か言う必要があります。
開発マネージャー（DM）。 製品が小さい場合（1〜3人の開発者）、彼は製品が何を、どのように、そしてなぜ行うのかを完全に理解しています。 製品が大きい場合、詳細を掘り下げる十分な時間がありません。 機能の一部として、彼は開発者とテスターのバンドルを信頼することを余儀なくされており、すべてがそこにあると信じています。 通常、DMは製品の一部を実装するのが困難であり、さらに単純で十分に説明されたインターフェイスデザイナーが得意です。
全体として、開発プロセスの上記の各参加者は、その「クリアリング」によってうまくガイドされていますが、ほとんどの場合、製品の完全な全体像を持っていません。
それで、すべてを知っている同じ人は誰ですか？ これはテクニカルライターです。 テクニカルライターの仕事は複雑で時間がかかるだけでなく、責任も伴います。 Techpisは、異なる人々によって行われた同じことを、最初に同じこと、次に正しく呼び出すことを確認する必要があります。 彼は「理解できない」と言い、プログラムのこの場所で何が起こっているかを調べに行きます。 最後に、開発者の不完全な説明に基づいて新しい機能の名前を発明し、プログラムの複雑な場所を説明するテキストを作成する必要があるのは彼です。 彼はプログラマーからロシア語への翻訳者です。 テクニカルライターは、わかりやすく、美しく、そして最も重要なことを考え出す必要があります。機能に関する短いテキストで、おそらく十分に設計または実装されていません。
ところで、製品をより良くするための最速の方法を知っていますか？ もちろん、ボタンの名前を変更します！ vonvogelからのこのトピックに関する有名な漫画の適応例は次のとおりです。
他に何？ Techpeaceは、インターフェースのさまざまな部分の整合性と相互の対応をチェックします。 そして彼は証明書を書きます。 そして彼は、それがハリネズミにとってさえ理解できるように書いています。 したがって、テクニカルライターのタスクは、適切なリファレンスを作成することです。 ユーザーは常に自分の質問に対する答えを見つけますが、この答えは明確であり、検索には最小限の時間がかかります。 これは実際にはどういう意味ですか？ ヘルプ構造は、直感的でできるだけシンプルでなければなりません。 テキストは読みやすく、フレーズは明確で、できるだけ短くする必要があります。 複雑な構成は避け、テキストはバランスがとれている必要があります-単純すぎず、機能が多すぎず、語彙が不十分ではなく、華やかな表現でいっぱいではありません。 複雑なことを簡単な言葉で説明できる必要があります。 ユーザーを混乱させないために、統一されたスタイルのプレゼンテーションとデザインを尊重する必要があります。 ヘルプは製品と一貫している必要があります。 新しい機能を説明し、存在しないものを削除し、変更されたものを書き換える必要があります。 そして、プログラムがまだ存在しないか、テストされていないか、デバッグされていない状態のすべてです。 したがって、何がどのように機能するかを見るのは不可能です。
それは、何年も前に、私たちが州の機関のニーズに合った製品をリリースしたという話を思い起こさせます。 当時の製品は劣っていました。アナリストでも、デザイナーでも、プログラマーでも、テスターでもありませんでした。 新しいバージョンでは、ドキュメントを更新する必要があるという事実は、リリースの数日前に記憶されていました。 すべては問題ありませんが、その時点でのプログラムはインストールされず、起動しませんでした。 経験豊富なテクニカルライターの開発者の言葉から新しい機能を説明することは問題ではありません。 しかし、政府機関向けのプログラムは正しいことを覚えていますか？ そして、私たちが知っているように、彼らの中では、コンピューターと友達でなく、すべてを恐れている中年の叔母が非常に頻繁に働いています。 もちろん、私たちは彼らを助けようとしているので、信じられないほど多くのスクリーンショットがヘルプにあります。 そして結果として、プログラマーが製品を完成させようとし、テスターが起動し、PMが実行され、PMが今日すべてを修正してテストする時間があり、テクニカルライターが
テクニカルライターは、ユーザーガイド、管理者ガイド、短いユーザーガイドなどを作成します。 各ドキュメントには独自の目的があり、それは独自の特性とニュアンスを意味します。
また、さまざまな国向けの製品もリリースしているので、テクニカルライターに飽き飽きする必要はありません。プログラムをさまざまな言語でローカライズする必要があります。 翻訳のためにすべての資料を収集し、それらをチェックし、製品に統合し、開発中に変更を加えることは、まさに技術的なことです。 プロセスの深刻さについてはこちらをご覧ください 。
別の話があります。 数年前にFineReader Nをリリースしましたが、アナリストが分析し、デザイナーがペイントし、プログラマーが実装し、技術的な説明が記述され、すべてが22言語に翻訳されました。 そして、ここにベータテストがあります。 そして、ユーザーは私たちに（または、1人のユーザー、または1人のユーザーでさえも）伝えます。「そして、2つのコマンドを返してください。それらなしでは生きていけません。 はい、同時に2つの余分なスクリプトを削除します。」 彼らはDMにどれくらいの時間を変えるか尋ねた。 「いいえ」と彼は言い、2行をコメントアウトして2行のコメントを外します。 テクニカルライターを除き、誰もが喜んでいました。 彼らは、スクリーンショットの一部を取り戻すために、プログラムのリソース、ヘルプ、ユーザーマニュアル（その時点で既に作成されている）、QRC（別名クイックリファレンスカードまたはクイックフレンドカード）に変更を加える必要がありました... 自分で言語の数を掛けます（calcが機能しない場合は、 MKrivosheevからの描画が役立ちます。 画像のビデオ説明 ）。
理想的には、各テクニカルライターは同時にアナリスト、デザイナー、テスター、そして時にはプログラマーであることが理想的であることがわかります（開発者向けの技術的な説明や製品など - など ）。
結果として、テクニカルライターは開発チームのスーパーマン（ほとんどの場合は超賢明ですが）です。 彼は人道主義者であり技術者であり、プログラミングと情報技術に関する基本的なアイデアを持ち、単純な（Wordのような）から非常に複雑な（Visual Studioのような）幅広いプログラムを理解できる必要があります。 詳細に細心の注意を払う必要がありますが、同時に製品全体を見て、それを最もよく説明する方法を理解する必要があります。 あなたの仕事の海にdrれないように、あなたの仕事を明確に計画できるようにしてください。 彼は、少なくとも文書を読むレベルで、文章に堪能であり、英語を知っている必要があります。 ストレス耐性、緊急モードでの作業、1つのタスクから別のタスクへの迅速な切り替えなどを忘れないでください。 一般的に、優れたテクニカルライターは商品です。 したがって、テクニカルライターを愛し、それらの世話をし、あらゆる面で彼らを助けてください。 それらがなければ、あなたの製品は少し惨めになり、舌で縛られ、彼らと共に幸せ、お金、成功を手にするでしょう。 まあ、または少なくとも良い製品。
エレナ・フォメンコの参加によるイヴァン・コルネエフのクロノマスター 、
テキスト認識製品の部門。