私は最近、約3年前に書かれた人事管理に関する古い記事を読み直しました。 その瞬間、私は初心者のプロジェクトマネージャーでしたが、プロジェクト管理の「力の暗黒面」ははるかに非現実的でした。
その後、明確な要件を備えたカスタムメイドのプロジェクト、「私の」チームを担当し、目標を設定し、外の世界から守り、保護しました。スケジュールを作成し、経営陣と顧客との話し合いで支持しました。 私はチームの立場から顧客だけでなく経営陣とも話し合い、その利益を擁護しました:期限が十分であり、新しい要件が「どこからでも」出てこないように、品質に対する主張は本当の根拠でしたなど。 私の意見では、チームとの関係は理想に近かった。 もちろん、対立や意見の相違はありましたが、ほとんどの場合、それらは即座に、痛みを伴わずに解決されました。
しばらくして、私は別の部門に向かった。 実際、.NETおよびJavaScriptのコンポーネントの製品開発に従事していたのは別の会社でした。 したがって、私のタスクの範囲内で、製品管理が追加され、マーケティングおよびセールスマネージャーを監督しました。 実際、ビジネスコンポーネントが私の責任に追加されました。
しばらくして、私は「明るい側」の理想から急速に離れ始めたことに気付きました。 私は、従業員のやる気とトレーニングに費やす時間を大幅に減らしました。 時々彼は男たちをまったく批判し始めました。そして、彼の声を上げることを数回許したことさえありませんでした。
ある時点で、振り返ってみると、自分の管理スタイルがどれだけ変わったのか、そしてそのイメージ(「そしてそのようなものだけがどこから来たのか」という言葉で)が自分のために描かれた下劣でプロではないPMのように見えたのが怖かったちょうど働き始めた。
もちろん、私は本当にそれが好きではありませんでした(一般的に、彼らが私を愛し尊敬しているとき、私はそれを愛します;)。 したがって、私はなぜこれが起こったのか、さらに「劣化」を防ぐために何をする必要があるのかを熟考することにしました。
私の頭に浮かんだ最初の考えは、節約することでした。「良い」ための十分な時間がないだけでなく、絶えず解決している多くの問題は、単に不均衡なストリームに入ることを許しません。
私はこの事実を確認し、チームを壊すことで負荷を減らし、各グループがチームリーダーに率先され、テストスペシャリストが「すべての準備ができた」と言うまで、優先順位を付けてタスクの束を与え、将来の運命に従わないようにしました。 。 さらに、従業員のトレーニングを委任し、製品開発とプロモーションに焦点を当てました。 実際、定式化、タスクの仕様、開発管理に関する作業ははるかに少なくなっています。 しかし、それにもかかわらず、「明るい側に戻る」ことはあまり助けにはなりませんでした。
もう少し考えてみると、現在の状況では何が欠けているのかがわかりました。 チームとの一体感はなく、カスタム開発で数か月間続くことがありました。
プロジェクトマネージャーには強い信念はありませんでした。 チームが作成したものを作成します 。 それどころか、気持ちは去りませんでした。 チームは私の製品を作ります 。 チームは私が必要とすること、私が計画したことをします。 そして、これが重要なポイントのようです。 全体的な問題は、私がビジネスの側面からチームを見始めたことであり、PMであること自体がその一部でした。
以前は、人々を管理することは、目標の設定、動機付け、学習、および外部の影響からの保護にかかっていました。 今-目標、動機、トレーニング、雇用、昇給などを設定する よく見ると、重要な要素が1つありません。 これは外部の影響に対する保護です。 実際、 外部からの影響は私です!
したがって、ビジネスの問題はすぐにチームに伝わり、PMAをバイパスします-過剰を排除し、タスクのフローを構築し、顧客が優先順位を即座に変更したり、要件を再描画したり、他のすべてを実行したりすることはできません» )そうするのが大好き。
そのため、このモラルはやや長いケースです。良い仕事のために、プログラマーは、絶えず変化するビジネス要件のためのフィルターとアダプターとして働くディフェンダーを必要とします。 ほとんどの場合、これはPMaのタスクです。 したがって、プログラマーがビジネスと直接やり取りし、そこからタスクを直接受け取る場合、彼らはシールドなしで放置され、モチベーションの継続的な請求を受けます。 したがって、製品がプロジェクトマネージャーである場合、「ダークサイド」へのパスはどのような状況でも提供されます。
PSひとつ注意点があります-良いプロセスは悪くないチームを守ることもできますが、それは別の話です。