改訂の参照条件：10のルールと少し面倒

「製品要件文書」というリクエストで外国のサイトを調べると、参照条件（TOR、PRD）が消滅したという事実に関する創造的で説得力のある記事を見つけることができます。 これの一部に同意する必要があります-製品をゼロから開発する場合、プロトタイピングは顧客レコードのボリュームよりもはるかに面白く効果的で、時には非常に専門的ではありません。 ただし、基本システムの最終化について話している場合、問題はまったく異なる方向を向いています。 私たちは洗練とカスタム開発の両方に直面しているため、料理人が私たちに嘘をついていない場合、犬はTKで食べられました。 一般的に、今日-購入およびインストールされたソフトウェアを完成させるために書かれた非常に古典的な技術タスクについて。 要するに、痛みについて。

相互作用の端

技術仕様の作成プロセスの準備を進める前に、プロジェクトを開始する請負業者と顧客が陥る四角形について話しましょう。


要件 -実装する顧客またはプロセス所有者によって記述されたシステムの望ましい動作。 原則として、要件は実務経験、正しいプログラムの動作の提示に基づいて形成されます。 これは開発者（ベンダー）にとって重要な情報ですが、要件を収集する段階で、最大数の競合、エラー、不要な要求などが発生します。

リソース -要件の実装に使用する人、車、在庫、開発環境、時間とお金。 リソースには、参照条件の承認の段階で明確な計画と評価が必要です。 顧客による有能な優先順位付けとベンダーによる労働リソースの分配により、期限を回避し、他のリスクを最小限に抑えることができます。

機会 -要するに、これはベンダー（実行者）が本当にできることです。 RegionSoft CRMの例を考えてみましょう。 クライアントがシステムを購入し、改訂のための技術的なタスクを作成します。サイトとの統合を作成し、CRMのイベントをオンラインストアの注文番号にリンクする必要があります。 これは本当に実行可能な要件であり、これを行うためのリソースと能力があります。 また、サイトコンテンツ管理システムであるCRM CMSを開発して固定する必要もあります。 理論的にはこれを行うことはできますが、安価に行う機会はなく、クライアントは私たちにあまりお金を払う機会がないので、タスクに人的資源と時間的資源を投入します。 その結果、顧客はこの要件を拒否します-そして、彼は本当にCMSを必要としません、すべてがとても良いです。 しかし、TKの「欲」について-後で。

制限 -TKからのタスクの達成を困難または不可能にする一連の障害：予算、技術スタック、ライセンスの問題、法的禁止、ハードウェア構成など。

したがって、4つのエンティティはすべて密接に絡み合っており、プロジェクト全体の成功を決定します。 各要素を検討し、技術的なタスクに取り組む際に留意する必要がある重要なポイントを強調してください。

要件の収集と分析

これは非常に重要な社内のプロセスであり、その過程でプログラムに必要なものが明確になります（以降、CRMを取り上げますが、潜在的なユーザーは他の種類のソフトウェアを使用します）。 SAPやシステムインテグレーターなどの大規模なベンダーに連絡すると、ビジネスコンサルタントのサービスを使用する機会が提供される可能性が高くなります（彼は個人マネージャーであり、アカウントマネージャーでもあります。 実際、ほとんどの場合、これは2つのタスクを持つ、よく訓練された普通のセールスマンです。プロジェクトのコストを引き上げ、フックから抜け出せないようにすることです。


彼はここに1時間滞在しており、白いマーカーボードにも触れていません。 彼は真のシステムアナリストではありません。

あなたとあなたの従業員よりも、あなたの会社を知っている人はいません。 したがって、要件の収集と分析は専らあなたのタスクであり、ベンダーはそのプロセスに介入することはできませんが、ベンダーが支援し指示することができます。 開発者にそのような実装について尋ね、何に注意を払うかを指定して続行します。 ところで、あなたの従業員は、プロファイルトピックに精通しており、ソフトウェアアーキテクチャを大体表し、開発プロセスに精通している優れたアシスタントになることができます。彼は、アナリストおよび内部の専門家として行動し、TKを作成してベンダーと通信するプロセスを閉じることができます。

非常に単純な要件収集スキームがあります。

