私たちは、より大規模で戦略的に重要な顧客の1人と繰り返し対立しています。同社(現在は "C"と呼びます)は、ハードウェアコンポーネントからヘアドライヤーまですべての技術記事を販売および配布しており、カタログには400000以上の製品があります。
「C」の製品ドキュメントおよび内部ソフトウェアの責任者でもある製品所有者は、90年代のある時点でソフトウェアテストのコースを受講し、現在、ユーザーテストとして「要件仕様」を作成しています。これらはしばしば矛盾し、エラーが発生しやすくなりますが、彼女は自分が書いたものは自分が望んでいるものであると主張します。さらに、彼女はプロジェクトの最終予算を要求し、予算のより小さな反復で作業することを望んでいません。
私は、開発プロセス(および私たち自身の経済)を制御し、それでも会社に最も価値のある製品を顧客に提供する方法についてのヒントを探しています。通常、私はプロジェクトの目標と組織のビジネスユースケースを特定し、ユーザーストーリーを使用してそれらの目標からスコープを導出することからプロジェクトを開始します。ユーザーストーリーの実装方法の詳細(仕様)は、それぞれのユーザーストーリーを含むスプリント前の仕様で決定されます。これにより、顧客により良い製品とより高いROIをもたらすことが繰り返し証明されています。
誰もが「リバースエンジニアリング」の必須のユーザーテストに使用できる技術の知識、または状況を処理する方法に関するその他の入力の経験がありますか?
歴史的に、彼女は開発プロセスを完全に支配することを許可されてきました。それは私たちの予算を吹き飛ばし、彼女が私たちのプロセスを制御していることを彼女に教えました。私たちの経営陣は私に、開発プロセスを管理する(そして防御する)ように頼みました。彼らは「C」に、彼女(製品の所有者)が私たちをどのように「完了」したと感じても、合意された予算を超える時間は使用されないだろうと言いました。もちろん、それは私のレバレッジになります。彼女は防御的になり、物事を自分のやり方で進めるために攻撃的にさえなります-専門家の参照や経験に基づく健全な議論は助けになるでしょう。
ファローアップ:
誰かが同様の問題でこの投稿に出くわした場合に備えて、フォローアップすると思いました。
私たちはコミュニケーションを好転させ、次のプロジェクトを予算内で時間どおりに提供することを期待しています(後で地獄が崩壊した場合は、この投稿を再度編集します)。
当初、私は自分とプロダクトオーナーの間に信頼関係を築くことに重点を置いていました。それは、関連する戦いを選択し、彼女のお金の最大の価値を得るための彼女のツールとして自分自身を提示することを意味しました。要件はほぼ同じ方法で表現されますが(彼女は構文についての入力を受け付けていますが、形式についてはしっかりしています:Wordドキュメントと電子メール)、開発プロセスに関する可視性と制御をゆっくりと交換しています。
私はなんとか彼女にプロジェクトのステータス、バックログのグルーミング、優先順位付けのための毎週の会議に参加するように説得しました。各会議の合間に、彼女は最新のリビジョンをテストする機会を得ます。これにより、以前はディスカッションの対象であったものをテストフィードバックし、バックログのグルーミングと優先順位付けに最も価値のあるフィードバックを作成します。テストからのフィードバックについて直接話し合うことで、開発に漏れる前に、誤解、矛盾、スコープクリープを「取り除く」ことができます。
私たちの間の信頼は、私たちがお互いの組織とそれらのプロセスと意図について建設的な話をすることを可能にしました。それは私たちの能力の欠如(専門的、理論的、そして系統的)である問題のかなり大きな部分に目を開かせました。
製品所有者は、私たちが行っている進歩を個人的に称賛するために経営陣に電話をかけたので、私はこれらの最初のステップでの成功を呼びかけています。
これは、利害関係者と協力するアジャイルシステムがほとんど機能しているように聞こえますが、完全には機能していません。
まず、命令型のユーザーストーリー(例を挙げてください)は単純に詳細であるため、そこからより適切なテストを生成できます。 この例 を使用すると、それらは機能しますが、顧客の要件の変化に直面して脆弱です。ただし、顧客の要件が非常に厳しい場合は、より適切です。この違いを顧客に強調し、どちらが顧客の状況に最も適しているかを判断する必要があります。
第二に、問題は、要件を作成する人が配信を受け入れる人であるということだと思います。開発中に元の要件が変更された場合、これに対する仲介段階はないようです(変更されているようです)。現在、アジャイル環境では、要件の変更が標準です。したがって、アジャイルです。 -しかし、顧客はあなたが彼らが要求したものを提供することを理解する必要があります、そして彼らが絶えず彼らの考えを変えるならば、あなたがすべての時間をやり直しに費やしたので、全体的な提供は多くの結果を含みません。
最終的な予算は明らかに双方が望んでいるものなので、時間の観点から予算を立てる必要があります。あなたは彼らのために好きなだけ働き、1日ごとに請求します。予算がなくなると、それだけです、あなたはやめます。これを実現するには、予算会議で顧客と経営陣にこれに同意してもらう必要があります。予算を制限するのは珍しいことではありませんが、関係する時間制限を理解する必要があります。これにより、私が幸せになるまで継続的に作業するのではなく、実際の配達に集中する必要があります。
最後に、あなたが抱えている大きな問題は、実際には習慣の1つです。人々は現状に慣れており、コラボレーションの境界を再確立するために集まる必要があります。あなたは彼女が敵であるか、無能である態度を落とさなければなりません。あなたは彼女と一緒に仕事をしなければなりません、そして間違いなく彼女はあなたが思っているよりもはるかに有能です、おそらくあなたはプロセスの両側で蓄積された失敗のためにあなたがいる状態になってしまったでしょう。したがって、何をするにしても、白紙の状態とオープンマインドから始めれば、この問題の修正に成功するはずです。
この顧客をネガティブな「難しい」と考えるのではなく、彼らだけが本当にプロセスに関与したいと思っているのを見てはどうでしょうか。おそらく、他のサプライヤーとの協力経験は、緊密な協力関係の恩恵を受けているのでしょうか。
歴史的に、彼女は開発プロセスを完全に支配することを許可されてきました
顧客関係を管理するための内部プロセス/ガイダンスはありますか?もしそうなら、それらは使用されていますか?この顧客がなんらかの形で「支配」している場合、彼らは行方不明であるか、使用されていないか、何らかの理由で不足していることに気づきます。
また、あなたはこれを行うのに最適な人ですか?あなたが主に技術的な役割を担っている場合、あなたの会社は、製品を構築している間に関係を構築するのを助けるために、より人に焦点を合わせた役割を持っている人を連れてくることを望むかもしれません。これは必ずしもあなたが作業する必要のある別のレイヤーになるとは限りません-それはあなたと彼らの間の二重の行為でなければなりません。
私の経験では、すべての顧客を関与させ、彼らの期待を最もよく管理するために従事し続けることが前進の道です。ここで採用できるテクニックと戦略はたくさんあります。
明確でオープンなコミュニケーション
したがって、顧客は何らかの方法で要件を変更したいと考えています。支払いをしているときに、これを行う権利がありますが、次のことを確認しましょう。
定期的な更新
したがって、通信はすべてイベント駆動型ではなく、頻繁な更新をスケジュールする-これが[ビデオ]であるかどうかを確認する必要があります。電話会議、オンサイトまたは社内会議。あなたと定期的に進捗状況を確認できることで、あなたは彼らとまっすぐである、つまり何も隠さないという自信を持って彼らを満たします。時間が経つにつれて、彼らはあなたが彼らに与える更新に従ってあなたのチームが提供し、彼らの要求が聞かれ、管理され、統合されるのを見てリラックスするでしょう。
私の(長い)キャリアの中で、私はプロジェクトの進捗状況について話し合う多くの会議を行いました。彼らはいくつかの質問をし、10分以内に完了しました。
また、オフィスに侵入し、機材が盗まれたため、1週間はまったく進展がなかったとの期待を持ってお客様に伝えなければなりませんでした。私たちは怒りを期待していましたが、彼らは私たちの挫折に共感し、完全に理解しました。ある顧客は私たちにいくつかの機器を貸与しました(〜1993年には128mb DRAMスティック)。
軽量変更管理プロセス
したがって、問題の1つが彼らの考えを変えることである場合(彼らには完全に権利があり、請求書を支払う「顧客」である)、軽量の変更管理プロセスを使用することをお勧めします。ここであなたができる最悪のことは、彼らが脅迫されていると感じるので、彼らにいくつかの法的に見える文書に署名させることですが、あなたは以下を行うことができます:
いつ助けを得るか
したがって、世界のすべての最善の意図がまだ顧客に伝わっていないように見える場合があります。これらは私が経験したものです:
ここにはたくさんの危険信号が飛び出している:
変更したくない人がいる場合[〜#〜] and [〜#〜]彼らは非常に重要なクライアントであるため、いくつかの選択肢しかありません。
これらが機能しない、または機能しない場合は、他に何ができるか完全にはわかりません。