エンジニアリング分野では、「セールスマン」になるように求められている頻度はどれくらいですか?また、あなたの反応はどうですか?[閉まっている]


12

私は最近、私のアイデアを実現することになると、「セールスマンシップ」が不足していると言われました。私のアイデアは健全であり、実装するデータは説得力があり、経営陣が理解できる方法でアイデアが提示されているというフィードバックを受け取りますが、時期が来たときにアイデアを「販売」するのは良い仕事ではありません実装する。

エンジニアとして、私はこのスキルを磨いていないことを理解できる一方で、これについて少し奇妙に感じます。しかし、一方で、これは私が持っていると期待されているスキルであると私はほとんど盲目的に感じます。意思決定者はすでに「実行に移る」と言っていますが、私が実行に移るとき、私がパートナーになることになっている人々は進歩への障壁を立てました。

他の人がどのようにこれに対処するのか疑問に思っています。

回答:


11

私はあなたが何を意味するか知っていると思います。「販売」および「販売」という用語は、この文脈ではやや混乱を招きます。本当にあなたは、相手が理解できる文脈で状況とその背後にある理由を説明できる必要があります。これは、管理者やエンジニアと話すときに異なります。私はこれを販売よりも正当化と呼びます。

1.経営の正当化

経営陣と話し合い、アイデアの青信号を得る場合は、技術的に実行可能な理由だけでなく、他のアイデアよりもこのアイデアのビジネス上の利点を説明する必要があります。たとえば、最初の実装にかかる費用が少なくなります。メンテナンスが簡単です(コスト削減)。維持するのが難しい(有利なサービス契約を作成する)...

「良い」ことは、技術的な観点から反対の最後の2つの例で強調されているように、企業のビジネス戦略に依存しますが、両方とも異なるビジネス戦略の下で有益であると考えられるかもしれません。

会社のビジネス戦略が気に入らない、または意見が合わない場合は、自分のビジネスを離れて開始し、顧客をよりよく扱います。または、少なくとも、技術的に素晴らしいにもかかわらず、アイデアが採用されない理由を理解し始めることができます。

2.エンジニアを正当化する

あなたはすでに経営陣から先に進んでいるように聞こえますが、今、あなたはこの方法が実際に優れている理由を他のエンジニアに納得させるのに苦労しています。まあ、あなたが苦労している理由は、それらの他のエンジニアがビジネス戦略とあなたのアイデアがそれにどのように適合するかを理解していないからです。だから今、あなたはエンジニアにビジネス戦略を説明しなければならないという奇妙な立場にいることに気づきました。ビジネス戦略そのものを正当化する必要はありません。技術ソリューションが経営陣から指示されたビジネス戦略にうまく適合する理由だけです。これは、非ビジネス指向のエンジニアが理解するという観点で行う必要があります。これは、多くの場合、最良の技術ソリューションがビジネス戦略と対立するため、注意が必要です。

説明のために最近対処しなければならなかった実世界の例を使用します。これはソフトウェア会社のものですが、あらゆるエンジニアリング状況に適用できます。

同社は、2つの異なるワークストリーム(2つのチーム)が本質的に同じことを行い、2つの市場で2つの異なる製品(同じことを行う)を作成することを望んでいました。特に両方の製品が非常に多くのコンポーネントを共有でき、実際にはこれらの2つの市場の違いに対処するためのいくつかのマイナーな構成オプションを備えた同じ製品にさえなる可能性がある場合、技術的には狂気です

エンジニアは、収益の80%が1つの市場からのものであり、競争もmuch烈であると説明するまで、このアプローチに同意するのに苦労していました。他の市場をサポートして、迅速に競争に勝ち抜くための考慮事項。流通市場は依然として活用して成長する価値があったため、2番目のチームはそれに焦点を当てます。これは私たちに与えられた戦略であり、これは私たちが解決する必要がある問題であり、単一製品を作るという他の問題ではありません。

結論

セールスを学ぶ必要はないと思います。他のエンジニアがあなたとは異なる問題を解決しようとしていることを識別できる必要があると思います(通常は、顧客、利益、経済などのばかげた非技術的なものが原因です)マラーキー)。次に、問題が実際に何であり、なぜであるかを説明できるようにする必要があります。そうすることで、彼らはあなたの(経営陣によってすでに受け入れられている)アイデアを受け入れます。