1. CRMを使用するマネージャーと経験豊富な専門家のワーキンググループを作成します。 選択するソリューションについて教えてください。デモ版へのアクセスを提供してください。
   
   
2. ワーキンググループのメンバーは、スタッフに情報を送信し、新しいプログラムへの希望を完全に無料の形式で要求する必要があります。 従業員の1人がそのようなソフトウェアに遭遇したことがなく、将来の使用に関して話す準備ができていない場合、定期的なタスクを説明するように彼に依頼する必要があります。これは普遍的なアプローチです。
   
   
3. 次に、各ユニットは、CRMにないものまたは対応していないものを決定し、情報を集約します。
   
   
4. ワーキンググループは、収集された要件を分析し、交差点をチェックして除外します。 たとえば、多くの場合、営業部とマーケティング部は同じレポートを注文しますが、フィールドとエンティティの要件は異なる場合がありますが、それらの背後にあるデータは同じです。 したがって、単一の形式にする必要があります。
   
   
5. ワーキンググループは、要件のリストを作成し、優先順位を付けます。 この段階では、ベンダーがリソースを担当しているため、ベンダーを接続できます。 たとえば、RegionSoft CRMのカスタムレポートの作成を依頼したり、サイトとの統合を注文したりできます。 これらは時間の面で完全に異なるタスクです;ここでは優先度が非常に重要です。
   

要件が収集され、分析され、スタッフと管理者と合意したら、技術仕様の作成を開始できます。 ベンダーにフォームを要求することも、自分で作成することもできます。いずれにせよ、コンプライアンスによって頭痛からあなたとあなたのCRMプロバイダーを救ういくつかの鉄則があります。

技術仕様の構造

技術仕様の作成プロセスについて説明する場合、いくつかの段階があります。 彼らの一貫した通過は、顧客を望ましい洗練に導きます。 ここにあります。

• 識別-要件の決定、解決する必要がある問題の検索。
  
  
• 分析-要件の分析、主要なニーズの特定、一般化。
  
  
• 適応-CRM機能と既存のビジネスプロセスのコンテキストでの要件の評価。
  
  
• ドキュメント-要件の正式かつ詳細な説明、TORの承認。
  
  
• ベンダー（開発者）とのコミュニケーション-コンパイルされたTORに応じた改善に関するベンダーとの反復的な対話。
  
  
• 実装-必要な機能の作成に関するベンダーの取り組み。 ベンダーが顧客と常に連絡を取り合っていると、より良い結果が得られます。そのため、出力される製品はクライアントのビジョンに最も密接に対応します。
  
  
• テスト-ベンダーの従業員、クライアントの内部専門家、エンドユーザーの機能をチェックして、リビジョンとTK、変更によるシステムのパフォーマンスのコンプライアンスを確立します。
  

一般に、参照条件はいくつかのレベルの要件に基づいて作成できます。これらのレベルは、プロジェクトを作成する際に交差したり協力したり、まったく対話しない場合があります。

ビジネスレベルは、複雑で優先度の高いタスクが解決される最もグローバルなレベルです。 このレベルには、ビジネスプロセスの統合、改良、モデリング、新しい機能モジュールの開発が含まれます。 原則として、これはリソースを集中的に使用する開発であり、お客様との真剣な協議と緊密なコラボレーションが必要です。 たとえば、当時のRegionSoft CRMでは、このようなカスタムメイドの改善は倉庫会計、レジ、生産でした。 徐々に変更がリリースされ、後に卸売、小売店、およびハイパーマーケット向けの新製品であるRegionSoft Retailの作成が許可されました。

ユーザーまたはユーザーグループレベル。 このレベルでは、既存のインターフェースを完成させるためのタスクが実装されています。 たとえば、ユーザーがカーソルをクライアントの上に置いたときに、最後の注文の番号とステータスが表示されたウィンドウを表示したい場合や、特別なデータのグループを含むカスタムレポートがある場合があります。 このレベルでの改善にかかる時間は短くなりますが、多くの可能性があります。たとえば、マーケティング、ロジスティクス、およびテクニカルサポート部門からのいくつかの要件です。

