私はマネージャーです。仕事関係とプログラマーとのコミュニケーションを改善するにはどうすればよいですか？[閉まっている]

最初に少しの背景。私は中規模企業のプロジェクトマネージャーです。私はCS専攻として始め、プログラミングに少し触れましたが、数か月後にそれが自分の道ではないことを知ったので、経営陣に切り替えました。それは良い決断であることがわかりました。卒業後、私はさまざまな企業でソフトウェア管理に携わりました（5年間）。

最近、非常につらいプロジェクトがありました。それは最悪の最悪であり、私たちの側と顧客側の両方で多くの間違いがあり、損失なしでそれをほとんど終わらせませんでした。それは多くの苛立たしい状況をもたらし、そのうちの1つは、私たち（経営陣）との口論により、私たちの上級開発者の1人が会社を辞めるところまでエスカレートしました。これは私にとって赤い旗でした：私はひどく間違ったことをしました。（記録については、議論はいくつかの誤った時間推定に関するものでした）

私は多くの場所で答えを探しましたが、友人がこのサイトを教えてくれました。ここには、管理に対する不満について多くの質問があります。一般的な悪い経験は、「​​スーツを着た男」に対する一般的な不本意につながることを理解できます。

私はスーツを着たあの男です。それはそのようには見えないかもしれませんが、私が望むのは成功したプロジェクトであり、限られたリソースで苦痛な決断を下します。それが私の仕事です。前述の上級開発者が不満を述べたものの1つは、作業機器でした。率直に言って、私が持っていたコンピューターが作業に適していないことは知りませんでした。この後、私は多くのプログラマーに尋ねましたが、一般的なコンセンサスは、より良いマシンが必要だということでした。それ以来それを修正しましたが、明らかに私とプログラマーの間に大きなコミュニケーションのギャップがありました。最も優秀な開発者の中には、最も内気で静かな人がいます。私はそれを知っています、そして、それはインタビューの間、決して問題ではありませんでした。人々は異なり、さまざまな分野で強みを持っています。

パワー不足のPCの場合は、コミュニケーションの問題があると私を考えさせた多くの事例の1つにすぎません。脅迫や繰り返しをせずにプログラマとのコミュニケーションを改善するにはどうすればよいですか？

私が望んでいるのは、人々が良いことについて不平を言わないことです。あなたの職場と愛を愛（あるいは、少なくとも場合は好き :)）あなたのマネージャー、それらについて教えてください。彼らは何をしているのですか？同様に、あなたがそれを嫌うなら、その理由を詳細に説明してください。私はそれが私の問題だと思うので、コミュニケーションの改善についての答えを探していますが、私は間違っているかもしれません。

うわー！質問してくれてありがとう。技術的には、あなたと同じように、私は管理者であると思います。コードを書くよりもチームのコミュニケーションと指導に多くの時間を費やしているからです。しかし、管理の範囲の両端からの私の見解です。私が開発者であろうと、別のマネージャーのために働いているマネージャーであろうと、私の経営陣とのコミュニケーションに役立つものがいくつかあります。

• どうして？ は、非常に重要な質問です。事実上の答えのほとんどは、その背後に「理由」があり、その「理由」は実際の質問よりも重要かもしれません。これにはいくつかの接線があります。
  • 開発者の理由 -開発者には、経営陣にとってまったく意味をなさない多くの回答があります。確かにそうでしたし、経営に着手した方法の1つは、経営陣が理解できる用語でチームを「なぜ」説明するのが本当に上手だったことです。「オタクの話者」が手元にない場合は、より一般的に理解されているメタファーでなぜ質問に対するオタクの答えを言い換えれば、オタクの話を学ぶことができます。何が起こっているのかを理解して同意するまで、それを守ってください。
  • マネジメントの理由-あなたの「なぜ」も同様に重要です。なぜ時間の見積もりが必要なのですか？何のために使用していますか？彼らが高すぎる、または低すぎる場合、私たちはどのように会社としてねじ込みますか？これは、マネージャーとしてのあなたがおそらく鋭い洞察を持っているものですが、これはすべて開発者にとっては無意味です。秘trickは、開発者が尋ねないことです。経営陣は彼に何かを求めており、正確でタイムリーで思慮深くなるために最善を尽くしますが、「理由」がわからない場合は、あなたがそうしなかった方法で最適化するかもしれません。あなたの理由を提供し、彼に同じことをするように頼みなさい-彼自身の言葉で答えを述べ直してください。

具体的に時間の見積もりについて-私はたくさんのことをしなければならなかった、と私は私の開発チームに「私はこれを必要とするので、私は給料を支払うためにより多くのお金を求めるつもりだから、あなたが言ったことを信頼します私はあなたの番号を使用します...つまり、あなたが私に低いボールを投げると、私はもう一度お金を要求することができないので、私たちはすべてねじ込まれます-私たちは提案したものと一緒に生きなければなりません」その文脈で、開発者は、彼らがどれほど自信があり、すばらしいかを示すための低い見積もりから、実際の期待設定にはるかに近い高い見積もりに変わりました。

• 誰も間違っていません -「理由」の質問は当然ですが、「それはとんでもない！仕方がない！」と言うのではなく、「なぜ」と尋ねます。会話が流れ続けます。誰かが尋ねられていることと、質問者が尋ねていることとの間に重大な断絶がある場合があります。私の最高の経営陣は私の答えに恐ろしく驚いていました。驚いたとき、彼らは驚いて点滅し、「なぜそれを言うのですか？」と尋ねます。彼らは（即座に）「あなたはそれを変える必要がある」とは言いません。競争上の目標を達成するために提案の数を減らしましたが、シーンを変えて質問の異なるコンテキストを作成する方法について激しく話し合った後です。

