このテーマに適した「魅力の写真」はありませんので、猫を飼ってください
何らかの理由で、IT分野の「メトリック」という言葉は、コードの記述された行のカウントやタスクのクローズなど、その愚かさの実践における「優秀」と密接に関連しています。 これらは最も役に立たず、歯のない「管理」管理ツールであると自信を持って言えます。 実際、適切なメトリックは、非常に条件付きですが、それでも、プロジェクトおよび/または作業のメトリック、結果と実行時間が明確で予測可能な時間、およびその逆のプロジェクトおよび/または作業のメトリックの2種類のみです実行時間を物理的に予測することは不可能です。 最初のタイプの場合、結果のメトリックが設定され、2番目のタイプの場合-距離、つまり勤務時間。
「結果による」最初のタイプのメトリック
従業員のメトリックを設定するための普遍的なレシピはありません-これは常に状況的な現象です。 従業員のメトリックは、常に次の質問に対する1つの簡単な回答から形成されます。最終結果を明確に予測でき、その結果、短距離または中距離での作業時間を予測できますか？
フリーランスの状況を見てみましょう。 ほとんどの場合、顧客は実行された作業量の支払いに基づいて実行者との関係を構築します。 つまり、プロジェクトには予算があり、その交渉予算の中でレッドラインと納期が合意されています。 これが、デザイナー、レイアウトデザイナー、および多くの開発者の仕事です。 ほとんどの場合、予算は変動しません。つまり、「実行時間」が変動部分です。
ただし、プラス/マイナスは常に予測可能です。つまり、顧客は注文の実行にどれくらいの「およそ」の時間がかかるかを明確に理解しています。 この図に基づいて、予算が割り当てられ、その後、適切なパフォーマーが求められます。
一般に、「注文を完了するのにどれだけの時間を費やすかは気にせず、うまくやり、私たちに受け入れられる時間内に」という原則は、フリーランス環境で明確に説かれています。 これにより、雇用されたフリーランサーまたは臨時従業員の仕事の監視に関する多くの質問が削除され、「給与」の3、4、10倍などを支払う必要がなくなります。 前払いのトランシェがあり、最終的な事前合意済みアカウントの閉鎖があります。
同様のアプローチは、人々が働いているように見える中小企業とフルタイムの両方に漏れていますが、特定の日に結果が必要な場合、会社は激しい競争と短い距離の状態に住んでいます。 「クレイジーな努力」で、次のような決定を下すのに役立つ大まかなブロック図を描くことができます。
UpWorkや他のフリーランスモデルの時間給はどうですか？
おそらく、この質問は読者の読者の方が記事の冒頭で生まれたのかもしれませんが、その答えにたどり着いたのは今だけです。 より正確には、答えにはいくつかあります。
まず、雇用会社は管理に慣れています。これは、ケースの50％の時給にはトラッカーが含まれ、100％の場合は実行された作業の監査を伴う定期的なレポートです。 つまり、顧客は管理機能の一部を請負業者自身に移し、請負業者は自分で報告します。
第二に、会社は1つの試行しかないため、開発プロセスを制御する必要があります。 プロジェクトが数週間以上続く場合、顧客は「どのような観点から」作業であるかを理解する必要があります。 ほとんどの場合、そのような大量注文に対して予算は1回しか割り当てられず、試行は1回だけです。 実際、かつて市場には大規模プロジェクトのエグゼキューターから定期的かつ時には厳しい報告を必要としない企業がありましたが、耳が小さい象についても同じことが起こりました-彼らは死にました（過熱による象、企業-期限のため）。
2番目のタイプのメトリックは「時間内」です
しかし、大規模なプロジェクトについて話し始めると、すべてがはるかに複雑になります。納期は「1〜3年」から「これは永遠の発展」です。「永遠の発展」の場合、最終結果を得る時間を予測することはほとんど不可能です次の理由：
- 1人がプロジェクトに取り組んでいるだけでなく、複数のチームでさえ作業しています。
- 各チームには「指示どおり」に2〜3〜数十人の従業員がいます。
- プロジェクトの作業が終了すると、誰も知りません。
そのような状況では、迷子になりやすく、既知のナシを既知のオブジェクトにまき散らします。 しかし、ビジネスは慈善活動に関与していないため、「結果による」メトリックから「時間による」メトリックのより複雑なカテゴリに移行する必要があります。
「定刻どおりに」働く最も単純で最も論理的な例は、開発部門の30〜50人の会社の通常のオフィスフルタイムです。 このような状況では、「陸上」ビジネスは、潜在的な従業員、つまり面接段階で、プロジェクトの完了時ではなく、労働法によると週40時間の労働に基づく1時間の労働コストに同意します。 私たちにとっては、給与のように見えます。
同時に、ビジネスは愚か者ではないことを明確に理解する必要があります。 RFPのサイズ（より正確には縮小）には、個人的な危機、オフィスをぐるぐる回る、喫煙休憩、昼食のための余分な20-30分（つまり、1時間ではなく1時間半）およびYouTubeでの先延ばしが含まれます。 一部の企業はこれらの費用を負担できます。これは、ビジネスが現在利益を上げているため、後任および中間管理職の期限を曖昧にして短期タスクを設定するだけで「ライト」バージョンの管理を行えるためです。
しかし、ビジネスが低マージンであるか、競合するレガシー環境に存在する場合、すべてが悪化します。 そして、ここから統一された地獄が始まります。開発者は「メトリック」という言葉があまり好きではありません。
労働時間を厳密に参照することは、効率の独立した測定基準ではなく、松葉杖が必要です。
人が結果に対してではなく、働いた時間に対して支払われる場合、その有効性を評価する方法は？ この質問は、ビジネスから常に寄せられています。 ここにはいくつかの変数があります。
- チームパフォーマンスを「結果」メトリックに短距離でリンクします。
- タスクおよびスプリントのレベルでのより小さいメトリックの使用。
- 責任、条件、優先順位の明確な構造を構築し、それをあなたが望むものと呼びます。例えば、「開発ポリシー」。
実際、ビジネスでは、「購入時間」という理解しやすいメカニズムに切り替わったように見える状況に直面していますが、労働時間の形でこの時間を支払うために何かを受け取ったかどうかを制御する必要があります。 つまり、「結果を購入する」という概念は、「時間を購入する」という概念に埋め込まれた変数になります。
ほとんどの場合、経営陣はビジネスと従業員のニーズを同時に明確に追跡できない、つまり、双方が満足しているメトリックを適用するシステムとポリシーを構築できないことがあります。 意味：メトリックは、ビジネスの利益を同時に満たし、従業員が理解し、実行可能でなければなりません。
ここで、別の問題に直面します。短距離で「順序どおりに」作業する場合、タスクがほとんどの場合、すべての関係者にとって明確で理解できる場合、大きな製品を開発する場合、構造全体が常に動きます。 Trite：競合他社が新しい製品または新しいツールキットをリリースし、経営陣が愛情を込めて作成したすべての計画が無駄になりました。
この時点で、管理に大きく依存します。 ここでは、メトリックを設定するための不適切で適切なアプローチを簡単に説明できます。
不十分な指標：
- コードの行数とコミット。
- 複雑さを考慮しないクローズドタスクの数。
- 開発者から投票権を奪う。
- 報告期間中のダイナミクスと開発のニーズを無視する（メトリックが常識を超える）;
- メトリックをレビューする長いプロセス、柔軟性の欠如、開発の見解を無視します。
ここでは、開発者が人から「コードライティングマシン」に変わるときの典型的な「ギャレー」について説明します。開発者が上から下に来る短期のタスクや指標にどう対処するかは気にしません。 この場合、開発者は、問題の「内部」を認識しても、開発に影響を与える機会を失います。 同時に、タスクの複雑さは考慮されておらず、それはすべて猿の仕事に帰着します。
適切な指標：
- タスクの複雑さの説明。
- 問題が発生した後の事実の後にメトリックを確認する機能。
- タスクについてコメントする機能。
- コードの行数/タスク数の定量的指標への緊密な結合の欠如;
- 必要に応じて、メトリックの部分的な非準拠を無視します。
適切なメトリックとは、フロアに固定されておらず、移動できるメトリックです。 ビジネスが最大の効率を目指している場合、この効率はすべてのレベルである必要があります。 タスクやコードの行数が実際にはあまり意味がないことは長い間明らかでした。タスクによっては製品に決定的な影響を与え、他の何百ものコストがかかる可能性があるためです。
さらに、メトリクスへの準拠に対する緊密な拘束は非生産的です。開発者が、20ではなく19のタスクを1週間で閉じたことにより「問題」があることを知っている場合、タスクの品質はバックグラウンドになります。 そして、少なくとも最後の1つである20個のタスクは、真に一度だけではなく、すべてのタスクを解決する代わりに、松葉杖と自転車で「ダンプ」に配置されます。
「時間購入」モデルの不可欠な部分としてのフィードバック
実際、作業時間に関係するしっかりと構築された開発モデルは、一見思われるよりもはるかに複雑です。 このモデルで効果的に作業するには、すべてのレベルで「パーティーポリシー」を絶えず調整する必要があるパフォーマーとリーダーの間で高品質のフィードバックを編成する必要があります。 結局のところ、不適切に設定されたタスク、つまり定式化されたメトリックは、開発者にとっては問題にはほど遠いものですが、この問題をパフォーマーにプッシュするのが慣習です。 不適切に定式化されたメトリックは、両当事者の作業が透明であるという条件で、請負業者にこのタスクを設定した経営陣だけの問題です。
作業時間が効率的に費やされるように、つまり予算が「燃え尽きない」ように作業を編成する必要がある管理ですが、同時に、開発者は数週間で燃え尽きることなくタスクに対処できます。 なぜなら、特に有能な人材に関しては、人的資源は膨大ではあるが無限ではないからです。
開発者が意味のない肉挽き器を手に入れる明確な「ギャラリー」とは異なり、勤務時間の詳細な記録を保持する会社とは異なる、経営者による決定に対するフィードバックと責任の存在です。
ビジネスで開発のボトルネックを見つけることができるのはフィードバックです。 部署の従業員が窒息し、消耗のために働いていたが、肩の代わりに荷物の一部を引き継ぐ新しい専門家の形で「補強」を受けなかった状況に遭遇した頻度はどのくらいですか？ このような状況は、開発と管理の間の質の高いフィードバックが不足しているために常に発生します。 チームの有効性とワークロードを明確に追跡する代わりに、マネージャーは指を鼻で摘み、そのようなリズムに耐えられない人が故障した場合、残りの開発者にすべてをプッシュします。 しないでください。
出力の代わりに
ワークフローを整理するプロセスで発生する可能性のある最悪の事態は、あるモデルに固有のメカニズムを別のモデルに「ジャグリング」することです。 たとえば、長期プロジェクトの場合、チームの複雑さと能力の適切な評価なしに厳しい期限が設定されます。 あるいは、短期的な自給自足のプロジェクトやタスクの場合、そのような制御形式は、ロケット科学の分野に適合するように構築されており、私たちはフリーランスの注文についてのみ話します。
構造や規模の異なる企業における特定の作業方法の適切性を明確に理解することは、仕事を探す際に健康と神経系の大きな部分を節約するのに役立ちます。 また、これらのメカニズムを理解している開発者、マネージャー、およびビジネスオーナーが多いほど、ITセグメントのすべての参加者にとってより良いものとなります。