ビジネス要件を技術仕様に凝縮[終了]

私は大手小売業者のIT部門で働いており、ウェブサイトの主要なシステムを再設計するためのプロジェクトを開始しました。

ビジネスユーザーは、システムを更新して改善したいと考えています。彼らはそれがどのように機能するかについて非常に高レベルの原則をいくつか持っていますが、それはそれについてです。

経営陣は、利用可能なリソースがあるため、開発チームが「何かを行う」ことを開始することを望んでいます。

開発チームとしての時間を過ごすための最良の方法を考えるのに苦労しています。ビジネスユーザーと一緒に座っても、非常に高レベルの原則や、ユーザーが望まないことは何も実現していませんが、要件への取り組みを検討することはありません。

機能の具体的な実装を漠然としたビジネス要件に関連付け、技術的な専門知識の欠如とビジネスからの賛同を得て、ビジネスが結果に満足できるようにするにはどうすればよいですか？

私の経験から、私は1分の開発に費やすことはしませんでした。ほんの少しのコードでもありません。この段階では、お客様が何を望んでいるのかわからないため、コンサルティングを適切に行うことが非常に重要です。それはあなたにとっても彼らにとっても重要です。

各プロジェクトの背後には、顧客のビジネスに関連するニーズ（場合によっては明らかではない）があります。したがって、必要性を明確にするために、最初にできるだけビジネスを学ぶ必要があります。その後、お客様を機能的なソリューションに導くことができます。

学習中は、ニーズとウィッシュを区別するときに注意してください。顧客が必要とするものと同じである場合とそうでない場合がある顧客のニーズは何ですか？

分析中に、お客様が決定を下さない場合は、自分で判断してください。コンサルタントとしてのあなたの仕事は、アドバイスを与え、プロセスをリードすることです。

@Ewanが指摘したように、実行する選択肢がある場合、顧客が決定を行うのは簡単です。いくつかの選択肢（長所/短所を公開）を提供することで、意思決定が容易になります。プロトタイプをモックアップすることは、プロトタイプについて考えていることの概要を示すのに良い方法です。顧客は、物事がどのようになるかについて最初に連絡（および感情）します。「創造性」のこの演習を行うと、問題が発生する前に、プロジェクトの光と影をすばやく確認できます。

エンドユーザーからできるだけ多くのフィードバックを得るようにしてください。私たちが「顧客」と呼んでいる人は何度も、システムを使用するのは誰かではありません。このような状況では、実際のエンドユーザーからより良いフィードバックが得られます。彼らはあなたが彼らが必要とするものについての貴重なヒントを提供します。質問に対する正しい回答を提供できる人物を明確にすると、顧客の期待に応えることができます。

一連の適切な要件を収集したら、それらをプロトタイプに入れます。この段階では、SCRUMのようなアジャイル手法が適切に機能します。プロトタイプに対してスプリントを実行します。

プロトタイプはスプリントに沿って破棄/変更されます。また、お客様に最も適したお客様を「案内」することもできます。;-)。双方にとって有利な取引を探しています。

明確で測定可能な要件が承認される前に、マネージャーが開発を開始しないようにしています。それ以外の場合、未定義の要件から開始すると、ひどく失敗する運命にあります。誰かが「カオス」を実装することを決めたので、多くのお金と時間が無駄になるでしょう（それを回復する保証はありません）。私たちの愛され混乱した顧客が今生きているカオスと不確実性。

従業員が仕事をしているが、その方法を（合理的に）説明することができない会社を見るのは衝撃的です。何人のプロジェクトマネージャーがこの問題を気にしていないかを見るのも衝撃的です。彼らは「全員に「はい」または「始めましょう。何が起こるか見てみましょう」と言っています。

最後に、@ Ewanは再び最も重要なポイントを指摘しました。

お客様に、必要なものを承認して実装してもらいます。

プロジェクトが完了したと言うために満たす必要のある要件と条件を明確に定義することを忘れないでください。合格条件

理由を言う必要はありません。

に沿って2つまたは3つのソリューションを提案するドキュメントを作成します。

「「高水準のプリンシパルx」を達成するために、「技術ソリューションが行うこと」を行う「技術ソリューションy」を提案します。 "

お客様に、必要なものを承認して実装してもらいます。

ムード音楽を正確に判断できなければアドバイスするのは難しい。

どちらか：

ビジネスユーザーと管理者は仕事をしておらず、開発者が対処するための道を進んでいるだけです（したがって、問題が発生したときに開発者をキックすることができます）。

または：

彼らは本当に自分が何を望んでいるのかわからないので、開発チームがガイドする必要があります。

当然、2番目のシナリオの方が適しています。いくつかのデザインのワイヤーフレームを作成し、それを土の中に入れて、ある種の計画を立てることができます。