機能のレベル。 以前のものと分離することは難しい場合が多く、ここでは正式な基準が機能します。インターフェイスに何かを表示するレベルではなく、システムロジックを洗練するレベルでの洗練です。 これには、さまざまな種類の要件、チャットとの統合、電話機能が含まれる場合があります。

サービスレベル -実際、このレベルの要件は、修正された新しいアセンブリに最初に該当する必要があります。 これらは、システムの応答速度におけるタスクであり、高負荷下で動作し、セキュリティを確保します。 理想的には、ベンダーはそのような改善を行うべきではありません。企業ソフトウェアは、同じレベルで速度を落としたり、データを失ったり、フォームを崩壊させたり、アクセス権を分配したりするべきではありません。 しかし、要件が現れており、それが顧客の個人的な妄想やハードウェア側の問題に関連していない場合、特別な注意を払う価値があります。

テクノロジーのレベルはリストの最後ですが、重要性と複雑さでは他のレベルを上回っています。 これらは、プラットフォーム、オペレーティングシステム、またはデバイスに関連するクライアント要件です。 たとえば、MacOSのビルド要求。 そのような要件が徐々にリリースに発展していくのは素晴らしいことですが、それらの修正は必須です。 このレベルでの顧客の要求から、MacOS用のRegionSoft CRMを構築し、まれではあるが既存のモバイルバージョンの要求に対する一時的なソリューションとしてTRMテクノロジーを使用したリモートアクセスを追加しました。

技術仕様の構造は単純であり、いずれの場合もスケルトンの形です。 技術的なタスクの必須部分は、顧客が問題に集中し、タスクを正確に定式化するのに役立ち、請負業者は彼らが彼に何を望んでいるかを理解するのに役立ちます。 ところで、理解について。 もちろん、記事の冒頭で、私たちはビジネスコンサルタントをクラスとして否定し、少しだましました。 ここで重要なのは、各ベンダーが市場で数年間（CRMの1日旅行について話しているわけではありません）、または数十年にわたって市場に取り組んでいるということです。つまり、ほぼすべての業界で一連のケースがあります。 したがって、エンジニア、プログラマ、および営業担当者は、各タイプの企業での実装の詳細に精通しています。 しかし、再び、あなた自身のビジネスに集中することが重要です。

誰のため？ このセクションでは、誰がリビジョンのエンドユーザーになるか、どのタスクをどの頻度で解決するかを説明する必要があります。

例を挙げましょう。 ある会社はCRMを導入し、かなり大きなデータ（1か月あたり数千万件のレコード、1日に数十万件のレコード）を扱うことになっています。 営業部長は、「毎日」の頻度でこれらのレコードのアンロードに関するレポートを要求しました。 当然のことながら、数百人のユーザーの同時作業を伴うこのようなレポートは、システムをロードしました-プロセスはプロセスを最適化するために見つかりました。 すでに作業の途中で、売り手は再保険に加入し、月末にのみレポートを必要とし、それが夜にスケジュールどおりに開始できることが判明しました。 言うまでもなく、時間とお金が無駄になりました。

なんで？ 洗練の必要性とビジネスプロセスにおけるその位置付けの正当化。 このアイテムは顧客自身がより必要としますが、ベンダーが影響を受ける他のプロセスを知る価値があります。 代替ソリューションを見つけることが役立つ場合があります。

どうすればいいですか？ 最も有益なユニット-要件、システムからの期待を記述します。 そして、ここでまさに真珠、奇跡、衝突が起こります。それはバショルグに送るのにふさわしく、人生を非常に複雑にします。 理由は1つだけです-ユーザーは、自分が何を望んでいるのか、何をする必要があるのか​​がわかりません。 まだ小さな理由があります-ユーザーは要件を策定できません。 そして、ここでの開発者（作業グループ、アナリスト、もしあれば）のタスクは、ニーズを正しく定式化し、適切な要件を選択し、タスクをシステムのコンテキストに適合させることです。 同じブロックに、期待される結果を記載する必要があります。

技術的なタスクのパラメーター -用語、実装の段階、すべての関係者からの責任、必要な連絡先など。 実際、これはドキュメントを技術的なタスクにする重要な形式的なもののセットです。 開発中の多数の変更を避けるために、委任事項に同意し、署名する必要があります（変更は引き続き行われますが、程度は低いです）。

