存在しない機能を営業チームが無責任に約束するときの名前はありますか？
会社の営業チームがセールを完了するために新機能を約束することはよくある問題です。多くの場合、これらの新機能はまだ開発中または設計中です。時々、開発チームがそれらを知る前に機能が販売されます。
機能がまだ実装されていないことをお客様が理解している場合、これは製品の設計の手助けとなります。ただし、営業チームがこれらの機能を無通知の時間枠で約束すると、締め切りに間に合うように管理者から請求される開発者に多大なストレスがかかる可能性があります。
さらに、開発がまだ要件を認識していない場合でも、存在しない機能が完成またはほぼ完成したものとして顧客に販売されることがあります（法的/倫理的な問題にもかかわらず）。
この慣行の無知識/無責任/非倫理的なアプリケーションを説明するために使用できる単語またはフレーズはありますか？
機能クリープに似ていますが、開発または設計の前に発生します。
過度に楽観的なスケジューリングは、Steve McConnellの著書Rapid Developmentで使用されている用語です。彼は希望的思考という用語も使用しています。
McConnellは、過度に楽観的なスケジュールが実際にプロジェクトを後回しにすることを（裏付けとなる証拠とともに）書いています。
スケジュールのプレッシャーで一度は悪い経験をしました。顧客は、同様のプロジェクトに沿っていたにもかかわらず、タイムラインに不満を持っていました。タイムラインの短縮を期待して、契約プログラマーを雇いました。顧客はさらに多くの機能を追加しました。 （「プロジェクトに時間がかかりすぎて、機能を追加したいですか？」というレビューはありませんでした。）契約プログラマーは私たちが期待したほど上手ではなく、バグと設計の問題を修正するために多くの時間を費やしました。
私はそれを助けることができる限り、その経験を再びやりたいとは思わない。
はい、あなたは営業チームと経営陣が彼らのコミットメントを満たすのを助ける創造的な方法を探すべきです。売上高はあなたの給料を支払います。
はい、あなたは非現実的なスケジュールについて丁寧にそしてしっかりと発言すべきです。スケジュールは変わらないかもしれませんが、あなたはできることをしました。あなたは彼らがあなたが聞きたいものではないときでさえ、あなたに彼らにあなたの最高の専門家の意見を与えるためにあなたの経営者に借りがあります。
"正常"
販売チームがあなたが書いた製品を販売するためにそこにいることを覚えておいてください。彼らは自然にクライアントの需要に適応し、彼ら（そしてあなたのもの）のクライアントが必要とする機能を販売しています。あなた実際に欲しい彼らはこれをしている;それは、収益が間もなく到来し、製品が市場のニーズとの関連性を維持していることを意味します。
これはベーパーウェアに関連している可能性があることに注意します。しかし、その用語の背後には、あなたの質問には当てはまらないニュアンスがあります。
これは、配信スケジュールが明確に定義されていない場合、または販売チームが配信できるものを過剰に約束した場合にのみ問題になります。これは、これらのビジョンの実装に関わる開発者にストレスをもたらしますが、最終的に解決するのは問題ではありません。上級管理者および製品開発管理者は、販売管理者と協力して、機能を販売のために宣伝できる時期と、どのスケジュールにコミットできるかを定義する必要があります。過剰なコミットメントは会社のイメージを損なうものであり、当然、上級管理職が解決すべき問題です。
一般的に言って、開発者（およびセールス...）は、セールスおよびマーケティングへのDesign => Sell => Developアプローチを好む。開発には、潜在的なクライアントに何がむずかしいのかという考えがあり、セールスには、潜在的なクライアントに興味がある場合に、アイデアXYZが実際にいつ配信されるのかについての考えがあります。
Sell => Design => Buildが表示される場合がありますが、このパスは開発チームに問題を引き起こす可能性が高くなります。一方では、セールスチームがコードベース*を本当に理解している場合、これは新しい契約への効果的なルートになる可能性があります。一方、妥当な期間内に実際に配信できるものを約束しすぎる可能性が高くなります。あなたの質問は、このアプローチがどれだけうまく機能するかを決定する上でのいくつかの鍵を呼び出します。
*はい、私は「決して起こらない」という皮肉な返事を知っています。しかし、会社の創設者の1人が高度に技術的であり、より多くの売上を牽引する役割に移行したときに発生することがあります。また、「テクニカルセールス」担当者の全支店もあります。
これはorganizational anti-patternの一種です。私はこの実践のためのいくつかの用語を聞いた：
- 販売主導の開発
- セールス志向のプログラミング
- ズボンの座面によるコーディング
これには根本的に何も問題はありませんが、時々それはビジネスにとって非常に良い場合がありますが、過度に使用すると、かなり急速にさまざまな既知の問題に悪化します 機能膨張 、 泥の大きなボール 、 マジックプッシュボタン など.
私の組織では、これを違反するセーフハーバー、または将来の見通しに基づく販売と呼んでいます。
すべてのプレスリリースとセールスプレゼンテーションには、「まだリリースされていない機能の配信を保証していないため、現在の機能に基づいて購入を決定してください」というセーフハーバーの声明が付属しています。当社の営業担当者は、特定の日付に新しい機能を決して約束しないことが義務付けられており、約束した場合、セーフハーバーの声明に反して約束します。
あなたがそれを説明するように、この販売手法には何の問題もありません。
これは、営業チームが約束した時間内に提供できないことを約束した場合にのみ、機能クリープに似たものになります。
これが発生すると、ソフトウェア開発プロセスが途中で失敗することが多く、物事を迅速に提供する必要があります。これにより、
- 悪いコード
- 悪いデザイン
- テストが不十分（またはなし）
悲しいことに、これは非常に一般的です。
私の皮肉屋は「コンサルティング」と言いたいですが、正直なコンサルタントがたくさんいるので、それは完全に公平ではありません。
ソフトウェアコンサルティングでは、特に、特注のグリーンフィールドプロジェクトを行っている場合は、まだ構築していないものを販売することは非常に一般的です。多くの組織は、カスタマイズや独自の機能（SAP、Microsoft Dynamics、Microsoft SharePointなど）を必ず含む、自社製品に関するコンサルティングサービスを販売しています。
技術チームから切り離されている営業担当者がいることに起因するフラストレーションに直面しているように思えます。この状況を改善する方法はたくさんありますが、職場で私たちが始めているのは、さまざまな人々がチームの残りの部分に自分の仕事について教える「学習セッション」です。開発者は、販売とその中の課題について学ぶことができます。営業担当者は、ソフトウェア開発の課題について学ぶことができます。もう1つのテクニックは、サービスを販売する人と一緒に営業担当者を座らせることです。 「私たち対彼ら」の境界を打破し、誰もが同じチームでプレーすることを奨励します。