より少ない技術知識で管理する方法は？
私は会社のプロジェクトマネージャーになりました。これまでに経験したことは次のとおりです。
最初、私はチームの他の開発者（約15人の開発者）と技術的に形を保つように努め、アーキテクチャから構文の一貫性に至るまで、プロジェクトで行われているほとんどすべてを知ることができるようにできるだけ多くのことを読みました。
しかし、すぐに私はあなたがすべてを知ることはほとんど不可能であることを理解しました。したがって、テクニカルレースに後退するのは当然です。 Ext JS、Angular JS、[〜＃〜] bre [〜＃〜]、[〜＃〜] wcf [〜＃ 〜]、Enterprise Libraryロギング用、アスタリスク、等々、すべて同時に。したがって、これは正しいパスではないようです。
その式は次のとおりだと思います。管理しなければならない人が多いほど、所有できる技術的知識が少なくなります。
ただし、チーム内で何が起こっているのかを技術的に知らないことには問題があります。
- 開発中のようにボトルネックを理解して検出できない場合があります。
- どのテクノロジーがパフォーマンスと生産性のどちらで優れているかを判断できない場合があります
- チームでの技術的な紛争の場合、あなたは助けることができないかもしれません
- コードから遠ざかるほど、開発者のストレス、プレッシャー、感情を理解できなくなる可能性があります（これは私にとって大きな懸念事項です）
- タスクを完了するために必要な時間を予測および予測できない場合があります
- 解決された問題について開発者が熱意をもって話すとき、あなたは情熱を失います。彼が話していることの40％ほどは理解できず、何かについて理解していなければ、それだけ退屈になるかもしれません。
- 開発者はあなたに何かを説明するのが難しくなるでしょう、そして彼らはあまり技術的に話す必要がありません
- 悪い開発者（まれですが既存の開発者）は、技術的な知識を誤用し、あらゆる種類の問題を引き起こす可能性があります
- ...
この現象はおそらくどんな職業や職業でも起こります。しかし、開発とコンピュータの世界は一般的に（自動車産業と比較して）より速く進んでいるため、6か月ほどの短い期間で後退したように感じます。バージョンごとにバージョン、機能ごとに機能、ライブラリごとにライブラリ、というアイデアが思い付きました。
私はこれらの質問を見ました、そしてそれらは良い提案を含んでいます。
プロジェクトマネージャーになった後、技術スキルを維持するにはどうすればよいですか？
プロジェクトマネージャーはどのくらい知っておくべきですか？
プロジェクトマネージャーはどのくらい知っておくべきですか？
IT会社のマネージャー（またはCEO）は、組織で実行するITバックグラウンドを持っている必要がありますか？
技術的負債に対処するよう経営陣を説得するにはどうすればよいですか？
ただし、これらは個人的な経験とアドバイスに基づいているため、もちろん良いことですが、それほど役に立たない可能性があります。
技術的な知識の少ないソフトウェア開発者のチームを管理する方法についての本、またはこの主題についてよく考えられて研究されたエッセイはありますか技術的知識が少ないチームメンバーよりも？効果的にリードし、チーム全体を成功に導くには、どのような点を考慮すればよいですか？
いくつかの簡単な考え。
- ボスではなくリーダーになる。何をすべきか、そしてどのようにすべきかを人々に言わないでください。代わりに、チームメンバーに解決すべき問題、所有するための課題、そして最も重要な責任を与えてください。
- スケジュールの後ろに隠れてはいけません。チームと話して、一緒に座って、彼らがどのように進んでいるか、どのような不満や問題があるかを尋ねます。それがあなたのチームが何をしているかを理解してください。
- チームを信頼し、彼らに影響を与える決定を行う前に情報を求めます。
- 「サーベルガラガラ」前に、チームの働き方を「自分の」方法に変更する前。何が機能して何が機能しないかを時間をかけて観察し、「自分のやり方」を課すのではなく、実際の問題をゆっくりと修正します。
- 着実に、冷静さや気性を失わないでください。常に解決策があり、多くの場合、あなたが決して考えたことはないが、チームの誰かが解決策を持っています。個人ではなく、チームとして成功したり失敗したりします。
- 自分のチームではなく、チームの活動を信用しないでください。あなたの仕事は、彼らを美しく見せることであり、代理として、彼らの成功は、人々があなたをマネージャーとして見る方法に影響を与えます。
そして最後に
- 新しく昇進した人々がチームのためにすべての仕事をする誘惑はしばしばそこにあります。あなたには理由があるチームがあります、彼らはあなたを助けたいです。それらを使用し、彼らにあなたを助けさせ、彼らに物事の責任を取らせてください。委任。実際には「作業」を行わないことを受け入れますが、代わりに行うことはチーム全体にとってはるかに価値があります。