優れたプロジェクトリーダーまたは上司に立ち向かうとき

私たちのプロジェクトヘッドは、天才的なソフトウェアアーキテクトであり、一般的には穏やかで思いやりのある人であり、自然のオタクであり、声で繊細です。しかし、時々、私たち（私のチームメイトと私）は意見が異なります-特にソフトウェアアーキテクチャの問題、システム設計の問題、UIの問題など、リーダーと。

意見の違いをいつ、どのように（もしあれば）表現すべきですか？

あなたはあなたの上司が間違っていると思うと仮定します。3つのオプションがあります

• 彼が言うことをして、あなたは何か愚かなことをするとイライラしてしまう-あまり良くない長期
• 彼はバカだと言ってください-彼はそれを無視するか、コミュニケーションの問題が発生します-何も得られないか、あなたを傷つけます。
• 彼が提案するアイデアに特定の懸念があることを伝え、それらの懸念を説明します。優秀な上司が自分の立場を説明すると、ビジネスに適した決定が下せるようになります。彼のアイデアがあなたのアイデアよりも優れていること、そして非常に重要なものを無視していることがわかるでしょう。

常に結果を考えてください。ほとんどの場合、あなたは正しいことのために正しいことをしたくない、あなたはちょうど良い仕事をしなければなりません。3番目のオプションは、その実現に役立ちます。

彼を同じように扱いなさい-反対を表明するとき優しくそして敬意を表して。

プロフェッショナルであるということは、同僚や上司に敬意を払うことを意味しますが、それが反対することができないという意味ではありません。

私のチームが私の方向性について疑問や反対意見を持っているとき、私はそれを自分自身とチームメンバーの両方にとって教育の機会と考えています。

これは、古い攻撃的または受動的な誤fallの例ではありませんか？

古典的な3番目のオプションは、積極的であり、建設的な批判と丁寧な意見の不一致を許容します。

同様に重要- 建設的な批判を受け入れ（必ずしもそれに同意する必要はありません）、合理的な意見の不一致を受け入れます（誰が正しいか、誰が間違っているかということに夢中になりません）。

http://en.wikipedia.org/wiki/Assertiveness

そして、一日の終わりには、ある種の受動性（上司に任せる）が常に必要になります。彼は決定に対して究極の責任を負います。能力、権限、責任は同じものではありませんが、少なくとも一緒にすべきです。

ところで-ロバートボルトンによる「People Skills」は、このようなもの-リスニングスキル、自己主張などについての良い（そしてかなり安い）本です。

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

あなたは彼を尊敬しているようで、彼は賢い人のように見えるので、次の方法で彼に尋ねてみてはどうですか。

「メソッド/方法/アーキテクチャはx問題をどのように処理しますか？」そうでない場合は、次のように発声します。「この方法でxの問題を処理する方法はありますか？」

このようにして、彼がすでに「x問題」について考えているかどうか、そして何かを学んでいるかどうかを知ることができます。あるいは、もし彼がそれについて考えていないのであれば、あなたのソリューションを使うか、別のソリューションを考えます（おそらく一緒に解決するでしょう）

もっと具体的な例を思いつくことができればいいのですが、あなたはそのアイデアを得ることができると思います。

特に上司がプログラマーまたはそのようなものでない場合は、どこにでも最初に行くとは思いません。

そして、彼のやり方が悪いと言う必要はありませんが、それが特定の状況をどのように処理するかを尋ねることによって、彼は問題を実現するか、なぜそれが問題でないのかをあなたに伝えることができます。

これがお役に立てば幸いです。

CONFRONTという言葉を使用すると、正しい考え方で問題に近づいていないことがわかります。

それは対立ではありません。敵対的ではありません。好戦的でも怒りでもありません。さまざまなアプローチとコストと利点についての議論です。

6発の銃で燃え上がってはいけません。考えたことを彼に伝えてください。「もし私たちがこのようにするとしたら？」あなたは彼を納得させるかもしれません。

そして、もしあなたが知らない場合、そして時にはあなたもそうしない場合、彼はあなたが知らないこと、予算、スケジュール、要件、その他の優先事項などをよく知っているかもしれないことを覚えておいてください。彼はあなたに同意しないからといって、必ずしもばかではありません。

