（ウォーターフォール）クライアントにアジャイル開発を販売する方法

私たちの開発ショップはもっとアジャイルなプロジェクトを本当にやりたいと思っていますが、クライアントを乗せるのに問題があります。多くのクライアントは、予算と期限を望んでいます。競合他社がウォーターフォールベースの固定期限と固定価格を考え出すとき、アジャイルプロジェクトでクライアントを売るのは難しいです。固定数が悪いことはわかっていますが、クライアントはそれを知りません。そのため、価格や期限を修正することはできませんが、競合他社は修正できるため、クライアントにとって見栄えが悪くなります。

それでは、アジャイル開発手法を使用するプロジェクト、またはそのような手法を使用して開発された製品を販売チームに成功させるにはどうすればよいでしょうか？私が見つけたすべての情報は、プロジェクト管理と開発者に焦点を当てているようです。

これをうまく行うための鍵は、サポート契約を使用することです。

基本的に、クライアントを初めて販売するときは、専門知識に基づいてクライアントを販売し、ウォーターフォールを行います。それは、範囲と確定期限を設定する契約を意味します。これがクライアントの要望です。クライアントは多かれ少なかれスコープを知っています。ウォーターフォールは、固定および定義されたスコープ環境で非常にうまく機能します。そのような環境ではアジャイルよりもうまく機能すると思います。そして、この場合、クライアントがあなたと一緒に仕事をしたことがないので、傾向が緊張する傾向があるときに、クライアントにある程度の快適さを与えます。それは大丈夫です、アジャイルは必ずしも滝よりも良いとは限りません。

したがって、Xスコープの固定価格契約があります。次に、クライアントに次のように伝えます。「見て、変更を加えようとしているので、ポストプロダクションをサポートする必要があります。サポート契約の手段。」

プロジェクト中に変更が生じた場合は、単にサポート連絡先の下で処理されるように延期します。（この変更がプロジェクトに深刻な混乱を引き起こすと仮定すると）

サポートの連絡先の条件は次のとおりです。「クライアントの要求に応じて1時間ごとに実行される作業は、変更要求または一般的なシステムサポートとメンテナンスに使用できます。」BAM！あなたはアジャイルにいます。

その後、サポート連絡先の延長を続行し、新しいプロジェクトを実行する手段としてサポート連絡先を使用するだけです。さらに、これらの時間を購入して前払いで支払う場合、通常、クライアントに15％の割引を提供します。Win-Winです。

アジャイルは期限と予算を排除しません。私がクライアントであり、開発者のところに行き、締め切りや見積もり費用をくれないと言われたら、彼らの正気を疑うでしょう。そして、彼らが理解していないことを彼らに伝えることはうまくいきません。彼らは予算と計画を立てることができる必要があります。

彼らはあなたの開発プロセスを知る必要はありません。彼らは、機能を開発するのにどれくらいの時間がかかり、どれくらいの費用がかかるかを知る必要があります。要件が100％正確であるという（偽の）仮定に基づいて数値を与え、要件が変更されたら、見積もりを変更します。

これにより、必要な予算の明細と導入日が与えられ、状況が変化したときにプロセスを柔軟に調整できるようになります。

営業担当者が開発チームと顧客の間にコミュニケーションの層を作成しているようです。IT市場で長い間販売していない場合、彼らは自分の役割を「製品の移動」と見なす可能性があります。つまり、「必要なものは何でも」契約の署名を取得します。要するに、彼らは、彼らが何を約束しているかに関係なく、閉鎖する動機を持っています。このような状況では、顧客の言語をできる限り厳密に追跡します。

私はこれを引用する壊れた記録であるが、ここに行く：あなたは手術台にいて、外科医の下で行っているように「私達は時間通りにそして予算の範囲内であなたをここから出させます」と言う。すばらしいです。私は生きますか？

ビジネスの内臓に取り組んでいる場合、任意の時点で停止しますか？通常、アプリケーションは、規制、ビジネス環境、競合他社の行動、いくつかの新しいパラダイムの出現など、あなたもあなたのクライアントも制御しない力の影響を受けます。顧客は3か月後に戻ってきて「よく...」と言います。一般的に、ウォーターフォールプロジェクトに同意したときに彼らが知らなかった何かを知っていることを意味します。

