低摩擦の最小要件の収集[終了]

Question

「製品所有者」からチームが要件を収集する方法できるだけ低摩擦でありながら、可能な限り使用可能ですか？

ここにガイドラインがあります。それができない、または企業が品質を重視するという決定を下す必要があるという投稿はありません、やだやだ。私が働いている製品は、長年成功している小さなグループです。私は彼らが一段上にステップアップするのを手伝いたい。

基本的に、私は6人または7人のチームに1人のプロダクトオーナーがいます。彼女は素晴らしい仕事をしていますが、いくつかの異なる役割をジャグリングしています（非常に小さなチームでは一般的だと思います）。通常、要件は散発的な時間に与えられます（電子メールコンボ、対面のディスカッション、会議など）。それらがシステムに入力されることはありません。これにより、機能がリリースされなかったり、誰もが必要な機能を忘れたためにリリースが押し戻されることがあります。

同様の状況にあるが、これを克服する方法を見つけた場合、私はそれを聞きたいです。この状況を緩和するためのコードを作成できてうれしいですが、製品所有者が何かを成し遂げるためにアクセスしなければならないWebサイトにすることはできません。彼女は非常に忙しく、これらの要件を収集するためにチームとして協力する方法が必要です。

現在、このようなことを考えています。開発者とチームメンバーは、直接会う会議で議論された要件を収集し、wikiページで議論された機能に関する簡単なメモを書きます。これらのページが更新されるたびに製品の所有者に通知され、正確さを保証する責任が製品所有者になります。

長所：機能の記録があります。短所：開発者は、通常はしないことに対して責任を負っています。ここで大丈夫です。この状況ではチームワークだと思います。

もちろん、これを行うと、製品の所有者が機能の正確性を確保するのに十分な時間がない可能性があることがわかります。最終的に彼女は過重負担であり、これはその事実を示すのに役立つと思いますが、最初にそのことに注意を向けることができる必要があります。

提案はありますか？

PS彼女の時間は非常に限られているため、議論後に要件を入力する必要があると考えるのは無理と考えられます。彼女には一度だけ話し合って先に進む時間しかありません。

Answer 1

「製品の所有者」という概念は私にとっては曖昧ですが、非常によく似た状況で仕事をしていると思います。顧客は非常に忙しく、常に要件の開発のボトルネックになっています。

表面的には、この状況で私たちがやろうとしていることは非常に明白で一見シンプルです。顧客が「読み取り専用/トーク専用」に関与していることを確認しようとします。モード。書き込みなし。最小読み取り。主に話しています。

もちろん、悪魔は詳細です。したがって、ここに私たちのプロセスに関するいくつかの詳細があります（順不同）：

• 私たちはしばしば、要件の最終的なソースである問題のステートメントの記録から始めます。実際、最初に記録するのは、紛失しないことを確認するためだけである場合もあります。

  NB：問題ステートメントと要件を区別することが重要です。問題文は明らかにいくつかの要件を明確に暗示している場合がありますが、一般に、単一の問題文はすべての要件をもたらします（それぞれが独自の重大度と優先度を持ちます）。さらに、特定の要件が複数の問題の解決策（通常は部分的なもの）を定義する場合があります。

  問題のステートメントを記録する主な理由の1つ（そしてこれはあなたの質問に非常に関連性があります！）は、意味的には「顧客の肌に近い」という意味です。それらから派生した要件よりも安定しています。これらの問題の記述により、顧客が開発チームにフィードバックを提供する時間があるときはいつでも、顧客を適切なコンテキストに簡単かつ迅速に入れることができると信じています。

• 要件をいつ実装するかに関係なく、要件をすべて記録 して問題のステートメントにバックトラックします。優先順位は、要件が実装される順序を管理します。もちろん、顧客は未完了の要件をレビューする順序も管理します。

  NB： すべての要件を含む単一のファットドキュメントは絶対にありません！すべての要件は、バグレポートとともに「問題追跡データベース」に配置されます。 （バグは、本の問題の特殊なケースです。）

• 「最終化」に必要な反復回数を最小化するために、常に最善を尽くします。各要件（または関連する要件のグループ）。理想的には、顧客は要件を1回だけ確認する必要があります。

  最初のレビューが不十分であることが判明し（常に発生する）、問題の要件が多くのテキストやイラストを必要とするほど複雑である場合、顧客が持っていないことを確認しますすべてを最初から読み直す。以前の改訂版以降のすべての重要の変更/追加/削除が強調表示されます。

  問題または要件が未完成の状態のままである間、すべての未解決の問題（主に顧客への質問）はドキュメントに埋め込まれ、強調表示されます。その結果、顧客が要件を確認する時間があるときはいつでも、会議を呼び出してチームに質問する必要はありません。代わりに、顧客は未完成のドキュメントを最初に開き、彼に正確に何が期待されているかを確認してから、未解決の問題に対処するための最善の方法と時間（彼にとって）を決定できます。顧客は問題のドキュメントにメールを書くかコメントを直接追加することを選択する場合があります。

