顧客から受け取った非構造化要件を管理および推定する方法
多くの場合、プロジェクトの入札フェーズでは、さまざまなソース（電子メール、Word文書、Excel）から非常に構造化されていない形式で、潜在的な顧客からソフトウェアシステムの要件を受け取ります。通常、これらの「提案されたソリューション」をビジネス上の問題に思いついたのは、顧客側の「製品開発」担当者の集まりです。彼らはビジネスドメインの専門家ですが、多くの場合、適切なソリューションがありません。
これは
- 同じ要件の複数のバージョン
- 2つの要件を1つに混合する
- 要件のいくつかのバージョンは、後になって、一緒に結合された要件が再び分離され、それぞれにいくつかの新しい追加が追加されます
このような要件をどのように処理し、適切なユースケースに分類して、開発が始まる前にそれらを整理しますか？特定の要件の履歴を追跡するために、それが最初に考え出されてから適切なユースケースに具体化されるまで、どのツールを使用できますか？このような方法で受け取った要件に対する作業の見積もりは悪夢であり、要件を正しく理解し、それに対する努力を正しく見積もることに間違いを犯します。
私たちがプロジェクトに勝ったら、お客様は要件についてさらに考え、適切に説明することができました。この場合に発生するのは、一部の機能が削除され、一部の機能が強化され、一部の機能がまったく新しいものになることです。これは基本的に、プロジェクトが落札される前に行われたワークアイテムの見積もりの一部を無効にする可能性があります。特定の要件のツリーを構築できるシステムがあるかどうか、および各ブランチが異なる見積もりをどのように得たかについて知りたいと思います。
このアクティビティをより管理しやすくするためのヒント、ツール、トリックはありますか？私は、要件管理や努力の見積もりよりも経験豊富な誰かからいくつかの洞察を得ようとしています。
要件は拡大し、変化します。誰もそれを主張することはできないと思います。
受信リクエストを収集して処理する方法。
私の経験では、新規または更新された要件を小さなグループの開発プランナーに提供するためのフィルターとして機能する単一または非常に小さな顧客グループがある場合に、要件を収集するときに役立ちます。彼らの側からだれでもそれらを提案するか、または書くことができますが、配達は非常に小さい少数を通してだけあるべきです。ある当事者から他の当事者への交換に関与する人々が少なければ少ないほど、より良いです。
少数の人々をフィルタリングする目的は、表面上重複または一見重要ではないとしても、他の人が入力した労力と情報を破棄または減少させることではなく、情報の損失または不適切な処理などの障害点を制限することです。カプセル化とインターフェースの目的と同様の原則に従います。プライベートデータを保護し、同様のリクエストを処理するための共通プロトコルを確立します。繰り返しますが、重複の送信は問題ありません。プランナーとしては、彼らが話していることや提案していることが重要であることを教えてくれます。すべてを保存または記録します。
要件を追跡および整理する方法
短期的には、ローテクに行く
明らかに、ホワイトボード、付箋、ポスターボードなど、必要なものを整理して追跡するのに大いに効果的なローテクソリューションがあります。これらは短期計画に最適です。それらは非常に見やすく、フリーフォーム表記を受け入れ、簡単に「再構成」できます。
長期的には、検索、ソート、リンクが可能なソフトウェアツールを使用します
より長い範囲の取り組みには、ある種のソフトウェアが価値があります。ドア、Clearcase/Clearquest、その他多くの特殊な要件管理ツールがあります。これらの高度に専門化されたツールは、その機能には優れていますが、多くの場合、やり過ぎです。時には、単純な古いスプレッドシートでも十分すぎるほどです。私は個人的にこれを達成するのにかなり便利な問題追跡システムを見つけました、そして今のところ私のお気に入りはredmineですが、他のものも大丈夫だと確信しています。
問題追跡システムを使用すると、許可することを選択した人はだれでも「新しい問題」または要件を作成し、含めるのに適すると思われる詳細を追加できます。彼らは問題を監視し、あなたがそれを使って行うあらゆる行動にフィードバックを与えることができます。分類し直したり、優先度を調整したり、本文を書き換えたり、補足情報を添付したり、他の「問題」に関連付けたり、より高いレベルの機能や「ユースケース」やストーリー、またはシステムに合った用語や悪心を宣伝したりできます。言い換えると、問題を介して、追跡可能で、ソート可能で、優先順位が付けられ、履歴を認識し、関連する要件のリストを作成するために多くのことができます。さらに、箱から出してかなり設定可能で、オープンソースなので、ツールが私が必要とするものでも、必要なものでもない場合は、プロセスのニーズに合わせて簡単に変更できます。
ツールについての最後のメモ、私が話し合ったいくつかの人々は、変更管理およびバージョン管理システムでプレーンな古いテキストファイルを使用してかなり成功しています。彼らは明らかに歴史的なバージョンの利点を得ます。また、要件を見つけ、リンクし、カタログ化するための基本オペレーティングシステムと補足ツールも利用します。彼らはそれほど多くの構造化された関連メタ情報を追加することはできませんが、彼らはそれが必要だとは思わず、彼らの努力のために十分な価値を追加していません。それはあなたのためのケースかもしれませんし、そうでないかもしれません。利点は、開発スタック上で管理および維持するソフトウェアの数が少ない可能性があることです。
契約後の特典/プロジェクト開発のキックオフ要件
質問の最後の側面は、取り組みが始まった後の要件の管理方法です。これについては2つの主要な考えがあると思います。それらをどのように処理するかは、顧客との関係の性質によって異なります。まず、固定値で契約している場合、契約の授与後に生じる要件を組み込むことができます。意味はそれらが努力の範囲を変えるかもしれないので、それらの余分なアイテムが配達されて受け入れられるとき率または請求書はより高くなるでしょう。受け入れられた提案から同等の労力が除かれない限り。対象範囲が変更される場合は、お客様が結果を理解して受け入れることを確認する必要があります。そうでない場合は、提出が遅れた場合に提出する必要があります。
第2に、契約が成立した後に発生する新しい要件について、契約が時間と材料の努力（作業の本体を完了するために必要なものは何でも）に向けられている場合、顧客はその特定の移動中にそれを含めることを主張します。含めるかどうかに関係なく、あなたが言うことすべてが完了する限り、あなたは支払いを受けます。
それらに慣れていない場合は、カンバンアプローチとアジャイルメソッドを確認することをお勧めします。これらの手法は、長期的な開発目標を見失うことなく、当面の懸念に焦点を当てるのに役立ちます。
「what if」シナリオとしてのオプションを提示し、お客様に選択と決定を与える
どちらの場合も、「what if」推定は、顧客やチームと交渉するときに採用するのに適した戦略です。タスク、それらのコスト、およびスケジュールを計画どおりに並べて比較し、列には代替アプローチの同じ情報を示します。ほぼ同様の一連のタスクに基づいて異なる見積もりを作成できるため、Microsoft Projectはおそらくこれを行うのに適した候補です。
ただし、基本的なスプレッドシートであっても、特定の変更や包含がコストとスケジュールにどのように影響するかを示すのに同じくらい効果的であることがよくあります。この場合のリストは、ツリーが違いを示すのと同じくらい効果的です。これらのシナリオを構築するために選択するツールと方法は、プロジェクトとスタッフの規模に大きく依存します（ただし、MS ProjectのようなトリプルAソフトウェアでも、有用性と能力には独自の制限があります）。
これらのwhat ifシナリオを内部の作業項目として検討し、プロジェクトの期間中それらを保存します。彼らは、意思決定と交渉プロセスにおいて重要なデモでした。また、それらを再確認するか、what ifsの連続ラウンドでそれらを繰り返す必要がある場合もあります。
What ifシナリオを準備する場合、技術的または実装の観点からの賛成論と反対論の補足説明（簡略化した用語）は、1つの代替案がそのような大きな影響を与える理由を正当化するのに役立つ場合があります。
私はこれを反復プロセスと見なします。ステップ1は要件を収集することです。ステップ2はそれらを分類することです。ステップ3は、それらに優先順位を付けることです。ステップ4は、作業量を見積もるのに十分な小さいビットにそれぞれ分割することです。ステップ5は、これらのビットを統合してグローバルな努力バケット（84人日としましょう）にすることです。ステップ6は、労力をリソースにマップすることです（84人日/ 2人の開発者= 42日）。
したがって、現在、ステップ1とステップ2の間で行き詰まっています。要件はありますが、必要な形式ではありません。
同じ要件の複数のバージョンがあるとします。これらは本質的に同じですか？もしそうなら、最も明確に見えるものを選び、それを使用してください。詳細が異なる場合は、最も論理的であると思われるものを選び、それを使用します。次に、要件を確認するよう依頼するメッセージをクライアントに送信します。要件を正しくするために、何度も何度も往復する必要がある場合があります。あきらめたり、落胆したりしないでください。要件が不十分なため、多くのプロジェクトが失敗しました。
Microsoftプロジェクトを使用して、変化する要件に同期して作業とスケジュールを維持します。クライアントが変更を要求する場合は、追加の作業を指定し、それをモデルにプラグインして、新しい日付を伝えます。スラックを拾うためにランダムな間隔で新しい開発者を連れてくることができると信じて夢中にならないでください。新しいリソースが追加されるたびに、スケジュールはランプアップ時間を考慮する必要があります。これを適切にモデル化できるのは、各プロジェクトに注意を払い、そこから学ぶ場合のみです。ボブがプロジェクトXに4か月間続いた後、ボードXに乗せたとします。最初の1か月の生産性はどれくらいでしたか。 3番目？
毎週プロジェクトモデルを見直し、必要に応じて更新してください。変更の履歴記録を保管してください。これにより、将来の見積もりを改善できます。
ダグ