無効な委任がIT業界をどのように害するか





委任、フラットな構造、その他の直接的な相互作用について聞いたことはあります。誰もが自律的な戦闘ユニットであり、誰もが素晴らしく、誰もが責任を持って働き、一般に、チームは開発チームというよりも共産主義のイデオロギービルダーのチームのようなものです。自律性と「平坦性」に関するこれらすべての会話の中心にあるのは、「人々に仕事をさせ、自分自身にプロセスを固定しない」という短い形式で定式化できる論文です。つまり、可能な限り委任し、委任できないものを、復讐して部下にプッシュします。オフィスの奴隷制はなく、最大限の自己認識だけです!平和!作業!五月!



私たち全員がその問題を理解しているわけではないので、この神話は二重に危険です。出演者が与えられたデータを望まない、または利用できないトマトの場合、委任は失敗したとみなされます。神は権力管理者です。しかし、多くの場合、慣例としての委任の失敗の問題は、マネージャーまたは開発リーダーが単に自分の権限を真に委任する方法を知らないか、または望んでいないことであり、部下が独立して行動することを許可するふりをするだけです。



さまざまなセグメントの数十のさまざまなIT企業の仕事を観察して、私は自信を持って宣言します。90%のケースでのいわゆる「権限の委任」は、架空のものであり、マネージャーの自己主張の方法です。委任は双方向のプロセスであるため、強力なパフォーマー(明らかです)だけでなく、鋼の神経を持ったインテリジェントなリーダーも必要です。そして今、その理由を説明します。



真空中での完璧な委任



何らかの理由で、私たちのマネージャーは、委任が他の誰かに仕事を投げかけていると考えることに慣れています。それはあなたが自分でしなければなりません。工場/企業/企業/集団農場および他の機関のディレクターが6か月間離れることができ、それらがなければすべてがうまく機能し、1242年4月のペイプシ湖のように魂を暖め、涼しくします。同様に、プロセスはデバッグされます。



架空のマネージャーの心の中でそのような物語は何を描いていますか?彼女は、ディレクターには実際にはタスクがないことを彼に引き付けます。すべては彼の部下によって行われ、すべてはそれ自体で機能します。彼は、彼自身が接続したい場合にのみ接続する必要があります。ええと、人生ではなく、おとぎ話ですね。自分で行って、従業員の奴隷を蹴り、時々彼らの活動の選択的な制御を手配します。良い-賞賛、悪い-罰する。



唯一の問題は、理想的な委任は、従業員とその直属の上司との間の複雑な相互作用のメカニズムであり、危険なメカニズムであるということです。



健全で実行可能な委任の概念は、単純で理解しやすい理論に基づいています。プロジェクトの委任されたセクションでの作業の過程での間違いは、同時に実行者とこの量の作業を彼に委任した人の両方の間違いになります。



実行者は決定を下すときに全力を持っている必要があり、マネージャーは必要に応じていつでもプロセスに参加する準備ができている必要があります。


そうでなければ、それは委任ではありません。



つまり、従業員が混乱することはありません-そして、わき柱の場合、従業員だけが答え、マネージャーが乾いて出てきて、犯罪者の個人的な処刑人になるとき、マネージャーだけが答えます、またはその逆です。同時に、すべてが単独で機能する場合に完全に自律的な委任がないのと同様に、指定された段階ですべての最終結果を上司と調整する必要がある場合、委任はありません。



マネージャーが極端になるモデルは、従業員の無責任とチーム内の信頼の喪失につながります。



モデルは、従業員が何も解決せず、マネージャーが「見ず、聞いていない」-意志の受動性と麻痺、およびタスクの失敗-を暗い悪夢の中に入れます。



これらのモデルは両方とも、代表団の仕事についてのまさに「protomyths」です。



それらは、いずれかの当事者の最初の深刻な「飛行」まで文字通り機能し、その後、会社はネジを締め始め、作業を継続することがほとんど不可能になります。



両方のケースを詳しく見てみましょう。



執行者の責任のない権限の委任



マネージャーが「良い上司」を演じたい場合、彼は部下の能力の境界を最大限に拡大し、それを「権限の委任」と呼びますが、実際には彼は自分の責任の領域で何が起こっているかを単にスコアリングします。その結果、DevOpsと開発者自身が、AWSでの容量の調達に関するデータを会計部門に提出でき、上司である管理者(機器の購入の見積もり)をバイパスできます。すべてがお互いの兄弟であるような親切な無秩序。従業員は、「私があなたをカバーします」という言葉でカルテブランシュを与えられたので、周りを見回すことなく、すべてを迅速かつ大胆に行います。



この「私はそれをカバーします」はどのバージョンでも-文字通りロシアのルーレットのゲームです。


責任の程度を認識し、慎重に行動 する適切な人々にこれらの言葉を言うと、マネージャーは信じられないほど幸運になります。しかし、経験が示すように、人々は責任を負うことを好まず、最初の深刻な飛行がマネージャーにとって問題になります。彼はそれを犯人と共有する代わりに、上司から自分自身に打撃を与えます。



