企業のトローリング-3、または不必要な心配なしの仕事の配達

前の記事（ first 、 second ）で、顧客の従業員がプロジェクトのさまざまな段階で抱いている反対の例を簡単に、冗談を交えて説明しました。 今日、検討の対象は仕事の引き渡しであり、1つのトロールが突破しないように、この段階に完全に武装してアプローチします。 多くの手紙が出ましたが、それだけの価値があることを願っています。

作業結果の提出は、プロジェクトの最も劇的な段階の1つです。 ソリューションの開発、デバッグ、テスト、および実装に費やされた工数は無駄になりません。 仕事の委託があなたに委ねられている場合、チームでのあなたの役割は非常に重要であり、上司があなたにそれを言わなかったとしても、経営陣の信頼は素晴らしいです。 仕事に夢中になることは、素晴らしいキャリアの終わりを意味する場合があります。 ですから、これをしない方がいいです。

受け入れテストプロセスは厳密に形式化する必要があります。 このプロセスの最後に、プロトコルと行為が表示され、それに基づいてシステムをパイロットまたは産業運用に移行する命令が発行されることを誰もが理解しています。 この行為はまた、プロジェクトの次の段階の支払いを請求する正式な理由でもあります。

この記事では、冗談は一切しません（冗談です！）できるだけ一貫して（もちろん、ブログの場合は）設計作業を送信するプロセスについて説明します。 もちろん、経験豊富な同僚にとって多くのことは明らかです。 させて しかし、経験の浅い同僚や引き継ぎの責任ある役割を試してみたい人は、この出版物が有用で有益であると思うでしょう。

トローリング方向のテスト

何人の人があなたの失敗に興味を持っているのか、あなたにはわかりません！ 誰かがあなたの精神的能力に関して自分の主張を証明したい、誰かが期限を延長したい、誰かがペナルティを夢見ている、誰かがBMWの新しいタイヤを必要としている...そのような場合、トロールキラーは委員会に渡されます（最初の投稿を参照してください） ） この段階では、対処しなければならないトローリングの3つの領域があります。

1. 正式な受け入れ。 トロールは、「システムにはクライアント/サーバーアーキテクチャが必要です」というような声明を出しています。 アイテムが閉じる方法を示す必要があります。 また、技術プロジェクトの説明文に「システムにはクライアント/サーバーアーキテクチャがあります」という行を含めるのを忘れていました。そうしないと、恐怖で見つけることができませんでした。 TKのすべてのセクションをくまなく調べて、必要な行を見つけてください。
2. テストのエラー。 テストを策定するときは、意図的な誤解の可能性を避けてください。 たとえば、「オペレーターはユーザーのリストから任意のユーザーを選択します」と記述します。 トロールは、テストが機能しないシステムユーザーまたは管理者のリストから選択します。 または、「 すべてのオブジェクトのプロパティが表示されました」と記述します。 トロールは、プロパティが表示されていないオブジェクトを突きます。 そして、「すべての必要なオブジェクト」を意味していましたが、列車は去り、「 すべてのオブジェクトのプロパティは表示されません」という恐ろしい発言を受け取りました。
3. 「非常に重要なポイント。」 メインバトルの銃が消滅したとき、クリティカルと非クリティカルに関するコメントの分析が開始されます。 重要なのはあなたの喉にあり、行為の署名を妨げます。 したがって、トロールはすべてのコメントを重要なものにしようとします。 すべての哀れみが含まれ、頭をうなずく権威ある同志、そして馬とのその他のサーカスが関係している。

次に、作業を送信するときに、説明されている問題を回避するために必要なものを検討します。

テストプログラムと方法論

私の意見では、PMI文書、またはテストプログラムとテスト方法論は、TKよりも重要です。 テストの成功の3分の2ではないとしても、半分はこのドキュメントの品質に依存します。

ドキュメントのコンテンツの要件は、 GOST RD 50-34.698-90のセクション2.14に記載されています。テクニカルライターのデスクトップ標準とも呼ばれます。 このドキュメントには何を含める必要があります：

