大規模な会議で優れたデザインをいかに効果的に「販売」するか

私は何度も悲しい悲劇を目の当たりにしました。発生することは次のとおりです。

1. 新しいプロジェクトのチーム設計レビュー。
2. かなりの数の穴があるシンプルなデザインが見えます。
3. 何気なく穴とそれらを回避する方法に言及します。
4. 警告は「実生活では決して起こらない」などのコメントでは無視されます
5. 最終的に「決して起こらない」ことが起こる
6. 壊れたプロジェクトの緊急チーム設計レビュー。

だから私は何をしますか？「私はあなたにそう言った」という態度を取り除いても、友人を獲得し、人々に影響を与えるつもりはありません。とにかく、時が経つとステップ3のコメントが忘れられることがあります。私は間違いなく、世界に落とし穴を思い出させる迷惑な害虫になりたくありません。タイタニック号がヨーロッパに向かっているのをよく見ます。

悪いデザインが前進するのを見るとイライラします。また、現在のパスの保留中の危険性を他の人に納得させることができないように思われることもイライラします。私は、チーム会議で最悪のことをします。そこでは、誰もが異なる用語を理解する異なる方法を持っています。また、エゴは理性と思考に勝つ傾向があります。グループの人々にいくつかの新しい複雑なアイデアを使うよう説得するための良い戦術を探しています。

可能であれば、プロジェクトに大幅な時間を追加しない修正を提案してください。現時点で行われていない場合は、後で再作業するのがはるかに苦痛になることを強調してください。完全に新しい方向性が優れているとチームに納得させようとすると、おそらくプロジェクトが遅れるなどの理由で難しくなります。

会議で人々を防衛モードにしないでください。彼らはあなたと勝者になるために戦うだけです。あなたは彼らが地球が丸いことに同意することはありません。これは通常の政治です（例：FoxNewsの人）

他の開発者から敬意を払うことは本当に助けになります。あなたがチームの新しい人なら、あなたはSOLだと思います。すぐに解雇されない場合は、チームの担当者を増やして、実際にレベルを上げてください。もちろん、あなたが常に悲観的な量のものであるならば、あなたは単に「ネガティブ」な男としてラベル付けされるでしょう。

シンプルなもの（つまり、スケジュールに影響を与えないもの）については、作業を最適な方法で行ってください。すぐに出力に努力を注ぐと（テストケースの作成や、いくつかの単純な（しかしクールな）機能の取得など）、最終的に他の人はあなたのコードが確実に機能し、時間のテストに耐えることに気付くでしょう。コードを使って巧妙なトリックを見せ始めたら、みんなの前で二度あなたを撃ち殺すと思うでしょう。

最後に、「私はあなたにそう言った」ルーチンを行いたくないが、実際にあなたが正しいとわかったときに上司/技術リーダーにヒントを落としてみてください。たぶん、あなたの古いコメントで古い電子メールを再送します。これが「新しい」問題の解決に役立つかどうかを尋ねます。あなたがこれをしなければ、彼らはあなたが初めてそれを持ち出した人であることさえ覚えていません。最終的に彼らは、あなたが単に会議で見せびらかしたいだけではないというヒントを得るでしょう。次回、彼らはあなたを吹き飛ばすことについて二度考えます。特に、「古い」デザインが現在の壊れたデザインを置き換えていることを回避する場合。

まれなユースケースで問題が発生すると思われるものだけでなく、何が機能するかを特定できる人物としての評判を確立してください。これらの潜在的な問題を見つけたら、後で対処する必要があるかもしれない脚注と考えてください。

人々は会衆に夢中になります。会議以外の重要人物に懸念事項を述べてください。彼らはこれをそれほど脅威ではないとみなし、彼らがデザインを守ることを考えるのではなく、あなたの議論を聞くのに時間がかかるかもしれません。また、有効なポイントがある理由を説明するのに時間がかかる場合がありますが、v1.0で対処することはできません。

キー！直属の上司のアジェンダが何であるかを完全に理解して会議に参加してください。たぶん彼らはこれをマイナーなプロジェクトと見なし、会議で最後に必要なことは、より重要な問題から時間を奪う否定論者です。あなたが彼らを助けるのを手伝ってくれるよう頼んでください。

それらに影響を与えたい場合は、設計会議の外でそれについて話します。そうでなければ、彼らはあなたが彼らから「得点」しようとしていると思うでしょう。多くの人は、「聴衆」との会議で本当の議論をしたくはありません。

この状況が、無知な上司を抱える一人の開発者とどう違うのかはわかりません。残念なことに、私は、差し迫った破滅の警告にもかかわらず、特定の方法でプロジェクトを構築し、それを出荷することを「確信」した回数を失いました。それはあなたが建物を作るだけでなく、有名なタイタニック号をすべて自分で氷山に航海することを可能にします。

あなたが説明したように、ビットがことわざのバケツに当たったとき、私の警告はずっと忘れられていました。時々（私にとっては幸運なことに）、プロジェクトに参加しなくなってから数か月以上経ってから、事態は悪化しました。残念ながら、これは私の後継者が私が狂っていなければならないと考えていました。

とにかく、「納得した」プログラマーのグループは、先のとがった髪のボスと同じくらい無知でありえます。これが発生すると、物事を修正する十分な時間があります。理性の単一の声を集合的な脳のおならで聞かせようとしないでください。あなたがそれを効果的に行うことができれば、あなたの場所は会議用ソフトウェアであり、机上のソフトウェアの後ろではありません。

アクションは言葉よりも雄弁であるため、次のことができます。

• 通常の状況で設計が失敗する理由を（テストシナリオで）示します。これはおそらく、あなたがプレゼンテーションをしている小さな会議になり、おそらくあなたが聞く必要があるすべてです。