• 周囲の雑音、単語の選択、単語間のスペースに耳を傾けます -私が好きで盗まれて自分自身を使用するために盗まれたものは次のとおりです：

  • 作業エリアでくつろいで、自分自身で何か生産的なことをして（開発者の仕事に入ろうとしないでください、彼らはあなたが開発者ではないことを知っています）、ただ聞いてください。チームはどのように問題を解決しますか？彼らの大きな問題は何ですか？あなた自身や経営者全体の直接的な評価で本当のスキニーを聞くことは決してありませんが、問題領域がどこにあるのかについて本当に良い感覚を得るかもしれません。生産性の高い独自の作業を行っていることを確認してください。スパイが好きな人はいませんが、士気があまりに低く、全員が避難せずに近くにいられない限り、近くでの生産性は許容できるはずです。
  • 単語の選択肢を探します-単語自体と同じくらい重要です。特にポジティブな言葉やネガティブな言葉を使ったとき、経営陣はよく知らない状況で、なぜこれらの言葉を選んだのかと尋ねます。
  • ポーズ、ギャップ、ボディーランゲージを探してください。自分と開発者との間に力の距離がある場合（そして、それがあるように聞こえます）、彼らはあなたに矛盾したり、直面したくないかもしれません。しかし、「ねえ、あなたは間違っています」と言う基本的な本能は、通常どこかに現れます。

• できるだけ多くの通信媒体に開かれます - 対面、電話、電子メール、IMでチャットできるようになります-コミュニケーションの流れを確立するためのあらゆるもの。人々は非常に多様であるため、たった1つのトリックではうまくいきません。そして私は、開発者ではなく、マルチフォーマットのコミュニケーターになることがマネージャーの仕事だと考えています。

• 誰かに問題や可能な解決策について話されたら、彼はあなたがマネージャーであることを受け入れるべきであり、おそらく受け入れるでしょう。面倒だと思う。しかし、3回目以降は、特に説明なしで起こった場合、約99％の人が何も言わないようになります。

そして、これは私にとって非常に難しいものですが、私がそれをすることができるときはうまくいきました- 内向的と外向的の違いに注意してください。あなたは外向的な人である可能性があります-だからあなたの仕事は良さそうで、開発職はそうではなかったのです。開発者は、ほとんどの場合、内向的です。「内向」とは「通信できない」という意味ではありませんが、そのパターン、プロセス、速度が大きく異なり、絶えず通信する衝動がほとんどないことを意味します。内省的な思考を引き出すために、時間と静かな（しかし同じ場所に）スペースを計画します。私の内向的な友人の多くは、私が「5分ほど黙って」待っているので、考えをまとめて対応できると言っています。ここに'外向的な人が内向的な人と、安らかな洞窟の休息についてのランドについて知っておくべき5つのこと-内向的な人にとって何が素晴らしいのかという、特に開発者にとって素晴らしい例です。ちなみに、ランドはかなり素晴らしいです。彼は自分自身がオタクなので、開発者を中心に考えています。それがあなたのスタイルではない場合はおかしくなりますが、彼は面白く、チーム開発に関する非常に優れた洞察を持っています。

お気に入りのマネージャーについて私が一番気に入っていることは：

• 彼らは私と同じようにプロジェクトに深くコミットし、興奮していました

• 彼らが私の背中を持っていることを疑うことはありませんでした-彼らが次のレベルの権威の前にいたとき、私（または私の仲間）が決して山羊にならないことを確信していました。障害が発生した場合、常にグループの障害になります。

• 当時、自分のスキルにとって重要かつ適切なものの所有権を与えられましたが、スキルを拡大して仕事を完了するのに十分なリソースがありました。

• 彼らは私を個人として、またチームの一員として見ました。彼らは私の長所と短所を積極的に知り、自分の長所を生かして自分の弱点を補うように働きかけました。

• 彼らは私の個人的な目標を知っていて、できる限りそれらを取り入れることに興味を持っていました

• 私を幸せにすることは、優先事項ではなく、そうすることもできませんでした。「この種の仕事が嫌いなのは知っていますが、それをする必要があります。これが永遠に続くわけではありません...」と聞くことには本当の価値があります。

• 全体像を説明する時間は常に1週間にありました（おそらく現時点ではありません）

• 指を指すことなくほぼ一定のフィードバックとステータスがありましたが、個々の作業は十分に認識されていました。

• 常に真実がありました。何かがデリケートで議論できなかった場合、彼らはそう指摘した。何かが不確かな場合、彼らはある程度の自信を与えました。

最初の簡単な部分：あなたの投稿に技術的な危険信号があります：「誤解した推定値」の言及に身震いします-それは推定値です、それはミスタケであってはなりません、それが推定値と呼ばれる理由です。少しずれることもあれば、かなりずれることもあります。そのため、見積もりと呼ばれています。あなたが福音として推定値を取っている場合、それは「あなたの」開発者があなたのスタイルで抱えている主な問題の一つになるでしょう。

ただし、開発者とのコミュニケーションの難しさについては100％同意します。プロジェクト管理トレーニングの開発者として、数年前に啓示を受けました。議論のオープンな雰囲気が作られた後、私は仲間の開発者の何人かが管理に対して絶対に手遅れになっているのを見ました（管理はここにありました）。間違っていたすべてが、開発者の目にはマネージャーのせいでした。キッカーは、経営者がその日に提起されたほとんどすべての大きな問題について知らなかったということでした。開発者は、経営陣がそれを見逃すことはおそらくありえないほど明白であると想定しており、管理者は開発者が必要なものを伝えると想定していました。

したがって、答えの最初の部分であるIMHOは、開発者にあなたが精神的なものではなく、実際にはおそらく技術的な面に関しては実に愚かであることを知らせる必要があります。あなたは、彼らがタイムリーにあなたに来ることを頼りにしています。あなたは彼らの人生を楽にするためにそこにいます。

そして、あなたが何をするにしても、あなたが実際に答えを知りたくない質問をしないでください-上記の「誤った見積もり」を参照してください;-)。それは開発者のクリプトナイトです。

ここにはたくさんの良いものがありますが、私は次のことを言う必要があると感じています.. ..申し訳ありませんが厳しい。

• PMとしての5年間、および開発者が必要とするPCの種類を知らないことは、とんでもないことです。
• 最初の真の危険信号として、悪い労働条件のために開発者を辞めることは非常識です。