しかし、これは私が話していることです。エンジニアに推論とデータをどのように納得させることができるかを示すのは素晴らしい仕事でした。それは私が苦労していることではありません。私があなたに言っているのは、データにもかかわらず、事実にもかかわらず、必要にもかかわらず、そして緊急にもかかわらず、私は十分に「それを売る」わけではないので、「いいえ」と言われているということです。優れた営業担当者であり、すべての証拠を無視します。
ティムD

1
セールスマンシップの好例は、スティーブジョブズです。スティーブウォズニアックは技術的にはもっと気になりましたが、セールスマンではありませんでした。スティーブジョブズは技術的にはあまり気にしませんでしたが、「次の」デバイス/玩具を購入する必要があることを人々に納得させる方法を知っていました。セールスピッチをどのように実現するかが重要な場合もあります。アニメーションが過剰ですか、それとも不足していますか?「クライアント」に関与しますか?あなたの声は単調ですか?どのような自信がありますか?他の方法を見てください。時々それはすべて人格と性格についてです。「クライアント」はあなたと一緒にいたいですか?
フレッド

6

この文脈での「セールスマンシップ」とは、「抵抗を克服できること」を意味します。

「抵抗」は、2つの形式のいずれかを取ることができます。それは、例えば経済的な理由から「合理的な」抵抗である可能性があり、それにより提案された技術的解決策は経済的に実行可能ではない。この場合、より安価な解決策、または少なくとも許容できる妥協案を見つけるためにうまくいくかもしれません。ここでは、古典的な「販売」スキルは必要ありませんが、ビーンカウンターに銀行を壊さないことを納得させるパッケージをまとめるには、「マーケティング」スキルが必要です。これらの人々は、少なくとも「数学がうまくいかない」、または「数字が合わない」(利益につながる)という異議については直接的なものになるでしょう。

「不合理な」種類の抵抗は、既得権益に反対する場合に起こります。次に、それらの利益が何であるか、「意思決定者」が誰であるか、そしてそれらの異議が消えるようにあなたの技術的解決策を改良できるかどうかを知る必要があります。これは、単純な「販売」状況というよりは、内部的な「政治的」状況です。

これらは日常的なエンジニアリングの問題ではありませんが、時々発生します。これらのイベントはエンジニアリングのキャリアを左右する可能性があるので、できる限りこれらのフィールドを使用します。これは、エンジニアリングを離れて「管理」に取り組む意欲がある場合に特に当てはまります。


2

多くの場合、クライアントは変更に対して抵抗力があります(内部または外部のクライアント)。技術的に何かが適切なソリューションであると思われる場合でも、既存のプロセスや製品を手放したくないと考えています。(なぜですか?それが私たちが常に行っていることですから)

したがって、この美しいデータがすべて揃っており、クライアントの問題に対するエレガントなソリューションが得られます。これが実際の作業の始まりです。これは難しいことでもあります。私が働いている会社では、エンジニアリングスタッフがMBAの学位を取得してビジネス感覚を養うように奨励することで対応しています。すべてのエンジニアが優れた「営業担当者」というわけではありません。

役立つアドバイスに関しては、基本的な出発点としてあなたのために私がマーケティングまたは説得力のある話の良い本を見つけることはあなたの技術的解決策の中にあるように聞こえないので、私は推測します。


2

ここで「セールスマン」という用語に固執することはありません。エンジニアリングは、(主に)合理的な企業(場合によって)です。したがって、一般的なアプローチは、技術的およびビジネスに関連する側面/懸念を特定して理解し、合理的に対処することです。

あなたの特定の問題について暗闇の中で快適に突き刺すことは、おそらくあなたのアイデアの最も重要な側面と影響が同僚の頭の中で明確であるかどうかを考える価値があると思います。お金、時間/リソース、プロジェクトに勝つ可能性などが、考慮したい考慮事項になる可能性があります。他の回答はすでにいくつかの良いコメントを提供しています。

まだ言及されていないと思う次の項目を追加したいと思います。

影響を受ける分野に関するタイミング

パートナーの分野や同僚にとって、即時の、追加の、潜在的に無給の仕事を意味する場合、良いアイデア/イノベーションは苦労するかもしれません。たとえば、(建物の設計と建設の背景から)建築サービスエンジニアが基本的に設計を完了し、新しいアイデアがサービスに大幅な変更をもたらす場合、無料で働くか、クライアントとのバリエーションネゴシエーションを入力します。何らかの理由で時間をオーバークロックした場合、どのステージであっても同じことが起こります。