理想的には、技術的なタスクはベンダーの積極的な参加によってコンパイルされ、その結果はほぼ次の構造になります。

1. 各メカニズムおよび各機能の要件の説明
   
2. この機能の実装の説明
   
3. 各ステージの個別の作業コスト
   
4. この技術タスクの総作業コスト
   
5. 作業のタイミング、段階別に分類され、優先順位を示します
   
6. インストールおよびテスト条件の説明
   
7. 参照条件およびその他の条件の網羅的な性質に関する予約
   

開発者の涙によって書かれた10のルール

リビジョンの参照条件は 、クライアントの必要なCRMの300ページの説明ではなく、 リビジョンのToRである必要があります。 要件を作成する前に、システムインターフェース、その機能、ドキュメントをよく理解する必要があります。ほとんどの場合、「ウィッシュリスト」のほとんどはすでに基本的な配信に含まれています。 2番目のステップでは、組み込みの洗練ツール（レポートデザイナー、コンフィギュレーターなど）に注意することをお勧めします。おそらく、必要なプログラマーが（多くの企業で）必要な変更を加えることができます。

委託条件は貪欲であってはなりません。 多くの場合、ビジネスはその能力を過大評価するか、「すべてを一度に」取得したいと考えています。 このアプローチは、お金の観点からも、ビジネスの観点からも正当化されません。 ベンダーは、原則として、数週間（RegionSoftの場合-15年）存在しません。しばらくしてから、CRMに何が欠けているかを本当に理解したら、ベンダーに連絡できます。

冗長性の顕著な例は、昨日からの文字通りです。クライアントは、有名なロシアの会社からERPを購入しました。一度会計が機能すれば、ベンダーのERPは良いと思います。 ERP自体はそれほど重要ではありませんでしたが、ビジネスにはあまり適していませんでした。 ただし、倉庫会計と生産を備えたRegionSoft CRMが適しています。 解決策があります。ERPを忘れ、泣き、1Cアカウンティングを新しいCRMと統合し、便利な実装を楽しんでください。 しかし、お金の腫れは残念です！ また、クライアントはCRMとERPを統合する必要があります。 私たちはそれをしませんでしたが、なぜそんなに無駄なのか、なぜ2つの比較的似たシステムなのか？

参照条件は、要件と用語の両方の観点から現実的で実行可能である必要があります。 ベンダーの意見に耳を傾けることは重要です。ベンダーは、このタスクまたはそのタスクに費やす時間を正確に知っているからです。 私を信じて、開発者が時間を無駄にし、締め切りを積み上げることは有益ではありません-彼が評判に打撃を与えないために、できるだけ多くのプロジェクトを完了し、それを行うことは有益です。 リアリズムについては、CRMをコライダー管理システムのレベルに追加する要求を避けるのは簡単です。現在および近い将来に実際に必要なものを要件に含める必要があります。

たとえば、RegionSoft CRMはデスクトッププログラムであり、ブラウザー用のクライアントはありません。 ある会社用のWebアプリケーションを作成するように依頼するのは意味がありません。これは大きな開発であり、現在進行中であり、ある会社にとっては可能な開発ではありません。 いいえ、もちろん、すべてに価格がありますが、やはり-一般的な場合、要件は不可能です。

カスタム開発に関する状況と混同しないでください。アプリケーションのアイデアとロジックが根本的に変化しているのは事実です。実際、新しいソフトウェアの作成は「あなた自身のために」支援されています。 しかし、これは別の話です。

参照条件を詳しく説明する必要があります。 プログラムの使用頻度からインターフェースの要望まで、将来のプロジェクトのすべての重要な詳細を示す必要があります。 要件が詳細であればあるほど、実装とテストは簡単かつ迅速になります。 特定の業界（医療、保険、銀行）で作業する場合は、詳細に特に注意を払う必要があります。ビジネスとプログラム間の相互作用のニュアンスを詳細に提示することにより、ベンダーはタスクを理解し、システムを会社に迅速に適合させることができます。