あなたが持っていると思うのは、コミュニケーションの問題ではなく、信頼の問題です。彼らがあなたがその情報で何をするかを信用していないので、何が間違っているのか誰もわかりません。これらすべての問題についてあなたに言った開発者は、そうすることで結果がなかったので、そうしました、彼は辞めていました。

個人的には、彼の経歴で開発経験のないPMを雇うことは決してありませんでした。次のプロジェクトでは、開発の一部として時間のごく一部を捧げるべきだと思います。チーム。チームリーダーの下でJr開発者として働いて、週8時間と言います。

これにより、開発チームのダイナミクスに目が開かれます。現在、あなたはそのチームの一員ではなく、部外者だからです。開発者の辞任があなたに衝撃を与えたという事実は、それを証明しています。チームの誰もが彼が不幸であることを知っていました。そして、彼らの誰もあなたに言っていない：

「あなたが何もしなければ、私たちは最高の男を失います」

それは赤旗＃2であるはずです。

マネージャーとして、トヨタ生産システムの理念の1つであるカイゼンが継続的な改善を意味すると聞いたと思います。

問題があることを認めたので、それは素晴らしいスタートです。

Kaizenには5つの主要な要素があります。

• 品質サークル：企業の運営のあらゆる側面に関する品質レベルについて議論するために会うグループ。

• 改善されたモラール：従業員間の強い士気は、長期的な効率と生産性を達成するための重要なステップであり、カイゼンは従業員の士気との継続的な接触を維持するための基本的なタスクとしてそれを設定します。

• チームワーク：強力な企業とは、すべての段階をまとめる企業です。カイゼンは、従業員と経営陣が競合他社ではなく、チームのメンバーとして自分自身を見ることを支援することを目指しています。

• 個人的な規律：チームは、チームの各メンバーが自分自身で強いことなしに成功することはできません。各従業員の個人的な規律へのコミットメントは、チームが強いままであることを保証します。

• 改善の提案：経営陣は、チームの各メンバーからフィードバックを要求することにより、すべての問題が重大になる前に確認および対処されるようにします。

（ソース）

これをよく見てみると、これらの要素に対する定数は、チームワークとフィードバックに重点を置いています。

例として、時間の見積もりに関して議論があったと言います。あなたはそれらの時間の見積もりを担当していますか？そのことについてチームと話しますか？申し訳ありませんが、マネージャーがas-から数字を引き出すだけです。重要なことの1つは、チームがあなたに与えてくれる見積もりを時間をかけて交渉しないことです。多くのマネージャーは、彼らのチームが一生懸命働いていれば、より短い期限に間に合うと想像します。これは嘘です。9人の女性は1ヶ月で赤ちゃんを産むことができません。

だから、私の最初のアドバイス：

聞く：チームへの簡単な電子メールから始めます：「開発チームが経営陣のパフォーマンスについて経営陣にフィードバックを提供する最良の方法は何ですか？」チームで繰り返し、コンセンサスを実装します。あなたの仕事は、チームが群れを作るのではなく、素晴らしいソフトウェアを開発できるようにすることです。これを覚えておいてください。

誠実さと忠誠心：あなたが何かを尋ねても誰も答えないなら、それは彼らがあなたが聞くことを信じないか、最悪の場合、あなたがそれを罰するだろうと信じているからです。正直言って。誰かがあなたが嫌だと言ったら、これをフィードバックとして受け取り、復venをしないでください。彼らの理由を理解し、改善してください。

そして最後に、ここでいくつかの批判を見てきましたが、The Mythical Man-Month：Essays on Software Engineeringという本を読むことをお勧めします。この本は、OS / 360の開発を管理するIBMでのフレッドブルックスの経験に関するものです。あちこちにいくつかのことがありますが、複雑なソフトウェアの開発プロセスがどのように機能するかを理解するための出発点です。S.Lottはアジャイルマニフェストを引用していますが、これは特に熱心ではありませんが、読む価値があります。

これを読む：

http://agilemanifesto.org/

• プロセスとツールを介した個人と相互作用

• 包括的なドキュメントよりも機能するソフトウェア

• 契約交渉を介した顧客コラボレーション

• 計画に従うことによる変化への対応

多くの場合、組織（つまり、上司）はあなたに

• 「死の行進」につながる論理的な結論に至るまで、明らかに壊れたプロセスに従ってください。これは、議論と辞任につながります。

• 過剰で価値の低い未使用のドキュメントを作成します。

• 複雑な変更管理a / k / a契約交渉に従事する。すべてのユーザーの変更には、変更を「品質」および「優先順位付け」するための精巧な儀式が必要です。本当に、それはすべて「フリーズ」、つまり変更を防ぐことです。

• 結果に関係なく計画に従ってください。一部の組織は、破損した（または役に立たない）ソフトウェアのオンタイム配信を重視しています。評価されるのは計画であり、ビジネス上の問題の解決策ではありません。

問題はあなたの個人的なコミュニケーションスキルではないかもしれません。

開発全体の「環境」または「方法論」が致命的に壊れており、悪い気持ちは一般的な悪い慣行の症状にすぎない可能性があります。

私にとって、これはあなたが開発者と簡単な雰囲気の中で話したことがないように聞こえます。彼らとのあなたの話は、単に公式の性質のものでしたか？残念です。

それらを個人的に知り、会社、職場、プロジェクトの良いところと悪いところを知りましょう。彼らの仕事に心からの関心と感謝を示すことによって、彼らを尊重し、彼らの尊敬を得る。

彼らがあなたを信頼し、ポーンのオファーであることを恐れる必要がないなら、彼らはあなたに魅力のない真実を告げるでしょう。

私はチームリーダーであり、私のチームは私を信頼しています。私はそれらを保護します。私はすべての責任を負い、彼らと名声を共有します。私たちの管理は私を守ります。それは士気を高めます。私たちには本当に難しいプロジェクトがあり、ほとんど邪悪な顧客がいて、終わらせることはほぼ不可能でしたが、最終的にはすべてを非常に率直でオープンに話しました。

