Epigraph：ラクダは、すべての顧客の要求に従って作られた馬です。
あなたがこれまでにインターネットプロジェクトに参加したことがあるなら-どんな複雑さでも、どんな役割でも-将来のシステムの目標と境界を定義することがプロジェクトタスクを解決するための基盤であることをおそらく知っているでしょう。 要件の収集、分析、管理は、チームの経験と方法論が決定的な役割を果たすプロジェクトの一部です。この分野でのエラーのコストは非常に高くなります。
ロシアには経験豊富で調整の行き届いたチームがありますが、要件を管理するための統一された、透明で使いやすい方法論はまだありません。 1つの組織でも、要件を管理するためのツールと方法、プロセス参加者の役割はプロジェクトごとに変化し、その結果、組織には十分な「成熟度」がありません。これは、一貫して高品質の出力でプロジェクト手順の再現性を保証します。
インターネット会社の「ワークショップ」またはプロジェクトオフィスのオーガナイザーの前に、ソフトウェアエンジニアリングから借用したかなり明確で十分に開発された要件管理方法論を使用する誘惑があります。 ただし、実際には、これらの方法論が過度に複雑になり、インターネットプロジェクトの詳細を考慮していない状況は珍しくありません。 実際、インターネットプロジェクトでのアセンブリおよび実装のためのソフトウェアの開発に非常に類似していることに加えて、設計、設計、および分析もあります。 もちろん、何らかの形でこれはすべてソフトウェアシステムの構築に存在しますが、それでも多くのニュアンスがあります：オペレーターのために明確で定義されたシステムを構築することと、完全に異種のユーザーの任意のセットのためのWebサイトを作成することはまったく別のことです。
さらに、すべての開発スタジオがソフトウェアエンジニアリングのツール（IBM Rationalファミリなど）を使用するために必要なシステム分析の専門知識を持っているわけではありません。また、顧客担当者にとって、これらのツールは通常、単に理解できないため、方法がありませんこのアプローチとのコラボレーション（SCRUMなど）は問題外です。
実際、ほとんどのカスタムインターネットプロジェクトは「古風な方法」で行われます。急速に老朽化したTK、その長く苦痛な調整、実装後期段階で作業範囲を変更する非常に洗練された方法、そしてその結果、予測が不十分で完全なリスク管理の欠如。
インターネットシステムの要件を管理するための便利で比較的普遍的な方法論の必要性は長い間待ち望まれていたため、現時点では3つの戦略的に重要なタスクを解決する必要があります。
- 便利で透過的で使いやすい要件管理方法論を実際に開発および改良します。
- 顧客と請負業者にこの方法論に従って作業するように教え、意識的な要件管理を伴うアプローチがビジネスにとって魅力的である理由を説明する。
- 問題1と2を問題なく解決できた場合は、方法論を業界標準として修正します。
ADV / web engineering co。で 数年にわたり、さまざまなツールと要件管理方法の実践的な研究が実施されてきましたが、インターネットシステムのカスタム開発で要件を最も効果的に管理する方法を明確に理解しています。
方法論は体系的なアプローチに基づいており、ビジネス要件のクラスターと機能のクラスターという2つの大きなクラスターに分割された、将来の機能の説明全体を単一の概念システムと見なします。 同時に、要件管理システム全体の基盤は、マーケティング担当者とエンジニアの両方が理解できる普遍的な用語で記述されたプロジェクトの一般的な目標、目的、ミッションにあります。
単一のシステムに残っているより深いレベルの詳細は、言語と説明の形式で互いに混ざり合っていないため、ビジネスユーザーは、システムのビジネス目標とセマンティック制限に焦点を当てることができます。 このアプローチでは、システムアナリストの役割が非常に重要です。その専門知識は、システムの整合性を損なうことなく、2つのクラスターを相互にリンクするのに役立ちます。
方法論のより詳細な説明は、サイクルの以下の記事、およびbeeosが7月28〜29日にRIKで実施するマスタークラス「 要件の管理 」で検討されます。
タスク1）は解決されたように見え、問題2）の解決に進みます-方法論を一般に公開し、業界レベルでより普遍的なツールとして徐々に「微調整」します。