決定や設計/ソフトウェアアーキテクチャを疑うのは間違いではありません。最初の仕事を始めたばかりの場合を除き、その場合、99％が間違っていると思われますが、全体像の一部が欠けています。

あなた（および/またはチーム）の意見が異なる場合は、プロジェクトリーダーに話し合う時間があるかどうかを尋ねるか、または小規模な会議（15〜30分）を計画することもできます。敬意を表してあなた自身の意見を述べ、彼がそうでなければ彼が決定した理由を聞いてください。あなたが彼をどのように説明したかを見ると、彼は問題についての彼の洞察を議論し、共有して喜んでいるでしょう。彼は「私がそう言ったから」とは言わないでしょう（そのような人々は悲しいことに存在します）。その場合、仕事を続けたい場合は自分の意見を無視するか、不幸になるのでそれを発散して別の仕事に出ます。

良い議論はいくつかの方法で終わる可能性があります。

• プロジェクトリーダーは、問題を解決するためのより良い方法としてあなたのソリューションを受け入れます（そして、彼は新しい技術、パターンを学んだかもしれません...まだあまり経験がありませんでした）。
• あなたとチームは、写真の大部分を見ることができます。または、なぜこのようにしてそれを行うべきなのかについて、良い説明を得ることができます。新しいことを学び、最初の解決策が正しいものであることを理解するか、新しい情報でそれを改善する方法を見つけることさえあります（ただし、ある時点で同意する必要があります）。
• 議論は役に立たず、あなたはまだ同意しません。それを吸い上げて、彼のソリューションを実装します（彼はより多くの経験を持っている可能性が高いため）、または去ります。

とにかく、あなたはそれを学ぶ機会とみなすべきであり、文明的で敬意を払う限り、これらの議論で素晴らしい経験をするでしょう。

持っていくだけ！

私ができる最も市民的で包丁的なやり方で、私は通常「この側面に関心があります。この潜在的な問題についてあなたはどう思いますか？」と言います。

私を教育するために彼のコートにボールを入れます。

成熟した開発者とマネージャーの一番の兆候は、彼らが間違っていることを認めることができるということです。まず、上司に自分が間違っていると認めることを完全に喜んで受け入れていることを示し、上司に同じ礼儀を期待していることを明確にします。

あなたが良い上司を持っている（そしてあなたがそう言うと言う）場合、これは一般的に全く問題になりません！建設的な議論ができ、すべての人にとって最良の解決策が見つかるでしょう。

注意する必要があることの1つは、ほとんどの場合、提案された設計を疑う実際の技術的で十分に根拠のある理由があることを確認することです。「それは間違っていると感じる」は一般に十分ではなく、建設的な議論には寄与しません。これがあまりにも頻繁に発生する場合、上司は「議論」（これは事実ではないので実際には議論ではない）を短絡させて「申し訳ありませんが、あなたができるまで私が提案したことを行います」他のアイデアが明らかに優れている理由を事実で示してください。」

だからこそ、あなたの上司は上司です-開発者が難しいと感じるかもしれない決定を下すために。

私の意見では、私は一般的に上司とどのように振る舞いますか：

常にあなたの意見を与え、話題が熱いながらできるだけ早くそれを行います。勇気を集めて決定がすでに決まっているときに後で行うよりも、新しい問題やプロジェクトをスクラムしているときに理想的です。

自分の意見、懸念、問題をオープンに提案し、そのような方法で行わなければならないことを課すのではなく、提案または懸念としてそれらが遭遇することを確認する必要があります。

それを習慣にして、より良いコミュニケーター、チームメンバー、そしてより良いチームになってください。良いチームは、ネガティブなこととポジティブなことについて率直に話します。優れたチームリーダーは、チームの声に耳を傾け、提供された情報を考慮して決定を下します。

がんばろう。

彼があなたが説明するのと同じくらい良い建築家であるなら、あなたの懸念の論理的で特定の理由で教育された方法で彼に近づいてください。

