... そして、ユースケースが非公式でありながら有用であることを経営陣に証明するにはどうすればよいでしょうか?
皆さん、こんにちは。
私はプロジェクトの途中で、ユースケース、ユーザーストーリー、要件、仕様に似たものがないことに気付きました。締め切りが短いため、現在の開発チームはそのようなことに時間を費やしたくありません。そのプロジェクトに参加したかったのですが、さらに掘り下げてみると、現在の開発は「すごい効果」を考慮して機能を追加し、基盤となるテクノロジーが提供する簡単さを使用して追加するものを選択していることがわかった. 彼らが要件なしでここまで (4 か月以上) 進んできたことに驚きましたが、これが現在の状況です。彼らが選んだ方法は、良いマーケティング価値を持つ製品を殺す最も確実な方法だと私は信じています.
私は正しいです。先に進む前に、開発チーム/経営陣がユースケース/要件を作成することを証明するために、同様の状況で何をしますか? 前もってありがとう、kh.
PS コックバーンの本が 2 冊本棚にあります...
同僚にユースケースの話題を提供する必要があります:D ユースケースは次のように役立つことを伝えます。
さらに弾薬が必要な場合は、他ならぬ Ivar Jacobson による「ユース ケース - 昨日、今日、明日」を読むことをお勧めします。
同僚がまだビジネス分析ツールとしてのユースケースの潜在的な有用性を認識できない場合、彼らはおそらく助けの手を差し伸べることができません:P 彼らが他の人々のニーズを満たし、彼らの問題をささいな仕掛けで短期的に彼らを誇示して印象づけるのではありません。そのため、少しの方向性と仕様が役立ちます。ユースケース自体がそれほど有用であることが証明されていない場合でも、それらを思いつくという単純な行為により、同僚はソフトウェアの実際の根本的な目的を検討する必要があります.
両側の質問をしてください。開発については、アプリケーションの使用を検討したすべての方法が、エンドユーザーが使用したいと思うすべての方法であると確信しているかどうかを尋ねます。彼らが持っていると言ったら、証拠を求めてください。管理職の方に、必要なことはすべて実行できるソフトウェアを使用したことがあるかどうかを尋ねますが、それでも最終的には使いにくくなります (使用する予定です)。これらの質問は、提供されるものが双方にとって望ましいものではない可能性があるという概念の種をまきます。次に、そのアイデアの種を使用して、ソフトウェアをどのように使用するか、どのように相違点を解決できるかについて (文書ではなく、最初から) 議論を開始します。最終的には、ユース ケース ドキュメントに取り掛かるでしょう。
私はプロダクト マネージャーを職業としており、あなたの投稿に対する私の最初の反応は、アイデアはどこからでも生まれる可能性があり、開発チームが適切なアイデアを持っている場合は、それらを製品に組み込む必要があるということです。
そうは言っても、製品は、ターゲット ユーザーのニーズを解決するという究極の目的に役立たない一連のバラバラなアイデアを通じて魂 (単純なメッセージ) を開発することはできません。そして、最終的には、製品にとって意味のある要件/ユースケースに時間を費やすほうがよいという主張をすることになりますが、明確な戦略/最終目標を持たないことによる機会費用は、シェフが多すぎて製品がうんざりすることにつながります.メッセージ。
このメッセージを理解してもらうための究極の方法は、他の利害関係者を巻き込み、開発部門に彼らの仕事を実演してもらうことです。最終的には意見の相違が生じ、より形式化された (カウボーイではない) アプローチが、より洗練されたシンプルな製品につながります。
あなたが言及した問題の 1 つは、開発者自身によって引き起こされたタイトなスケジュールとスコープ クリープです。ユースケースを使用することで、「未使用」の山にたどり着く可能性がある機能を削除することで時間を稼ぐことができることを説明してください。ユース ケースを使用すると、顧客が必要としている機能と対価を支払うことになる機能を見つけ出し、重要でない機能を実装する時間がある範囲から除外することができます。スコープの定義とは別のユースケースは、すべての利害関係者を特定するのにも役立ちます。これは、スコープを定義する際にさらに集中するのに役立ち、些細なことを忘れるのを防ぐのに役立ちます。 .
それらを見せてください。
例は人々を教育する最良の方法ではありません、それは唯一のものです。
拡張機能と例外に焦点を当てた例を示します。言い換えれば、システムがどのように機能するかは誰もが知っているため、障害シナリオを強調します。記述されたユース ケースの真の価値は、何か問題が発生したときに何が起こるべきかを特定することです。
ただし、書面によるユースケースなしで生活しなければならない場合があることを考慮してください。そして、あなたが説明した環境にとって、主要な勝利はあらゆる種類の要件ドキュメントです。多くの場合、スクリーン カンプやプロトタイピングは簡単に導入できます。