ここでは、プログラマーがどのように、そして何に対して報酬を受け取るかについて説明します。 開発者のモチベーションシステムによって解決されるタスク。 KPI。
I.目標と目的
Ultima開発者の物質的な動機付けのシステム（SMMR）は、3つのグループの目標を達成することに焦点を当てています。
-顧客との満足
-標準に従って発行されたコードの品質
-開発者の専門能力開発の刺激
SMMRの目標は、それらを対応するKPIに変換することで達成され、そのKPIの値は、係数の増加/減少、および\またはボーナス\悪用を決定します。
ウルティマコンサルティングからの特記事項：ウルティマのSMM（P！だけでなく）は、すべての従業員の総収入を生成するときに、例外なく100％の主観性と指から吸い出されたでたらめが排除されるように設計されています。
コンピューターは、すべてを完全に自動化されたモードで考慮します。したがって、データベース内の客観的に測定、記録、および保存されたインジケーターにのみ基づいています。 「上司の評価」、「会議の結果」、またはその他の企業特有の異端性はありません。
各従業員は、収入を増やすために何をする必要があるかを非常に明確に知っています。 また、何もありません。
ただし、これは重要ですが、十分ではありません。 さらに重要なことは、SMMは従業員の個人的な利益とビジネスの共通の利益を同期させるように構築されていることです。 つまり、 従業員は会社でより多くのお金を稼ぎますが、それ以外は何もしません。
厳密に数学的には、人事管理で真正面から使用される計画システムを持たず、持つことはできません。
ファット原則の別の直接的な結果は、経済的利益を客観的に計算できないポストの人員配置表が存在しないことです。 実際、前のパートでは、このアプローチは内部テスターを放棄する場合で実証されました。
さらに、これらすべてを詳細に分析します。
II。 開発者給与計算式
期間中の開発者の最終収入=完了したタスクのボーナスの合計（2.1）+ MalusPaエラー（2.2）+一般懲戒ボーナス（2.3）
完了したタスクのボーナス（2.1）=使用時間（2.1.1）*開発者の関税率（2.1.2）*優先度係数（2.1.3）*顧客の評価係数（2.1.4）*エラー係数（2.1.5）*星の係数（2.1.6）+ Malus DelaysPerformanceApplications（2.1.7）
一般懲戒ボーナス（2.3）=コーディング標準の違反に対するマルス（2.3.1）+勤務スケジュールの違反に対するマルス（2.3.2）
合計は代数的です。名前によると、悪意は負の値です。
次に、式の各コンポーネントを分析します。
2.1完了したタスクのボーナス
2.1.1時間
詳細- 前のシリーズを参照してください。 簡単に説明すると、開発者は、問題を解決するために何時間を費やしたかを示します。
2.1.2開発者料金
実際には、 プログラマーの基本時間率（以下、内部料金と呼びます）。 前のシリーズでは、必要な開発者の資格を選択することにより、 クライアントの 1時間のコスト（外部関税）がどのように決定されるかを見てきました。 会社の観点から見ると、魂にひねりを加えることなく、最初は原価と呼ばれ、2番目は販売価格と呼ばれます。 もちろん、最初のものは2番目のものよりもかなり小さいです-私たちが住んでいるのはまさにこの「2パーセント」です。
内部関税と外部関税は当然関連しています。 しかし、直接ではなく、開発者のグレードの対応表を通じて。
いくつかのグレードは、クライアント（ジュニア、開発者、シニア）のプログラマー資格の1つのレベルに対応できます（実際には対応できます）。各グレード内には、それぞれ独自の基本レートを持つ複数のサブグレードが存在できます（実際には存在します）。
開発者の成績は、彼の専門レベルの公式評価です。
合計で6つのグレードがあります。
開発者は、最初のトレーニングに合格した後、1年生を受け取ります。 サブグレードとグレード間の移行は自動的に行われます-問題の解決における経験の蓄積（ヒーローからの経験）は、妥当なレベルの品質を条件とします。
実験は充電時間の合計を通して考慮され、成績が悪く、エラーはマイナスになります（些細なことです-各エラーについてマイナスで非常に多くの時間があり、X未満のグレードについてなど）。
必要な経験を超える高い成績を得るには、内部知識ベースの記事を書く必要があります。
実際には、開発者は雇用後約1年半から2年で5年生を受け取ります。
したがって、内部グレードのシステムは、プロの成長と並行して、開発者がより多くのお金を受け取るという事実により、あなたがより良い仕事をすることを奨励します（同時に）。
2.1.3優先度比
優先度の高いタスクの場合、開発者は、グレードサブグレードに起因するベースレートに適用される増加した係数が強化された（クロスアウト）を受けます。
2.1.4顧客評価率
タスクを「完了」に変換するとき、顧客は結果の評価を選択します。
社内のキッチンでは、4はそれぞれ満足できる評価と見なされます。この評価では、開発者は基本グレードのレートで受け取ります。
4以上のスコア-このタスクの係数を増やし、それ以下-下げます。
評価係数は、最終収入で最も重要な調整係数です。
そして、開発者はそれを知っています。
したがって、フォーム上のボタンのレイアウトの魅力、顧客との接触の正確さと適時性、彼の考えや欲求の浸透など、それを見る動機があります。
または、少なくとも、「性交で...」行動しないでください。
2.1.6スター比
アプリケーションの顧客は、開発者のレベルだけでなく、アプリケーションの特定の請負業者も示すことができます。
開発者の1人の需要が高い場合、増加する係数をグレードから生じる基本レートに適用できます。 係数は、クライアントがこの請負業者のみを選択するアプリケーションにのみ適用され、一般的なキューからロボットによって配布されるアプリケーションには適用されません。
2.1.5エラー率とエラーの2.2 Malus
前のパートで書いたように、「エラー」などのタスクは特別な方法で処理されます。
エラーには2つのタイプがあります。
-子アプリケーションとして作成-つまり、オンライントラッカーでエラーを修正する段階で、どのアプリケーションが発生したかを実装した結果として知られています。
-個別のアプリケーション-エラーの事実があるが、発生源が明らかでない場合
「子」エラーは、メインアプリケーションを作成した請負業者に直接送信されます。 エラーはクライアントとプログラマの両方に対して無料で修正されます。
優先度に従って、個別のアプリケーションが汎用キューに分散されます。
そのようなタスクが割り当てられている実行者は、可能であればエラーの原因を示すことができます。 この場合の修正作業は、後者を犠牲にして（費用で）実行されます。
ジョイントの作成者を決定できない場合、修正のコストは、請求された時間の合計に比例して、プロジェクトに参加したすべての開発者に均等に配分されます。
開発者の個人的なエラーを修正するための費用の額と、割り当てられていない横棒の比例配分は、彼の個人的な月間MalusZaエラーを構成します。
このような慣行は、その明らかな深刻度（またはむしろ感謝）にもかかわらず、開発者が「結婚ではなく、受け入れ、受け入れる」という原則に従って行動することを明確に動機付けています。
なぜ明らかなのですか？ 店主やレジ係の物質的責任の慣行と比較するのは簡単です。 彼女は当然のことと考えられています。
エラーを最小限に抑えるための妥協のない動機の自然な結果は
-読みやすさの方向での出力コードの改善
-統合テストの作成
開発者は、間違いを簡単に修正できる（そして軽微な損失を被る）理解しやすいコードと不明瞭なゴミとの関係を明確に理解しています。
理解できないコードでは、エラーフラグのあるタスクを受け取った開発者は、トライアルに多くの時間を費やすことができます。 そして、タスクについて有罪当事者も決定される場合（そしてそれを決定する動機が大きいほど、関節の修正がより高価でした）、...
要するに、豊かで健康的であること、つまり、理解可能なコードを書き、他の人からそれを行うことを学ぶ方がよいのです。
同様の考慮事項により、開発者は統合テストを作成することになります。
2.1.7 Malus遅延実行アプリケーション
確かに、私たちは次の質問に精通しているだけではありません。「アプリケーションXXXはどうですか？ すでに3日間、それをどのように行うべきか！」非常に不満な口調。
顧客満足の重要な要素は、納期を守ることです。
実際には、これらの期限の遵守またはタイムリーな延期。
Malusのアプリケーションの遅延実行は、実際には用語を改訂する多くの客観的な理由があるため、正確に顧客の認識を目的としています。
たとえば、タスクには顧客の機器との統合が必要です。 そして、この機器は壊れています。 修理または交換を待つ必要があります。
全体として、開発者が期限を遵守するよう動機付けするか、少なくとも顧客に変更を通知する必要があります。
数多くの実験の後、ネガティブな動機のみが働いた。
優先順位のあるアプリケーションの場合、通常の増加は、アプリケーションの計画日を超える日ごとのアプリケーションの実行の遅延です。 緊急かつ重要なタスク-1時間ごと。
アプリケーションで予想される期間は顧客のみが延期できるため、必要に応じて、後者とその根拠を適切に通知する必要が自動的にあります。
2.3一般懲戒ボーナス
2.3.1規格をコーディングするためのMalus分解
各開発者は自由にコーディング標準を使用します。 何を、どのように、何をすべきか、何をすべきでないか。
文書は常に更新されます-一方では 、 新しいプラットフォームビルドをリリースする際に原子力システムエンジニアから、他方では 、ポップアップジャム（実際には、典型的なPDCAサイクル）の理由を分析する際に申請者から。
このドキュメントの一部には非常に正式な要件が含まれており、自動的にチェックされます。 たとえば、すべてのソリューションはロシア語と英語で動作するはずです。 これは、プログラムに定数文字列（特別にマークされた文字列または一意に定義されたもの-SQLクエリなど）を持たせてはならず、すべての文字列定数をリソースから取得し、リソースがサポートされているすべての言語の値を持つ必要があることを意味します。 このチェックと同様のチェックは、Roslynを使用して自動的に実行されます。 開発者が原則として不適切な作業を顧客に譲渡できないように実装されています。
さらに、手動チェックの必要性を可能な限り減らすために、コーディング標準をできる限り形式化するよう努めています。
Malusは、jambコードの検出の各ケースの固定量として計算されます。
Coding Standardの開発に関する開発者の提案からの有用な推奨事項は、無料の修正による損失を減らすだけでなく、1回限りの報酬があります。
2.3.2勤務スケジュールとのわずかな矛盾
前回の記事で、開発者は自分のスケジュールに従って自由に作業できると述べました。 ただし、独自のスケジュールを作成したら、開発者はそれを遵守し、自分で設定した時間に利用できるようにする必要があります。
開発者が適切なタイミングで連絡を取っていなかったことが判明した場合は、sabzh malus-Xルーブルを各ケースに加えます。
結論として
SMMRの長年にわたる進化的開発の結果として、顧客満足度、コード品質、信頼性の真の増加を確実に観察します。コードレビューを導入し、コードとサービスの品質をさらに向上させるための動機付けのプラットフォームがあります。
2015年のタスクの平均スコアは4.4です。この2つは非常にまれな不可抗力です。
次のシリーズでは、ビジネスアナリストとは何ですか（陰謀を生み出すために-我が国では、この概念は一般に受け入れられているものとは大きく異なります）、それが必要な理由とその動機
著者は、会社のビジネスプロセスの構築とこのシリーズの作成の両方において、貴重な助けをしてくれたウルティマコンサルティングに感謝します。