web-dev-qa-db-ja.com

難解で非技術系の管理者を寄せ付けず、それでも優れた仕事を提供するにはどうすればよいでしょうか。

この質問は主観的(警告が表示された)と見なされてクローズされる可能性がありますが、これについては良いアドバイス/経験が必要なので、リスクを冒します。

Joel Spolsky が設立し、CEOを務める会社 Fog Creek Software'About' ページで以下を読みます。

2000年にさかのぼる、フォグクリークの創設者であるジョエルスポルスキーとマイケルプライアーは、プログラマーがきちんとした労働条件のある職場を見つけるのに苦労しており、技術者ではない非技術系マネージャーが悩むことなく、素晴らしい仕事をする機会を得ました。道。すべてのハイテク企業は、優れたプログラマーを望んでいると主張しましたが、彼らはお金を口に使うことはしませんでした。

それは、物理的な環境から始まりました(何十ものキュービクルが騒々しく暗い部屋に押し込まれ、営業担当者が電話で叫んでいるため、開発者が集中できなくなった)。しかし、それはそれよりもはるかに深かった。変更を恐れたマネージャーは、新しいアイデアを奇妙なウイルスとして扱い、隔離しました。ナポレオンの複雑なジュニアマネージャーは、物事は正確に彼らのやり方で行われるか、あなたが解雇されると主張しました。コーポレートファニチャーポリスは、キュービクルで映画のポスターを誰かがテープで録画したときに苦痛を感じました。解体は非常に蔓延していたので、たとえアイデアが良かったとしても、それらから製品を作ることは不可能だったでしょう。経験の浅いマネージャーは、ヒットアンドラン管理を実践し、フィアットの大惨事の結果を見にこだわることなく、物事を正確にどのように行うかという厳しい命令を出しました。

そして最悪の場合、担当のMBAタイプは、コーディングは基本的にはファンシーなタイプのタイピングであるサポート機能であると考えていました。

今日のほとんどの大規模ソフトウェア会社についての率直な真実残念ながらすべての開発者がJoel Spolskyと同じようにgutsy(またはlucky)であるとは限りません!だから私の質問は:

そのようなマネージャーと連携し、それらを寄せ付けずに素晴らしい仕事を提供するための最良の方法はありますか?

11
Curious

開発者はビジネスの問題に無知であると認識されていますが、テクニカルマネージャーが開発者を軽視することはあまりありません。開発者はビジネスケースを学び、ビジネス用語の改善を推進または提案する必要があります。開発者とマネージャが同じ言語を話すようになると、物事はより簡単になります。

これは態度の変化と同じくらいです。はい、管理には常にahem頑固な個人がいます。しかし、「私たちと彼ら」の態度を作ることは、これを両側から補強します。

19
akton

オプション1:自分でマネージャーになり、正しいことを行う方法を全員に示します。多くのプログラマーが考えるほど簡単ではないことがわかるでしょう。

オプション2:離れて、より働きやすい場所を見つける。私は、この問題を少なくとも知っており、それを解決しようとする大小の会社がたくさんあると思います。成功の度合いはさまざまです。

10
Euphoric

あなたの仕事は素晴らしい仕事を提供することです。管理はサポート機能であり、その目的はあなたが素晴らしい仕事を提供することを可能にすることです-あなたとクライアントと利害関係者と政治と販売の間のバッファとして機能しますなど、障害を取り除きます 毎日のがらくたを抽象化します これにより、最善を尽くすことができなくなります。

memory manager について考えてください。 あなたとあなたのプログラムを(== --- ==)コマンドするのはボスではなく、それは解放する )コンピュータで行われている他のすべてのことを考慮して、プログラムに不可欠なことに集中できるようにします。それがJoelが書いていることであり、それがマネージャideallyが機能する方法です。

すべてのマネージャーが完璧というわけではなく、あなたも完璧ではありません。何もありません。物事が完全にクレイジーでない限り、それを吸い上げて最善を尽くし、不快なことを無視して、yourの作業に集中してください。あなたが素晴らしい仕事を提供する場合、マネージャーは最終的にあなたをより尊重し信頼し、あなたがあなたのやり方でもっと仕事をするようにします、あなたがあなたを示したらできる素晴らしい仕事を提供します。

70%完璧な組織で働くことは問題ありません。あなたの状況が本当に悪い場合は、雇用主を切り替えます。しかし、早くあきらめないでください。信頼を獲得するプロセス-マネージャーと能力の組織を説得する-には数年かかる場合があります。

4
Joonas Pulakka

それらを寄せ付けないで、それでも素晴らしい仕事を提供する

頑張ってください。私は自分の会社を設立し、それが本当に私が提案できるすべてです。

うまくいけば、このような状況では、エンジニアは団結し、実際の問題が発生した場合は、技術プロジェクトマネージャー、技術製品マネージャー、アーキテクト、または独自の開発マネージャーのいずれかがあなたの仕事の範囲を理解し、非技術者をあなたのところから遠ざけることができます仕方。

しかし、常にそのように機能するとは限りません。私は巨大なハイテク企業で働いていましたが、マネージャーはおそらくテクニカルで、開発者が毎日4人のプロジェクトマネージャーとのノンストップミーティングについて不平を言ったとき、彼の対応は-OKだったので、プロジェクトマネージャーとのミーティングを増やしたいと思っています。

過去10年間、実際の才能のような技術的な「才能」は、ソフトウェア組織のビジネス側によって信じられないほど疎外されてきたと感じており、これは私たちにとってキャリア上の問題です。

低賃金のビジネスパーソンで高給の開発者を管理することは、ライオンの飼いならされた学校にあなたの子供姉妹を送るようなものです、それは単に働きません。

しかし、私が間違いなく反対する解決策の1つは嘘です。本当に優れた開発者が、技術的に根拠のないストーリーでマネージャーを退去させようとするのを見てきました。これを行わないでください。もしそうするなら、あなたはあなたの魂を売りました、そしてそれは安っぽい仕事をするより悪いです。

2
deleted_user