TKでレーキを踏まないでください：競争と2つの物語の壮大な体験

不正確なTKの広く知られている例



一般に、同僚と私はTKを使用して壮大な事例を選択しました。これはおそらく、誰かが私たちの間違いを繰り返さないようにするのに役立つでしょう。 まあ、または楽しんでください。



かつて私は非常に難しい顧客と1年半の間設計されたプロジェクトを得ました。 ステータス：6か月が経過しましたが、技術仕様はまだ交渉中です。 彼らは1つのことに同意しましたが、顧客は頑固に新しい要件を提示し続けました。 タスクは時間通りに終わることやお金を稼ぐことでさえありませんでしたが、すべての人の損失を最小限に抑えて尊厳をもって去ることでした。



それは難しいことでした-正しい言葉ではありません。 長いフライトで、TKを20ページ読みました。 このような特異性がありました：流youに読めば、正しく正確に書かれているように見えるかもしれません。 しかし、エンジニアリングの実装の詳細を掘り始めた場合、予想外の多くの人々が一度に浮上しました。 3.2.5や4.8.2.9などのサブパラグラフの一部の要件は、現実の世界では互いに矛盾したり、単に相互に不可能な場合があります。

TKにすぐに同意できないのはなぜですか？

競技会や入札において、十分に完全な技術的課題（または少なくとも詳細な受け入れ基準、または単に分かりやすい技術的要件）を見つけることが非常にまれであることは秘密ではありません。 曖昧なドキュメントは、驚くべき量のサプライズと作業量の増加をもたらします。 以下に、作業量を評価して購読するために必要な実際のドキュメントの例をいくつか示します。

• 「システムには、直観的なグラフィカルユーザーインターフェイスが必要です」とロシア語に翻訳されています。「コンソールに加えて、ロシア語でGUIが必要で、多くの説明が必要です。秘書が複雑を管理するからです。」 最も可能性が高い。 なぜなら、顧客は直観について独自のアイデアを持っていることが判明する可能性があり、彼はそれらを主張するからです。 しかし、ほとんどの場合、このフレーズは文書化の典型であり、一般的にはそれほど危険ではありません。
  
  
  
  
• 「システムは、システムのユーザーにアクセス権のシンプルで柔軟な設定を提供する必要があります」、これは桁違いに悪いです。 存在する権利については説明していません。また、ネットワークロールの詳細の違いがアーキテクチャに影響を与える可能性があります。 そして、それに応じて、プロジェクトに必要な機器。
  
  
  
  
• かつて、ワークフローシステムの詳細な説明の後、「情報の保持期間は期間ごとにカスタマイズできるようにする必要があります」と答えました。顧客が何を念頭に置いていたかを推測してみてください。 まず第一に、あなたは私たちが話している情報の種類とそれがどこに保存されるかに興味があります。 等しく成功した場合、これは、レコードのアーカイブを使用できるようにする（非常に単純な）通常のフレーズ、または別のサイトにバックアップする必要があることが判明する場合があります。

悲しいかな、ほとんどの場合、競争に応募する前にそのような落とし穴を評価することは不可能です。 「悪い」ケースでは、私たちの読書版からの可能な逸脱の平均分岐が推定され、およそこの数の作品が置かれます。 最大限に書くことはできません。そうすれば、どんな競争でも勝つことは不可能です。 一方、顧客が知られている場合、または顧客がすでに一般的にどのような要件を持っているかが明らかな場合、プロジェクトの機能を大まかに見積もることができます。

生態学的バランス

当然のことながら、問題に関する特別な（そして非常に深い）知識なしに、参照条件を完全に登録することは非常に困難です。 原則として、顧客は常にそのような知識を持っているとは限りません。 したがって、請負業者は、作業明細書がその場で補足されること、および顧客-請負業者がそれを理解できないことを常に知っています。 TKへの追加の程度と誤解が少ないほど、当事者はより適切です。 しかし、繰り返しますが、大規模なプロジェクトでは、誤解はほとんど常に発生します。



次に何が起こりますか？ その後、興味深い生態学的バランスが生まれます。



悪い場合：

• 巨大なTKが突然現れたときに、請負業者が自分のイニシアチブで州の顧客の契約を拒否した場合、彼はサプライヤーの「ブラックリスト」に追加できます。
• 顧客は結果を受け取りませんが、お金を使います。

通常の場合、「参照条件に正確に従って」いると、プロジェクトは明らかに機能しません。

