数年前、同名のスタジオで導入された作業プロセスの整理の哲学に関するArtyom Gorbunovの「労働時間管理の革命的システム」に関する記事に触発されて、ユニットが安定して動作するためにどれだけの人的資源が必要か？







それは私がリーダーとして来たアイデアと結論についてです。 この記事は、初心者のリーダーや、ただ1人になることを計画している人にとって有用です。

私たちは何について話しているのですか？

Artyom Gorbunovのスタジオで導入された概念、「リソース」をアイデアとして、「リソース」を研究の主な対象として、物事ははるかに多面的であり、私が触れた問題です。 しかし、私は人的資源についてより詳しく説明したいと思います。

誰かがこれらは完全に異なるものであり、部分的に正しいと言うでしょう。 しかし、上記の概念の主な目的は人/従業員であるため、部分的にしかありません。

結局のところ、人が「リソース」という概念を呼んで、人的資源との関連付けを故意に予測することは無駄ではありませんでした。



状況を想像してください。新しいグループ/部門/プロジェクトが形成されています。 従業員の開始数を2人とします。 これらの人々の役割は何ですか？ 1人の特定の人が部門の活動に責任を負うべきであるため、2人の間でも従属スキームが必要です。 したがって、一方が責任者であり、もう一方が活動的な人であることがわかります。











私が説明させてください、最初のものは事実に直接責任がありません、彼はチャーター/規制/規則に責任があります。 つまり 彼はユニットの活動に責任がありますが、これはすべての場合に100％責任があるという意味ではありません。 そして2番目に、まず部門のタスクを直接実装するタスクがあります。 もちろん、最初のものも「手作業」で作業を行う必要があり、それを行うことができますが、程度はそれほど大きくありません。

分割形成

2、3、4人が働いており、タスクの量が増えているため、生産性を高め、いわば部門の耐障害性を高める必要があります。 従業員の数を増やすか、現在の従業員の生産性を高めるか、または両方向を使用しますか？ そのような質問の出現は、ユニットの開発における通常の段階です。











答えは、原則として、一度に2つの方向で作業することです。従業員の数が増加し、従業員のスキル（現在と新規の両方）の質が向上しています。

それでは、チームの規模はどうでしょうか？ チームなしでは誰もできませんか？

部門の形成のためには、部門内で健全な競争を形成する必要があります。 競合が最小限で、生産性が最大で、関心のある従業員の成長の見通しがはっきりと見えるもの。 平等な社会での競争は本質的に弱く、ガイドラインはありません。 重要な成功/開発は、先例（良いか悪いか）なしでは達成できません。











私たちは普通の専門家と主要な開発者の間の競争について話しているのではなく、主要な開発者の役割は、興味のある人がより速く開発できるようにすることです。 逆の点があります。専門家が開発のために努力しなければ、彼を強制する必要はありません。 彼に快適な位置/役割/仕事を見つけることが必要です。 おそらく、これはこの従業員の価値です。

役割と専門分野

チームメンバーの役割を開発します。 任命しないでください。 この役割またはその役割を持つイニシアチブは、無意識ではありますが、従業員自身から出されるべきです。



彼の直接の義務を果たす以外に、彼が何をしているのかを分析します。











役割は、批評家からすべてを知る人まで非常に異なっている可能性があり、最も明白なのはチームリードです。 この役割の従業員には、「誰とどの問題について相談できるか」を理解する機会が与えられます。 そして、リーダーはチームの自己組織化のためのもう1つの「良い」ツールになります。



役割に加えて、従業員の専門性を開発することが可能であり、必要です。特定の従業員にとって非常に興味深い狭い領域。 このスキルは部門で適用されることが必要な場合がありますが、すべてのチームメンバーがそれを持っている必要はありません。

数量または品質？

そして、今では、最小限の構成ではあるものの、部門が形成された瞬間にタスクが完了し、時折新しい候補者を提供します。

