チームを率いて、私は耐え忍んでいますか？
私は非常に奇妙な立場にいると思います。私は特定のプロジェクト、シニアソフトウェアエンジニアの役職で「チームリード」を務めています。私のチームには4人の開発者がいますが、そのうちの1人は別のプロジェクトで同様の役割を果たしていますが、現在、私の鉱山が優先されているため、彼は私の鉱山に取り組んでいます。また、テスターが2人います。1人はマネージャーです。チームのもう1人のメンバーは、完全に無関係な部門の一部である「顧客代表」です。私の真上にはマネージャーもいます。チームの一部であるテストマネージャーの上にもいると思います。
私の役割が正確に何回かである理由を明確にしようとしました。私が権限を持っているとしても、自分の権限がどこで始まりどこで終わるかを理解するのは私にとって困難です。私が現在取り組んでいる答えは、私がチームの「テクニカルリード」であるということです。これは、製品コード自体に関係するアーキテクチャ、設計、およびプロセス/コーディング標準に関する技術的な決定に対して私の権限が存在することを意味しているようです。
今日、何かが起こり、コードの結果をチームのメンバーの1人に委任しました。コードの結果は、私たちのスクラム見本市会議で会社の残りのメンバーに示されました。顧客代表者が自慢を披露します。今日は私が本当に同意しなかった何かが披露されました、そして何が起こったかについて発言したいかどうか誰も私に尋ねたことさえありませんでした。つまり、ユーザーが次の方法（ "doc"ユニット、デザインユニット、丸めではなく丸め）でレポートに値を表示する機能を提供するために、各順列にアクセスフィールドを提供しました。したがって、値は丸められたdoc単位、丸められた設計単位、丸められていない文書単位、丸められていない設計単位の値になります。ユーザーが操作することを望む各レコードには、そのような多くの値があり、各レコードはこの方法で並べ替えられます。
本当に嫌いです。
これを示した人々は、レポートに使用するAPIがデータをExcelにエクスポートするなどの方法と同じであることを確認したいと考えています。残念ながら、今私たちはこの勢いを本当に悪い方向に進んでいます。
私は次の会議で少し動揺しました、そしてこれをした二人に「なぜ私はこの決定に関与しなかったのですか？」と尋ねました。それは今後も続く問題であり、私が関与する必要があるかどうか私に尋ねるように私を導くことになっているチームの人々をちょうど得るように思われるのに苦労します。時々私はしません、そして彼らが思いついたものは何でもいいと思います。他の場合は私がします。人々が私に尋ねない限り、私の意見を必要とする何かが起こっていることを知ることさえ難しく、彼らは私にその機会を与えません。
残念ながら、私の権威は人々に「私と話をせずに自分でこのようなことをしに行くとき、あなたは懲らしめられるだろう」と言うことにとどまりません。これは「広報」の問題であり、私の権限の範囲にはまったく明確に含まれていない領域の1つです。他の人が喜んでそういうのがらくたに対処する必要がないので、それは実際には私には問題ありません。
今日、しかし、私のマネージャーは皆の前で（私がそうするようにそれを育てるのは私の責任でもあると思います）、私はすべての決定に関与することはできないので委任する必要があると私に言いました。
もちろん私は正しいと思います。私がBSだと思うことは言わない。私はこの問題についてアプローチされ、もっと良いアイデアがあるかどうか尋ねられるべきだったと思います。これは実際には新機能の非常に初期の段階なので、提供する値を1つに決定し、必要に応じて将来さらにアクセスできるようにするためのオプションについて話し合うことでした。私は現在の実装を承認したり推奨したりすることは一度もなかったでしょうし、実際にそれが日の目を見ることであるとは本当に思っていません。
問題は、私が無理なのか？
さて、私たち2人はそれについて話し、私たちは両方とも「ボールを落とす」ことに同意し、同じページにいるように見えます。月曜日の朝...チームでの私の役割が明確であることを確認するつもりです。そうすれば、設計またはタスクの変更がいつ必要になるかを判断できます。私は提案を受け、より深く見る必要があることに同意または決定します。次に、他のいくつかの作業を行って、彼らが私に来ることができることを彼らが確実に認識できるようにします。
ソースのコミットを監視する必要があるようです。 PERFORCEにはこの機能がネイティブであり、Gitにはフックを介してそれがあります。他のユーザーには独自のメソッドがあるはずです。すべてのコミットをニッピックする必要はありませんが、少なくとも通知を受け取り、それらを比較することで、プロジェクトに入るすべてのことを簡単に垣間見ることができます。
あなたが委任する必要があると言っているあなたのマネージャーに関しては、私が同意するかどうか私は確信がありません-4人の開発者のチームで、あなたはそれを処理することができるはずです。もう、私は彼（または彼女）の側にいるかもしれません。もちろん、委任されたタスクであっても、ステータスの更新や設計変更のウォークスルーなどを依頼する必要があります。
Nothing否定的ever会議で持ち出される-あなたとあなたのマネージャーの両方がこのボールにボールを落としたように聞こえます。ピアにできることeverの最悪のことは、恥ずかしいことです。リーダーとして（マネージャーと同様）、親しみやすく信頼できる必要があります。誰かを苦しめることは恨みにつながり、チームを導くあなたの能力を汚します（そして不満を持つ従業員につながります）。
I hate主導権を持つ人から「規律」という言葉を聞く。 （少なくともこのコンテキストでは）規律は否定的で生産的ではありません。作業中誰か（個人的であり、会議設定ではない）、理由彼らは何かをし、あなたが彼らの提案された解決策に同意しない場合の代替案を提供します。時々、あなたが一緒に働いている人が正しいとあなたの腸の本能が間違っていることがわかります。どうして？彼らはあなたが持っているよりもその特定の問題により多くの時間を費やしてきました。
他に気になるのは「私はいつも正しいと思う」です。 IMO、それはどんなリードからの最悪の可能な態度です。あなたは当然能力に自信を持っているべきですが、特定の問題に首を突っ込んでいなければ、多くの場合、提案は（あなたがどんなに経験があっても）あなたの後ろから出てきて、最高ではないかもしれません。特定の問題に集中しているis誰かが代替案を提供する場合、それはyour仕事（自分の経験レベルに応じて、自分の仕事も同様）からproveなぜあなたの方が優れているのか、単に「私は」と言うのではなくm先導し、私は常に私は正しいと思います」、これはあなたの文が私を信じるように導くものです。
まとめる
はい、あなたはいくつかの点では無理ですが、他の点ではそうではありません。リードとして、機能またはアーキテクチャの変更がある場合、それらは少なくともあなたによって渡されると思います。
ただし、システム全体とコードの品質を保証するのはyourの仕事でもあり、自分で行う必要があります。あなたの会社はコードレビューを採用していますか？プログラマーに、コードに入る前に作業内容を設計してもらえますか？そうでない場合は、このような品質管理メカニズムの採用を検討することをお勧めします。
あなたは管理のためにチェックアウトされている可能性があり、そうである場合は失敗します（それは悪いことではないかもしれません。私たちの多くは優れた開発者であり、悪いマネージャーであり、私はプログラマーを管理するよりもむしろプログラムしたいです）。
マネージャーは、期待されるすべてのことを行う権限を持っていないことがよくあります。とにかく物事を成し遂げることは、優れたマネージャーの1つの兆候です。懲戒処分をせずに人々に物事を行わせる方法を見つける必要があります。 （注：人前で人を中傷することはそれではありません。人前で称賛し、非難し、部下に人としての関心を示します。）
マネージャーは、それが痛いときでも、委任する必要があります。この問題の処理には、自分で書くよりも多くの時間を費やす可能性が高く、それで問題ありません。あなたがそれに対処したら、それをした人々は何かを学んだはずであり、将来彼らが間違った方法で物事を行う可能性は低くなります。
このようなものに対処する正しい方法はプライベートで、まず開発者になぜそのように表示をしたのかを尋ねます。会議ではなく、前もってあなたが正しいと彼らが間違っていると仮定するのではなく（たとえあなたが正しいと彼らが間違っているとしても）。彼らに説明する機会を与える。それはあなたが彼らの決断に行かなければならないという意味ではありません。結局のところ、あなたは技術的なリーダーです。それはあなたが彼らにあなたのやり方でそれをする理由を与える必要があることを意味します、そしてあなたはそのプライベートミーティング中に現れるどんな根本的な問題にも取り組むべきです。
また、マネージャーは自分の人々から出てくるものについて責任があります。特に顧客の前で、彼らが何をするにも目をつぶらないようにしてください。これには、コードのチェックインを追跡したり、開発者と簡単なミニ会議を行ったりすることが含まれる場合があります（注意が必要ですが、ゾーンにいるときは中断しないでください）。おそらく、お客様担当者とのミーティング前の午後に、すべての開発者と話し合う必要があります。
個人的に服用しないでください
それはチームの努力です。プロジェクトの唯一の担当者ではなく、技術リーダー。あなたはチームに間違いやプロセスの変更から学ばせることに焦点を当てるべきです。
リードして学ぶ
テクニカルリードを含め、リーダーシップのポジションの一部は、自分が持っている人々に対して最善を尽くすことを理解することです。チームが協力するほど、物事を持ち出すときと持ち出さないときがよりよくわかります。チームに口述するという罠に陥らないようにしてください。何が問題だったかを確認してくださいおよび週ごとに何がうまくいったか。チームに別の方法で行動してもらいたい場合は、チームと連絡を取ってください。懲罰的措置は常に最後の手段である必要があり、それらは通常、誰かを解雇する必要があるか、またはあなたの役割に失敗したことを意味します。
お客様に提示する前に確認
プロジェクトのリーダーである場合、なぜそれが提示される前に機能と実装を確認しなかったのですか？
間違っている場合は修正してください
何かが間違っている理由を明確に説明し、それを変更してください。それはより高価ですが、それが実際に間違っている場合は修正してください。それが間違っていなければ、やりたいこととは違うだけです。プロジェクトに取り組んでいるのはあなただけではありません。
何が実装されることになっているのかを文書化した仕様はありましたか？オープンエンドの要件が与えられている場合、開発者は適切であると考えるものを何も入力せずに（またはマイクロマネージメントを要求し）ます。
つまり、「仕様の内容に取り組むのではなく、[機能]を行うことに決めました。そもそも機能が承認されなかったため、私たちは取り残されています。」
その後、開発者が再割り当てされたら、機能のスクラブを開始できます。
編集>そして、いや、あなたが屈辱的だとは思わない。彼らの仕事はあなたのお尻になってしまいます。
私はしばしば同じ立場にあり、ミーティングやディスカッションでそれを育てることはどこにもないようです。時々私が辞任する前の最後の手段として、私の決定ではないことに同意します（私のものではありません）。関係者に、理由を明記したメールを白黒で送信します。
次に、そのメールをアーカイブします。そのため、マネージャーや顧客から、なぜそのようにして何かが行われたのか、または変更によって修正に多大な費用がかかる理由が尋ねられた場合に備えて、将来必要になる場合に備えて確実に参照できるようにします。
あなたが認めたように、あなたがあなたがしたようにそれを持ち出すのは間違っていたと思います。このレベルで設計について何らかの情報を入力する必要があると言うのは間違いではありませんが、それを実装することをどのように期待するのが合理的かはわかりません。デザインが単純だと考えられても、人々がデザインを実行することはありません。彼らは、デザイン自体についてそうであるのと同じくらい簡単であることについて簡単に間違っている可能性があるので、あなたが間違ったデザインをすべて見せようと志願する人々を見つけることはありません。この時点で、私は主にあなたの仕事の習慣とコミュニケーションパターンに興味がありますが、実際にそれがどのように行われたとしても、あなたはこれらの事柄に盲目になるでしょう。すべてのコミットを入念にレビューすることを除けば、あなたがこれをどのように証明するかはわかりません。
はい、あなたの上司は正しいです-あなたはeveryの決定に関与することはできません。実際、自分ですべてを行わない限り、このようなすべてをキャッチすることは不可能です。私はそれがあなたの出身だと思います-細部すべてに関与しない限り、プロジェクト全体をうまく処理することはできないと感じますが、あなたを圧倒しなければ、細部すべてに関与することはできません（完全に士気が低下します）チームとおそらくあなたを燃やす）。
答えは、うまくいかないことについて心配することではありません-彼らは常に間違っています-その代わりに、建設的に、後で修正することについて心配することです。
コミュニケーションを順調に進めると、委任するだけでなく、レビュー、ディスカッション、および誤ったコントロールによって彼らをコントロールすることを常に控えることなく、シニアの人々が立ち去って必要なことを実行できるようになります。彼らが正しいことをすることを信頼し、何が起こっているかについて「チャット」するためにそこにいて、ループに留まることができます（そして、本当に必要だと感じたら鼻を刺してください）。
私はしばしば感情的にこのように感じます：
I of course think I'm right....I always do.
しかし、私は時々私が間違っていることを知るために知的に感覚を持っています。私はまた、いつ戦いを選ぶべきかを知っています-あなたはすべてについて議論することはできず、時にはあなたの側での予期しない合意が不思議に働くことができます。
真のリーダーとは何ですか？
fire部下、部下のいずれかができる人です。 （しかし、新しいものを雇う必要はありません）
時々、ほとんどの人はあるプロジェクトのリーダーとして「タグ付け」されていますが、火の力がなければ、それは真のリーダーよりも「ガイダンス」/「教師」になります。
しかし、繰り返しになりますが、チームのリーダーになることはできても、現在のプロジェクトをリードすることはできません。 最悪のケースは、顧客がプロジェクトを主導しているときです。この時点で、プロジェクトが失敗した（そして失敗する）場合、それはあなたの責任ではありません。
そして最悪のケースは、プロジェクトの2つのリーダーが存在する場合です。
軍隊として、指揮系統はすべてです（「プロジェクトの死ぬ」ほど過激ではありませんが、十分に近いものです）。この問題について、あなたのmanagerはあなたのステータスを壊し、「あなたの」人々のモラルを下げ、まったく助けになりませんでした。
あなたにはいくつかの問題があります。最初に、マネージャーはチームの側にいて、さらに委任するように指示しました。これは、チームをリードする能力に自信がないことを示しています。実際には、技術リーダーの称号を持っているが、実際には、権限がないため技術リーダーではないことを示しています。あなたはあなたのマネージャーと一緒に座り、これについて心から心を持つ必要があります。彼のマネージャーのサポートなしで、そして彼の同意なしにチームによってなされた設計決定を変更する権限なしで、誰もテクニカルリードポジションで成功することはできません。あなたには仕事をする権限がありません。上司は、あなたが勝ち組の立場にないこと、そしてそれを改善するために公のサポートをあなたに与えなければならないことを理解する必要があります。権限のない責任は、自分を見つけるのに最悪の状況です。
次に、あなたのチームはあなたを盲目的に扱いました。これについて彼らと話し合う必要があります。彼らが開発を行う前、そして彼らが公開プレゼンテーションを行うずっと前に、彼らとデザインについて話し合う必要があります。設計の一部を委任することは問題ありません（ただし、設計者ではなく、委任する必要があると判断したものを決定します）。ただし、通知せずに続行してもかまいません。彼らはあなたを盲目にすることであなたの信頼を失いました、今、彼らはより良い行動を学ぶ必要があります。あなたは彼らに頻繁にチェックして、彼らが再びあなたを盲検化していないことを確認する必要があります。彼らが盲目的である場合、あなたは人事に問題のある種の正式な報告をしているはずです。リードはポピュラーになるリードではありません。開発者が知らされないように言われた後で意図的に周りを回るとき、彼らは結果に値します。彼らがあなたを好きかどうかは関係ありませんが、現時点では明らかにあなたを尊重していません。彼らは彼らの不適切な行動のために結果を持っている必要があり、そうでなければそれはさらに悪化します。ただし、管理サポートの問題を修正するまで、問題のこの部分を修正することはできません。
次にあなたは公に破裂しました、あなたは公に謝罪する必要があります。これにより、評判を取り戻すことができます。
次に、各人を個人的に脇に置き、彼らの継続的な悪い行動の結果を彼らに伝える必要があります（マネージャーに結果を与えることを許可することに同意してもらうと）。世間の称賛と支持、私的な批判はあなたのルールであるべきです。また、グループのnmeetingsの外でより頻繁にチェックインして、彼らがあなたの目をつぶらないようにする必要があります。
率直に言って、あなたは上と下の両方があなたは無視され、知らされないままでいることができる人物であるとはっきりと思っているので、あなたは彼らにあなたを軽蔑している原因について自分自身を探す真剣な魂を実行する必要があります。また、技術リーダーでなくても幸せにならないか、責任を負う権限を持つ場所に移動するかを決定する必要があります。あなたがispositionにとどまりたいと決心した場合、あなたは人々があなたにそれほどよく扱わない理由についてあなたと同じレベルになるように人々に尋ねなければならないでしょう。それは苦痛であり、おそらく答えを聞きたくないでしょうが、彼らがあなたをはっきりと知覚する方法であなたがなぜ知覚されているのかを知る必要があります。