1. GOST（テストの目的と目的、テストの量と条件など）に準拠した正式な部分。 その結果、これらのセクションを読んだ後、委員会のメンバーは、たとえプロジェクトにまだ参加していなくても、彼らが何をしていて、彼の個人的な役割がこのすべてであるかを理解しなければなりません。
2. ドキュメント、ディスク、転送されたコピーの数など、すべての完全性をチェックします。 したがって、これはすべてテスト用に物理的に存在する必要があります。 目標は、作業指示書と配達に関する契約の正式な要件を終了することです。
3. テストの実施方法の説明。 物理センサーからシステムの実際のデータを供給しますか、またはテストファイルまたはエミュレーターにスリップしますか？ システムは実際のオブジェクトを管理しますか、それともログを見るのに十分ですか？彼女がこれをやったことはどこに書かれていますか？ ユーザーは厳重に制御室に座るべきですか、それともオフィスのラップトップに制限することができますか？
4. 高レベルのシステムテスト。 詳細は、顧客によって異なる場合があります。 一般的なテストとステップバイステップの手順を伴うテストの両方があります。 テストの目的は簡単です。最後のテストに合格したら、技術仕様のすべての機能要件を閉じ、操作文書に必要な情報が含まれている（つまり、作業に適している）ことに注意する必要があります。
5. テストスクリプト。 テストは、テスト時間と不要な質問を最小限に抑えるために必要な順序で配置する必要があります。 たとえば、人事プログラムで従業員の受付、異動、解雇を確認し、シナリオをそれだけにしてみましょう-仕事のために誰かを雇ってから、彼を異動させてから解雇します。今回は。 または別の例。 テストの1つでは、バックアップを確認し、システムを復元する必要があります。 テストが連続して数日間続く場合、最初の日の終わりにバックアップテストをスケジュールする方が賢明です。 そうすれば、長い手順が終わるまで待つ必要はありません。 そして、回復は最後から2日に計画することができます。 リカバリの前に、緊急シャットダウンのエミュレーション、ログおよび重要なファイルの損失などの厳しいテストを実行できます（もちろん、これを経験する必要がある場合）。 さて、上記は明白に思えますが、実際の文書を読んで、これが誰にも明らかでないことを確認してください！

テストレポート

PMIテストに基づいて、テストレポートを準備する必要があります。 プロトコルは、システムが作業指示書に従って実装されていることを確認する文書になります。これについては、対応するエントリが行為で作成されます。 委員会の前に青白い外観にしたくない場合は、プロトコルの準備を他の人に信頼しないでください。 通常、プロトコルはPMIからの「コピーアンドペースト」であるため、準備にそれほど時間はかかりません。

テストレポートは、一般的な部分、テストテーブル、およびコメントのリストで構成されます。

テスト結果が入力される表は、次の列で構成されます。

1. スルーナンバー（あなたにとって便利な形式）。 たとえば、Test_Number、Step_Number。
2. オペレーターのアクション。 結果を得るためにオペレーターが行うこと。 言葉遣いが悪意のある誤解を排除していることを確認してください。
3. 期待される結果。 簡単に言えば、オペレータのアクションの記述された結果であり、確認することができます（タッチ、シー、匂い）。 例：「トップパネルの緑色のライトが点灯」、「ユーザーのリストに新しいユーザーが表示されました」、「画面に間違ったパスワードに関する警告が入力されました」、「システムログXにエントリYが表示されました」 言葉遣いはできるだけ具体的であり、悪意のある誤解を排除するようにしてください。 また、トロールの食物ベースである「すべて」、「全員」、「すべて」、「なし」などの言葉も覚えておいてください。
4. ドキュメントの項目（ユーザーガイドなど）。実行されたアクションの詳細な説明を提供するか、作業ステートメントの非機能要件を閉じます。 このアイテムの存在は、1つの石で2羽の鳥を殺します。 まず、設計文書に反映する必要があるすべてのものを文書化します。 第二に、（注意！）テストは技術設計の要件を満たす従業員に対して許可されているため、オペレーターのアクションを詳細に書き留める必要はありません。
5. このステップで閉じるTKのポイント。 列の合計は、TKの要件すべて（機能だけでなく、正確にすべて！）を与える必要があります。 そのため、プロトコルにドキュメントの完全性をチェックする「バカなテスト」が含まれ、プログラムはJavaで記述され、Oracle DBMSデータベースはリレーショナルである（ドキュメントの対応するセクションで指を突く）。
6. 委員会の決定。 次のソリューションを主張する必要があります：「合格」、「コメント付きで合格」、「未合格」、「未テスト」。 ここには他のエントリはありません。 エントリ「未テスト」は、委員会が実施したくない、またはテスト時に実施することが物理的に不可能だったテストに対して作成されます。 たとえば、彼らはソケットからクラスタノードを抜かないことを決めました。 プロトコルにそのようなエントリがないことが望ましいので、トローリングの不必要な機会はありません。
7. コメント コメント付きでテストに合格した場合は、コメント番号が必要です。 すべてのコメントは、自由形式でプロトコルの付録に入力されます。 テスト中にコメントがあった番号を指定できます。 それ以上の時間はありません。 委員会の決定が「合格」である場合、「コメント」列に何も書かないようにしてください。

ドレスリハーサル

それなしではできません。 この方法でのみ、テストのすべての粗さを把握し、時間を盗むテストと結果が疑わしいテストを特定できます。 視覚的なコンポーネントは完璧でなければならないことを忘れないでください。 クライアントが処理しているものに似た自然なデータをシステムに入力してみてください。 ユーザー名やその他のフィールドに冒とく的な表現（実装者やプログラマーのお気に入りの冗談）が含まれていないことを確認してください。 これらの「ジョーク」は、時には雄牛の赤い布のように委員会に作用します。