拍手！拍手！拍手！あなたは確かに良い人であるべきです、あなたはあなたの仕事で良くなるために何ができるかを見るためにオープンに出てきたからです。

素晴らしいマネージャーで私が目撃したこと、そしてチームをシニアメンバーとして率いるときに個人的に採用したものを以下で見つけてください。

• M entor管理する以上。
• 自分の考えや懸念を表明するLLOWチームのメンバー。それに耳を傾けてください。建設的なものを取ります。
• Nは、今までに分裂政治を再生することにより、チームメンバーを裏切ります。これは、より早く静かに裏目に出ます。
• ないnger。チームと一緒にいるときに顔にしかめっ面をしないでください。これは本当に難しいです。
• Gは、彼/彼女の良い仕事に対して勝者を心からオープンに感謝します。同じ幅で、非常に柔らかく、戦術的に、人ではなく人の仕事を、責任を持ち、孤立していて、開かれていない人に批評します。
• Eすべての個人でncourage所有権とリーダーシップ。彼は尊敬されていると感じるので、これは人の士気とコミットメントを高めます。
• Rは、たまには自分のチームの周りOAM。これは、チームメンバー内の結合を誘導/増加させます。

あなたの誠実な努力で幸運を祈ります:)

一般に、trenchにいる人たちは、状況を修正できる人や、その状況を修正する人に不満が聞かれないと感じると、反抗的な気持ちになります。彼らが会社での地位を危険にさらすことなく不満を感じることさえできないとき、それはさらに悪いことです。

私はTheory-Yのような男で、ほとんどの「知識労働者」はそうなる傾向があります。機会があれば、私たちは仕事が好きで、うまくやりたいと思っています。しかし、Theory-Yの職場の欠点は、問題があることはすぐには明らかにならないかもしれないということです。人々は、うまくやりたいので、波を作りたくないので、その問題を回避する方法を見つけるか、単にそれを無視します。これは、最終的にチーム全体の顔に吹き飛ばされる、悔い改めのフラストレーションにつながります。Theory-Xマネージャーが運営する店には、おそらくもっと早く文句を言う人がいるでしょう。従業員はお金のためだけにその中にいるので、仕事がいつもよりもひどい場合、彼らは不満に思うでしょう。

あなたができることに関して言えば、仕事をしている部屋の先輩や主任がいる環境では、彼らはあなたの最高の資産です。彼らと話してください。「双方向」のために週に30分をスケジュールすることができます。この場合、リードはプロジェクトの日々に関する最新情報と空気の懸念を提供し、ビジネス側で最新情報を提供し、懸念を解決するために計画を立てます。チームに深刻な影響を与える問題になる前に。

アジャイルでは、各「スプリント」または「イテレーション」の最後に（通常1〜3週間続く開発作業の単位です）、チーム全体で、最も若いメンバーからPMまで、「回顧」があります。 「。彼らは何をしたか、何がうまくいったか、何がうまくいかなかったかを振り返り、やり続けることと変化することを特定します。いくつかの形式があり、独自の形式を考案できますが、レトロの結果は、人々が自分の声を聞いたと感じ、結果として物事が変わることです。

アジャイルについて話す; 私の最初の仕事は小さな会社で、「小さな」ということは、会社全体がソフトボールチームを編成できなかったことを意味します。私が始めたときは4人のプログラマがいましたが、私が去る前に2人に減りました。会社の創設者、社長、CEO、および95％の利害関係者は鉄拳でそれを支配し、彼は組織内の計画の唯一の源でした。ボスは仕事中毒であり、他のすべての人も同様であると期待していました。あなたが与えなければならなかったすべては彼の期待以上であり、このために彼は10年間彼のために働いていた人々にエントリーレベルの給料を支払った。

私はその会社を去り、別の会社で仕事を始めました。彼らは、毎日のスタンドアップ、ペアプログラミング、スプリントチーム、および回顧展で、SCRUMアジャイルの基本的な方法論を実践しました。各スプリントの開始時に2週間ごとに1日間、次の2週間の作業を計画する以外に何もしませんでした。別の日の大部分について、私たちは何もせずに、やったことを振り返り、チームとして改善する方法を見つけました。Microsoft MVPであり、仕事を成し遂げ、私がやっていることを奨励し、補完する開発者が私の隣に座っていました。

夜。そして。日。主な違いは？まず、私はプロジェクトのために自分自身を殺すことを期待されているとは感じていませんでした。アジャイルの基本原則は、開発の持続的なペースです。第二に、私は自分の仕事をどのように行うかを決定する声がありました。私は仕事をしなければなりませんでしたが、次のスプリントで達成が期待されるものに「胸焼け」があれば、私はその意見を表明することができ、それは聞かれ、重さを与えられるでしょう。もっと良い方法があると感じたら、そう言うことができ、楽しまれるでしょう。

解決策を見つけて問題を解決する限り、トップダウンで作業しているように見えないように注意する必要があります。コンピューター用。RMR（定期的な月間収益）では、会社は2週間に4台のコンピューターのみをアップグレードできます。最初の4台のコンピューターがすべてリードとシニアに行くべきではありません。彼らは最も遅いコンピューターを持つ人々に行くべきです。チームにボーナスを与える場合は、「貴重な先輩やリード、これがなければ誰もできなかった」だけにボーナスを与えないでください。開発チームの全員がそれを実現しました。ジュニアに苦情がある場合は、彼の声を聞いてください。彼が後輩だからといって、何も知らないわけではありません。