• 請負業者は、この顧客とのさらなる作業のために、または単に作業を行う必要があるため（評判のため）、ポートフォリオの契約を必要とします。 この場合、彼はいくつかの修正に耐える準備ができていますが、一方で譲歩と妥協を期待しています。
  
  
  
  
• 顧客は、業務明細書に正確に従っていると、驚きが反対方向から始まり、時間とお金を失い、アイドルソリューションを得ることができることを理解しています。

その結果、誰もが完全に理解し、同意します。 もちろん、TKを持っている大規模な顧客がインテグレーターを文字通り狂わせることができる別のプロジェクトがあります。 もし彼がそうすれば、このインテグレーターが競技会で彼に来ないということを完全によく理解しているのは彼だけです。 そして、国内の多くの作品については、純粋にプロジェクトの複雑さと量の観点から、一般的にこれを引き出すことができるのは2〜3社のみです。 最後の一人で最後に一人でいるのは怖いです、パフォーマーはすでに条件を指示します。



たとえば、ここにプロジェクトがあります。 作業指示書には、「システムを監視する必要があります。」という行がありました。 これにより、別のプロジェクトが発生しました。人件費を見積もることも計画することもできませんでした。 そして、顧客はすべてを異なって見ました。 彼には内部規制があり、歴史的に形成されています。 その後、いわゆる「おろし金」が始まります。 一方では、「ToRに従ってあなたにそれを行います」、他方では-「私たちはそれを受け入れません。」 両当事者がある程度の権利を持っていることは明らかであり、彼らは問題を紛争に持ち込みたくないのです。一方で、私は繰り返します。 誰もそれを必要としません。



その結果、TKの他の部分で譲歩し、顧客の要件が正確に何であるかを認識しました。 次のプロジェクトでは、当社はすでに信頼できるサプライヤーであり、フォークのない決済の正確な基盤を持っています。

本当に悪い場合の対処方法

昨年、私は壮大な失敗状態のプロジェクトを得ました。 お客様は、控えめに言っても非常に奇妙だと警告されました。 正確なTKは、数か月の作業開始後に記述されました。 一般的に、難しいと言うことは何も言わないことです。 コンパイルされたTKの各行には質問があります。 タスクは、損失を最小限に抑えてプロジェクトを完了することです。



最初に、TKをいくつかのドキュメントに分割しました。 実際、彼らは責任を恐れていたため、マネージャーのチーム全体と調整しました。 そして、彼らは新しいものを見つけるたびに。 細分化されたドキュメントは、ユニットごとに調整され、最終的に問題は解決しました。 彼らは「あなたが書いたもの」ではなく、「あなたが望むもの」を理解し始めました。 さらに、「あなたが望むものは不可能であり、必要ではありません。そのように改善しましょう」-実現した要件に最初に到達し、次に妥協点に到達しました。



どこかで彼らはすぐに決定し、どこかで彼らは自分のTKに応じて彼らを連れて行って何が起こるかを見てみました。 顧客は、作業が実際に行われていることを確認し、その通りであることに同意し、すべてが動いている間はプレスしませんでした。 一般的に、彼らはタクシーを使いました。

個人的な会議と旅行

別の面白いpopalovoは、顧客がくしゃみごとに会いたい場合です。 極東の石油産業である場合は特に快適です。 1つのプロジェクトには伝統がありました-ミーティングで週に1回、あらゆる些細なことが議論されました。 会社から12人、鉄の生産者から5人、そして3人が集まった。 そして安全。 最終的に、彼らはまた破片になり、電話会議に転送することができました。 電話では、男性はお互いに会わず、金曜日に喜ばなかったため、会議は3倍速くなりました。



一方、人をよりよく理解するには、最初に会う必要があります。その後、メールでリモート通信することもできます。 これはすでに多くのプロジェクトでテストされています。



繰り返しますが、複雑な問題を解決するには個人的な会議が必要です。 重大な決定またはステップはすべて満たすことです。 電話では機能しません。

鉄

一度仕事と機器の供給のための競争に参加したが、勝たなかった。 しかし、受賞企業はまだ下請けのために私たちを雇ってくれました。この国にはもうスペシャリストがいなかったので、このトピックは非常に具体的でした。 まあ、私たちは誇りに思っていません、私たちは仕事をするだけです。 納品の2週間前に、ゼネコンが間違ったハードウェアを注文したことがわかりました。 もっと正確に言うと、その構成ではありません。 私たちは、注文についてどのコメントを書くか、サプライヤに話す特定の魔法の言葉をどうにか知っていました。 そして、ここで、大まかに言えば、彼らはモデル内で1つの文字を混同しました。 ロシアでは、単にそのような鉄は物理的にありません。 配達前-2週間。



