プロジェクトでの節約について
競合他社が同じサービスで提供している価格と、私たちと同じように機能する価格についての研究に出くわしました。 そして、このデータは不快でした。私たちは明らかに高価でした。 注文を保持してポジションを保持するには、変更が必要でした。
今後は、最終的に作業を再構築したと言います。 さらに、コストを削減するだけでなく、プログラマーの給与も引き上げます。 方法-カットの下で読んでください。
まず、プロジェクトの人件費の構造を理解することにしました。 プロジェクトのすべての作業は、個別のブロックに分割されました。 各ブロックは、主要な開発者が評価する評価、est、およびプログラマが費やす時間で知られています。 「プログラマーの作業速度」を比率（推定量）/（消費量）として決定し、1つのプロジェクトの1つのチームについてこの指標を計算しました。 テーブルが判明しました：
速度分散が目を引きます。 彼はどこから来たのですか？ たぶん実験のエラーでしょうか？ 最初は、さまざまな開発者がさまざまな難易度のタスクを得ると考えました。 そのため、1つのプロジェクトの表を作成しました。作業は互いに似ていました。 また、サンプルは1つのチームに提供され、すべてのプログラマーがプロジェクトに関する情報に同じアクセス権を持ち、コミュニケーションや技術専門家からの助けを得る機会も同じでした。念のため、他のプロジェクトや他のチーム用に同様のテーブルを作成し、確認しました：スキャターもあります。
後で確信したように、このような幅広いバリエーションは、プログラマーでない人にとって重要な事実です。 経営陣との会話の前に証拠ベースを強化するために、私はソフトウェア開発の専門家がこの主題について言っていることを読むことにしました。 S. Arkhipenkovaの本では、パフォーマンスのばらつきについて言及されています。 A.オルロフは、「 Secrets of Programmer Management」という本で同様の方法で話しています。
ジョエル・スポルスキーの本で 、彼はイェール大学のスタンリー・アイゼンシュタット教授が行った研究に関する興味深いデータを見つけました。 数年間、学生は宿題のプログラミングにどれだけの時間を費やしたかを報告するよう求められました。 結果の一部を次に示します。
上記の例は、私たちのプロジェクトで観察された速度のばらつきは、当社のプロジェクト管理の機能ではなく、さらにはエラーであると述べるのに十分です。 これは、考慮すべきプログラマーの職業の客観的な特徴です。
それでは、私たちの仕事に戻りましょう。プロジェクトを実施する際のコストを削減します。 私の最初のタブレットから、速度の広がりは6倍になったということです。 そして、このチーム内での給与のばらつき（最大レートと最小レートの比）は約2でした。したがって、プログラマNに仕事を与えると、同じ仕事をプログラマ＃1に与える場合よりも3倍多く支払うことになります。
結論は、プロジェクト内の強力なプログラマーの割合が大きければ大きいほど、それが安くなることを示唆しています。 そのため、既に強力な開発者を雇用し、既に経験を積んだ人材を維持する必要があります。 さらに、これはジュニアレベルの従業員の完全な拒絶を意味するものではありません。第一に、誰かがやらなければならない簡単なタスクが常にあり、第二に、有望なジュニアが時間の経過とともに成長します。
ただし、表を作成して自分で結論を出すことは1つのことです。 別のことは、アイデアをリーダーシップに伝え、彼の無実を彼に納得させることです。
記事の冒頭で述べたように、アクションは競争とコスト削減（節約）を背景に行われました。 通常、そのような状況では、オフィスは給与の引き上げについて話していません-総貯蓄が開始されます（まあ、何らかの形で価格を下げる必要があります？！）。
就職率の向上と給与水準の引き上げという考えは、予想外に控えめに言っても見えました。
たとえば、建設現場の煉瓦職人の仕事がどのように支払われるかを見てみましょう。 ほとんどの場合、彼の給与は生産量に比例します。彼は2倍速く働いて、2倍のお金を受け取りました。 状況は、たとえばミニバスの運転手でも同様です。彼はより速く運転し、単位時間あたりの乗客を増やし、より多くのお金を集めました。 正直かつ公正に（安全ではありませんが）。
このデフォルトのアプローチは、マネージャーだけでなく、多くの人々の頭の中にあります。 したがって、PMの非IT担当者は、中間賃金がメイドよりもK％高いことを確認すると、中間賃金が約K％速くなると考えます。 これは、システムが線形であることを意味します。$ 1000で2人= 2000で1人。 さらに、彼らと仕事をすることにはある種の「不便」があります。
私の観察によると、プログラマーのレベルが高いほど、彼が取り組んでいる製品の品質に対してより多くの要件を課しています。 緑の初心者が既に製品に組み込まれた実用的なコードを作成したことに満足している場合、経験豊富な同僚が自問します。なぜこのテクノロジーを使用し、他のテクノロジーは使用しないのですか？ 製品に実装されている本当にクールなものは何ですか？ 競合他社よりも優れているのはなぜですか？ 実際には、これは、開発者がプロジェクトにそれをより興味深いものとして含めるように要求し、慢性的に原始的な仕事を得た場合に不満を表明するという事実に変換されます。 または、「松葉杖から」すばやくコードをビルドすることを拒否し、通常の開発に時間がかかります。
時々、誤って、この行動は「スター病」として分類されます。 そして、この定式化では、経験豊富なプログラマーよりも初心者と一緒に作業する方が本当に良いです。
最後に、情報はリーダーシップに伝えられ、提案された改革が実行されました。私たちはほとんど専任の強力なプログラマーと仕事をしています。 その結果、次のようになりました。
そして、これは金銭的な指標の問題だけではありません-状況が中間管理職とトップ管理職に説明されたため、開発者とプログラマーの職業に対する彼らの態度が変わりました。
今後は、最終的に作業を再構築したと言います。 さらに、コストを削減するだけでなく、プログラマーの給与も引き上げます。 方法-カットの下で読んでください。
リサーチ
内部分析
まず、プロジェクトの人件費の構造を理解することにしました。 プロジェクトのすべての作業は、個別のブロックに分割されました。 各ブロックは、主要な開発者が評価する評価、est、およびプログラマが費やす時間で知られています。 「プログラマーの作業速度」を比率（推定量）/（消費量）として決定し、1つのプロジェクトの1つのチームについてこの指標を計算しました。 テーブルが判明しました：
| 開発者 | 「スピード」 |
|---|---|
| 1 | 1,61 |
| 2 | 1.55 |
| ... | ... |
| N-1 | 0.31 |
| N | 0.26 |
速度分散が目を引きます。 彼はどこから来たのですか？ たぶん実験のエラーでしょうか？ 最初は、さまざまな開発者がさまざまな難易度のタスクを得ると考えました。 そのため、1つのプロジェクトの表を作成しました。作業は互いに似ていました。 また、サンプルは1つのチームに提供され、すべてのプログラマーがプロジェクトに関する情報に同じアクセス権を持ち、コミュニケーションや技術専門家からの助けを得る機会も同じでした。念のため、他のプロジェクトや他のチーム用に同様のテーブルを作成し、確認しました：スキャターもあります。
外部ソースからのデータ
後で確信したように、このような幅広いバリエーションは、プログラマーでない人にとって重要な事実です。 経営陣との会話の前に証拠ベースを強化するために、私はソフトウェア開発の専門家がこの主題について言っていることを読むことにしました。 S. Arkhipenkovaの本では、パフォーマンスのばらつきについて言及されています。 A.オルロフは、「 Secrets of Programmer Management」という本で同様の方法で話しています。
ジョエル・スポルスキーの本で 、彼はイェール大学のスタンリー・アイゼンシュタット教授が行った研究に関する興味深いデータを見つけました。 数年間、学生は宿題のプログラミングにどれだけの時間を費やしたかを報告するよう求められました。 結果の一部を次に示します。
| プロジェクト | 平均 | 最低 | 最大 | 偏差 |
|---|---|---|---|---|
| COMPRESS00 | 33.83 | 11.58 | 77.00 | 14.51 |
| COMPRESS99 | 27.47 | 6.67 | 69.50 | 13.62 |
| Tex00 | 21.22 | 6.00 | 75.00 | 12.11 |
上記の例は、私たちのプロジェクトで観察された速度のばらつきは、当社のプロジェクト管理の機能ではなく、さらにはエラーであると述べるのに十分です。 これは、考慮すべきプログラマーの職業の客観的な特徴です。
レシピ
それでは、私たちの仕事に戻りましょう。プロジェクトを実施する際のコストを削減します。 私の最初のタブレットから、速度の広がりは6倍になったということです。 そして、このチーム内での給与のばらつき（最大レートと最小レートの比）は約2でした。したがって、プログラマNに仕事を与えると、同じ仕事をプログラマ＃1に与える場合よりも3倍多く支払うことになります。
結論は、プロジェクト内の強力なプログラマーの割合が大きければ大きいほど、それが安くなることを示唆しています。 そのため、既に強力な開発者を雇用し、既に経験を積んだ人材を維持する必要があります。 さらに、これはジュニアレベルの従業員の完全な拒絶を意味するものではありません。第一に、誰かがやらなければならない簡単なタスクが常にあり、第二に、有望なジュニアが時間の経過とともに成長します。
ただし、表を作成して自分で結論を出すことは1つのことです。 別のことは、アイデアをリーダーシップに伝え、彼の無実を彼に納得させることです。
より高価なプログラマーと仕事をするように経営陣を説得することが難しいのはなぜですか？
心理的障壁
記事の冒頭で述べたように、アクションは競争とコスト削減（節約）を背景に行われました。 通常、そのような状況では、オフィスは給与の引き上げについて話していません-総貯蓄が開始されます（まあ、何らかの形で価格を下げる必要があります？！）。
就職率の向上と給与水準の引き上げという考えは、予想外に控えめに言っても見えました。
問題の表面的な外観
たとえば、建設現場の煉瓦職人の仕事がどのように支払われるかを見てみましょう。 ほとんどの場合、彼の給与は生産量に比例します。彼は2倍速く働いて、2倍のお金を受け取りました。 状況は、たとえばミニバスの運転手でも同様です。彼はより速く運転し、単位時間あたりの乗客を増やし、より多くのお金を集めました。 正直かつ公正に（安全ではありませんが）。
このデフォルトのアプローチは、マネージャーだけでなく、多くの人々の頭の中にあります。 したがって、PMの非IT担当者は、中間賃金がメイドよりもK％高いことを確認すると、中間賃金が約K％速くなると考えます。 これは、システムが線形であることを意味します。$ 1000で2人= 2000で1人。 さらに、彼らと仕事をすることにはある種の「不便」があります。
スター病
私の観察によると、プログラマーのレベルが高いほど、彼が取り組んでいる製品の品質に対してより多くの要件を課しています。 緑の初心者が既に製品に組み込まれた実用的なコードを作成したことに満足している場合、経験豊富な同僚が自問します。なぜこのテクノロジーを使用し、他のテクノロジーは使用しないのですか？ 製品に実装されている本当にクールなものは何ですか？ 競合他社よりも優れているのはなぜですか？ 実際には、これは、開発者がプロジェクトにそれをより興味深いものとして含めるように要求し、慢性的に原始的な仕事を得た場合に不満を表明するという事実に変換されます。 または、「松葉杖から」すばやくコードをビルドすることを拒否し、通常の開発に時間がかかります。
時々、誤って、この行動は「スター病」として分類されます。 そして、この定式化では、経験豊富なプログラマーよりも初心者と一緒に作業する方が本当に良いです。
最後に何が起こったのですか？
最後に、情報はリーダーシップに伝えられ、提案された改革が実行されました。私たちはほとんど専任の強力なプログラマーと仕事をしています。 その結果、次のようになりました。
- チームの強力なプログラマの平均給与は50％以上増加しました。
- 作業単位あたりの平均コストは50％減少しました。
そして、これは金銭的な指標の問題だけではありません-状況が中間管理職とトップ管理職に説明されたため、開発者とプログラマーの職業に対する彼らの態度が変わりました。
All Articles