数値形式、フィールド名、ドロップダウンリストの有無、ボタンとヒントの動作、データ型に注意してください。 顧客がCRMオペレーションロジックに組み込む必要がある独自の数式を使用する場合（ たとえば、ディーラーボーナスの計算など ）、これらの数式は、指定と計算ロジックの完全な解釈とともに記述する必要があります。


はい、企業ソフトウェアはこのようなもので、重要な小さなものがたくさんあります

委任事項は明確で正確でなければなりません。 あいまいな表現、実装オプション、あいまいな要件-これらはすべて行き止まりへの道です。 クライアントは、善意で、TKにシステムの動作に関するいくつかのオプションを書き込みますが、同等ではありません。 この場合、彼は助けになると確信しており、プログラマーに伝えていますが、実際には、地獄への道は善意で舗装されており、開発者は必要なものを理解する必要があり、システムの機能と使用されているテクノロジーのスタックに基づいてそれを行う方法を選択します。


今年もまた願い事をすることができます。 理解しやすいビジネス要件など、私でさえ達成できないことだけに無駄にしないでください！

参照条件は、人間の言語で作成する必要があります。 そして、これは重要です、いいえ、重要です。 言語の問題がプロジェクトの実装の遅延につながる2つの状況を取り上げます。

1. クライアントは技術的なリテラシーを実証しようとしており、「カレンダーの本文にヒントを付けてウィンドウを実装し、イベントの呼び出しに応答できるようにします...」ではなく、「タスクを完了済みとしてマークできるウィンドウがカレンダーにポップアップ表示される」ようにします。 あなたまたはあなたの内部の専門家が技術的なテキストを書くスキルを持っていない場合、グーグルしないでください-普通の言葉で書いてください、私たちはそれらを理解します。
   
   
2. TKには文法的な誤りがたくさんあります。 あいまいな説明や隠phor（ 実際の説明から：「コンピューターは、痙攣で死ぬかのようにきしむことはない」 ）、余分な言葉、寄生的な言葉を取り除く必要があるだけです。 句読点を確認します-多くの場合、エラーは要件の意味をゆがめます。 プロジェクトの割り当ては文書であり、その中の語彙は適切である必要があり、識字率は100％に近い必要があります。
   

まだ-理解していない場合は、Microsoft VisioやUMLダイアグラムなどのエディターを使用しないでください。 開発者から見ると、美しくてビジネスのように見えるものは、地獄の混乱であることがわかります。 図や絵を挿入したい場合-人間の方法で描いてください。気にしないでください。これは開発者の助けにはなりません。

委任事項は哀mourのある本であってはなりません。 問題を説明するのではなく解決し、フォントに注意を払い、要件の説明を忘れることが必要です。 TKには、問題自体だけでなく、理解レベルでの解決策も含める必要があります。開発者は既にコードレベルでそれを解決します。 「営業部門は計画を立てず、数字を失い、1年間戦ってきました」と「命名グループのコンテキストで、計画の価値と販売の事実を月単位で保存するレポートを作成する必要があります 」と比較してください。

委託条件は、将来を見据えたものでなければなりません。 まあ、実際にはそうではなく、その背後にいる人々。 ビジネスプロセスの変更がすぐに発生することがわかっている場合は、修正のために2回支払わないように、これを考慮する必要があります。

委任事項は官僚的であってはなりません。 このドキュメントを少なくとも一度作成したことがあれば、おそらく官僚機構に潜り込み、入門的な言葉を作り、厳格な順番をつけ、各段落を刑法の記事として説明するのがいかに難しいかを感じたでしょう（好ましくは、違反者全員を罰する）。 官僚的言語は、TKを作成する目的の不完全な理解を隠しています。 ベンダーの責任は契約書に明記されており、予算もそこに記載されています。 これらのポイントを参照条件に移さないでください。

参照条件は、参照条件である必要があります。 逆説的に聞こえますが、多くの場合、TKの代わりに、手紙、苦情、契約書、CRMへの新たに書かれた指示、または会議の議事録を読みます。 もちろん、そのようなドキュメントで作業することは不可能です。 フォームとコンテンツから逃げないように、古い学校のトリックを使用してください：言葉で用語を検討してください。 技術は洗練を決定することを意味し、この手法はソフトウェアを変更することで問題を解決することを目的としています。 これはソフトウェアのコンテキストでの問題であり、話し合う必要があります。 タスクとは、アドバイス、ヒント、予備評価なしの質問、問題を意味します。 問題の声明。