関係の改善：
難しいプロジェクトがありましたか？後で休憩を与えます。リラックスして休暇を過ごすための休暇の時間。
コーダーの権利章典これらは与えられたものです。言うまでもなく行くべき基本的なこと。これらに違反すると、codemonkeyを乱用していることになります。
ジョエルのテスト私はそれらのほとんどに同意します。しかし、いくつかは本当に依存しています。不足している場合は、おそらくプログラマーの生活を必要以上に難しくしているでしょう。
技術的な負債。したがって、完了をプッシュすることはできますが、コーナーをカットすることで、技術的な負債が発生し、後日修正するのに時間がかかることを認識しなければなりません。プロジェクトの終了前にその日付が来た場合、あなたは本当に台無しになっています。
RSAアニメーション：モチベーションこれは、ナレッジワーカーの動機付けの方法を実際に示す素晴らしいビットです。
彼らが望むものをコーディングする自由な日。RSAビデオから。名前を覚えてはいけませんが、言及している会社のサイトには簡単な説明があります。私には良いアイデアのようです。ほとんどの店には、誰もが破産していることを知っているものがありますが、誰も修正する時間はなく、優先度は高くありません。これにより、技術的な負債に取り組むことができます。また、彼らは彼らの素晴らしいアイデアを披露することができます。

そして、神の愛のために、週に40時間働くようにしてください。また、フレックスタイム。フレックスタイムはでたらめの世界全体を補うことができます。少なくとも私にとっては。

プログラマと上司の間のコミュニケーションを改善する
それは私にとって難しいです。その全体的なシュムージングは​​、プログラマーの焦点では​​なく、ボスのスキルセットに近いものです。時間の見積もりなどの基本的なことは単なる見積もりであると言えます。凍結していれば、水の上を歩いて要件を満たすことは簡単です。恥ずかしがり屋のプログラマーに、コードレビューなどでプロジェクトのプレゼンテーションをするように依頼することもできます。練習で完璧になりますか？しかし、私はこれに関する他の人のアドバイスに頭を下げます。

「同様に、あなたがそれを嫌うなら、その理由を詳細に説明してください。」
さて、ここで水門が開かれます。そして、もし明らかに私にリンクされる可能性のあるopenIDを使用していなかったなら、私もおそらくベントするでしょう。やってはいけないことの巨大なリストが本当に必要な場合は、匿名の投稿により友好的なフォーラムで質問してください。

私は常に、一般の人々はあなたがあなたを治療するよりもあなたをより良く治療しないことを発見しました（彼らはあなたをより悪く治療するかもしれませんが）。私は個人的に（私は開発者です）正直に正直に、敬意を払い、信頼に信頼するなどに対応しています。あなたは中立的な雰囲気の中でチームと非公式のチャットをし、あなたが今言ったことを彼らに話すべきです。有毒な「私たち対彼ら」の環境で忘れられる点は、それがすべて「私たち」であるべきだということです。管理者と従業員の両方がそれを知る必要があり、企業はそれをサポートする必要があります。

幸運を。

これで、フィードバックを受け入れるだけでなく、それに基づいて行動するという実績があります。上位の意思決定者に影響力があることを実証し、チームのために物事を成し遂げることができます。それは大きな違いになります。プログラマーは内向的かもしれませんが、プログラミングについて話すのが好きです。非公式の環境は素晴らしいですが、誰もが専門家である必要があります。人々がいくらか発散することを許可しますが、議論が生産的なものであり、単なる雌犬のセッションではないことを確認してください。

私の経験から、マネージャーが好きまたは嫌いになる最も重要な要因は、マネージャーが開発全般を理解し、私がしている仕事を理解していることです。いくつかの肯定的な結果はここにリストされています：

• なぜ変更にそれほど時間がかかるのか、実装できないのかを正当化するために時間を無駄にする必要はありません。まあ、技術的には、あらゆる変更を実装することができ、通常、経営陣は何らかの方法で実装を要求します。しかし、少なくともそのような状況では、直属の上司があなたの側にいて、（あなたを押したり燃やしたりするのではなく）より多くの時間を求めます。
• 悪い状況（WTFハック、生産上の問題など）の場合にサポートされる可能性が高いことを知っています。通常、非技術者はそのような状況で開発者を非難する傾向がありますが、優れたマネージャーは実際に何が起こっているのかを理解し、開発者をサポートします（単にそれを知っているか、そのようにするつもりはありません）。
• 私は自分の仕事とパフォーマンスが適切な人によって評価されることを知っています。

私の意見では、あなたがこれ以上プログラミングを行わず、通常はタイトなプロジェクトスケジュールまたは予算で行う場合、開発者が好む可能性は非常に低くなります。その場合は、すぐに上に移動し、他の誰かが直接マネージャーになることをお勧めします。申し訳ありませんが、私はこの段落で悪い音を立てましたが、それは私が見る方法です。あなたは良い人のようで、いくつかの真実に値します。

私もスーツを着た男の1人で、15年以上も働いています。始めたときはソフトウェア開発者でしたが、機会があればコードを書いています。ですから、私は両方の側で話をすることができ、これらの状況で少しの経験があると思います。また、スタッフによって選出された「年間最優秀従業員」などの資格を持っているため、こうした状況に対処する自信があります。

私が頻繁に目にするのは、経営陣と開発者の間で取られる価値システムと運用方法/アプローチに大きな違いがあるということです。

多くの開発者にとって、誠実さ、誠実さ、その他の点で柔軟な職場環境が非常に重要です。残念ながら、トップマネジメントのリストでは、同じ値はそれほど高くありません。そしてこれは、特に中間管理者（あなたと私）が完全にトップマネジメント側を引き受けることに決めた場合に、必然的に大きな衝突につながります。これから抜け出す唯一の方法（私の観点から）は、チームの前にしっかりと立ち、彼らを最後まで支援し、オープンなコミュニケーションを通じて、そして最も重要なこととして、あなたが言っていることをすることによって、信頼関係を構築することです（これは、政治が誠実さを完全に圧倒するトップマネジメントから得られるものとはしばしば反対です）。

同時に、自分で操作できる状態を維持する必要があるため、経営陣が理解し、ゲームをプレイする言語で経営陣とコミュニケーションを取る方法を見つける必要があります。それが中間管理職の真の課題です。

開発者の幸福により、生産性はすべてささいなことになると思います。数学は管理のために非常に素晴らしい結果を出します。朝にドーナツ（-25セント）をくれれば、一日中2倍（+多額）働きます。不満なときにはゆっくりと作業することで積極的に物事をサバトゲするのではなく、非常に複雑なシステムに取り組んでいるということです。私たちが怒っているときは、あまりコード化しない方が本当に良いでしょう。