このような状況で機能するのは、キャニオンを通るドライブがどのようなものであるかをあなたの営業スタッフに示すことです。毎ターン、驚きがあります。約3か月以上先を見ることはできません。そのため、顧客が18か月のプロジェクトを要求している場合、完了間近までに認識できなくなります。したがって、営業担当者は、プロジェクトの金銭的な見返りを見つけることから始める必要があります。これにより、売上が1,000万ドル増加しますか？もしそうなら、その追加の1000万ドルを作るために200万ドルを投資する価値がありますか？顧客と営業担当者が500,000ドルのコミットメントに集中している場合、何かが間違っている可能性があり、誰もそれが何であるかを知ることができません。「気分が悪い」とは、役に立たないというリスクを伴う何かをするというコミットメントです。

2つの最新のジェット旅客機モデルには、スナフスの歴史があります。Healthcare.govは議論する必要さえありません。旅客機で書籍やプレス記事を見つけることができれば、楽観的であることが証明された特定の仮定がどのように行われ、プロジェクトが期限を繰り返し逃したことを引き出すことができます。多くの場合、これは複雑さが過小評価されているためです。コーディングを開始するまで、その複雑さを実際に把握できない場合は、実際の問題をよりよく理解するために「初期ラウンド」が必要になります。予算のカットオフは、追加の総利益（または場合によっては収益）の一部である必要があり、その数は、現在のプロジェクトにかかると考える人よりも多くなければなりません。「ペイオフ限度」を超えずに最後のマイルストーンを渡す方法を示すことができる場合、

ソフトウェア開発以外でアジャイルスクラムの利点を達成するための主なハードルは、既存の制御メカニズムとアジャイルスクラムを統合することです。これらの制御メカニズムは、さまざまな組織の前提条件により規定されており、通常、線形ウォーターフォールのアプローチと方法論を使用して実現されます。

これらの典型的な組織的前提条件の4つを以下に示します。

• 大規模なグローバル企業-これらの階層マトリックス組織では、トップダウンのポートフォリオ管理が今日のルールです。自由spirit放なアジャイルアプローチには、厳密な制御に順応するのに苦労します。特にアジャイル計画に固有の固有の概念により、組織がアジャイルスクラムを飲み込みにくくします。

• 高度に規制された産業–一部の産業は、コンプライアンスおよびガバナンス機関により、厳格な拘束力のある管理メカニズムを持つことが求められています。これらは、たとえば、医療機器、航空機、医薬品の研究および製品開発のビジネスユニットです。個々のチームがアジャイルスクラムを運用する場合もありますが、開発プロセスは、トレーサビリティとガバナンスのための厳格な線形ウォーターフォールアプローチ手法に従う必要があります。

• 複雑な定義済み製品-ハードウェア、ソフトウェア、組み込みなどの両方を含む一部の統合製品は、定義済みの要件セットの下でエンドカスタマーとの契約として開発されます。これらの場合、要件の柔軟性の程度は小さくなりますが、最初に予想されるものよりも大きくなります。これらの場合、アジャイルスクラムの完全に柔軟なバックログの概念はかなり苦しみます。

• 一般的なIT部門–メンテナンス主導のIT部門での毎日および毎週の活動の多くは、臨時です。毎日のスケジュールの変更は非常に多く、即座に行われます。チームの仕事における絶え間ない干渉が標準です。これらの状況では、タイムボクシングと干渉なしの概念を維持することは困難です。

当然のことながら、上で詳述した4つの個別のカテゴリの多くは、実際に混在しています。そのため、グローバルな大企業で複雑な製品を見つけることは一般的であり、それは会社の規制を順守する必要があります。

実際の経験に基づいて、これらのシナリオおよびその他のシナリオに取り組む推奨方法は、アジャイルPMOを、新たなアジャイルスクラムチームとリニアウォーターフォール要素の間のイネーブラー、ドライバー、およびトランスレーターとして機能させることです。

特定のガイドラインについては、以下の表を参照してください

ソース- マイケルニルによる線形ウォーターフォールとアジャイルアプローチのインターフェイス