これらのボードを交換するようベンダーに依頼しました。 ベンダーにとって、このプロジェクトはイメージベースであったため、結局のところ、このような鉄の最初のインストールです。 新しいボード、特別な飛行機、特別な人、出来上がりが見つかりました。それらは2日前からも一緒にいました。



しかし、しかし、私は2週間、バレリアンを飲まなければならず、一度に2つのタイムゾーンに住む必要さえありました。 日中は、施設で監視、「ドラッグ」、保存、「スナッチ」を行い、夜間は州の同僚と郵便や電話で、必要な鉄をどのように持ってくるかを考えてください。

外国人と働く

外国の請負業者や顧客と仕事をすることも「楽しい」です。 その後、あなたは国内の従業員を愛し始めます。 ロシアでは、開発方法論が存在しないか、通常のウォーターフォールが存在する可能性があります。タスク、ドキュメント、およびフェーズがあります。 参照用語は何であるかはどこかにより良く、どこかより悪いとはいえ、ほとんどすべての人に知られています。 そして、外国人はしばしば多くの段階を単に無視します。 TKの概念がなくても、「作業明細書」または技術的な要件があります。



私たちはハードウェア、外国人の同僚、ソフトウェアを担当しています。 私たちはそれらを提供します：仕事の一部、責任の範囲を明確に書きましょう、私たちは通常のTKを行います：私たちがやっていること、結果は何ですか、そして定期的にテストして合格します。 彼ら：「なぜこれが必要なのですか？ 作業の説明があります！」-そして、精神の中で2ページのドキュメントがあります：「私たちのプロのエンジニアが来て、すべてをします、心配しないでください。」 そして、彼らは次のように付け加えました：「私たちのサイトにシステムの説明があります-ここに。」 最終的な詳細なToRなしで署名しました。 そのまま実装。 彼らは実際にシステムに署名し、2年後にシステムを完成させました（システムの2世代が変更されました）。特にこの顧客のために、機能の一部を開発しました。



そして問題は、彼らがすべてアメリカ向けに調整されており、ヨーロッパにはデータ処理のための独自の内部標準があることです。 そして彼らは彼らに会いませんでした。 もちろん、顧客は標準システムを受け入れませんでした。 この瞬間、同僚たちは正確なTKが必要な理由を鋭く認識しました。 より正確には、顧客ではなく、それが必要であること。



それらから詳細な作業を得るのは非常に困難です。 彼らは何週間も引っ張り、サービスに含まれるものを伝えます。 時々、彼らはそこでマネージャーに仕事を設定しているように見えます-各契約で100キログラムのサービスを販売するので、彼は詳細なしで書いています。 それから、もちろん、これはすべて捨てられますが、多くの神経が途中で損なわれます。



下請けはまだ面白かった。 彼らは耳を使ってこのようなフェイントを作るのがとても好きです。彼らは主な仕事が終わったと言って、サブスクライブして閉じましょう。すぐに残りを終えます。 基本的には機能します。 そして、ゼネコンとして、私たちは彼らに言いました：「いいえ！」しかし、すべてがうまくいかないのに、なぜそれを閉じますか？ その結果、ロシア人は有害であることがわかりました。 外国人はその後四半期が終了し、ボーナスが支払われなければならないので、それから何か他のもの。 私たち-彼らに：「私たちはあなたを気の毒に思いません。」 そして、はい、数ヶ月間、彼らはこれらの小さな微調整を解決できないことがわかりました。

利他主義と勇気

おそらく純粋にロシアのプロジェクトのもう1つの特徴は、「チップとデールが助けを急いでいる」です。 まれですが、画期的なものがあります。たとえば、降伏に直接、鉄は失敗します。 しかし、利他主義と勇気は私たちを無敵にします。 外国の請負業者が手を振ってベンダーを通じて標準的な交換を開始する場合、私たちは耳を傾け、一般のしきい値で、スウェーデンのどこかに現れるか、さらに悪いことに、はんだごてで鉄片に入れてそれを修正することができます。 もちろん、助けにはなりませんが、一般的には機能します。 確かに、余分なネジは常に残ります。

顧客の規制

最も驚くべきことは、「顧客の規制に従って作業を完了または同意する必要がある」というフレーズの後に始まります。