• （ドキュメンテーション全体に散らばっている場合でも）公式ドメイン語彙の確立と維持に最善を尽くします。最も重要なことは、私たちは実際に顧客にその語彙に固執させることです。

  NB：これはプロセスの最も難しい部分の1つであり、顧客は「反抗」しようとします。ティムから

Answer 2

＆quot;開発者とチームメンバーは、対面ミーティングで議論された要件を収集し、簡単なメモを書きます

それから始めます。メモを取っていない場合は、わずかな変更を行ってください。メモする。後で、ウィキに投稿したり、機能のバックログを作成したり、スクラムやバグジラなどを使用したりすることができます。

ただし、最初に小さな変更を加えます。自分がしていないことのように何かを書き留めるので、それをして、何が改善され、次に何ができるかを見てください。アジャイルに。徐々に作業します。

Answer 3

部屋のHiPPOに注意する必要があります。最高給者の意見は必ずしも良いものではありません。開発者向けの優れたツールとサポートの提供に重点を置く傾向がありました。これらのことを正しく行うことで、開発の手間が省け、より速く、より楽しくなります。これにより、開発者はワークロードの点でより柔軟になり、最新の変更を受け入れやすくなります。

ワンクリックのテストと展開は、最初にいくつかの良い方法です。すべての開発者が数秒で独自のソフトウェアスタックを実行し、直接アイデアを試すことができることを確認してください。その後、開発者はすぐに修正を加えたり、興味のある副次的なパスを実行したりできます。これらのパスは、多くの場合最も成功します。そして、成功とは、システムで直接収集され、関係者全員がすぐに利用できるようになった実際のメトリックに基づいて、測定された成功を意味します。所有者は、要件を定義するのではなく、定義していない要件ではなく、おそらく重要なメトリックを設定できます。

もちろん、それは所有者とあなたの特定の状況に依存しますが、メトリックは要件よりも議論が容易であり、開発者もそれらを解釈するのが得意であることがわかりました。典型的な問題は、顧客がショッピングカートをいっぱいにするのに長い時間を費やしているように見えても、チェックアウトに進まないことです。

1）マーケティングの要件として、チェックアウトボタンを大きくして赤くすることがあります。 2）CEOはとにかく一度に1つのアイテムしか購入しないため、CEOの要件は、顧客をチェックアウトに直接連れて行くことです。 3）UIデザイナーの要件は、2番目のチェックアウトボタンをカートの上部に配置することと、既存のボタンを下部に配置することです。 4）開発者の要件は、画面の周りのマウスポインターに従うWeb 2.0 AJAXウィジェットである場合があります。誰ですか？

誰が気にするのか...顧客はおそらくばかげた配送コストを見て逃げた。ただし、要件ではなくメトリックとして問題を再定義すると、開発者が突然興味を持ちます。開発者は、ボタンの赤の濃さをCMOで10ラウンドする必要はありません。彼はWeb 2.0を1週間プレイして、月曜日の朝に他の3つのソリューションを急ぎます。それぞれが48時間ライブ展開され、カートからチェックアウト率が即座に測定および報告されます。いずれも違いはありませんが、開発者は仕事をするようになり、ビジネスは、販売する安っぽい製品と配達時に測定する価格に焦点を移しました。

まあ、それでこの例は不自然です。プロジェクトが小規模であり、チームが経験豊富であり、ホットデプロイメントが簡単で、インスタントロールバックが提供され、全員が参加していることを確認するために、多くの作業があります。私たちが到達したかったのは、開発者の潜在能力をすべて無駄にしない状態です。そのため、開発者は最初からだけでなく成功にも関与しています。登録時のクリック数が多すぎるなどの問題から始めて、設計委員会を介して実行すると、実際に設計仕様でクリック数が増加することがわかりました。とにかくそれが私たちの経験でした。ただし、開発者には自由にクリック数を減らすだけにしておいてください。実際に特許を取得したソリューションになる可能性があります。開発者が特許を気にしているわけではありませんが、メリットがあり、クリックはありません！