潜在的な顧客と開発者との2回または3回の推定セッションを設定し、手元の作業について議論し、受け入れ基準を設定します。開発者は、会議中にストーリーポイントで作業を見積もります。

その後、顧客に多くのストーリーポイントを販売します。これが可能なのは、彼がストーリーポイントの価値についてよく知っているからです。プロジェクト中にバックログ/スコープを微調整する可能性があり、ストーリーポイントを使用することで簡単になると彼に伝えます。また、進行中のソフトウェアを頻繁に配信して、進捗状況を監視し、新しい洞察を得ることができることも伝えます。

ストーリーポイントの数に同意することにより、顧客はお金の価値を得ることが保証されます。彼がバックログを変更しない場合、彼は固定価格/固定範囲プロジェクトを持っていますが、私の経験では、彼は変更を加えるでしょう。潜在顧客の存在下で見積もりを行うことにより、オープン性と信頼に基づいて関係を構築しようとします。

「予算と締め切りを希望する」あなたのようなクライアントを説得することができ、ドキュメントから作業するのではなく、彼らが必要とするものを本当に理解したいと喜んでいた。これらのプロジェクトに投資したいことを示しました。

推定セッション中に、バックログ全体を推定しました。これにより、xストーリーポイントが与えられました。その時点ではまだ明確でなかったり、知られていない機能には25％を追加することをお勧めします。契約に推定バックログが添付されたため、固定予算ですべてを手に入れることができると安心しました。

当初、入札は時間と材料でした。彼らは固定価格で入札したかったので、私たちは彼らに与えた価格で働き、偶発性のために25％の追加ストーリーポイントを使用することを提案しました。うまくいけば、25％のうち、発生した遅延をカバーするために使用されなかった部分が、より多くの機能を顧客に提供するために使用されます。

これは多くの方法で彼らを刺激しました。最初に、彼らは開発者が可能な限り速く動作できるようにするためにできる限りのことをしました。質問への回答を待つ必要はありませんでした。第二に、彼らはストーリーポイントの概念を本当に理解しました。プロジェクトが始まる前に、彼らはすでにいくつかのストーリーを削除し、他のストーリーを見積もるように頼んでいました。これには複雑な契約交渉は必要ありませんでした。

私たちは彼らに進捗状況を知らせ、非常にオープンなコミュニケーションを維持しました。彼らは2週間ごとに進捗レポートを受け取りました。ストーリーポイントのx％が推定時間のy％で行われ、残りのストーリーポイントのz％が利用可能になります。少し難しいスタートでしたが、プロジェクトの終わりまでに見積もりに追いついたため、追加のストーリーポイントの100％が追加の開発に利用できました。顧客は、本当に必要なものをすべて手に入れたので幸せでした（そして、それは最初に要求された機能とは少し異なり、一部を削除して追加しました）。

顧客は、すべてが予定された時間内に配信されたため、満足していました（チケットの追跡、質問への即時回答、毎週の分析会議へのユーザーの参加、機能テストへの参加など、可能な限りのことをすべて行いました）。

納期どおりに予算内で納品したため、私の会社は満足していました。このプロジェクトが成功したことで、より多くのプロジェクトへの扉が開かれたため、私の会社も幸せでした。私たちは、世界中の人々に送られた顧客の月刊誌でも言及されました。

適切な見積もりを行うことはプロジェクトの最も困難な部分でしたが、見積もりセッションを事前に行うことで、困難とリスクを理解することができました。これにより、事実に基づいて見積もりを出すことができ、多くの未知の要素が削除されました。

コンサルタント/入札環境でアジャイル手法を使用しようとすることは、顧客が搭乗していない場合は非常に困難です。

ウォーターフォールスタイルに慣れている場合、「ここに要件、量、所要時間はありますか？」プロジェクトをタイプし、アジャイルまたは他の方法が優れていることを彼らに納得させる時間がないので、入札にそれを出している。

アジャイルには利点（およびもちろん欠点）がありますが、率直に言って、顧客は舞台裏の詳細を知らないか気にしないことがよくあります。