• 入札書類に規制を添付することはできません。 自分を検索してください。
• 規制が変更される可能性があります。たとえば、欧州規格に準拠したスタジアムエンジニアリングの要件である場合、作業の最後にヨーロッパ人が新しい要件を採用したことが判明する場合があります。
  
  
  
  
• ある金融機関にセキュリティサービスがありましたが、規制も示されていませんでした。 警備員がちょうど来て言った：「これは許可されていません。 なぜ-言わないよ。」 そして去った。
  
  
  
  
• 「少なくとも10年間モスクワに住んでいる」または「外国人を仕事に巻き込まないでください」などの内部要件があります。
  
  
  
  
• 銀行は、ロシア銀行の文書に基づいた規制全体を持っていることが多く、入札の要件として示されていない場合があります-当然のことです。 それは契約と実装に関係します-このことは「次はシステムの要件です」という言葉とともに現れます。 そして、権利の分離、管理、証明書の担当者の要件があります。
  
  
  
  
• バックアップのための「忘れられた」要件、少なくとも10人の専門家向けのトレーニングなどがある場合がありますが、毎回これを確認する必要があります。

多くの場合、ドキュメント標準があります。 これは信じられないほどのpopalovoでもあります。説明が作品自体よりも長くかかったプロジェクトがありました。 一方、顧客がドキュメントを忘れた場合、あなたは彼に思い出させる必要があります、そうでなければ、彼らは後でサポートすることができません。 はい、そしておそらく私たちもサポートするので、ドキュメントが必要です。



しかし、多くの場合、状況はさらに悪化します。文書は示されておらず、顧客はGOSTを参照しています。 また、たとえば、3つのテスト期間があります-事業運営、試運転、産業運転の最終試運転。 一部のお客様の場合、例えば、試運転前に何らかの理由で最終配送が行われます。



顧客が単に作業明細書と間違われていることがあります。 私たちは機器を持ち込みますが、どこにも置く場所がなく、単に場所がありません。 どうする 再び妥協を模索する。

受け入れ計画

最も重要なこと-怠beにならず、少なくとも単純な受け入れ計画を立ててください。 テスト方法は特別なものではありません。 書く価値はあります。 受け入れ時に、顧客は多くの場合、まだ何かをテストしていないことに気付き、テストプログラムの変更を提案します。 すべてを一度に予測することをお勧めします。 それは多くの対立を取り除き、銀行で多くを助けます。



たとえば、約10年前はそうでした。 私たちのエンジニアはシステムを引き渡しました。ドキュメントは悲惨で、要件はありません。 極東、私たち：「行為に署名すれば、私たちは行きます。」 顧客は細心の注意を払っていましたが、十分でした。 彼は次のように語っています。「今、あなたはヘリコプターに座りますが、私はこのヘリコプターに取り残されます。 本当に確認しましょう。」 まあ、外出先で彼らはテスト方法論を思いつき、それが何でどのように機能するかを示しました。 サインアップしました。 私はもう1週間ほとんど滞在しました。



または、場合によっては、システムを引き渡しました。 誰もが署名し、誰もが幸せです。 そして、セキュリティ担当者は、ITスペシャリストが要件を記述した方法を使用したくないことがわかりました。 プロジェクトが書かれていたときに彼らがどこにいたかは不明です。 私たちは前進し、要件の上で助け、すべての人に合ったオプションを見つけました。 その日、私たちは別の難しいサイトで妥協しました。 それが仕組みです。

一般的に

一般に、状況は変化しています。過去8年間で、顧客は非常に成熟しており、ビジネスについてより深刻になっています。 以前は、アレンジメントスキームでさえ伝えることができなかったとしても、まったく紙がありませんでした。 今、すべてが書かれています。 また、レーキをつかみ、プロジェクトに必要なドキュメントがあると主張し始めました。これは私たちの防御でもあるからです。 目標は、全員が理解することです。



主要なポジションにいる顧客は、異なる視点からプロセスを見たインテグレーターから人々を得ました。 この文化が高まったことにより、市場は成長しました。 西洋の専門家が来て、何とその理由もよく知っていました。



しかし、10年前に今日の仕事のやり方を提案した場合、1人の顧客が私たちの話を聞くことはありません。 文化はなく、役に立たなかった。 私はそれがそれらの深い年にそのようなものでさえあったことを覚えています：受け入れプログラムが署名されました。 顧客は「それは違うはずだ」と言います。 私たち：「これはあなたが署名した文書です。」 彼：「彼を捨てて、私たちは何か他のことをする必要がある！」