最初のシナリオを処理する場合、プロジェクトを何度も殺すことはやりがいのある要件であり、「完了」の概念がないことは絶対に明らかです。プロジェクトは最終的に完了しますが、それまでにいくらのお金がトーチされますか？

ある時点で、開発者はアプリケーションを開発し、後でそれが要件を満たしているかどうかを確認できる一連の要件が必要になります。そして、要件に合ったアプリケーションを作成します。

そして、要件を満たすアプリケーションがビジネスに利益をもたらすような要件を持つことは、本当に良いアイデアです:-)

誰かがこれらの要件を作成する必要があります。ビジネスの所有者はできません。開発者は望んでいない。開発者は、ビジネスの所有者に要件を作成させようとしましたが、成功しませんでした。それでも、誰かがこれらの要件を作成する必要があります。

あなたは会社で誰かを見つけ、それを彼の仕事にすることができます。開発者が最初に行ったようではなく、要件を要求しようとして失敗しましたが、人を選んでフルタイムの仕事にしました。開発チームが要件を作成できると感じた場合は、それを会社に提案し、ジョブとその権限を割り当てます。

どちらにしても、要件を作成するのは誰かの仕事です。また、開発チームが要件を作成する場合、要件は会社が得るものであり、彼らがそれを好まない場合、要件が変更されていることを確認する必要があることを明確にする必要があります。開発作業が始まる前にこれを行うのが最善です。

そして、あなたは人々に選択を与える必要はありません。あなたは彼らに、要件にあるものは何が起こるかであると伝えることができ、彼らはそれを承認するか、不平を言って要件を変更することができます。

プロトタイプが洗練されすぎてクライアントを混乱させると思われる場合は、スケッチしてください。クライアントを促すのに役立つと思われる場合は、複数のバージョンを使用できます。

これは、捨てるコードの束を作成せずに何かを実行するという管理者のニーズを満たします（何が良いかを知っている場合）。

また、クライアントは、このタイプのものに支払う必要があることを知る必要があります。そうでなければ、彼らをプロジェクトに移す動機はほとんどありません。多くの人が物事を遅くするだけの役に立たない提案を投入することなく、プロジェクトと意思決定に本当に関与している人を絞り込むことができれば、会議にメリットがあります。

思考実験をしてみましょう。一から家を建てたいと思っていて、建設について何も知らない場合を想像してみてください。ビルダーに要件をどのように説明しますか？たとえできたとしても、「クローゼットに十分なスペースがあることを確認したい」や「モダンなキッチンが欲しい」などのあいまいな表現になるでしょう。当然のことながら、すべての詳細を知ることはできません。計画を描くアーキテクトは大量の質問をし、業界のベストプラクティスに従って自分でいくつかの決定を下します。

これはあなたがいる場所です：誰かが何かが欲しいと決めましたが、彼らはあなたが何を望んでいるかを正確に説明するのに苦労しています。それを理解するために彼らと協力するのはあなたの仕事です。

利用可能なリソースがあり、高度な原則がある場合は、それらの原則をユーザーストーリーに分解します。そこから、実行するタスクのリストを作成できます。途中で提案を行いますが、最初に更新のビジネスニーズを完全に理解していることを確認してください。パフォーマンスは悪いですか？安全ではありませんか？デザインは時代遅れですか？エンドユーザーが認識していない詳細の多くを処理するのはあなた次第です。行った選択とその理由を文書化し、ビジネスユーザー（または該当する人）にサインオフしてもらいます。今、あなたは要件を持っています！

開発者は常にコーディングしている必要はありません。時間のかなりの部分も計画している必要があります。開発者が持つことができる最も重要なソフトスキルの一部は、漠然とした「ビジネスアイデア」を取り、それらを実用的なプロジェクトに変換し、ビジネスニーズに合った製品を出力するこのプロセスから生まれます。

プロトタイプを作成することは、より良い要件につながる具体的なフィードバックを得るための素晴らしいアイデアです。軽くてシンプルにしてください。コードを1行も書かなくても、動作するモックアップを作成できるツールがあります（ここに1つあります）。

また、基本的なプロトタイプは、ビジネスユーザーによって誤って解釈されることがよくあります...

確かにそれは可能です。だからこそコミュニケーションはとても重要です。何度も試作品であることを説明します。何であれ、「ドラフト」と書かれた透かしをはめ込みます。ビジネスユーザー、特にハイテクに精通していないユーザーは、特に何も見当たらない場合は、単に要件を与えるだけで信じられないほどの困難を経験するでしょう。彼らが一緒にプレイできるプロトタイプをすばやく作成できれば、見たときに「私はこれよりも好きだ」と言うのが簡単になります。