もちろん、マイクロマネジメントはITだけでなく、黒人の儀式が従業員の専門能力開発は言うまでもなく、開発プロセスと最終結果に重大な害をもたらす可能性があるのはこの分野です。
おそらく、最初に、この大変動を制御から定義する価値があります。 したがって、businessdictionary.comによると、マイクロマネジメントは、従業員が行う仕事の厳しい、徹底した、継続的な、そしてしばしばやる気を起こさせるコントロールです。 言い換えれば、上司があなたが正しく行ったかどうかを確認せずに一歩踏み出すことを許可しない場合、常にすべての行動を監視し、ごくわずかな動き、おめでとうも報告する必要があります。あなたは潜在的またはすでに本格的なマイクロマネジメントの犠牲者です
マイクロ管理のマイナス面は何ですか？
この管理スタイルの最大の危険性は、独創的で独創的なイニシアチブワーカーが、目を輝かせることなく定期的に課題を実行する意欲の低いゾンビに変わることです。 ITの枠を超えて考え、明るいアイデアを生み出すことができる人の割合が非常に高いことを考えると、マイクロマネジメントなどの管理スタイルは不合理であるだけでなく、場合によってはプロジェクトの麻痺、競合、さらにはチームからのスペシャリストの退任にも貢献します。
危険なマイクロ管理とは何ですか？
リーダーからのチームに対する自信の欠如と、ミスを犯すことの禁止は、チームの発展の停止につながります。 人々が信頼されていないと感じた場合、チームビルディングは凍結されます。 そうです、ゾンビにはチームスピリットがありません。彼らは反逆した墓の地理的近接によってのみ団結します。
マイクロマネージャーは、決定を下す際に自分のチームを信頼できるときとそうでないときを知っていると考えています。 彼は一つの原則に従います-彼は彼の理解で正しく行動する限り、彼は彼の人々が独立して自由に行動できるようにします。 これは何でもありますが、独立と自由ではありません。 自由とは、
絶え間ないチェックと頻繁な報告は、開発者の信頼、彼自身の強さに対する彼の信仰、そしてチームリーダーと協力したいという欲求を殺すもう一つの素晴らしい機会です。 あなたが毎分コントロールする必要がある未発達の子供のように扱われているという感覚ほど、働く熱意を破壊するものは何もありません。 道徳基準の低下に加えて、このような管理モデルには、マネージャー自身による時間の非効率的な使用が伴います。 2人のスペシャリストが開発者のタスクに取り組んでいることがわかります。開発者自身とマネージャーであり、後者の時間ははるかに高価です。
ミクロ管理の別の欠点は、焦点が合っていない問題を解決するための戦略的アプローチが失われることです。 もちろん、ハリネズミになりたかった賢明なフクロウやネズミについての冗談のような戦略的アプローチではなく、開発プロセスを計画する際の適切な戦略的思考です。 フォーカスを失うと、極端な戦術的計画に陥る危険性があり、開発管理自体が無効になります。
マネージャーのもう1つの明白な敵は完璧主義です。 完全主義の主な特性は制御されていない分布であるため、完全主義がいつミクロ管理に入るかを判断することは非常に困難です。 完全性としての自分への卓越性と信仰の追求は驚くべきことです。マイクロマネージャーは、自分を最後から2番目のレベルの強力な戦闘魔術師と見なし、ポンプでくみ上げられた戦闘機の隊列に指を当てます。 しかし、愚かなホラー映画のようなカジュアルな外観が、ヒロイズム、ゾンビのかわいい物理学によって歪められた通常の顔の代わりに、突然ひったくります。
さらに、しばらくの間マイクロマネージャーの範囲内にいた開発者は、開発をやめるだけでなく、カルマやキャリアさえも著しく損なう可能性があります。 ゾンビをリハビリし、別のチームに統合するのにどれくらいのマナが費やされますか？ 独立した考え方を忘れがちであり、このスキルを回復するには貴重な時間とリソースが必要になります。
すべてが本当にひどく、マイクロマネジメントが許容される状況はありませんか？
もちろんそうです。 たとえば、プロセスへのチームの関与に問題がある場合。 大規模な認知的不協和音、季節性うつ病、または単なる休日の気分などです。その結果、チームは単純にプロセスから外れ、独自の自由意志でそれに陥りたくありません。 次に、ネクロマンシー大要を開き、そこからゾンビを作成して制御するための少なくとも簡単な呪文を読み上げます。
場合によっては、個人的な理由で、従業員が突然、実行された仕事や同僚に対して破壊的な振る舞いを始めます。 この場合、マイクロ管理は害を与えることはありませんが、予期しないイベントや不快なイベントの防止に役立ちます。 つまり、（プロジェクト、情報、従業員の）内部セキュリティに対する脅威がある場合、行動と保護の戦略としてのマイクロマネジメントが正当化されます。
しかし、マイクロマネジメントの正当な使用は、ルールではなく例外です。
一般に、開発プロセスからこの黒魔術を除外することが最善です。 どうやってやるの？
初心者および成功したマイクロマネージャー向けの推奨事項を以下に示します。
-あなたはチームリーダーであり、開発者やテスターではないことに注意してください。 あなたの役割は、部下があなた自身ではなく知識と開発経験を適用するのを助けることです。 あなたが息をのむようなレベルのソフトウェア開発の魔法に汲み上げられたので、誰も疑うことはなく、これについてもう一度思い出す必要はありません。 すべての脳が無限という概念に対処できるわけではありません。 自分や他の人ができるだけ早く安全に試して、専門家からリーダーに新しい品質への移行を行ってください。
- 問題の説明に焦点を当て、それを解決する方法を説明するのではなく。 何をするかではなく、何をするかを教えてください。 共同の魔法の努力の結果として何が起こるべきかをチームに伝え、また、タスクを完了するときに考慮する必要があるパラメータまたは制限について必要な説明を提供します。 チームが初期データ自体を処理し、その経験と創造性を活用して、適切な行動方法を見つけましょう。 権限を委任することを恐れないでください。彼らと一緒に責任を委任するので、それ自体が動機です。
- プロジェクト全体の文脈における特定の開発段階の重要性を説明します。 全体像のビジョンとプロジェクトの段階間の相互接続は、意識的に前進し、すでに行われた作業を体系化し、今後のタスクを予測するのに役立ちます。
-チームにさらに質問をし、 既成の回答を少なくします。 リーダーとして、可能な限り質問をし、絶対に必要な場合にのみ答えてください。
-覚えておいてください： リソースではなく、人！ （c）開発者はプロジェクトの最適化中に数字と工数として認識されますが、マネージャーとチームが連携するときは、開発者とプロジェクトマネージャーの両方の目標が一般的であるため、チームとのパートナーシップを構築することをお勧めします。
再制御されたゾンビに加えて、非常に多くのより効率的かつ効果的なユニットがあるので、
尊敬されるハブラッグ市民から、開発者による現場でのマイクロマネジメントへの対処方法を非常に聞きたいです。 成功した闘争の場合に特に興味があります。