時間/リソースに余裕がある場合は、自分が正しいことを証明するシナリオのテストを試みてください。自分の側にいくつかのデータがあることは大きなプラスになります。

彼と話したら、彼は次のことしかできません。

a）あなたに同意します：問題は解決しました！

b）それらを拒否し、その理由を説明してください。

c）理由なくそれらを拒否する：彼が不合理であり、あなたが完全に確信している場合、責任のあるプロジェクトに懸念を表明してください。この場合、あなたは本当に冷たいデータを必要とし、可能であれば、チームの他のメンバーのサポート。それは建築家をあまり幸せにしませんが、倫理的なことです（あなたが建物を設計していて、構造に欠陥を見たと想像してください...）

私の質問は、意見の違いをいつ、どのように（どうして）表現するかです。

絶対にイエスが答えです。乱気流やそれによる仕事の喪失の可能性が非常に大きい、制御不能なまれな状況がない限り、意見が異なる場合は他の人に立ち向かわなければなりません。

ここでの本当の鍵は、いつ、どのようにです。

最初の「いつ」：すべての環境は異なりますが、一部の場所では毎週の会議またはオープン/ラウンドテーブルディスカッションが行われ、特定のトピックを取り上げることが適切なアリーナです。あなたがしたくない主なことは、あなたと他の1つまたは2つだけの間にある個人的なデザインの議論を軽視したり公開したりするようにすることです。あなたが挑戦している人々は、挑戦されることに感謝せず、たぶん人前で恥ずかしいことさえするでしょう。これらの状況では、あなたの考えを詳述するために、問題の人と1対1のミーティングをスケジュールしてみてください。

2番目の「方法」：高齢者に行く場合は、考えを裏付けるためにすべてのアヒルが並んでいることを確認してください。「すべてのWebフォームを停止する必要があり、MVCを行う必要があります！」「なぜ？」「それはみんながやっていることであり、それはすべての雑誌に載っています」とあなたは言うでしょう、それは遠くまで行かないでしょう。何度も議論する準備をして、アーキテクチャ、コーディング、設計、ベストプラクティスなどに関する考えを正当化するように求められます。同様に助けます。ここで重要なことは、自我の戦いに参加したり、感情が浮かんだりしないようにすることです。

最終的に、堅実で正当な論理的な提案がある場合は、それらを考慮する必要があります。ただし、この世界には自分以外の人の話を聞きたくない不合理な人がいることにも注意してください。願わくば、あなたがこのタイプの性格で追い詰められないことを願っています。

がんばろう！

間違いを犯さずに質問されることなく、どのようにして素晴らしいソフトウェアアーキテクトになることができるのかわかりません。彼が以前にこのような状況にあったと仮定するのは安全だと思います。

賢く、成熟した、プロフェッショナルな人々は、より良いアイデアの魅力に長く抵抗することはできません。たとえ彼が彼のアイデアに疑問を抱くことによって最初に動揺していても、最終的に彼はやって来なければならず、あなたはそれに対する敬意を得るでしょう。彼が成熟しておらず、専門家でもない場合、あなたはより大きな問題を抱えており、おそらくこれはそれに光を当てるでしょう。

彼がプロの建築家である場合、彼はセカンドオピニオンを尊重し、受け入れます。ただし、いずれの場合でも、事実/専門知識に基づいて代替案を十分に準備し、適切に提示する必要があります。また、アーキテクチャに関して、そのような問題には基本的に2つの異なる可能性があることに留意してください。

1. 1つのアプローチ/デザインは、数学2 + 2 = 4のように5つではなく、単純に正しいか間違っている可能性があります。間違っている場合は、事実に基づく異議に基づいて、適切な解決策をできるだけ早く考え出す必要があります。
2. システム設計のほとんどのトピックは、排他的ではない可能なアプローチです。経験、フレーバー、バイアス、全体像などに応じて選択する他の選択肢もあります。開発者が意見を述べて共有することが推奨される場合、より良いアプローチを監督しないように、通常プレゼンテーションとディスカッションがあります。しかし、アジャイルプログラミングでは、これらの段階が明確に定義されているため、議論する期間と実装する期間があることに留意してください。