ラリーペイジとセルゲイブリンは、彼らの会社にはマネージャーは必要ないと真剣に信じていました。 2002年、彼らはプログラマーを管理するマネージャーなしで、水平的な組織構造を構築しようとしました。 それで、彼らは、アイデアの急速な交換と出現を妨げるものは何もないと信じていました。 さらに、彼らは大学でとても気に入った学生生活の雰囲気を再現したかったのです。 実験は長続きしませんでした：数ヶ月後、それは止められなければなりませんでした。 BrinとPageは、会社の内部構造について考えを変えました。従業員は、財務報告やお互いに対する苦情など、創造的とはほど遠い質問でPageに身を投じました。 そして、会社が成長し始めたとき、創業者はマネージャーが他の点で有用であると確信していました：彼らは戦略、プロジェクトの重要性とそれらの優先順位を説明し、チームで確立されたコラボレーション、人々のキャリア成長を監視し、すべての作業プロセスとシステムはタスクと一致していたビジネス。
ただし、多くの開発者は、マネージャーは必要ないと考えています。 そうですか？ まとめましょう。
マネージャーが悪いとき
多くの場合、開発者はマネージャーに不満を抱いています。 コードを書いて理想的なアーキテクチャを考える代わりに、彼らはいくつかのレポートに記入し、他の退屈で理解できない仕事をすることを余儀なくされます。 マネージャーはしばしば職場に不在であり、膨大な数の集会に参加しており、彼らの仕事の結果をコードの行で測定することは非常に困難であり、これはまさに顧客が結果として支払うものです。
この観点からいくつかの真実があります（さらに、非常に実質的なもの）。 非常に多くの場合、管理者は、仕事の結果がないことを正当化するために、部下に毎日の報告書を作成させ、すべてのステップ、たとえば喫煙室を訪れた時間を記録して、嵐の経営活動をシミュレートします。 一部のマネージャーは、「プロセスを実装する」という事実にのみ従事し、Scramの5分間の議事録を保持し、あらゆる場面で集会を開催します。
悪いマネージャーの最初のルール：何をすべきかわからない場合は、集会を開催します。
多くのITマネージャーがそれほど有能ではない理由は、ITバイアスを持つマネージャーを準備する本格的な教育機関がないためです。 そのため、マネージャーはしばしば非常に貧しい、または非常に優れた開発者、またはITで働いたことがないが良い英語を話す人のいずれかになります。 これらのすべての場合において、プロジェクトにマネージャーがいると、プロジェクトを害する可能性が高くなります。
約10人のプロジェクトマネージャーが部門で働いていたある会社では、このトピックに関する小規模な調査が行われました。 結果は圧倒的でした。誰も本を読んでいませんでした。 誰もブルックスと彼の神話上の人月について尋ねませんでした。
なぜマネージャーは訓練されないのですか？ 算術をしましょう。 ITスペシャリストのマネージャーを作るには、0.5年（ほぼ理想的なケースであり、ITの世界ではめったに見られない）から4年が必要です。 会社でのITジョブの平均期間は1年半です。 したがって、企業がITマネージャーの変革プロセスへの投資を開始すると、競合他社はこのトレーニングの作業を使用する可能性が高くなります。 したがって、企業はITスペシャリストを継続教育コースで喜んでトレーニングしますが、マネージャーのトレーニングに投資する準備はできていません。
この場合、ITスペシャリストは何をすべきですか？ 最初に、彼が将来マネージャーになりたいかどうかを決定します。 答えが「はい」の場合、中間レベルからどこかで始めて、テクノロジーの本と並行して心理学、リスク管理、プロジェクト管理に関する本を読み始める必要があります。
マネージャーが良いとき
それでも、マネージャーは何のためにあるのですか？ 当初、ペイジとブリンの記事はすでにこの質問に少し答えていました。彼らは戦略、プロジェクトの重要性とその順序を説明し、チームでのコラボレーションを確立し、人々のキャリア成長を監視し、すべての作業プロセスとシステムがビジネス目標に沿っていることを確認します。
マネージャーのより重要なタスクを貯金箱に追加したいと思います。
タスク番号1：顧客とパフォーマーの間の壁になる
私たちの知り合いの一人は、まだかなり若いうちに、たまたま非常に深刻な顧客（Fortune 100）の「23歳のシニア」（およびチームリーダー）の役割を果たしました。 このプロジェクトは技術的には複雑ではありませんでしたが、ハードウェア環境の統合と要件の点では困難でした。 統合のために、（顧客側で）別のマシンが割り当てられ、すべてが正常に開始されました。 しかし、これは顧客のエンジニアにとって十分ではなかったため、個人のラップトップと稼働中のコンピューターにシステムを展開することにしました。 そして、ある時点でシステムが起動しませんでした。 私は長い間その理由を理解しなければならず、次々と問題が発生しました。
マネージャーが状況に介入していなければ、これはかなりの期間続く可能性があります。 彼は、顧客のエンジニアが彼の知識なしに請負業者にタスクを与え、テストされていないハードウェアにシステムを展開することを禁じました。 この介入の後、状況は落ち着き、開発者はもはや引っ張られず、プロジェクトは数日後に正常に完了しました。
タスク番号2：プロジェクト全体の責任を取る
「プロジェクトに問題があります」と、プロジェクトが作られた会社のトップマネージャーは一度言いました。 開発者は寒くなった。 「しかし、心配しないでください。あなたの責任範囲ではありません」と彼は付け加えました。
1つの簡単な考えを覚えておく価値があります。プログラマーがコーディングし、マネージャーが応答しています。 プログラマーが悪い仕事をした場合-いずれにせよ、マネージャーはプロジェクトの進捗状況を追跡しなかった、および/または不適切な従業員を雇ったため、責任がある。
はい、マネージャーはより多くのパンを受け取りますが、彼の責任は桁違いに高くなっています。
タスク3：リソースへのアクセスが制限されている状況で目標の達成を保証する
さらに、顧客とパフォーマーの両方の目標の達成を保証する必要があります。 これはめったに不可能です。 結局のところ、マネージャーは数百の異なる問題に直面しています：人員の不足と不十分な数、時間と予算、悪か無能な顧客、専門知識の不足など。
しかし、マネージャーが結果を保証できれば、どこで、どのくらい、どのように働いているかは関係ありません。 さらに、1日に7〜8時間働くマネージャーは、プロジェクトをあふれさせることが保証されています。 マネージャーは、彼の決定と最終結果に対して支払いを受けなければなりません。 理想的には、マネージャーは、linkininやskypeで費やした時間数ではなく、完了したプロジェクトのボーナスの形で主な収入を受け取るべきです。
タスク番号4：意欲を高め、部下の成長を監視する
開発者が私たちにどの会社と仕事をするのが最適かと尋ねたら、私たちはためらうことなく答えます。
ある会社では、プログラマーは上司から大きな信頼を得ています。 信頼は、彼（プログラマー）による決定の完全な承認、仕事の自律性、開発者会議の開催の支援、トレーニングコース、さまざまな会議への旅行で構成されていました。 結果はすぐに来ました。5〜6人の新しい部門が開設されました。 イベントで得た知識がワークフローに導入され、最新のテクノロジーとツールがプロジェクトで使用されるようになりました。 結果は？ 他の企業のすべてのオファー（高給のオファーを含む）は、後悔することなく1年半にわたってプログラマーによって拒否されました。
彼はどんなマネージャーですか？
Googleは、優れたマネージャーの8つの資質を区別しています。
1.敏感なメンター。
2.チームに自由を与え、すべてのステップを制御するわけではありません。
3.部下の成功を監視し、支援を試みます。
4.有能で結果重視。
5.人と話すことができる-情報を聞いて共有します。
6.部下のキャリア形成を支援します。
7.彼のグループの将来について明確な考えを持ち、その作業の戦略を理解している。
8.基本的な専門スキルを所有しているため、グループにアドバイスを提供できます。
このポートレートに次を追加します：理想的なマネージャーは、著作権の問題、リスク管理、心理学、動機、リソース管理、法律などの分野で有能である必要があり、社会性、堅さ、公正さ、十分。
理想的なマネージャーはほとんどいませんが、そのような資質とスキルを備えた人に偶然出会った場合、優れた結果はそれほど長くかかりません。