エントリー
私は、石油およびガス機器の卸売および小売配送（約30ccルーブルの売上高）を扱う大企業で1。5年間働いていました。 内部には、管理システム（1Cで開発）が導入されました。これには、いくつかの簿記、倉庫などのいくつかの構成が含まれます。 システムで毎日作業している約2,000人のユーザー。
アナリストチームは、システム全体をサポートおよび開発します。 この間、私は、大企業セグメントのすべてのアナリスト（ビジネス、要件）およびマネージャー、サポートスタッフ、さらには小さな開発者に役立つルールを開発しました。
1.足分析フィード
このルールは私の同僚によって考案されました。 ユーザーと主要な顧客がいる同じ建物にいる場合は、ユーザーを訪問して話し合う必要があります。 誰もが明確かつ明確に自分の考えを書面で表現する方法を知っているわけではないので、15分間の会話が3日間のやり取りに取って代わることがあります。
この規則を無視すると、メールのやり取りが長くなり、タスクが無限に形式化されます。
2.描く
ビジネスプロセス図とインターフェイススケッチを描くと、タスクを理解し、ビジョンをユーザーに簡単に説明できます。 ビジネスプロセスの美しいフローチャートは、顧客のリーダーシップに大きな印象を与えます。 個人的には、無料のアドオンでEPC表記を使用しました（十分に理解してクリアできるほど単純です）。
このルール
3.簡素化（または複雑化しない）
アナリストとビジネスアナリストは、タスクが複雑になる傾向があります。 定期的に、これは結果に悪影響を及ぼします。 私は、問題を解決することは可能な限り簡単であるべきだと信じています。
1年後の仕事のどこかで、次のアルゴリズムに従って考える必要があることに気付きました。
a）簡単な解決策を考え出す。
b）なぜ適合しないのかを見つけようとする。
c）少し複雑になります。
d）それが合わない理由を見つけようとする;
e）少し複雑になります。
など ソリューションが最適になるまで。
この規則を無視すると、自転車が作成され、誰も使用しない不当に複雑な決定が下されます。
4.将来のすべてのユーザーとプロセスのすべての参加者にインタビューする
ビジョンは主観的であるため、隣接する影響を受ける人々を含め、将来の改訂に関心があるすべての人々の意見を見つけてください。 実際には、自分のラインを曲げるアクティブなユーザーが常に存在しますが、彼は他の部門の落とし穴や活動だけでなく自分の部門も知らないため、間違っていることが判明する可能性があります。
このルールを無視すると、ソリューションが全員に適しているわけではなく、作業する1人のユーザーのみが満足するという事実につながります。
5.問題の一番下に到達する
ユーザーはフォーム上のボタン、リスト上のフィルターを常に要求し、その理由を説明したくありません。 しかし、「なぜ」という質問に対する答えを見つけた後、より効果的かつ効率的に機能する可能性のあるまったく異なるソリューションを思い付くことができます。
このルールを無視すると、ソリューションが不完全になるか、タスクのすべての要件を満たさなくなります。
6.グローバルな課題を解決する
たとえば、ERPシステムで作業するプロセスに部門を含めるドキュメントを作成するように求められます。 この要件に基づいて、グローバルタスク「計画および経済部門の自動化」を設定し、関連する要件を見つける必要がありますが、ルール5の一番下にも到達する必要があります。
この規則を無視すると、タスクが解決されないという事実につながります。
7.ユーザーは成功を目指しています（結果）
ユーザーまたは顧客が必要なものを理解せず、結果にほとんど関心がないというのは非常によくある誤解です。 神話は、彼らが定期的にささいなことを味わい、そこで開発を引きずるという事実から浮上しました。 実際、すべてのユーザーと顧客は結果を望んでいます。 それを忘れないでください！
この規則を無視すると、紛争が発生します。
8.普遍的な決定を下す（自動化を自動化しない）
膨大な数のアクティビティが自動化されています。 取引、タスク管理、会計などのための十分な普遍的なソリューションがあります。 しかし、それ以降の各顧客は、自分の会社が他の人と同じように機能せず、プロセスが他の人とは違うと考えています。 時々これは真実ですが、ほとんどの場合、プロセスを簡単に従来のプロセスに変更することでクライアントのコストを大幅に節約でき、多くの神経を使うことができます。
この規則を無視すると、リソースが不必要に消費されます。
9.請負業者は、自分が何をしているかを理解する必要があります。
アナリストは、問題の本質を開発者に説明するのが面倒くさく、開発者や、耳を傾けて掘り下げるのが面倒な人たちに説明します。 開発者は、「...ボタンを追加する」だけでなく、自分が何をしていて、なぜそれを理解している必要があります。 これにより、開発者は情報に基づいた決定を下すことができ、時にはアナリストに賢明なアドバイスを与えることができます。
この規則を無視すると、設計上の決定が下されます。
10.あいまいさを避ける
結果のビジョンがあなた、主要なユーザー、開発者にとってユニークになるような詳細にタスクを分割してください。 これは常に可能というわけではありませんが、このための努力が必要です。
このルールを無視すると、タスクを満たさないソリューションにつながります。
推奨読書：
1.「 ソフトウェア要件の開発 」、2004年。カール・ウィガース
2.「 ソフトウェア要件を扱う原則。統一されたアプローチ 」、Dean Leffingwell、Don Widrig