私はマネージャーです。仕事上の関係とプログラマーとのコミュニケーションを改善するにはどうすればよいですか？
最初に少し背景。私は中規模企業のプロジェクトマネージャーです。私はCS専攻から始め、プログラミングに少し触れたことがありましたが、数か月後には自分の道ではないことがわかったので、管理職に切り替えました。それは良い決断であることがわかり、卒業後、さまざまな企業でソフトウェア管理に携わってきました（5年間）。
最近、非常に苦しいプロジェクトがありました。これは最悪の最悪の事態であり、当社側と顧客側の両方で多くのミスがあり、ほとんど損失なく終了しました。それは多くの苛立たしい状況を引き起こしました。そのうちの1つは、私たち（経営陣）との口頭での議論の後に、上級開発者の1人が会社を辞めるところまでエスカレートしました。これは私にとって赤信号でした。私はひどく間違ったことをしました。 （記録のために、議論はいくつかの誤った時間推定についてでした）
私は多くの場所で答えを探し、友人が私をこのサイトに案内してくれました。ここでは、経営者への不満について多くの質問があります。一般的な悪い経験は、「訴訟を起こしている人」に対する一般的な抵抗につながることは理解できます。
私はスーツを着たあの男です。それはそのように見えないかもしれませんが、私が欲しいのは成功するプロジェクトだけであり、限られたリソースでそれは苦痛な決定をします。それが私の仕事です。前述の上級開発者が不満を感じたことの1つは、作業機材でした。率直に言って、私たちが持っていたコンピュータが作業に適していないことを知りませんでした。この後、私は多くのプログラマーに尋ねましたが、一般的なコンセンサスは、より良いマシンが必要だということでした。それ以来それを修正しましたが、私とプログラマーの間には明らかに大きなコミュニケーションギャップがありました。最も優秀な開発者の一部は、最も内気でサイレントな人々です。私はそれを知っています、そしてそれは面接の間決して問題ではありませんでした。人はそれぞれ異なり、さまざまな分野で強みを持っています。
パワー不足のPCのケースは、通信の問題があると私が考えるようになった多くの1つにすぎません。威圧的で反復的ではなく、プログラマーとのコミュニケーションを改善するにはどうすればよいですか？
私が望んでいるのは、人々が良いことについて文句を言わないことです。あなたがあなたの職場を愛し、そしてあなたのマネージャーを愛しているなら（または少なくともlike :)）、それらについて教えてください。彼らは何をしているのですか？同様に、嫌いな人はその理由を詳しく説明してください。私はそれが私の問題だと思うので、コミュニケーションの改善についての回答を探していますが、私は間違っているかもしれません。
うわー！質問してくれてありがとう。技術的には、あなたのように、私は管理者だと思います。私はコードを書くよりも、コミュニケーションやチームの指揮に多くの時間を費やしているからです...しかし、これは管理の水平線の両端からの私の見解です。私が開発者であろうと別のマネージャーのために働いているマネージャーであろうと、私の経営者とのコミュニケーションに役立ついくつかのものがあります：
- なぜですか？は非常に重要な質問です-ほとんどすべての事実に基づく回答には「なぜ」という背後にあり、「なぜ」は実際よりも重要である可能性があります質問。これにはいくつかの正接があります：
- 開発者の理由-開発者には、経営者にとってまったく意味のない多くの答えがあります。私は確かにそうしました、そして私が管理に入る方法の1つは、管理が理解できる言葉で「なぜ」チームを説明するのが本当に上手でした。 「オタクのスピーカー」が手元にない場合は、より一般的に理解されている比喩で「なぜ」の質問に対する回答を言い換えることで、オタクを話すことを学ぶことができます。何が起こっているのかを理解して同意するまで、それを守ってください。
- 経営上の理由-あなたの「理由」も同様に重要です。なぜ時間の見積もりが必要なのですか？何に使うの？彼らが高すぎる、または低すぎる場合、私たちは会社としてどの程度ねじ込まれますか？これは、マネージャとしてのあなたがおそらく鋭い洞察を持っているものですが、これはすべて開発者にとってはブードゥー教です。トリックは、開発者が尋ねないかもしれないということです。経営陣は彼に何かを要求しました、そして彼は彼が正確でタイムリーで思慮深いようにできる限り最善を尽くすつもりです-しかし、彼が「なぜ」彼が知らないなら、彼はあなたがしたくないよりもあなたが望む方法で最適化するかもしれません。理由を説明し、彼に同じことをするように頼んでください-自分の言葉で答えを言い直してください。同様に、ビジネスの理由について説明します。多くの場合、開発者は気にしますが、ビジネス開発の仕組みについて直接の知識はありません。誰かにボランティアを依頼することは、この情報に動機づけと啓発の両方をもたらします。
具体的には時間の見積もりについて-私は1トンもしなければならなかったので、開発チームに言うことから絶対に利益を得ています。「給与を支払うためにより多くのお金を求めるつもりなので、これが必要です。私があなたの言うことを信頼し、私はあなたの番号を使用します...つまり、あなたが私に負けた場合、私はもう一度お金を要求することができないので、私たちはすべてねじ込まれています-私たちは提案したものと一緒に暮らさなければなりません。」そのような状況で、開発者は、自分がどれほど自信があり、見事であるかを見せようとした低い見積もりから、実際の期待設定にかなり近づいた高い見積もりに変わりました。
誰も間違っていない-「なぜ」の質問は当然の結果で長くなります-「それはとんでもないことだ！」と言う代わりに「なぜ」を尋ねる会話をスムーズに保ちます。時々、誰かが尋ねられていることと質問者が尋ねていることの間に深刻なつながりがない。私の最高の経営陣は私の答えにひどく驚いており、驚いたとき彼らは驚いて瞬き、そして「なぜあなたはそれを言うのですか？」と尋ねます。彼らは（すぐに）「あなたはそれを変更する必要がある」とは言いません。競争上の目標を達成するために提案の数を減らしましたが、どのようにしてシーンを変え、質問に対して異なるコンテキストを作成できるかについて激しく話し合った後でのみです。
周囲のノイズ、単語の選択、単語間のスペースを聞きます-これは、私が気に入って盗んだもので、自分自身を使用するためのものです。
- 作業エリアにたむろして、あなた自身の生産的な何かをして（開発者の仕事に参加しようとしないでください、彼らはあなたが開発者でないことを知っています）、ただ聞いてください。チームはどのように問題を解決しますか？彼らの大きな問題は何ですか？あなたやあなたの経営者の直接的な評価で本当の細い音を聞くことは決してありませんが、問題のある領域がどこにあるのかを本当によく感じるかもしれません。あなたが生産的であるあなた自身の何かをしていることを確認してください。スパイを好む人はいませんが、士気が低く、全員が避難している状態で近くにいることができない場合を除き、近接環境での生産性は許容できるはずです。
- 単語の選択を探してください-それらはしばしば単語そのものと同じくらい重要です。特にポジティブな言葉やネガティブな言葉を使用した場合、よく知らない状況でなぜこれらの言葉を選んだのか、経営陣からよく聞かれます。
- ポーズ、ギャップ、ボディランゲージを探します。自分と開発者の間に力の距離がある（そしてあるように聞こえる）場合、彼らはあなたに矛盾したり対立したりしたくないかもしれません。しかし、「おお、あなたは間違っている」と言う基本的な本能は、通常どこかに現れます。
できるだけ多くの通信媒体を開きます-直接、電話で、電子メールで、IMでチャットする準備ができています-確立するものすべてコミュニケーションの流れ。人々は非常に多様であるため、1つのトリックだけではうまくいきません。そしてそれは、開発者ではなく、マルチフォーマットのコミュニケーターになることをマネージャーの仕事と考えています。
話しかける価値があるようにしてください誰かが問題について、そしておそらくは可能な解決策についてあなたに言った場合、彼はあなたがマネージャーであることをおそらく受け入れ、したがってその可能性があります別の解決策を選択するか、まったく解決策を選択しないことをお勧めします。しかし、3回目以降はこれが起こります。特に説明なしで起こった場合、約99％の人々はあなたに何かを話すのをやめます。
そして、これは私にとって信じられないほど難しいですが、私がそれを行うことができるときは素晴らしい働きをしました-内向的と外向的の違いに注意してください。おそらくあなたは外向的です-それがあなたの仕事が良いように見え、開発の立場がそうでなかった理由です。開発者は、ほとんどの場合、内向的です。 「内向的」とは「通信できない」という意味ではありませんが、パターン、プロセス、速度が大きく異なり、絶え間なく通信するという衝動は事実上存在しません。時間と静かな（ただし同じ場所にある）スペースで計画を立て、内向的な考えが出てくるようにします。私の内向的な友人の多くは、彼らが考えをまとめて応答できるように、私が「5分ほどシャットダウン」するのを待っているだけだと言っています。同じことに関するいくつかの素晴らしい記事を以下に示します- 外向性者が内向性について知っておくべき5つの事柄 および Rands in the Repose on the Nerd Cave-特に開発者向けの、内向的な人にとって素晴らしいことの例 =。ところで、Randsはかなり素晴らしいです。彼はオタクなので、自分のスタイルではない場合は見当違いかもしれませんが、彼は面白いし、チーム開発に関して本当に良い洞察力を持っています。
私の好きなマネージャーについて私が一番好きだったのは：
彼らは私と同じように（それ以上ではないにせよ）プロジェクトに深くコミットし、興奮していた
彼らが私の背中にいることに疑いはありませんでした。彼らが次のレベルの権威の前にいるとき、私（または私の同僚）がスケープヤギになることはないことを確信していました。失敗があった場合、それは常にグループの失敗です。
私は当時、自分のスキルに重要で適切な何かの所有権を与えられましたが、自分のスキルを拡大して仕事を成し遂げるのに十分なリソースがありました。
彼らは私を個人としてもチームの一員としても見ました-彼らは私の強みと弱みを知ることに積極的に取り組み、私が自分の強みを発揮し、弱みを増すのを助けるために働いていました。
彼らは私の個人的な目標を認識していて、できる限りそれらを組み込むことに興味を持っていました
私を幸せにすることは優先できなかったし、そうでなかったときに彼らは前向きでした。 「この種の仕事が嫌いだということは知っていますが、やらなくてはいけません-永遠に続くことはありません...」を聞くことには真の価値があります。
全体像を説明するために、常に1週間に1時間がありました（たぶん、現時点ではありません）。
ほぼ一定のフィードバックとステータスがあり、指差しはありませんでしたが、個々の作業には十分な認識がありました。
常に真実がありました。何かがデリケートで議論できない場合は、空欄にしてください。何かが不確かなら、彼らはある程度の自信を与えた。
最初の簡単な部分：投稿に技術的な危険信号があります：「誤解した見積もり」についてのあなたの言及に私は身震いします-それは見積もりですCANNOT BE MISTAKEN、それが見積もりと呼ばれる理由です。少しずれている場合もあれば、大きくずれている場合もあります。そのため、見積もりと呼ばれています。ゴスペルとして見積もりを取る場合、それは「あなたの」開発者があなたのスタイルで抱えている主要な問題の1つになるでしょう。
ただし、開発者とのコミュニケーションの難しさについては100％同意します。プロジェクト管理トレーニングの開発者として、私は数年前に啓示を受けました。オープンディスカッションの雰囲気が生まれた後、仲間の開発者の何人かが絶対に管理職に背を向けているのを見ました（管理職はここにいた）。間違ったことはすべて、開発者の目にはマネージャーの責任でした。キッカーは、経営者がその日に提起された大きな問題のほとんどすべてについて何も考えていなかったということでした。開発者たちは、経営陣が見逃すことはあり得ないほど明白であると想定していました。経営陣は、開発者が彼らに必要なことを伝えると想定していました。
したがって、私見の答えの最初の部分は、開発者にあなたが超能力的ではなく、実際には技術的な側面に関してはまったく愚かであることを知らせる必要があります。あなたは頼りにして、頼りにして、彼らがタイムリーにあなたのところに来るのを信頼しています。あなたは彼らの生活をより難しくするためではなく、より簡単にするためにそこにいます。
そして、あなたが何をするにせよ、実際には答えを知りたくないような質問をしないでください-上記の「誤った見積もり」を参照してください;-)。それは開発者のクリプトナイトです。
ここには良いものはたくさんありますが、次のことを言う必要があると思います... ..辛くて申し訳ありません...しかし、これは言う必要があります：
- PMとして5年、開発者がどのようなPCを必要としているかを知らないのは、とんでもないことです。
- 開発者にquitを最初の真の赤旗として悪い労働条件のためにさせることは、狂気です。
あなたが持っていると私が思うのは信頼の問題であり、コミュニケーションの問題よりもそうです。あなたがその情報で何をするかを信用していないので、誰も何が間違っているのかはわかりません、そしてそれが彼らに対して使用されることを恐れるかもしれません。これらすべての問題についてあなたに言った開発者はそうしましたそうすることに結果はなかった、と彼はやめた。
個人的に私は決してPM彼のバックグラウンドで開発の経験がなかった人を雇うことはありません。あなたの次のプロジェクトでは、と思いますあなたはあなたの時間の一部を開発チーム。週8時間、チームリーダーの下でJr開発者として働いています。
これは、開発チームのダイナミクスに本当にあなたの目を開きます。なぜなら、今のところ、あなたはそのチームの一部でもなく、部外者だからです。あなたの開発者の辞任があなたに衝撃を与えたという事実は、それを証明しています。チームの誰もが彼が不幸であることを知っていました。そして、彼らのうちの一人もあなたに言っていませんでした：
「あなたが何かをしなければ、私たちは私たちの最高の男を失うでしょう」
それは赤い旗＃2でなければなりません。
マネージャーとして、kaizen、つまりトヨタ生産システムの理念の1つであり、継続的な改善を意味することを聞いたことがあると思います。
あなたは問題があることを認めたので、それは素晴らしいスタートです。
Kaizenには5つの主要な要素があります。
Quality Circles：会社の運営のあらゆる側面に関する品質レベルについて話し合うために集まるグループ。
モラルの向上：従業員間の強いモラルは長期的な効率と生産性を達成するための重要なステップであり、カイゼンはそれを一定に保つための基本的なタスクとして設定します従業員の士気との接触。
チームワーク：強い企業とは、あらゆる段階を結集する企業です。 Kaizenは、従業員と経営陣が競争相手ではなく、チームのメンバーとして自分自身を見るのを助けることを目指しています。
個人的な規律：チームの各メンバーが自分自身で強いでなければ、チームは成功できません。各従業員による個人的な規律への取り組みは、チームが引き続き強くなることを保証します。
改善のための提案：チームの各メンバーにフィードバックを要求することにより、経営陣はすべての問題が重大になる前に、それを調べて対処することを保証します。
（ ソース ）
これを長期的に見れば、これらの要素に対する定数はチームワークとフィードバックに重点を置いています。
一例として、時間の経過に伴う議論があったとします。あなたはそれらの時間の見積もりに責任がありますか？それについてチームと話しますか？申し訳ありませんが、マネージャが自分の番号から番号を引き出すのを見てきました。重要なことの1つは、時間をかけてhaggleチームがあなたに与える推定を決してしないことです。多くのマネージャーは、チームがもっと頑張れば短い時間の期限を守ることができると想像しています。これは嘘です。 9人の女性が1か月で赤ちゃんを産むことができません。
だから、私の最初のアドバイス：
聞く：チームへの簡単な電子メールから始めます：「開発チームが管理パフォーマンスについて管理にフィードバックを送るための最良の方法は何ですか？ ？」チームで繰り返し、コンセンサスを実装します。あなたの仕事は、チームが素晴らしいソフトウェアを開発できるようにすることです。これを覚えておいてください。
誠実さと忠誠心：誰かがあなたが何かを尋ねたときに誰も答えない場合、それは彼らがあなたが聞くことを信じていない、または最悪の場合、彼らがあなたを信じているからですそれらのためにそれらを罰する。正直に言うと誰かがあなたが吸うと言った場合、これをフィードバックとして受け取り、復讐をしないでください。彼らの理由を理解し、それを改善してください。
そして、ついに、私はそれについてここでいくつかの批評を見てきましたが、 The Mythical Man-Month：Essays on Software Engineering と呼ばれる本を読むことをお勧めします。この本は、OS/360の開発を管理するIBMでのフレッド・ブルックスの経験について書かれています。ここにはいくつか古くなっているものもありますが、複雑なソフトウェアの開発プロセスがどのように機能するかを理解するための最初のステップです。 S.Lottは Agile Manifesto を引用していますが、私は特に熱心ではありませんが、読む価値もあります。
これを読む：
プロセスとツールに関する個人と相互作用
包括的なドキュメントに対応する実用的なソフトウェア
契約交渉を介した顧客のコラボレーション
計画の転換への対応
多くの場合、組織（つまり上司）は、
明らかに壊れたプロセスに従って、「死の行進」につながる論理的な結論を導きます。これは今度は議論と辞任につながります。
過剰で価値の低い未使用のドキュメントを作成します。
複雑な変更管理a/k/a契約交渉に従事する。すべてのユーザー変更には、変更を「品質」および「優先順位付け」するための入念な儀式が必要です。本当に、それはすべて「凍結」、つまり変更を防ぐことに関するものです。
結果に関係なく計画に従ってください。一部の組織では、壊れた（または役に立たない）ソフトウェアの予定どおりの配達を重視しています。重要な計画であり、ビジネス上の問題の解決策ではありません。
問題はあなたの個人的なコミュニケーション能力ではないかもしれません。
開発の「環境」または「方法論」全体が致命的に壊れている可能性があり、悪い感情は一般的な悪い習慣の症状にすぎません。
私にとって、これはあなたが簡単な雰囲気の中で開発者と話したことがないように聞こえます。彼らとのあなたの会談は単に公的な性質のものでしたか？それは残念です。
それらを個人的に知り、会社、職場、プロジェクトの良い点と悪い点を知りませんか？彼らを尊重し、彼らの仕事に対する誠実な関心と感謝を示すことによって、彼らの尊敬を得ます。
彼らがあなたを信頼し、ポーンのオファーであることを恐れる必要がない場合、彼らはおそらくあなたに魅力のない真実を伝えることさえします。
私はチームリードであり、私のチームは私を信頼しています。私は彼らを守ります。私はすべての責任を負い、その名声を彼らと共有します。私たちの管理は私を守ります。それは士気を高めます。私たちは本当に難しいプロジェクトとほぼ邪悪な顧客を持っていて、完了するのはほぼ不可能でしたが、すべてを非常に率直かつオープンな方法で話し合ったので、最終的にそれをやりました。
クラップ！クラップ！クラップ！あなたは確かに良い人であるべきです。なぜなら、あなたは仕事でより良くなるために何ができるかを見るためにオープンに出てきたからです。
優れたマネージャーで私が目撃し、シニアメンバーとしてチームを率いるときに個人的に採用したことを以下に示します。
- [〜＃〜] m [〜＃〜]管理以上のものを入力します。
- [〜＃〜] a [〜＃〜]チームメンバーが自分の考えや懸念を表明できるようにします。それに耳を傾けてください。建設的なものを取る。
- [〜＃〜] n [〜＃〜]分裂的な政治を行うことでチームメンバーを裏切る。これはより早く静かに逆火します。
- [〜＃〜] a [〜＃〜] ngerではありません。チームと一緒にいるときに顔をしかめっ面にしないでください。これは本当に難しいです。
- [〜＃〜] g [〜＃〜]受賞者の優れた業績を熱心に率直に感謝します。同じように、責任を負う人に、オープンな状態ではなく、責任を持った人に、作業を非常に柔らかく戦術的に批判します。
- [〜＃〜] e [〜＃〜]すべての個人の所有権とリーダーシップを奨励します。彼は尊敬されると感じるので、これは人の士気とコミットメントを向上させます。
- [〜＃〜] r [〜＃〜]たまにチームと歩き回ります。これは、チームメンバー内の結合を誘導/増加します。
誠意をこめて頑張ってください:)
一般に、塹壕の中の男たちは、状況を修正することができるし、修正しようとしている人々が自分の不満を聞いていないのを感じると、反感を感じ始めます。彼らが会社での地位を危険にさらすことなく彼らが不満を感じることができるとさえ感じないとき、それはさらに悪いことです。
私は理論-Yのような人で、ほとんどの「知識労働者」はそうである傾向があります。機会があれば、私たちは仕事が好きで、うまくやりたいと思っています。ただし、理論Yの職場の欠点は、問題があることがすぐに明らかにならない可能性があることです。なぜなら、うまくやりたいので、波を作りたくない人々は、その問題の周りに方法を見つけるか、単に無視するからです。これはうんざりする欲求不満につながり、最終的にはチーム全体の顔に爆発します。 Theory-Xのマネージャーが経営するショップには、おそらく以前に不満を言う人がいるでしょう。従業員はお金のためだけにそこにいるので、仕事がいつもよりも多くを吸うなら、彼らは不満を抱くでしょう。
あなたが何ができるかに関しては、仕事をしている部屋で高齢者とリードがいる環境では、それらはあなたの最高の資産です。彼らと話してください。週に30分の「双方向」をスケジュールする場合があります。ここでは、リードがプロジェクトの日常に関する更新と空気の懸念を提供し、ビジネス側に更新を提供し、懸念を解決するために計画を立てますチームに深刻な影響を与える問題になる前に。
アジャイルでは、各「スプリント」または「反復」（通常は1週間から3週間続く開発作業の単位）の最後に、最も若いメンバーからPMまでのチーム全体が「回顧」彼らは何をしたか、何がうまくいったか、何が失敗したかを振り返り、続けなければならないことと変更すべきことを識別します。いくつかのフォーマットがあり、独自に作成できますが、レトロの結果として、人々は自分の声が聞こえたと感じ、結果として物事が変化するはずです。
アジャイルについて話す;私の最初の仕事は小さな会社でした、そして「小さな」とは、会社全体がソフトボールチームを戦うことができなかったことを意味します。私が始めたときは4人のプログラマーがいて、去る前は2人に減っていました。創業者、社長、最高経営責任者、そして会社の95％の利害関係者は、それを鉄拳で支配し、彼は組織の計画の唯一の情報源でした。上司は仕事中毒であり、他の誰もがそうであると期待していました。あなたがしなければならないすべてのものは彼の期待とほぼ同じでした、そしてこれのために彼は10年間彼のために働いていた人々に初心者レベルの給与を支払いました。
私はその会社を辞めて、まったく違うことをする別の会社で働き始めました。彼らはSCRUMアジャイルの基本的な方法論を実践し、毎日のスタンドアップ、ペアプログラミング、スプリントチーム、回顧展を行いました。各スプリントの開始時に2週間ごとに1日間、私たちは次の2週間の作業を計画するしかありませんでした。別の日の大部分については、私たちは自分たちがしたことを振り返り、チームとして改善する方法を見つける以外に何もしませんでした。マイクロソフトMVPである私の隣に座っている開発者がいて、仕事を成し遂げ、私がやっていることを励まして補完していました。
夜。そして。日。主な違いは？最初に、私はプロジェクトのために自殺することを期待されているように感じませんでした。アジャイルの基本的な信条は、持続可能な開発のペースです。第二に、自分の仕事をどのように行うことが期待されるかを決定する際に発言権がありました。私は仕事をしなければなりませんでしたが、次のスプリントで引き離すと予想されることについて「胸焼け」があった場合、その意見を表明でき、それが聞かれ、重みが付けられました。もっと良い方法があると感じたら、私はそう言うことができ、楽しまれるでしょう。
解決策を見つけて問題を解決する限り、トップダウンで作業しているように見えないように注意する必要があります。コンピュータ用;あなたのRMR（定期的な月収）は、会社が2週間に4台のコンピューターをアップグレードすることのみを許可していると言います。最初の4台のコンピュータはすべて、幹部や先輩に行くべきではありません。彼らは最も遅いコンピュータを持っている人々に行くべきです。チームにボーナスを与える場合は、「私たちの貴重な先輩と見込み客に、これがなければ実現できなかっただろう」だけにボーナスを与えないでください。開発チームの誰もがそれを実現しました。ジュニアが不満を持っている場合は、彼に聞いてください。彼が後輩だからといって、彼が何も知らないというわけではありません。
関係の改善：
難しいプロジェクトがあっただけですか？その後、彼らに休憩を与えます。リラックスして息をのむための休暇。
コーダーの権利章典これらは与えられたものです。言うまでもなく行くべき基本的なこと。これらに違反すると、コードモンキーを悪用していることになります。
ジョエルテスト私はそれらのほとんどに同意します。しかし、いくつかは本当に依存しています。いくつかが足りない場合、おそらくプログラマーの生活をより困難にするでしょう。
技術的負債 。したがって、完了のためにプッシュすることができますが、コーナーをカットすることによって、後日修正するのに時間がかかる技術的負債を負う。プロジェクトの終了前にその日付が表示される場合は、本当に失敗しています。
RSA animate：Motivationこれは、ナレッジワーカーのやる気を高める方法を実際に示す素晴らしいビットです。
彼らが望むものをコーディングする自由な日。RSAビデオから。名前を覚えていないが、それが言及する会社は彼らのサイトでそれについて短い説明をしている。私には良い考えのようです。ほとんどの店で誰もが逮捕されていることを知っているものがありますが、誰も修正する時間はなく、それは高い優先順位ではありません。これにより、技術的な負債に取り組むことができます。また、素晴らしいアイデアを披露することもできます。
そして、神の愛のために、週に40時間働くようにしてください。また、フレックスタイム。フレックスタイムは、でたらめの世界全体を埋め合わせることができます。少なくとも私にとっては。
プログラマーと上司の間のコミュニケーションの改善
それは私にとってより難しいです。その全体をなめらかにすることは、プログラマーの焦点よりもむしろボスのスキルセットです。時間の見積もりのようないくつかの基本的なことは単なる見積もりです。水の上を歩いて要件を満たすことは、凍っていれば簡単です。たぶん、恥ずかしがり屋のプログラマに、コードレビューなどで自分のプロジェクトについてプレゼンテーションをするように頼むかもしれません。練習は完璧だよね？しかし、私はこれについて他の人の忠告に屈するだろう。
「同様に、嫌いなら、その理由を詳しく説明してください。」
これで、水門がここに開きます。そして、明らかに自分にリンクされる可能性のあるopenIDを使用していなかったとしたら、おそらくそれもベントするでしょう。すべきでないことの巨大なリストが本当に必要な場合は、匿名の投稿に対してよりフレンドリーなフォーラムで質問してください。
私はいつも、一般の人々があなたを治療するよりもあなたを治療しないことを常に発見しました（彼らはあなたをより悪く治療するかもしれませんが）。私は個人的に（私は開発者です）、正直に誠実に、尊敬に敬意を払い、信頼に基づいて信頼するなどしています。中立的な雰囲気の中でチームと非公式のチャットをして、私たちに今言ったことを伝えてください。有毒な「私たち対彼ら」の環境で忘れられるポイントは、それがすべきすべて "私たち"であることです。管理者と労働者の両方がそれを知る必要があり、企業はそれをサポートする必要があります。
幸運を。
これで、フィードバックを受け入れるだけでなく、フィードバックに基づいて行動した実績のある記録が得られました。あなたはより高い意思決定者に影響力を持ち、チームのために物事を成し遂げることができることを実証しました。それは大きな違いを生みます。プログラマーはもっと内向的ですが、プログラミングについて話したいと思います。非公式な環境はいいですが、誰もがプロである必要があります。人々が一部を発散できるようにしますが、話し合いが生産的なものであり、単なるビッチセッションではないことを確認してください。
私の経験から、私のマネージャーが好きか嫌いかという最も重要な要素は、マネージャーが開発全般を理解し、私がしている仕事を理解しているかどうかです。いくつかの肯定的な結果がここにリストされています：
- 変更に時間がかかる、または実行できない理由を正当化するために、多くの時間を無駄にする必要はありません。まあ、技術的には、どんな変更でも実装でき、上級管理職は通常、何らかの方法で実装を要求します。しかし、少なくともそのような状況では、直属の上司はあなたの側にいて、（あなたを押し倒したり、燃やしたりするのではなく）より多くの時間を求めます。
- 悪い状況（WTFハック、プロダクションの問題など）の場合にサポートされる可能性が高いことはわかっています。通常、技術者ではない人は開発者をそのような状況のせいにする傾向がありますが、優れたマネージャーは実際に何が起こっているのかを理解し、開発者をサポートします（ニースであると知っているか、そうするつもりはありません）。
- 私の仕事とパフォーマンスは適切な人によって評価されることを知っています。
私の意見では、プログラミングをこれ以上行わず、通常は厳しいプロジェクトスケジュールまたは予算で行う場合、開発者が好きになる可能性は非常に低くなります。その場合は、すばやく上に移動し、他の誰かが直属の上司になるようにしてください。申し訳ありませんが、この段落では悪いように聞こえましたが、それは私がそれを見る方法です。あなたは良い人のようで、真実に値する。
開発者の幸福の生産性はすべて、ささいなことに帰着すると信じています。数学は管理のためにかなり素晴らしいです。午前中にドーナツ（-25セント）をください。一日中2倍（+ドル）頑張ります。私たちが不満を持っているときにゆっくり作業することによって積極的に物事をサバトゲすることではなく、非常に複雑なシステムで作業していて、何かに不満を感じているときに集中することが非常に難しいということです。怒っているときはコードを書かないほうがいいでしょう。
ただし、見積もりは自分で対処する必要があります。 私が持っているすべての問題は、非現実的な見積もりを除いて、ドーナツを渡すことで解決できます。これは開発者の見方です。管理者には、新しいボートのように、より短い見積もりですべてを得ることができますが、開発者には失うもの（1か月分の睡眠など）があります。経営陣が担当するので、彼らは毎回推定戦争に勝つ。見積もりシステムは、開発者が期限を決定するときに最適に機能すると思います（正確な見積もりを出すのは難しいので、マネージャーはどうでしょうか？）。少しずれている。
私もスーツを着た男の1人で、15年以上の経験があります。私は最初はソフトウェア開発者でしたが、機会があればコードを書きます。だから私は双方のために話すことができると思います、そして私はこれらの状況で少し経験があります。また、「今年の従業員」など、スタッフが選出した資格を持っているため、これらの状況への対応に自信を持っています。
私が頻繁に目にするのは、経営陣と開発者の間で取られる価値体系と運用方法/アプローチに実質的な違いがあることです。
多くの開発者にとって、誠実さ、正直さ、さもなければ柔軟な作業環境が非常に高いリストです。残念ながら、非常に同じ値は、トップマネジメントのリストではそれほど高くありません。そして、これは必然的に巨大な衝突につながります、特に中間管理職（あなたと私）が完全にトップ管理側を取ることに決めた場合。これを回避する唯一の方法は（私の観点から）、チームの前にしっかりと立ち、彼らを全面的に支援し、オープンコミュニケーションを通じて信頼関係を構築することです。そして最も重要なのは、あなたが言っていることを実行することです（これは、政治が誠実さを完全に圧倒するトップマネジメントから得られるものの多くの場合反対です）。
同時に、自分自身を運用し続ける必要があるため、トップマネジメントが理解し、ゲームをプレイする言語でトップマネジメントに連絡する方法を見つける必要があります。それが中間管理職の真の挑戦です。
質問、コメント、または懸念がある可能性のあるプログラマーにどのような反応を示しますか。 「何が欲しいですか今？」または「なぜthisで私を悩ませているのですか？」一種の反応？開発者に懸念やコメントを表明することをどの程度うまく勧めていますか？ただし、これは単なる出発点です。
第二に、あなたがこれらの議論をしようとしているところに注意してください。私のマネージャーがすべてのことを聞いている範囲内にいることを知っていれば、次のキューブの誰かと私の作業機械について話し合うことは非常に率直であるとは思えません。あなたが人々に率直で正直なフィードバックを与えたいのであれば、彼らの答えが公に放送されたり、彼らに対して使用されたりしないことを知るためにいくつかのプライバシーが与えられなければなりません。
第3に、どのような Emotional Intelligence スキルを持っているかを検討します。 プロジェクトマネージャーのための感情的知性：優れた結果を達成するために必要な人々のスキル アンソニーメルシーノ著は、私がランチから得た本の推奨事項であり、EQについて学びます。ここで本当に心理学を深く知りたい場合は、さまざまなパーソナリティプロファイルツールを使用できます。エニアグラム、ソーシャルスタイル、MBTI。
最後に、あなたの会社の文化は何ですか。間違いは敷物の下で一掃されますか？苦情は誰かを本当に簡単に困らせることができる大きなノーノーですか？どのような行動が報われたり奨励されたりし、どの行動が許容され、受け入れられますか？この一部は観察ですが、一部はオフィスから離れて、または盗聴されそうにない部屋で開催する必要があるいくつかの会話も必要とする場合があります。あなたは最初にこれを使おうとすることでおそらく繰り返します。文化が主に誰もが「それを吸い込む」ことを知っている文化であった場合、新しい慣習を確立して人々に意見を表明させようとするのであれば、それは悪いことではありません。これは他の回答よりもかなり手間がかかるかもしれませんが、これについて私が作業している場所について尋ねられた場合、これは私が回答に与えるものです。
開発者として私は主要なオタクであり、社会的スキルに欠けています。私はそれについて謝罪しません。結局のところ、私は才能であり、あなたは私の才能のために私を雇いました。仕事にソーシャルバタフライが必要な場合は、開発者ではなくプロジェクトマネージャーでいっぱいの部屋ができます。
一部の開発者は非常に社会的に賢いことを知っていますが、中央値は内向的なオタクに傾いていると思います。
誰かが私に何かをするように要求するとき、私はまったく推論をせず、要求されたものを正確に行います。一部のプロジェクトマネージャーの場合、プロジェクトについて推論することは絶対にしないと期待しているため、常に問題が発生するようです。そのため、正確に何であっても、期待どおりに結果が得られないことがあります。彼らは要求した。これが一部のプロジェクトマネージャーで発生する理由は、彼らが高品質のHLD、BRDを提供せず、白黒ではなくプロジェクト管理の社会的側面にあまりにも多くの価値を置くためです。
これが世界がぶつかるところだと思います。プロジェクト管理の世界では、社会的スキルと個人的な率直さの質が重要な要素だと思いますが、私のような開発者にとっては、それはまったく何の意味もありません。このタスクまたはそのタスクがどれほど重要であるかについてあざ笑うことは、私には感心しません。ランチやビールに出かけたくないのです。
私が本当に欲しいのは、良質で高品質のHLDとBRDです。達成可能なスケジュールと期限が必要です。新しい設計や計画が導入された場合は、スケジュールと期限を再調整してください。私は要件がその場で変化するように見えるプロジェクトに取り組んできました-これは私が質の悪いプロジェクトのリーダーシップを扱っているという私の赤い旗です。開発者としてあなたができる最悪のことは、特に私たちがすでにスケジュールを持っているか、またはスケジュールの約束をした後で、毎日新しいプロジェクト要件を私に持ってくることです。新しい要件が提出されたときは、納期までの補償なしでは耐えられません。作業時間を増やし、作業時間を遅らせても問題はありませんが、開発に関して常に定量的とは言えません。一部の変更は数時間かかる場合があります。一部の変更は、適切なR＆D、テスト、QAなどに数週間かかる場合があります。これは、常にケーキを焼くようなものではありません。要件に対する単一の変更が、レシピ全体を変更するような場合もあります。プロジェクトマネージャーが落ち着き、電話会議でかんしゃくを起こしているのを目撃しました。締切では追加の開発が許可されないためですが、当初のプロジェクト要件になかった開発を求めています。
私は自分の個人的な偏見と経験を例としてのみ示すことができるので、私がすべての開発者の代わりに話していると推測しないでください。私は自分のキャリアの縮図を通してこれらのものを見るだけですが、この投稿は私がことわざを投げ入れる原因となった正確な状態を説明しています。
開発者はあなたが彼らの擁護者であると感じていますか？つまり、暴力を振るうことなく、懸念や不満を自由に共有できることを彼らは知っているということですか。彼らはあなたが彼らのために戦うと感じていますか？彼らはあなたが彼らの仕事に感謝していると感じていますか？彼らはあなたが本当に彼らのキャリアで成功することを望んでいると感じていますか？
彼らが感謝していると感じた場合は、おそらくより良いコミュニケーションがあるでしょう。
短くて甘い。あなたがしていることに秀でている-これはコミュニケーションを生むでしょう。
開発者にとって、excellingとはどういう意味ですか？ ..読んで、もう一度読んで、はい、勉強さえしてください PeopleWare
どのくらいの頻度で開発者と話しますか？プロジェクトステータスミーティング、成果物やその他のトピックに関する質問ではありません。プログラマーの1人と一緒に座って、進捗状況を尋ねる頻度はただ聞いてください。
他の多くの答えは本当に良いです-あなたはアジャイル開発を調べるべきです。開発者は、その役割を学び、成長する必要があります。しかし、実際に開発者が言っていることを聞いていない（または聞いていない）場合は、まずそれを処理する必要があります。
1対1の適切なリファレンス- http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html
私はパーティーに遅れましたが、この質問を見ました。
私が十分に対処されていないと私が思う1つのことはこれです：
うなり声は決して訴訟に真実をすべて伝えません。ランズはこれを [〜＃〜] dna [〜＃〜] で述べていますが、直接対処するのではなく、別のトピックを扱っています。
あなたはスーツを着ており、小切手に署名します。あなたは会社の利益を代表します。あなたはエンジニアの代表ではありません。あなたがそうした場合、あなたは彼らの小切手に署名しないでしょう、彼らはあなたの署名するでしょう。
もちろん、これはあなたやエンジニアにとってニュースではありません。しかし、エンジニアが特定の問題を提起することを知っている場合-彼の職場での問題-は重大な対立を引き起こす-リスクと報酬のトレードオフはエンジニアに有利ではありません。エンジニアは、製品を生産するために報酬を支払われ、職場の文化の戦いを開始するのではありません。それらに関与することは、間違った仕事をするための速い道です。
したがって、管理タスクの一部は、企業の政治やキャリアの反発を招くことなく、エンジニアが問題についてオープンになる方法を提供することです。結局のところ、引き上げがあったのはいいことです。他の会社も相性が良いと感じなければ、他にもあります（-===-）。
チームをビールに連れて行きましょう（そしてあなたは買っています）。
上記の投稿のすべての素晴らしいアイデアとコメント！
アイデアは次のとおりです。ITを送信してください。地元のコミュニティカレッジでのコミュニケーションワークショップのスタッフ-もちろん会社が支払います。
A）ワークショップの評判がよく、b）従業員を一緒に送らないようにしてください。彼らは一緒に固執し、他のクラスのメンバーと混ざり合う傾向があり、ワークショップの価値を低下させるだけでなく、他の人々に混乱をもたらします。
生産的なチーム指向のコミュニケーションは誰でも習得できるスキルですが、ほとんどの学問的な道のりには欠けていると私が感じる主題です。
このアイデアは決して魔法の弾丸ではありませんが、パズルの良い土台片です。同僚はお互いにコミュニケーションをとることができるようになるだけでなく、あなたの仕事をよりよく理解し、尊重し始めます（コミュニケーションはPMの中核です）。
ちょうど私の2ビット:)
あなたの質問と主題を正確に扱っているこの素晴らしい本について誰も言及しなかったことに驚いています "Peopleware：Productive Projects and Teams" by DeMarco and Lister 。社説から：ソフトウェア開発の主要な問題は技術的なものではなく、人間的なものです。アマゾンでの最初の3つのレビューは、私があなたの状況にあった場合、私にこの本を購入するように説得するのに十分です。
私は長年にわたり、開発者、上級開発者、技術リーダーなど、さまざまな役割を果たしてきました。
あなたの質問から-あなたが助けることができると彼らが考えていないのであなたの開発者があなたに何かを言わないのは非常に明白です。
これには2つの理由が考えられます。
- 彼らはあなたが物事を修正する力を持っているとは思わない。しかし、おそらくあなたはそれを知っているだろうし、開発者もあなたにそれについて愚痴を言うだろうから、これはありそうもないと思う。
- あなたは、開発者が問題を抱えたときに、次のことを1つ以上行う人です。
- 彼らが問題を抱えて来たとき、あなたは彼らに言います-私は問題ではなく解決策が好きです。
- あなたは彼らにきちんと耳を傾け、そして問題の修正を彼らに課します。あなたは彼らに、問題を解決する責任が与えられることは彼らにとって何の名誉であるかについて、説教をします。時間が経つと、問題のある場所に行くと余分な作業が必要になるため、問題が発生することはありません。
- あなたはそれが問題であることを否定します。あなたはこれについて説得力のある理由を与えます。しかし、これが発生し続けると、やがてあなたは問題であなたに近づく意味がないことをあなたの部下は学びます。
- 「はい、わかりました」と言います。あなたはこの種のことが時々起こり、誰もすることができないと言います。これがパターンである場合、あなたの連中もそれを理解している。
上記のいずれかまたはすべての場合は、修正する必要があります。
ここでの回答の多くは非常に良い点を持っていますが、役立つかもしれないいくつかのリソースを投入したいと思います。私はいくつかの状況で、関係者間のコミュニケーションのせいで、自分自身で大きな混乱に陥ったり、非常に効率的に解決されたりしました。特に本がたくさんあるストレスの多い状況では、3冊の本が私の個人的なコミュニケーションスキルの向上に役立ちました。
あなたの質問を読むことから、あなたはコミュニケーションの価値を理解していると思います。個人的には、コミュニケーションはビジネスや技術的なスキルよりもマネージャーやリーダーにとって重要であると感じています。あなたが主導している人々は、プロジェクトの大部分を完了するために必要なハードスキルを持っている必要があります。優れたテクニカルリーダーまたはプロジェクトマネージャーは、チーム内、チームとお客様、チームと事業体（またはこれら3つを組み合わせたもの）の間のコミュニケーションに集中できる必要があります。
技術労働力の視点を洞察する2つの優れた小説を読んでください。
- ハッカー、スティーブンレヴィ- http://en.wikipedia.org/wiki/Steven_Levy
- Microserfs、ダグラスクーランド- http://en.wikipedia.org/wiki/Douglas_Coupland
- 大聖堂とバザール、エリックレイモンド- http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar
これらは、管理に関する典型的な回顧録と同じくらい重要です（Drucker et al）。