• グループが「コーナーケース」に過ぎないと考えていたものに適切に対処する競合製品を表示します。たとえば、スプレッドシートプログラムの間違いをGoogleが予測する長さに驚かれることでしょう。

• 出荷予定の1週間前に一から書き直す必要がある最後のプロジェクトを繰り返します。

言い換えれば、最初のステップは、あなたが何をするにしても、個人または（はるかに）小さなグループに対処することです。あなたの懸念が本当に有効であるならば、私は彼らが開発に1週間か2週間よりよく受け取られると確信しています。ちょうど、あなたが述べたように、「私はあなたにそう言った」スタンスを避けてください。

可能であれば、会議前（または会議後）にデザインを確認し、プライベートでデザイナーに相談してください。すべての同僚の前で会議で人々を打ち倒すことは、あなたの提案について即座に防御的で閉ざされ、あなたが助けになっていると思っていても「トラブルメーカー」としての評判につながる可能性があります。

「批判」を提示するための良い（しかし、しばしば難しい）方法は、主要な質問をすることです。そうすれば、それは彼ら自身のアイデアに非常に似ているように思われ、彼らはそれを前進させる可能性が高くなります。繰り返しますが、これはプライベートな議論で最も効果的ですが、会議の状況ではより外交的で効果的な方法になります（注：会議で人々を説得するために議論や長い議論に入ることは避けてください。 「単純な30分を作った男よりも、それを手放し、会議後にデザイナーとチャットして、「よくわからないことを片付ける」方が良いかもしれません。ミーティングは私の朝を無駄にします」）

もう1つの方法は、提案を（外交的に）リードデザイナー（または関連するが小さな配布リスト）にメールで送信することです。それはあなたのアイデアを検討するのに役立つかもしれませんし、将来の「私があなたに言った」状況をサポートするための「ペーパートレイル」を提供するかもしれません無視されます。しかし、事態が悪化した場合、おそらくあなたは適切な会社で働いていないでしょう）

最後に、時々「間違っている」可能性があることに留意してください。あなたが話している人々はあなたよりも彼らのデザインをより明確に、またはより完全に理解しているかもしれず、彼らのアプローチに正当な理由があるかもしれませんパフォーマンスはまだ許容できると思っていたので、意図的な設計でしたが、開発コストは半分になります-コード品質の決定ではなく、ビジネスの決定でした。他の人のアイデアについて心を開いてみてください-時々、あなたにとって悪い考えであるように見えるものは、あなたが考慮していない理由のために良い考えかもしれません。

「決して起こらない」シナリオに出会ったとき、それらの「決して起こらない」アイテムを修正しなければならなかった過去のすべての時間を思い出させます。しかし、「私はあなたにそう言った」と出くわさないように注意する必要があります。過去の問題（およびそれらを修正するのにどれだけ費用がかかり、苦痛だったのか）を提起するのが最も効果的だと思います。決して起こりません」引用。

おそらくあなたの問題は、問題を回避する方法を何気なく言及していると言うことだと思います。おそらく、より多くの情報を入手し、これがシステムに対するリスクである理由をより詳細に示す必要があります。少し研究をする時間があった後、2回目の会議で主題を取り上げることを意味する場合があります。今やるのがいかに安いのか、後でやるのがどれほど高価なのかについて、ビジネスケースを構築します。

最善の策は、チームリーダーの地位に就くために働くことです。これらの機会を利用して、これが来るのを見たことがあり、回避できた可能性があることを指摘してください。現在のチームを売る必要はないはずです。

「穴に触れてください」の「カジュアル」が問題のようです。プロジェクトのリスクを分析するために、書き留めたプロセスを使用する（または存在しない場合は持ち込む）ようにしてください。通常、リスク分析会議の出力は、単純な2列の表です。リスクと、リスクを軽減するための合意された戦略は何ですか（「決して起こらないと思う」は許容可能な緩和です。重要なことは、現在の思考を記録することです当時の問題について）。問題がリスクとして記録されていることを確認してください。リスクは定期的に見直されるべきです。危機が実際に発生するずっと前に、かなりの数の人々があなたの視点に戻ってきて、リスクレビューが「起こる OMG」として機能する可能性があります; 長期的には、ペーパートレイルは、「見て、ここに制度上の問題があるようだ」と言って、設計または変更されたものに対する態度を得るための有用な証拠です。

アイデアを実装する方法

最初の会議では、問題を課題と呼びます。問題を解決し、課題を克服します。課題は良いことですが、問題はそうではありません。

ゆっくりと開始し、一度に1つのチャレンジでこの手法を使用します。次回、上司にアイデアの1つを採用してほしい場合は、次のことを行います。

• 3つの類似した異なるアプローチを開発する
• 上司に何か助けが必要だと伝える
• 3つの方法のどれが問題を解決するための最良の行動方針であるかわからないことを説明する
• 3つのうちの1つを選択するために彼/彼女に依頼

1.これは非常に強力です。あなたがしていることは、最後ではなく選択肢を提供することです。アルティメイタムは、彼らの考えではなく、選択肢が1つしかないため、撃ち落とされないことがよくあります。

2.ここでは、言葉の使用が非常に重要です。「私はあなたの助けが必要です」。

3.ボスに「A」、「B」、または「C」を選択させます。実際、ボスが「A」、「B」、「C」からセクションを引き出してオプション「D」を作成できるようにします。あなたがしていることは、あなたの上司に選択させることです。

この時点で、彼がどのオプションを選択するかを気にする必要はありません。すべてのアイデアだからです。彼はあなたが決定を自分のものにするので、彼は実際に問題を解決していると思うでしょう。

持っているProof of Conceptあなたのアイデアのは実装されています。あなたのチームに現在の問題を解決し、解決する何かを見せれば、彼らはそれを好むでしょう。