合理的な質問があります：どのような種類の従業員を探すか、チームを強化する方法、冗長性を提供する方法、部門の技術開発のためのリソースを見つける場所はどこですか？

今後、私が思いついた結論はあなたのモデルには適さないかもしれないと言います。 あなたのチームが専門家のみで構成されている場合、またはその逆の場合、モデルがジュニアウェア用に「ワークアウト」されている場合、スキームはあなたのためではありません。

チーム内の誰が事前に決められた品質で最も本物の製品を作っているかを分析しましたか？

あなたの答えが「普通の専門家」であることを願っています。 若い専門家は、多くの理由で、普通の専門家のスピードで問題を解決することはできません。彼は勉強し、多くの質問をし、適切な専門的スキルがありません。 高レベルの専門家：主要な開発者、技術リーダーは、より多くの場合、よりグローバルな技術的問題に対処します：アーキテクチャ、ツール、ジュニアを教えるなど。

そして、若くて一流の専門家が実際の製品を小さくしているという事実は標準です。

それ以外の場合、おそらくチームでいくつかの問題が発生する可能性があります。まず、全員が自分のタスクに従事する必要があります。

「ボウル」のコンセプト

「カップ」という言葉がどこから来たのか覚えていないことを認めなければなりません。ゴルブノフから読んだり、議論の中でその言葉が生まれたり、自分で発明したのです。それは重要ではありません。 主なものは、用語が明確かつかなり正確に概念を反映していることです。



ビジネスに取り掛かろう。 横軸（x）は専門家のポンプの条件付きレベルであり、縦軸（y）はこのレベルの従業員の条件付き数であることに同意しましょう。



従業員の大半が後輩である部門を想像してください。 この状況を反映した「ボウル」を見てみましょう。











左側がひどく過負荷になっています。 専門家はほとんどいません-中心部は満たされていません。 このオプションは、管理とテストの点で最も高価です。 しかし、毎月の人件費の面で安い。 開発の総コストについては、コードの品質に直接依存します。 そして、ここでのばらつきは重要です。 このようなスキームでの開発時間は長いです。











チームが主要な専門家に基づいている場合の逆の状況。 通常のスペシャリストの一般的/平均レベルが高い場合と、これらのスペシャリストがチーム/プロジェクト内で高い地位を占める場合です。 中央部には専門家がほとんどいません。

この状況では、垂直成長の機会は非常に限られており、モチベーションが低下し、従業員の不満が高まっています。

はい、ひげを生やした専門家だけで構成されるチームがありますが、この場合、チームは製品/会社などの動機を超えている必要があります。 すべての上にある統一要因がなければなりません。 この雰囲気は、成功した製品よりもスタートアップにとってより典型的です。



主な実際の作業は通常の専門家によって行われたことを思い出します。 この場合の「ボウル」を見てみましょう。











すべてのスケジュールの専門家の総数は同じであることに注意してください。 わかりやすくするために、1つの画像でさまざまな状況を示します。











従業員の大半は普通の専門家です。 ジュニアとホストはいますが、過剰ではありません。 ジュニアには成長の余地があり、スペシャリストには開発のための環境があります（学ぶ人がいます、学ぶ人がいます）、リーダーには十分な責任と管理の領域があります。

エキスパートに感謝します！ 彼らは部門の主な強みです。

多くの若い専門家がいる状況が発生する可能性があり、十分な管理スキルを備えた従業員がいないと、多数の後輩を適切に管理することができなくなります。 同様に、多くのクールな開発者がいる可能性があります;彼らは十分なクールなタスクを持っていない可能性があります。

そして、2〜3年の経験を持つ多くの専門家-これは幸せです！ 原則として、タスクの半分以上は、既存のコードの現在の開発とサポートです。 そして、これらのタスクのために、あなたのチームには十分な数の普通の専門家が必要です。

従業員が退職する可能性は、ボウルの端で正確に最大化されることに注意してください。ジュニアは疲れたり、「私のものではない」ことを理解したり、試用期間を過ぎたりすることはできません。



使用して開発してください！