-1

私がかつて働いていた場所では、問題に対する彼らの典型的な反応は、システムを完全に使用していないことをハードウェアまたはユーザーのせいにすることでした。私は、その仕事の前に別の方法で証明できるまでは自分のせいだという哲学を採用していました（これまでのところ、100回のうち少なくとも99回は正しいです）.

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

タイムアウトのない数か月後、マネージャーはタイムアウトを修正したと自慢しました (「見て、タイムアウトはありません!」)。岩をつかんで「ほら、トラじゃない！」と言うのをためらわなければなりませんでした。しかし、私は彼がどのようにしてそれらが発生することを知っていたのかを尋ねましたが、私には応答がありませんでした. タイムアウトは、数か月後に戻ってきました（さらに多くの数で）。

私は状況をどのように処理したかにかなり満足していますが、あなたが知っている（または非常に確信している）ソリューションが間違っていて、数千ドルを無駄にする可能性が高い解決策を上司/同僚に実装させた場合、SOの群衆がどのように反応したか興味がありますか？

4

5 に答える 5

4

それらを許可しますが、同時に本当の原因を探し続けます。

それが私がその種の考えに逆らうのを妨げるならば、数千ドルはよく使われるお金です（それは無駄です）。

于 2009-01-30T21:08:43.157 に答える
3

さて、問題が上級管理職である場合、私はあなたがしたようにやります-あなたの苦情を提出し、そして指示に従ってください。彼らが正しかったことが判明した場合（それは時々起こります）、あなたはあなたの不安にもかかわらず良い従業員のように見えます。あなたが正しかったことが判明した場合、あなたが彼らの順番を許可したことを考えると、彼らはあなたの話をもっと喜んで聞くかもしれません。

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

同僚の場合は、問題をレベルアップし、上司に相談して、問題に取り組む方法についてアドバイスを求めてください。あなたの視点と同僚の視点の両方に公平になり、与えられたアドバイスに従ってください。

于 2009-01-30T21:07:27.200 に答える
2

マネージャーを任せた方が良い場合もあります。彼のプレッシャーと責任について考えると、彼は「何もしない」のではなく、何かをしているという印象を与えなければなりませんでした。十分な時間が経過した後、タイムアウトを停止する必要がある外部の関係者にとって、「調査」は何も解決しません。

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

これにより、彼は前向きな何かを得ることができ、最終的に成功するあなたが望む解決策を達成しながら、チェーンを生産的に見せることができます.

長期的には、あなたの技術的な決定を暗黙のうちに信頼し、率直に話すことができ、何が起こっているかを知っている方法で彼が政治をナビゲートするのを助けるのに役立つ人のために働くべきです. あなたのマネージャーがその人ではない場合は、移動してください。

于 2009-01-30T21:52:29.370 に答える
1

これは大きな問題ですか？あなたが報酬を得るためにあなたの会社が溶剤のままであって欲しいということ以外にあなたの会社のお金を節約することはあなたの仕事ではありません。

マネージャーが1人だけの場合、遅かれ早かれ彼は除かれます。あなたの企業文化全体がこのようなものであれば、次に進む時期かもしれません。

それまでの間、上司の視点からこれを確認できるかどうかを確認してください。

于 2009-01-30T21:07:59.133 に答える
1

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

多くの人 (ときどき私自身) に共通する問題の 1 つは、問題を診断しようとするときに慌ててしまうことです。あなたがそれを大雑把に推測しているなら、そして現代のコンピューターに特化していれば、あなたが正しい可能性はごくわずかです. この種の問題にそのような態度でアプローチすることは、通常、決して修正できないことを意味します。

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

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

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

ポール。

于 2009-01-30T21:42:11.967 に答える