戒めは終わり、今は戒め

これらのルールに加えて、言及する価値のあるものがいくつかあります。 私たちは目標、計画、期待について話し合っています。プロジェクトを成功させるために去るすべての人々、そしてベンダーとクライアントの関係はほとんど友好的です。

移動体通信事業者や大規模なハイパーマーケットのプロセスを自動化するタスクに直面している場合でも、参照条件を迅速に記述する必要があります。 これは、技術が途方もない速度で開発されているという事実と、実装するシステムでさえ、6か月または1年でメジャーリリース（場合によっては2つ）を生き延び、新しい機能を取得できるためです。 改善の必要性を再検討し、プロセスを再度開始する必要がある場合があります。


最後に、彼はToRを完了する時間を見つけました。 しかし、残念ながら、それを実装するために残された開発者はいません。

クライアントは、スタックと技術的な制限を認識していません。 そして、彼は知らないはずです-これはベンダーの仕事です、技術的な仕事の準備の後に仕事を評価するのは彼です。 顧客は技術を掘り下げて、ベンダーがこれを行うことができるのか、それともそのことを行うのかをあらゆる点で尋ねるべきではありません。 包括的なToRを作成すると、開発者は適切なアーキテクチャを選択します-多くの場合、あなたが考えているよりも優れています。

予算を評価し、不愉快な驚きを避けることは、ほぼ第1位の共同作業です。 ベンダーを引っ張って、仕事の概算評価を彼に要求しないでください（少なくとも、概観で、目で、しかし、このタイプのプロジェクトでは、他の人と同様に、しかし、経験から、間違いなく誤差の範囲内で）。 完全な予算評価は、参照条件を読み、分析し、最終承認した後にのみ可能です。 開発者がそうしない場合-完了に少なくとも2倍の費用がかかるという事実に備えてください。

変更と拡張の客観的な必要性から進んでください -開発者が消えることはなく、いつでも要件に変更と追加を加える準備ができていることを上に書きました。 したがって、CRM / ERPの夢を一度に作成しようとせず、ベンダーボタン「コーヒーを飲みながらすべてが機能する」を必要としないでください。システムで作業し、重要なコメントを特定し、要件の収集とTKの作成に進みます。

あなたは技術的なタスクについて延々と書くことができます;これはミームや物語だけでなく頭痛の本当のジェネレータです。 優先順位と設計規則、1989年のGOST、TKを非人間的なもの、IEEE規格、やや優れたもの、プロトタイプとそれらを補完するTKについて話すことができます。 しかし、最終的には、最も重要なルールである1つに制限したいと思います：参照条件は法の支配ではなく、GOSTでもドグマでもありません。したがって、改善、改善が可能であれば、単純化することができます-簡素化、それはエレガントに行うことができ、誰もがそれを好むはずです-それを行う必要があります。 それ以降は誰もTKに鼻を刺さず、そこに書かれていないとは言わないでしょう。 またはほとんど誰も。

---

12月中、RegionSoft CRMと当社設計のすべてのソフトウェアを割引価格で提供します。 12月1日から12月15日まで-15％およびクールな分割払いとレンタル条件。 ライセンスの経済的に合理的な価格を維持し、天井からそれを取らないため、-70％と-90％はありません。

---

まあ、 CRMシステム （改良の有無にかかわらず）が必要な場合は、 当社のWebサイトにアクセスしてください ; CRM、その利点、その他の企業ソフトウェアについてはたくさんあります。

もちろん、CRMやその他の製品の販売、CRMの変更と販売、ソフトウェアの販売、ユーザーの教育を行う準備ができているパートナーを常に探しています。 収益の共有は、パートナーにとって正直で有益です。 教え、教え、教えます。 ディーラー@ regionsoft.ruへの書き込み

スライド、スライド。 http://www.modernanalyst.com/およびPinterestから撮影したコミック。 より良い翻訳があれば、私たちはそれを投稿に導入して喜んでいるでしょう。