考えられる解決策は次のとおりです。

  • プロジェクトの早い段階でアイデアをプッシュして、同僚がアイデアの影響を消化して理解する時間を確保する
  • あなたのアイデアをチームの入札の一部にしましょう(あなたのアイデアがチームの次のプロジェクトに勝つかもしれません)
  • プロジェクト概要に影響を与える機会はありますか?
  • このプロジェクトでは発生しない可能性があることを考慮してください。時間をかけて、当面のプロジェクトのコンテキスト外で同僚にアイデアを説明してください。耳を傾け、質問し、抵抗の理由を理解しようとします(@TomAuと@jhabbotで既に議論されているように、正当な理由があるかもしれませんし、そうでないかもしれません)。

パートナー規律のリソースへの影響

パートナーの専門分野があなたのアイデアを理解していない場合、彼らはどのくらいのリソースと時間を割り当てるべきかを特定するのに苦労するため、それをサポートしないことに決めるかもしれません。多くの場合、プロジェクトの時間はこれを修正する適切な時間ではありません。その後、人々は締め切りを追いかけます(ただし、プロジェクトの時間が唯一の機会である場合もあります)。早い段階でアイデアを紹介してください。同僚の懸念に耳を傾け、それらを克服するための支援を提供します。

コンテキスト内の設計プロセスを理解する

プロジェクトの費用は誰が負担しますか?特定のアイデアから利益を得るのは誰ですか?設計、実行、運用、段階的廃止の間に影響を受けるのは誰ですか?あなたのアイデアが採用された場合、プロジェクトプログラムまたは予算(クライアントおよび/または関係する分野)に影響はありますか?特別なリソースが必要ですか?誰かが時代遅れになりますか?

あなたの1つのアイデアと、あなたのセールスマンシップを改善するように言い続けているこの1人の同僚に固執しないでください。

この特定のアイデアが今日も飛ばない場合は、今のところそのままにして、次のアイデアを待ちますが、頭の後ろでアイデアを保持し、時間が来たら再び言及します。

この1人のキーパーソンを納得させられない場合は、別のキーパーソンを見つけるか、別のキーパーソンを待ちます。それまでの間、「セールスマンシップ」の意味、良い例があるか、あなたに期待していたこと、メンターになれるか、自分でメンターできるかを尋ね続けてください。これらの質問への回答は、彼らの動機と考え方を理解するのにも役立つかもしれません。


1

土木工学の分野では、自分のアイデアを「売る」ことについてコメントしたことがないと思います。私の分野では、すべてのレベルの人々が技術的な提案を行うことができ、良いものは実装されます。

ただし、社内の土木工学チーム内で行われる「販売」はあまり多くありません。通常、解決すべき問題があり、それを議論する会議があり、その会議から行動が出ます。あなたの分野では、あなたはより製造/生産工学に近いので、良いアイデアだけがプロトタイプ化されるという印象を受けますか?私は市民で同等のものを見つけることができるとは思わない。


1

エンジニアリングキャリアが進化すると、ソフトスキルを開発することが重要になります。優れたコミュニケーションスキルは、ピアがかつての観点を受け入れるよう説得するのに役立ちます。

エンジニアリング設計チームのメンバーにアピールする広範なエンジニアリング分析データを含むプレゼンテーションは、製造または運用エンジニアリングチームのメンバーにアピールするとは限りません。そのような場合、エンジニアリング分析データをトーンダウンし、製造または運用エンジニアリング部門の利点を強調することをお勧めします。

エンジニアリングのキャリアが発展すると、マーケティング、会計、製造、運用などの他の部門に対するエンジニアリングの影響を理解することは有益です。他の部門のメンバーと良好な関係を築くことは、プロセスが複雑な技術情報を伝達するのに役立ちます。これらの内部部門は内部クライアントであり、外部クライアントと同じかそれ以上のサーバーである必要があります。

米国で確立された評判の良い企業は、ソフトスキルの重要性を認識しています。これらの企業には、従業員のためにソフトスキルと優れたコミュニケーションスキルを開発するプログラムがあります。マイヤーズやブリッグスなどのパーソナリティテストは、個人のパーソナリティ特性を判断するのに役立ち、注意が必要と思われる分野を開発するためのトレーニングプログラムです。

最後に、「はい:同意せずに契約を交渉する」「友人が影響力のある人々を獲得する方法」は、述べられた質問の懸念に対処するのに役立つ良い本ではありません

参照:

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.