コストと時間のスケールという2つの要素が必要です。そして、あなたが彼らにそれを告げると、彼らはそれからそれをより安くそしてより早くほしいと思う。そして、あなたは何を知っている、私たちはそれがすべて欲しい。すべての要件。待つことも、切り刻むこともできません。

そして、私はほとんどの生活の中で営業担当者が嫌いである限り、営業担当者をあまり厳しくしないでください。それは大変な仕事です。

彼らはソフトウェアを構築しません。彼らは、それが話題の言葉を超えてどのように機能するかほとんどわかりません。

それでも、彼らはいくつかの羊毛質の要件を満たすことに基づいて、時間スケールとコストを考え出す必要があります。たぶん彼らは彼らを統治するために彼らと一緒に技術者の何人かを持っていますが、彼らは物事を続けるために販売をする必要があります。

それでは、アジャイル開発手法を使用するプロジェクト、またはそのような手法を使用して開発された製品を販売チームに成功させるにはどうすればよいでしょうか？

営業スタッフに顧客をオフィスに連れて行ってもらいます。アジャイルの全体的なポイントは、クライアントから即座にフィードバックを得ることで、クライアントが望むものを（そしてそれ以上は）作成できないようにすることです。彼らを連れてきて、彼らが何を望んでいるか尋ねます。2週間後、それらを持ち込み、デモ/プロトタイプを見せます。そのインタラクションでそれらを売ります。彼らに進捗を見せ、この種の反復があなたがしたいことであることを説明してください。

必要な作業量の見積もり（つまり、予算とは何ですか）を提供しますが、予算に収めたいものを含めることができるようにします（読み取り：責任）。

答えは、ほとんどの場合、おそらくあなたはおそらくそうではないと思う。最初はこれをあなたのビジネスの小さな部分、おそらく20％で、残りは従来のモデルで見ようとするでしょう。時間が経つにつれて、私はアジャイル製品とクライアントにもっと集中し、その部分をさらに成長させようとするでしょう。

これに取り組む別の部分は、おそらく両方のアプローチを試して使用することです。上級管理職および契約交渉担当者とウォーターフォールアプローチを使用します。たとえば、「クライアントがポートフォリオを維持し、ブラウザベースのデバイスと携帯電話デバイス（AppleおよびAndroid）の両方を使用して投資判断を行うことを可能にするシステム」。またはそのようなもの。次に、ホームページの作成、ログインページの作成、Portolio管理履歴の作成、モバイルログインの作成など、より詳細な機能に関する開発チームの開発にアジャイルを使用します。

別のアイデアは、アジャイルを差別化要因とすることです。大部分ではないにしても、多くの組織がアジャイルを行っていないことを知っています。しかし、ほとんどの（私の経験では大多数の）中小企業はそうです。アジャイルは急速に成長しており、これは続くと思います。このルートの利点は、すでにそれを認識している顧客に最もやりたいことを売り込むことです。このアプローチでは、成功を保証することなく、時間をかけていくつかの作業が必要になります。

また、クライアントがテストを好む場合、いくつかの牽引力を見つけるかもしれません。十分にテストされた製品を持つことは、一部のクライアントへの販売を容易にすることができます。私がこの分野で役立つと思う本は、Adison Wesley Pressによる「アジャイルテスト」です。

現在のイベントを使用して、ケースをサポートすることもできます。たとえば、現在の（2012年10月にこの記事を書いている）ヘルスケアサイトは、運用開始の2週間前に必要であった変更を処理しない方法の素晴らしいケースです。また、明らかなオーバーエンジニアリングは、よりアジャイルな方法によりよく対処されていたでしょう。

あなたの仕事に満足している以前のクライアントに連絡してください。特に、彼らがアジャイルに変換するウォーターフォールである場合。少なくとも、あなたのクライアントではない変換者。

（顧客としての）彼らの証言は、あなたが言うことができる何よりも重要です。彼らはあなたの新しい顧客の懸念や恐れにあなたがこれまで以上に対処することができます。

管理の観点から見ると、予算と期限がプロジェクトのビジネスニーズです。これらのニーズに対応していることを確認する必要があります。また、切り替えに関するビジネスの証言を見ると、それがすぐにわかります。切り替えに関する開発者の証言を見ると、しばしばそうではないことに気付くでしょう。