ただし、見積もりは自分で対処する必要があります。私が持っているすべての問題は、非現実的な推定値を除き、ドーナツを渡すことで解決できます。真か偽か、これは開発者の見方です。経営陣はより短い見積もりで（新しいボートのように）すべてを得ることができますが、開発者は（1か月分の睡眠のような）失うものをすべて持っています。ただし、経営陣が担当しているため、毎回見積もり戦争に勝ちます。見積もりシステムは、開発者が締め切りを決定するときに最適に機能すると思います（正確な見積もりを出すのは難しいので、マネージャーはどうでしょうか？）。少しずれている。

プログラマーに質問、コメント、または懸念を抱く可能性のある反応を考えてください。「今、何が欲しい？」というのはありますか または「なぜこれで私を悩ませていますか？」一種の応答？開発者に懸念やコメントを表明することをどの程度奨励していますか？ただし、これは出発点にすぎません。

第二に、これらの議論をしようとしている場所に注意してください。私のマネージャーがすべてを聞くことができると知っていたら、次のキューブの誰かと自分の作業機械について話し合うことを非常にオープンにするとは思えません。人々に率直で正直なフィードバックを提供したい場合、回答が公開されたり、彼らに対して使用されたりしないことを知っていることに対して、プライバシーが与えられなければなりません。

第三に、どのような感情的知性のスキルがあるかを考えてください。 プロジェクトマネージャーの感情的インテリジェンス：アンソニーメルシーノによる傑出した結果を達成するために必要なピープルスキルは、昨日昼食から得た本の推薦であり、EQについて学びます。ここで心理学を深く知りたい場合は、エニアグラム、ソーシャルスタイル、MBTIなど、使用できるさまざまな性格プロファイルツールがあります。

最後に、あなたの会社の文化とは何かを考えてください。敷物の下に何か間違いがありますか？苦情は、誰かを本当に簡単にトラブルに巻き込む可能性のある大きなノーですか？どのような行動が報われ、奨励され、どの行動が許容され、受け入れられますか？この一部は観察ですが、一部は会話を必要とする場合があり、会話はオフィスから離れているか、盗聴される可能性が低い部屋で行う必要があります。おそらく最初からこれを使用しようとするのを繰り返すでしょう。文化が主に誰もが「それを吸い上げる」ことを知っていた場合、新しい実践を確立し、人々に声をかけようとしていれば、それは悪いことではありません。これは他の答えよりも感触が少ないかもしれませんが、これは私がすることです

開発者は、あなたが彼らの支持者であると感じていますか？それによって、彼らは彼らがあなたに彼らの懸念/欲求不満をsられずに自由に共有できることを知っているということですか？彼らはあなたが彼らのために戦っていると感じますか？彼らはあなたが彼らの仕事に感謝していると感じていますか？彼らはあなたが本当に彼らが彼らのキャリアで成功することを望んでいると感じますか？

彼らが感謝していると感じるなら、あなたはおそらくより良いコミュニケーションを持っているでしょう。

開発者として私は主要なオタクであり、社会的スキルを欠いており、それについて謝罪しません。結局のところ、私は才能であり、あなたは私の才能のために私を雇った。仕事をするためにソーシャルバタフライが必要な場合は、開発者ではなくプロジェクトマネージャーでいっぱいの部屋が必要です。

一部の開発者は非常に社会的に抜け目がないことを知っていますが、中央値は内向的なオタクに傾いていると思います。

誰かが私に何かをするように要求するとき、私は全く推論をせず、要求されたものを正確に行います。一部のプロジェクトマネージャーでは、私が絶対にやらないプロジェクトについて推論することを期待しているため、常に問題が発生するようです。彼らは要求した。一部のプロジェクトマネージャーでこれが起こるのは、高品質のHLD、BRDを提供せず、白黒ではなくプロジェクト管理の社会的側面にあまり価値を置いていないためだと思います。

これが世界が衝突する場所だと思います。プロジェクト管理の世界では、社会的なスキルと個人的な率直さは重要な要素であると思いますが、私のような開発者にとっては絶対に何も意味しません。このタスクまたはそのタスクがどれほど重要であるかについて、私は気が遠くなりません。ここで何人かが提案したように、私は昼食やビールに出かけたくさえありません。

本当に欲しいのは、良質で高品質のHLDとBRDです。達成可能なスケジュールと期限が必要であり、新しいデザインや計画が導入された場合は、スケジュールと期限を再調整する必要があります。私は、要件がオンザフライで変化するように見えるプロジェクトに取り組んできました-私にとってこれは、私が質の低いプロジェクトのリーダーシップに対処していることの私の赤い旗です。開発者としてあなたができる最悪のことは、特に私たちがすでにスケジュールを持っているか、スケジュールのコミットを行った後、私に毎日新しいプロジェクトの要件をもたらすことです。新しい要件が導入された場合、期限を補償せずに耐えられません。もっと時間をかけて、遅くまで働いて、私はそれで問題はありませんが、それは開発において常に定量的なものではありません。変更によっては数時間かかる場合がありますが、適切なR＆D、テスト、QAなどに数週間かかる場合があります。ケーキを焼くのとは限りません。要件を1回変更するだけで、レシピ全体を変更するような場合もあります。私はプロジェクトマネージャーが溶けて、電話会議でtempが起こるのを目撃しました。なぜなら、彼らの期限は余分な開発を許可しないからです。

例として、私自身の個人的な偏見と経験しか与えられないので、すべての開発者を代表して話をしていると推測しないでください。私はこれらのことを自分のキャリアの縮図を通してしか見ていませんが、この投稿は私がことわざのタオルを投げ入れた正確な条件を説明しています。

どのくらいの頻度で開発者と話しますか？物事が予定されており、それらをどのように聞いて、どのくらいの頻度、あなたのプログラマーの1に座るん-私は、成果物またはあなたがそれらにもたらすその他のトピックについての質問に、プロジェクトのステータス会議を意味するものではありませんだけ聞きます。