PMIを最初から書き直すことを恐れないでください。 時間を後悔し、テストを書き直す代わりに再配置しました。 その結果、嘆かわしい全体像を変えることなく、単に安心できました。 彼らがかき集めました。

一緒に合格した場合、一緒にテストを駆動します。 同僚を招待し、彼らに過失を見つけさせ、任務を装います。 その結果、これらのゲームに費やした時間により、すべてのお客様が満足した顧客からお金を受け取ることができます。

効果的なデュエット

変更に最適なチームは、実装者（またはプログラマー）とビジネスアナリスト（コンサルタント）のカップルです。

実装者（プログラマー）：

• システムで動作し、インターフェースの習熟を示します
• 技術的な質問に答えます

アナリスト（コンサルタント）：

• システムについて顧客と話し、会話を行う
• 一般的な質問に答えます
• 記録を残す
• 実装者（プログラマ）のテーブルの下でキック

このようなチームにより、「マイク伝送」と呼ばれる手法を実装できます。 プログラマーが突然バグを踏んだ場合、コンサルタントは彼に顔を平手打ちし、誰かの曲がった手にdして、顧客をすぐに怒らせることができます。 効果はサーカスのようになります。 顧客は自分自身に笑い、すぐに彼は道化師ではなく、彼の手はより直接的になると考えます。

同様に、コンサルタントが愚かだと言い、顧客がそれに応じて眉をひそめた場合、プログラマーはsystem辱された罪のない顔でシステムの別の機能を示すことができ、顧客は彼に同情します。彼は本当のプロが誰であり、道化師がネクタイを着ているのかを理解するからです。

特に緊張した瞬間には、友好的な小競り合いを配置して、状況を緩和し、システムの完全に正しくない操作から観客の注意をそらすことができます。

西洋の「ITエバンジェリスト」が二人一組で仕事をするのが好きなのは、何の理由もない。

プロセスが開始されました！

テストを開始したとき、すぐにシステムに入ることを敢えてしないでください！ 最初に正式な部分全体に目を通すようにしてください。 ドキュメントコード、ストレージメディアを確認し、作業指示書を開いて、ユーザーガイドを表に記載します。 機能以外の要件を確認します。 Windows OS-チェックマーク。 サポートされているブラウザのバージョン-1、2、3、チェックマーク。 開発言語、アーキテクチャ、データベースですが、TKで何が書かれているかはわかりません！ すべてをドキュメントに表示する必要があります。 少なくとも1つの文のみがあり、それはそこにあるに違いありません！ この官僚主義を無視しないでください、トロルはこれを待っています。 プロトコルで、「請負業者はJava言語が高レベルのクロスプラットフォーム言語であることを実証していません。 TK 1.2.3および3.2.1の要件が満たされていません」 しかし、これは発明された狂気ではなく、これは人生そのものです。

物事の正式な側面を完了したら、システムに突入しないでください！ テストの次のグループは、モニターをオンにして、デスクトップ、アイコンをデモンストレーションし、プログラムを起動することです（起動をテストする必要がある場合）。 間違ったパスワード、チェックマーク、正しいパスワードでのログイン-再びチェックマーク、チェックマーク、チェックマーク。 メニューは素晴らしいです！ メインフォーム、何かのリスト。 チェックマーク。

システムのボタンを押すことに関しては、委員会はすでに疲れていて空腹です。 また、初日には、たとえば、基本ディレクトリと基本機能をスキップできます。 そして翌日、バックアップ、管理、その他のナンセンスを残します。

備考

彼らは、あなたが疑う余地はないでしょう。 コメントがないシステムはありません。 あなたの仕事は、すべてのコメントを重要なものとそうでないものに分けるように顧客に強制することです。 最初のものは、試運転に正常に移行するために修正する必要があります。 2番目は試運転中に修正できます。 したがって、最初のものはまったく存在しないか、修正が難しくないもののみが存在する方が良いです。

顧客がコメントするとき、あなたは数分で彼の言葉遣いを記録します。 記録された言葉を話して、お互いを理解していることを確認してください。 レコーダーがテスト中に動作する場合、より良いでしょう。 発言の文言を建設的にするようにしてください。つまり、発言を撤回するために何をする必要があるかが明確です。 「すべて」、「何もない」、「全員」、「任意」という言葉、および「悪い」、「遅い」、「速すぎる」などの測定されていない定性的評価 発言はすべきではありません！ 「システムが遅い」場合、「要求されたフォームは5秒以内に表示されるはずです」と記述する必要があります。 「ダイアグラム内のシンボルがほとんど識別できない」場合は、「ダイアグラム内のシンボルを18ポイントに増やす」と記述する必要があります。 などなど。

