技術的な意思決定をしようとしているビジネス

多くの場合、ビジネスがクライアントに新しい機能を約束するシナリオに出くわします。ビジネスは、機能が特定の方法で実装されることを約束します。ビジネスによって約束されたこれらの技術的な詳細は、通常貧弱です。残念ながら、クライアントは現在設定されており、この機能をビジネスで説明されている方法で実装する必要があります。

最終的に、ビジネスは品質と保守性に関係なくこの機能を完成させたいだけです。押し戻す良い方法はありますか？要件を収集する前に技術的な詳細を提供するのは悪い考えだと、ビジネスにどのように説明できますか？

それは組織的な問題です。上層部がこれを理解していない場合、できることはあまりありません。技術者でない上司に問題を説明してみてください。しかし、どこにも行かなくても驚かないでください。

これは、何らかの理由でソフトウェアを販売する非開発会社で働く開発者にとって一般的な問題です。

それは楽しい戦術ではありませんが、あなたはただ証拠でそれらをblすることができます。プロジェクトの開始時に、失敗する理由を正確に書き留め（技術的な詳細が不十分だったため）、関係者にメールで送信します。常にメールを送信し続け、最終的にプロジェクトが顧客を怒らせて惨事に陥った場合は、あらゆる機会に送信したメールを引用してください。それはいくつかの悪意を生むかもしれませんが、そのような全身の問題を修正しようとする良い方法は本当にありません。

開発者の観点から見ると、これは仕様記述に関しては、失敗の2つのフレーバーのうちの1つです。起こりうるもう1つのことは、販売が大きな約束をした後、ITに頼ってプロジェクトを指定し、見積に変換できる評価を提供することです。

問題は、多くの場合、それが作業の大部分です。おそらく、実際のコードは、適切に設計された仕様でレイアウトされたアプローチの詳細を実装しているだけです。

同時に、仕様の開発などの予備費を請求するのは難しいと感じています。私たちはまだクライアントと一緒に寝ているわけではありません、そして彼らがお金を払ってどれだけのお金を手に入れるかを理解するのは奇妙です。

これが、新しいクライアントとの「最初の」プロジェクトのほとんどが最終的に損失のリーダーになる理由です。LUCKYの場合、最初のプロジェクトを使用してクライアントになる方法をクライアントにトレーニングし、2番目のプロジェクトまたは最初のプロジェクトで保守契約を締結して、収益を上げることができます。