他の多くの答えは本当に良いです-アジャイル開発を検討する必要があります。開発者はそれぞれの役割を学び、成長する必要があります。しかし、実際に開発者が言っていることを聞いていない（または聞いていない！）場合は、まずそのことに注意する必要があります。

1対1の参考資料-http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

短くて甘い。あなたがすることでエクセル-これはコミュニケーションを生み出します。

開発者にとってexcellingとはどういう意味ですか？..読み取り、再読み取り、PeopleWareの学習も可能

上記の投稿のすべての素晴らしいアイデアとコメント！

アイデアは次のとおりです。ITスタッフを地元のコミュニティカレッジのコミュニケーションワークショップに送ります-もちろん会社が支払います。

a）ワークショップの評判が良いこと、b）従業員を一緒に送らないことを確認してください。ワークショップの価値を低下させるだけでなく、他のクラスのメンバーと交流することなく、他のクラスのメンバーと交流する傾向があります。

生産的なチーム指向のコミュニケーションは、誰もが学ぶことができるスキルですが、ほとんどの学問の道に欠けていると感じている主題です。

このアイデアは決して魔法の弾丸ではありませんが、パズルの優れた基礎部分です。あなたの仲間はお互いにうまくコミュニケーションを取ることを学ぶだけでなく、ボーナスもあなたの仕事をよりよく理解し、尊重し始めることです（コミュニケーションはPMの中心にあります）。

ちょうど私の2ビット:)

すでにいくつかの 答えで出てきた推奨事項から答えを出すためだけです。Michael Lopp（別名rands）は、彼のブログRands in Repose、およびManaging Humans（book sources）で、開発者の管理と「頭に浮かぶ」ことについて書いています。この本には、2007年以前の彼の投稿のほとんどが編集されたコンテンツが含まれており、彼のブログの管理関連の部分に追いつくための良い方法を提供します（ギャンブルなどについても話します。彼の文章は一般に素晴らしく、しばしばユーモラスですので、彼を読むことにはほとんどリスクはありません。

チームをビールに連れて行きましょう（そして、あなたは買っています）。

私はパーティーに遅れましたが、この質問を見ました。

対処方法がよくわからないことの1つは次のとおりです。

うなり声はスーツに完全な真実を決して言わない。RandsはこれをDNAで述べていますが、正面からは触れていません。彼は別のトピックに取り組んでいます。

あなたはスーツを着ており、小切手に署名します。あなたは会社の利益を代表しています。あなたはエンジニアを代表していません。もしそうなら、あなたは彼らの小切手に署名するのではなく、彼らはあなたの小切手に署名するでしょう。

もちろん、これはあなたやエンジニアにとってのニュースではありません。しかし、エンジニアが特定の問題を引き起こすことを知っている場合-問題-彼の職場で重大な競合を引き起こすだろう-リスク/報酬のトレードオフはエンジニアに有利ではありません。エンジニアは、職場の文化の戦いを始めるのではなく、製品を生産するための報酬を受け取ります。それらに関与することは、間違った仕事をするための速い道です。

したがって、管理タスクの一部は、企業の政治やキャリアの反発を招くことなく、エンジニアが問題についてオープンになる方法を提供することです。結局のところ、昇給をするのは良いことです。そして、もしこれが気の利いたものでなければ、他の会社もあります。

DeMarcoとListerの「Peopleware：Productive Projects and Teams」というあなたの質問と主題を正確に扱っているこの素晴らしい本に誰も言及していないことに驚いています。社説から：ソフトウェア開発の主要な問題は技術的ではなく人間的です。アマゾンでの最初の3つのレビューは、私があなたの状況にあったなら、この本を買うように私を説得するのに十分であるでしょう。

ここでの答えの多くは非常に良い点を持っていますが、私は役立つかもしれないいくつかのリソースを投入したいと思います。私は、自分自身を巨大な混乱に陥れたり、関係者間のコミュニケーションのために非常に効率的に解決されたりしたいくつかの状況にありました。3つの本は、特に回線が多いストレスの多い状況で、個人的にコミュニケーションスキルを向上させるのに役立ちました。

• 難しい会話：最も重要なことを議論する方法
• 重要な会話：ステークスが高いときに話すためのツール
• 重大な対立：約束の破綻、期待違反、悪い行動を解決するためのツール

あなたの質問を読んで、コミュニケーションの価値がわかると思います。個人的には、コミュニケーションはビジネスや技術のスキルよりもマネージャーやリーダーにとって重要だと感じています。あなたが率いる人々は、プロジェクトの大部分を成し遂げるために必要なハードスキルを持っているべきです。優れたテクニカルリーダーまたはプロジェクトマネージャーは、チーム内、チームと顧客間、チームとビジネスエンティティ間（またはこれら3つの組み合わせ）であるかどうかにかかわらず、コミュニケーションに集中できる必要があります。

技術的な労働力の視点への洞察を与えるいくつかの素晴らしい小説を読んでください：

• ハッカー、スティーブン・レビー-http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs、Douglas Coupland- http://en.wikipedia.org/wiki/Douglas_Coupland
• 大聖堂とバザール、エリック・レイモンド-http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

これらは、管理に関する典型的な回想録と同じくらい重要です（Drucker et al）。

開発者、シニア開発者、テクニカルリードなど、長年にわたってさまざまな役割を果たしてきました。

あなたの質問から-開発者があなたに助けてくれるとは思わないので、あなたのことを言わないことは非常に明白です。

これには2つの理由が考えられます。

1. 彼らはあなたが物事を修正する力を持っているとは思わない。しかし、おそらくあなたはそれを知っているだろうし、開発者もそれについてあなたに泣き叫ぶだろうから、これはありそうにないと思う。
2. あなたは、開発者が問題を抱えてあなたのところに来たとき、次のことの1つ以上を行う種類の人です。
   • 彼らが問題を持ってあなたのところに来たとき、あなたは彼らに言います-私は問題ではなく解決策が好きです。
   • あなたはそれらをきちんと聞いてから問題を解決するように彼らに働きかけます。あなたは彼らに問題を解決する責任を与えられることの名誉についての激励を与えます。時間が経つにつれて、あなたの部下は、彼らが問題を抱えてあなたのところに行くとき、彼らが余分な仕事をすることになるので、彼らは問題を抱えてあなたに来ないことを理解しています。
   • あなたはそれが問題であることを否定します。これには説得力のある理由を挙げます。しかし、これが起こり続けると、時間の経過とともに、あなたの仲間は問題であなたに接近する意味がないことを学びます。
   • あなたは「はい、わかりました」と言います。あなたは、この種のことがたまに起こると言い、誰にもできることは何もないと言います。これがパターンである場合、再びあなたの仲間はそれを理解しています。

