技術的な決定を下そうとするビジネス
私たちはしばしば、ビジネスがクライアントに新しい機能を約束するシナリオに出くわしました。ビジネスは、機能が特定の方法で実装されることを約束します。ビジネスによって約束されたこれらの技術的な詳細は、通常、不十分です。残念ながら、クライアントは現在設定されており、この機能をビジネスで説明されている方法で実装することを望んでいます。
結局のところ、企業は、品質や保守性に関係なく、この機能を完成させたいだけです。プッシュバックする良い方法はありますか？要件が収集される前に技術的な詳細を提供することは悪い考えであることをビジネスにどのように説明できますか？
それは組織的な問題です。上層部がこれを理解していない場合、あなたができることはあまりありません。技術者ではない上司に問題を説明するようにしてください。しかし、どこにも行かなくても驚かないでください。
これは、何らかの理由でソフトウェアを販売する非開発会社で働く開発者にとって一般的な問題です。
それは楽しい戦術ではありませんが、証拠で彼らを棍棒で打つことができます。プロジェクトの開始時に、（技術的な詳細が不十分だったために）失敗する理由を正確に書き留めて、関係者に電子メールで送信します。常にメールを送信し続け、プロジェクトが最終的に顧客の不満を募らせて大惨事になったときは、あらゆる機会に送信したメールを引用してください。それはいくつかの悪意を生み出すかもしれませんが、そのような全身的な問題を修正しようとする良い方法は実際にはありません。
開発者の観点から見ると、仕様の作成に関しては、これは2つの失敗の1つです。起こり得るもう1つのことは、販売が大きな約束をした後、ITにプロジェクトを指定し、見積もりに変換できる書き込みを提供することです。
問題は、多くの場合、それが作業の大部分であるということです。実際のコードは、適切に設計された仕様でレイアウトされたアプローチの詳細を実装しているだけである可能性が非常に高いです。
同時に、販売はスペック開発のような予備的な請求をするのが難しいと感じています。私達はまだクライアントとベッドに入っていません、そして彼らにお金を払ってどれだけのお金を払うべきかを理解するのは奇妙です。
これが、新しいクライアントとのほとんどの「初回」プロジェクトが最終的に損失リーダーになる理由です。 LUCKYの場合は、最初のプロジェクトを使用して、クライアントになる方法についてクライアントをトレーニングします。2番目のプロジェクト、または最初のプロジェクトの保守契約でお尻を稼ぎ始めることができます。