具象化は、1つまたは別の発言をクリティカルランクに不当にドラッグする可能性を最小限に抑えます。 顧客は、リクエストを6秒間処理することは受け入れられず、5秒間は許容できないと主張するかもしれません。 プロトコルに表示させてください！ しかし、表示されないものがあります。 または、コメントは重要ではないと宣言されます。

重要であると認識されたすべてのコメントは、行為に記録されます：「委員会は、システムがTORに準拠することを決定し、以下のコメントを作成する条件下で試運転を開始することを推奨します：...」 それらの多くは通常あり、責任ある署名者を怖がらせることができます。 顧客が重要でない発言を解決しないことを心配している場合は、準備することが強く推奨されているドキュメント「Test Operation Methodology」の助けを借りて顧客を安心させます。 そこで、簡単でアクセス可能な形式で、試行操作の進行方法、見つかったバグの解決方法、および試行トライアルジャーナルの記入方法を説明する必要があります。これにより、MAの痛みのない終わり、システムの試運転とプロジェクト終了によるシャンパンでの敬礼が保証されます。

すべてがなくなった場合の対処方法

テストが満足のいくものではないこと、システムがいこと、そして顧客がすでに呪いを使い果たしていることを理解すると、あきらめる必要はありません！ キャラバンは前進し続けなければならず、新しいリリース、新しいトライアルがあります。 そして、プロジェクトが散らかっていても、あなたにとってひどいものは何もありません。 賢明なパフォーマーが深刻に不足している状況では、特にそのような状況を許すあなたの会社では働いていないので、あなたはすぐに仕事を見つけるでしょう。

エーテルのような口論で時間を無駄にしないために、「他人が恐れないように自分のビートを打つ」戦術を使用することをお勧めします。 お客様と一緒に「これらの曲がったプログラマー」、「貪欲なリーダーシップ」をscり始め、情熱が減ったら、お客様に「this glukalov」の最大のバグを集めて、これらの悪い人たちがどれほど悪いかを見せてください。

その後、トロールキラーが率いる顧客のアクティブな従業員は、バグの収集を開始し、プロトコルに何百ものコメントを記入します。 実際、彼らはあなた自身のお金で高レベルの機能テストを実施しますが、テスト結果から判断すると、開発者はそれができませんでした。

良い、説明されたい状況によると、まったくないはずです。 しかし、プロジェクトビジネスは奇妙な変動を特徴とする場合があります。最初のプロトタイプを完全なシステムとして渡そうとすると、ボスは部下と自分自身に嘘をつきます。周囲の誰もが悪いゲームに対して良い顔をして、お互いに必須で不可欠な成功を保証します。

このような状況での2番目のアドバイスは、すでに述べたように、そのような「ショール」を許可するオフィスから直ちに辞めることです。 すべての基準で、真の専門家はこのように評判を損なうべきではないからです。

おわりに

だから、同僚は、これで企業のトロルの三部作を完了することを急いでいます。それは恐れる必要はありませんが、尊敬され、何らかの方法で愛されるべきです。なぜなら、彼らはITビジネスの怠zyな猿が木の大食いから落ちて、私たちを良い状態に保ち、さらには私たちを連れてくることさえできないからです非常に退屈なことにある程度の関心がありますが、多くの設計作業が必要です。

2011年6月23日からUPD ユーザーigendoは、契約を締結する段階で既にプロジェクトの公式文書のフォームを承認するのが良いとコメントに追加します。

引用：

私は、行為、プロトコル、およびその他の正式な文書の形式が契約で修正されると、仕事で多くの助けになると付け加えます。 そのため、プロジェクトの途中でそれらを事前調整、再交渉、やり直し/再署名する必要はありませんでした。

また、非常に困難で大規模なプロジェクトでは、プロジェクトのチャーターを作成するのが慣習であり、その深い意味についての特定の文書を何時間も話すことができることを自分で追加することもできます。 そこでは、プロジェクトドキュメントの形式、プロジェクトの進行状況を監視する手順、および高レベルのビジネスタスクについて議論できます。 しかし、これもまた別の投稿のトピックです。

LiveJournalユーザーryzhij_papaビジネスへの影響の程度についてコメントをランク付けする慣行があることを追加し、ランク付け手法もPMIに記録されます。

引用：

クリティカル、高、中、低の優先度のコメントを正式に説明する必要があります。 説明はビジネスの観点から行われます。 誇張すると、これは次のとおりです：従業員が石鹸を飲んでいるときは平均で$ 1000、高い場合は$ 100、損失は非常に高いですが、損失はありませんが、低い-5-6年の人生でわずかな精神異常のようなバグがあるかもしれません...