上記のいずれかまたはすべての場合は、修正する必要があります。

私が一番嫌いなのは、私、開発者、そしてエンドユーザーの間にいる人々です。最高のマネージャーは私にこれをさせて、ユーザーが望んでいる、またはできると思うものに合わせてソリューションを変更します。

私にとって最悪のプラクティスは、しばしば「良い」と装うことです。通常、マネージャーは自分自身を持っています。

カスタマイズされたソリューションである場合、開発者でさえ時間がかかることがわからず、通常、顧客は彼らにとって何が最善かを知る手がかりがありません。それが反復開発が素晴らしい理由です。ほとんどの取引が行われる方法ではありませんが、優れたマネージャーは上記のように働くために戦うでしょう。

最後に、一部の開発者はコミュニケーションが苦手で、顧客と関わりがありません。それらは、明確な要件、特に明確な技術的要件を持つ問題におそらく最も適しています。おそらく、より良いコミュニケーターであり、純粋な技術的な問題ではなく、ビジネスの問題を解決するために働きたい開発者が必要でしょう。

チームを幸せに保つのはとても簡単です

彼らの質問にも答えがたくさんあるので、彼らの話を何度も聞いてみてください。私は、チームメンバーに問題と可能性のある解決策を提供することをお勧めします。

チームの外出は良いアイデアです（ゲームプランの場合があります）

プロジェクトに深夜と週末の仕事が必要であり、実際にチームに多くの価値を追加してはならないと思う場合、何かを食べてチームの努力について感謝し、可能であればチームに感謝することをお勧めしますいくつかのPTOの前向きを手配する

チームメンバー全員と隔月で1：1を行い、快適であることを確認します。

最後になりましたが、プロジェクトを機能的に、そしてある程度技術的にも理解することをお勧めします。

さらに質問がある場合はお知らせください

私はまた、科学技術のバックグラウンドを持っているが、元々ITソフトウェアのバックグラウンドを持っていなかったソフトウェアマネージャーでもあります。ですから、私は最初はコーディングに特別な親和性はありませんが、デミングの学校の統計的品質エンジニアであり、デミングから継承するふりをするが、その後のすべての「現代の」学校に非常に異なる教えを持っています。最悪の場合は6シグマ、リーンの方が優れていましたが、残念なことに、このhttp://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-sayが発生しました：

「元々、シックスシグマは、6シグマレベルの品質を達成するためにMotorolaのトヨタ品質管理（TQM）から派生し、Allied SignalとGEを通じて、統計に基づいてBlack Beltsのプロジェクトにモーフィングし、コスト削減プログラムになりました。明確なROIが必要です。言い換えれば、私たちは、リーダーシップの哲学から、コストを削減するための1回限りのプロジェクトまで、プログラムを非難しました。それはオリジナルの完全なろくでなしであり、リーダーシップと文化が欠けていたため、永続的で持続可能な変化につながることはめったにありませんでした。

「同様のことが、ツールキット（バリューストリームマッピング、KPIボード、セル、かんばんなど）に縮小されたときに無駄になりました。

「リーンシックスシグマは、優れた日本企業やデミングのような教師たちの当初の考え方を決して反映していません。」

今日、アジャイルの動きは無駄のないものです（ジェフ・サザーランドのコースとデミングの彼の栄誉を参照http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -scury-of-scrum /）、Waterfallよりも優れていますが、元のテキストでDemingを読む代わりに、グルは14の管理原則全体を引用することはほとんどないため、Demingを読むのではなく、そして、それ自体ではほとんど価値のないツールやセミナーを販売しています。

現在、ソフトウェアの分野に関しては、一般的な原則は知っているが実際にそれを実際に適用する方法について実際のアイデアを持っていない人や、ソフトウェアを書いているが原則を無視しているだけの人がいるという問題があります実際の原則を伝えずにツールを販売した偽の達人であり、実際に独自の管理ツールを構築する必要があります。

だから私にとって、ソフトウェアプロジェクトマネージャーは、Microsoft Projectでの計画（またはアジャイルでのバーダウンチャート）やPowerpointでの上級管理職への素晴らしいプレゼンテーションだけでなく、ソフトウェアコーディングの日々の運用性をさらに深める努力をするべきです。開発者チーム。技術的な問題であっても開発者チームに問題がある場合、プロジェクトマネージャーは外部の目で診断の方向付けを支援できます。彼はコードを見ることができます。たとえ小さな詳細を理解していなくても、彼は開発者がその手がかりを考えていないことに気付くかもしれない素朴な質問をすることができます（私は多くの個人的な例がありますが、私は長すぎますむしろ私のブログに記事を書いてください）。

他のことは、技術的な記事を読むことで、新しいフレームワーク、新しいアーキテクチャのパラダイムなどの分野の進化について一般的な認識を得ようとすることです。私はいくつかの統合テストに参加し、自分でドキュメントを作成します（プログラマーが嫌いなものを私がやるので、もちろんコアを教えてくれます）、チームを支援するために実際にできることなら何でも。

一般的に、開発者はハードワークをしているように感じますが、それは本当です。抽象化を維持することで簡単なことをしているとよく言いますが、それでも必要に応じて具体的に助けようとしています。干渉感を生じる可能性があるため、どちらも良くありません。

結論として、開発者とのスローガンを排除し（実際にはDemingの14の原則の1つです）、ドキュメントや上級管理職とのミーティングだけではなく、プロジェクトの具体的なソフトウェアに関心があることを示します。