「上司は常に責任がある」というのはかなり便利な論文ですが、それは半分のケースでしか機能しません。管理者が機器の購入のために2つの同一の申請書を提出し、それがbukhが支払った場合、これはまず第一に、管理者の間違いです。つまり、ここでの状況は、愚か者と装填された銃のようなものです。銃を持った愚か者が最終的に不自由になった場合、それはまず第一に、愚か者自身のせいであり、それから彼に銃を手に取るように申し出た人のせいです。



権力の「委任」の場合も同じです。従業員が「委任された」領域での行動に責任を負わない場合、これは彼が間違いの責任を負わないことを意味するものではありません。権限誤って委任したマネージャーに問題があります。



そして、これは、最初の過ちから成長する、2番目の代表団の神話の領域が始まるところです。これは、マネージャーがまだ「委任」したいときであり、それはプラントディレクターの話のようになりますが、同時に彼は部下を絶対に信頼していません。



意思決定力のない代表団



上記の状況が疑似委任のケースの10%を占める場合、以下では、現代の「効果的な」管理の最も頻繁で一般的な問題について説明します。



問題について話し合い、計画し、開発するよりも、問題の最終決定に多くの時間が費やされる状況に何度も直面したことがありますか。



「オファーが2階に上がり」、跡形もなく消えてしまう状況はどのくらいありますか。



この問題は、決定が表面的かつ非効率的に行われる場合の誤った管理の問題とも交差しますが、いわゆる「委任」の状況にも存在します。



国内の開発やビジネスでは、タスクの範囲が階層の下位の従業員に移るときに、このような「委任不足」に遭遇することがよくありますが、同時に、彼には中間の決定さえする権利が与えられていません。



最も印象的な例は、マーケティングまたはその他の外部活動です。「効果的な」マネージャーは、条件付きのコールドコールの作業だけでなく、一般的に可能なすべての作業がシフトされる中国のダミーのチームを募集します。これはすべて、リーダーが最終決定のみを行う必要があり、部下が大まかな作業を行う必要があるかのように、委任のソースの下で提供されます。



標準的な指示を超える作業または交渉の過程での質問は、次の形式の回答につながるため、管理者側のこのようなアクションは、ローカルの崩壊につながります。



上司に相談する必要があります。


つまり、従業員は確率の境界を概説することすらできず、決定を下す際に単に麻痺し、話す人形の役割のみを実行します。



このような疑似委任モデルは、すべての利害関係者が適切に参加することで、数時間から数週間から数か月に及ぶプロセスを拡張します。マネージャーが部下の時間を気にしないと状況はさらに悪化します..。そして、これはマーケティングやPRだけでなく、開発のアウトソーシングの問題でもあります。プロジェクトマネージャーや他の管理者が代表団やフラットな構造で遊んでいるときの、開発者とクライアント間の終わりのない会議、承認、電話、フィールド訪問なども、人々に仕事をさせる代わりに部下を不必要な活動に巻き込むのは誤りです。



マネージャーは、従業員に委任されたプロセスに完全に従事し、それを自分で引き受ける準備ができている必要があります。


この用語は印刷して、雇用時にすべての幹部に与えることができます。何らかの理由で、管理者は委任された権限が依然として自分の権限であることを常に忘れています。つまり、制作の必要性に応じて、上司はすぐに作業プロセスに参加する必要があります。あるいは、この作業を委託した人の代わりに行う必要があります。さらに、この包含は、マネージャーの主導だけでなく、従業員の要求によっても開始する必要があります。



経営陣は、任務が委任された場合に、下位の従業員が上位の専門家に問題への参加を強制する権利を有するべきであるという事実をしばしば無視します。



これは理想的な代表団がどのように見えるべきかです



この全体の話は、一連の単純な論文に要約することができます。



委任とは、タスクの転送であり、中間または最終決定を行う権利です。
委任は、プロセスと結果に対する責任がパフォーマーに完全に移転することを意味するものではありません。


委任は、プロセスに対する責任を適切な比率で共有することを意味する必要があります。
委任は一時的なプロセスと見なされ、タスク領域に戻す準備ができている必要があります。


必要のないフラットな構造や委任で遊んではいけません。開発者は、クライアントとの会議に参加するのではなく、コードを作成する必要があります。PR担当者はPRである必要があり、メッセンジャーのように請負業者と部門長の間を行き来するべきではありません。



そして、マネージャーは率先して責任を負い、オフィスをだらしなく見つめ、「私がすべてを他の人にどれだけうまく委任したか」を考えるべきではありません。






広告



DDoS保護と最新のハードウェアを備えた強力なVDSこれはすべて、私たちの壮大なサーバーに関するものです。最大構成は、128 CPUコア、512 GB RAM、4000 GBNVMeです。






All Articles