非論理的なマネージャーへの対処 [終了]

Question

私が以前働いていた職場では、問題が発生したときの典型的な対応は、システムを完璧に使用できていないハードウェアまたはユーザーのせいにすることでした。私はその仕事に就く前に、そうでないと証明できるまでは自分のせいだという哲学を採用していました（そしてこれまでのところ、少なくとも100回中99回は正しいです）。

私が在籍していたときの最後の「解決できない」問題の 1 つは、大量のデータベース タイムアウトでした。何か月も研究を続けましたが、まだ理論だけはありましたが、どれも証明できませんでした。私の開発者の 1 人は、ネットワーク (すべてのルーター、スイッチ、アクセス ポイント) を交換することを断固として提案しましたが、ネットワークが原因であるという証拠は提示できませんでした。しかし、私のマネージャー (開発/IT 経験なし) によれば、それが「明らかに原因」だったので、彼が問題を引き継ぎました。1 つの注意点とフォグ クリークのプラグイン: 彼は、FogBugz を介したエラー報告が完全に機能し、残りのデータと同じ SQL Server に報告されたという事実を説明できませんでした。

数か月後、タイムアウトがなくなり、私のマネージャーはタイムアウトを修正したと自慢しました（「見てください、タイムアウトはありません！」）。私は岩をつかんで「見て、トラはありません！」と言って我慢しなければなりませんでした。しかし、私は彼が彼らが私が反応しなかったことをどのように知っていたかを尋ねました。数か月後にタイムアウトが再び発生しました (さらに多くの回数が発生しました)。

私は自分がこの状況にどう対処したかにはかなり満足しているが、間違っているとわかっていて（または確信を持っている）解決策を上司や同僚に実装させ、数千ドルを無駄にする可能性が高い場合、SOの群衆はどう反応するだろうかと興味がある。

Answer 1

そのままにしておきますが、同時に本当の原因を探し続けてください。

数千ドルは、そのような考え方（無駄です）に反することを防ぐのであれば、十分に使えるお金です。

Answer 2

そうですね、問題が上層部にあるのであれば、私もあなたと同じように苦情を申し立て、指示に従うでしょう。彼らが正しかったことが判明した場合（それは時々起こります）、あなたは不安にもかかわらず、優秀な従業員のように見えます。あなたが正しかったことが判明した場合、あなたが彼らに順番を許可したことを考えると、彼らはあなたの話をもっと喜んで聞くかもしれません。

もちろん、これは楽観的です。

同僚の場合は、問題を一つ上のレベルに引き上げ、上司に相談して、その問題にどのようにアプローチするかアドバイスを求めてください。自分の視点と同僚の視点の両方に対して公平であり、与えられたアドバイスに従ってください。

Answer 3

場合によっては、マネージャーを放っておくことが最善の場合もあります。彼のプレッシャーと責任を考えると、彼は「何もしていない」のではなく、何かをしているように見られなければなりませんでした。十分な時間が経過すると、「調査」はタイムアウトで停止する必要がある外部の関係者にとっては何も起こらなくなります。

行動を起こすことで、研究を続ける機会が生まれます。コツは、あなたの解決策を彼の文脈に当てはめる方法を見つけることです。これが私たちに今できること、そしてこれからもできることです。たとえば、「予防措置としてネットワーク機器を交換し、バージョン管理ログを調べてその可能性を排除できます。」

これにより、彼は積極的な何かを得ることができ、最終的に成功するであろうあなたが望むソリューションを達成しながら、チェーン全体で生産性を発揮できるようになります。

長期的には、あなたの技術的な決定を暗黙のうちに信頼し、率直に話すことができ、何が起こっているのかをお互いに知っている方法で政治をうまく乗り切るのを手助けしてくれる人の下で働くことを探すべきです。あなたのマネージャーがそのような人ではない場合は、移動してください。

Answer 4

これは大きな問題ですか?会社の資金を節約するのはあなたの仕事ではありませんが、会社が支払い能力を維持して給料をもらえるようにしたいということ以外にはありません。

たった 1 人のマネージャーであれば、遅かれ早かれ淘汰されるでしょう。会社全体がこのような文化であれば、次へ進む時期が来ているかもしれません。

それまでの間、これが表示されるかどうかを確認してください あなたのマネージャーの視点。

Answer 5

あなたのマネージャーの意図は良いことだと思います。私がもっと難しいと思うのは、迷惑をかけたくない人々です。そのエネルギーを役に立てるように使う方法を見つけるのが最善です。

多くの人 (私自身も) に共通する問題の 1 つは、問題を診断しようとするとバタバタしてしまうことです。もしあなたが乱暴に推測しているとしたら、特に現代のコンピュータでは、あなたが正しい可能性はごくわずかしかありません。この種の問題にそのような態度で取り組むと、一般的には決して解決できないことを意味します。

複雑なデバッグを処理する最良の方法は、分割統治することです。この場合、まずテストを考え出し、それを実装します。そのテストは期待どおりに機能しましたか?テストのどこにいるかに応じて、問題に近づいたり遠ざかったりします。重要なのは、すべてのテストが何らかの具体的な (客観的な) 動作をもたらす必要があるということです。結果があいまいであれば、テストは役に立ちません。

システムの一部で切断が発生しているが、他の部分では切断されていない場合は、大量の貴重な情報が得られます (ネットワークではないこともわかります)。部品の違いは何ですか？どこかに着くまで下り始めてください...

マネージャーに話を戻します。この種の性格上の問題に遭遇したときは、そのエネルギーをより有益なものに向けるように努めます。願望はそこにありますが、それを形にするためには助けが必要なだけです。テストが具体的であることを確認するようマネージャーを説得できれば、十分なテストを行えば、バグを正しく推測するのに十分な情報が得られるでしょう。確かに、より一貫したアプローチの方が早いかもしれませんが、一部の無料支援を拒否する理由はありません。私は一般的に、どのプロジェクトでも誰にとっても何らかの有益な役割があると感じています。それはすべて、彼らの努力を活用できるようにすることです...

ポール。