Secrets of the Madrid court. Part II: Developer Material Motivation System
The previous text of the series , which describes the structure of the business process of setting and performing tasks, is recommended for preliminary familiarization.
Here - how and for what programmers receive money. Tasks solved by our developer motivation system. KPI.
The Ultima Developer Material Motivation System (SMMR) is focused on achieving goals from three groups:
- customer satisfaction with the result
-quality of the issued code according to standards
-stimulating the professional growth of developers
The goals of SMRM are achieved through their translation into the corresponding KPI, the values ​​of which, in turn, determine the raising / decreasing coefficients and \ or bonuses \ malus.
Further we will analyze all this in detail.
Total developer income for the period = Sum of Bonuses for completed tasks (2.1) + MalusSaError (2.2) + General Disciplinary Bonus (2.3)
Bonus for the task performed (2.1) = SpentHours (2.1.1) * Tariff Rate of the Developer (2.1.2) * Coefficient of Priority (2.1.3) * CoefficientEvaluation of the Customer (2.1.4) * Coefficient of Error (2.1.5) * Coefficient of Star Rating (2.1.6) + MalusEnder Proposal Fulfillment (2.1.7)
General Disciplinary Bonus (2.3) = Minus Delay Compliance with Standards Encoding (2.3.1) + Minus Correspondence with Working Graphics (2.3.2)
The sum is implied algebraic: malus, according to the name, negative values.
Now analyze each component of the formula.
2.1.1 Hours spent
Details - see the previous series . In short - the developer indicates how many hours he spent to solve the problem.
2.1.2 Developer Tariff Rate
Actually, the basic rate of the hour for the programmer (hereinafter we will call it the internal rate). In the previous series, we looked at how the cost per hour for a client (external tariff) was determined through the choice of qualifications of the required developer. From the point of view of the company, it’s possible to call the first one cost one, and the second - the selling price. The first, of course, is significantly less than the second - it is for these “two percents” that we live.
The internal and external tariffs are naturally connected. But not directly, but through the developer grade table.
One degree of qualification of a programmer for a client (Junior, Developer, Senior) can correspond (and corresponds to reality) to several grades, and within each grade there can exist (and exist in reality) several subgrades, each of which has its own basic hour rate.
Grade developer is the official assessment of its professional level.
In total, we have six grades.
The first grade developer receives after passing the initial training. Transitions between sub-grades and grades occur automatically, as experience in problem solving (experience from Heroes) is accumulated, provided a reasonable level of quality is achieved.
Experience is considered through summing up the enchanting hours, bad estimates and errors go into a minus (trivially - for every mistake so many hours into a minus, for a score lower than X, so many, etc.)
To obtain higher grades beyond the required experience, writing articles for the internal knowledge base is required.
In practice, the developer gets the 5th grade approximately one and a half to two years after employment.
So, the system of internal grades stimulates working more and better by the fact that in parallel with professional growth, the developer gets more money (during the same time of work).
2.1.3Priority Ratio
For the tasks of increased priority, the developer receives an enhanced supply (to cancel) the increased coefficient applied to the base rate resulting from his grade-sub-grade.
2.1.4 Customer Evaluation Ratio
When transferring the task to “completed”, the customer selects the result assessment:
In our internal kitchen, a four is considered a satisfactory rating, respectively, with this assessment, the developer will receive at the base rate of grade.
A score above four - a raising factor for this task, a smaller one - a lowering one.
Evaluation factor is the most important modulating factor in total income.
And the developer knows it.
Accordingly, the attractiveness of the layout of the buttons on the form, the correctness and timeliness of contact with the customer, insight into his thoughts and desires, and so on - there is an incentive to look at it.
Or, at least, not to act “on ... fuck”.
2.1.6 Star Coefficient
Let me remind you that the customer in the application can indicate not only the level of the developer, but also a specific artist for the application.
If one of the developers is in high demand, a multiplying factor can be applied to its base rate resulting from the grade. The coefficient applies only to those applications in which the client selects only this executor and does not apply to applications distributed by the robot from the general queue.
2.1.5 Error Coefficient and 2.2 Malus Error
As I wrote in the last part, “Error” tasks are handled in a special way.
There are two types of errors:
-Created as child applications - that is, at the stage of fixing an error in the online tracker, it is known, as a result of the implementation of which application it arose
- Separately standing applications - when the fact of error is, and the source of origin is not obvious
“Subsidiary” errors go directly to the artist who made the main application. Errors are corrected for free - both for the client and for the programmer.
Separate applications are distributed in the public queue in accordance with the priority.
The contractor to whom such a task is assigned may indicate the culprit of the error - if this is possible. Corrective work in this case will be made at the expense of the latter (at cost).
If it is not possible to determine the author of the shoal, then the cost of the correction is evenly distributed among all the developers who participated in the project in proportion to the amount of enchantment hours.
The sum of the cost of correcting the personal mistakes of the developer and his proportional share of unallocated jambs constitute his personal monthly MalusSaEs.
This practice, despite its apparent severity (and, more precisely, thanks to) uniquely motivates developers to act in accordance with the principle of “accept, not create, not skip marriage”.
Why seeming? It is easy to compare with the practice of liability storekeepers or cashiers. With whom it is taken for granted.
The natural consequence of uncompromising motivation to minimize errors is
-improvement of the output code towards its readability
- writing integration tests
Developers clearly see the connection between clear code, in which it is easy to correct the error (and incur minor losses) and muffled rubbish .
In an incomprehensible code, a developer who has received a task with an error sign can spend a lot of time on the trial. And if the culprit is determined (and the motivation to determine it is the more, the more expensive the correction of the joint is) by task, then ...
In short, it is better to be rich and healthy, that is, to write clear code and learn how to do it from others.
Similar reasoning leads developers to write integration tests.
2.1.7 MalusEdit Execution Applications
Surely not only we are familiar with the question: “What about the application XXX? 3 days how it should be done! ”Very dissatisfied tone.
An important component of customer satisfaction is meeting deadlines.
In practice, compliance or timely postponement of these deadlines.
MalusProslochki Fulfillment of the application is directed just to the awareness of the customer, because in real life there are many objective reasons for the revision of the term.
For example - the task requires integration with the equipment at the customer. And this equipment has broken. We have to wait for his repair or replacement.
Total, we need to motivate the developer to comply with the terms, or at least keep the customer informed about the changes.
After numerous experiences, only negative motivation has earned.
For applications with priority, the Malus Proposal Fulfillment of the application is increased for each day over the planned application date. For urgent and critical tasks - for each hour.
Since the expected time in the application can only be postponed by the customer, the need to properly inform the latter and the justification, if necessary, follow automatically.
2.3.1 MalusBacking upCoding Standards
At the disposal of each developer is Coding Standard. What how what should be done, and what can not be done.
The document is constantly updated - on the one hand, from the nuclear system engineers when releasing new builds of the platform , on the other hand - from applied specialists when analyzing the causes of emerging jambs (actually, a typical PDCA cycle).
A part of this document contains fairly formal requirements, which we check automatically. For example, all our solutions should work in Russian and English. This means that the program should not have constant strings (except for those specially marked or uniquely defined - for example, SQL queries), all string constants should be taken from resources, and resources should contain values ​​for all supported languages. This and similar checks are performed using Roslyn in automatic mode. They are implemented in such a way that the developer, in principle, cannot hand over the inappropriate work to the customer.
In turn, we strive to formalize the Coding Standard as much as possible in order to minimize the need for manual checks.
Malus is calculated as a fixed amount for each case of detection of a junction code.
Useful recommendations of the developer’s proposal for the development of Coding Standard not only reduce the losses from the free fix, but are also rewarded once.
2.3.2 Negative Correspondence to Working Graphics
In the previous article, I mentioned that developers are free to work on their own, convenient schedule. However, having created your own schedule, the developer must adhere to it and be available at the hours set by him.
If it turns out that the developer was not in touch at the right time, plus sabzhevy malus - X rubles for each case.
As a result of the long-term evolutionary development of SMRM, we reliably observe a real increase in customer satisfaction, quality and code reliability, there is a motivational platform for introducing code review and further improving the quality of code and service.
The average score for the tasks for 2015 is 4.4, deuce is an extremely rare force majeure.
In the following series - what is a business analyst (in order to create intrigue - we have this concept significantly different from the generally accepted one), why is it needed and its motivation
The author thanks Ultima Consulting for their invaluable assistance, both in the actual construction of the company's business processes and in the creation of this series.
Here - how and for what programmers receive money. Tasks solved by our developer motivation system. KPI.
I. Goals and Objectives
The Ultima Developer Material Motivation System (SMMR) is focused on achieving goals from three groups:
- customer satisfaction with the result
-quality of the issued code according to standards
-stimulating the professional growth of developers
The goals of SMRM are achieved through their translation into the corresponding KPI, the values ​​of which, in turn, determine the raising / decreasing coefficients and \ or bonuses \ malus.
Special note from Ultima Consulting: The SMM at Ultima (not just P!) Is designed so that when forming the total income of all employees without exception, 100% exclude subjectivism and arbitrary rubbish being sucked from the finger.
Everything counts a computer in a fully automatic mode - and, accordingly, solely on the basis of objectively measured, fixed and stored in a database of indicators. No "boss ratings", "meeting results" and other corporate-idiotic heresy.
Each employee knows very clearly what he needs to do to earn more. And also, what NOT.
')
However, this is important, but not enough. Much more important is that the SMM is built in such a way as to synchronize the personal interests of the employees and the common interests of the business. That is, the employee makes more money with the company and nothing else.
Strictly mathematically, this implies that we do not have and cannot have a planning system that is used in a front-end way in HR management.
Another direct consequence of the bold principle is the lack of posts in the staff list, the economic returns of which cannot be objectively calculated. Actually, in the previous part, this approach was demonstrated on the case of rejection of internal testers.
Further we will analyze all this in detail.
Ii. Developer Salary Formula
Total developer income for the period = Sum of Bonuses for completed tasks (2.1) + MalusSaError (2.2) + General Disciplinary Bonus (2.3)
Bonus for the task performed (2.1) = SpentHours (2.1.1) * Tariff Rate of the Developer (2.1.2) * Coefficient of Priority (2.1.3) * CoefficientEvaluation of the Customer (2.1.4) * Coefficient of Error (2.1.5) * Coefficient of Star Rating (2.1.6) + MalusEnder Proposal Fulfillment (2.1.7)
General Disciplinary Bonus (2.3) = Minus Delay Compliance with Standards Encoding (2.3.1) + Minus Correspondence with Working Graphics (2.3.2)
The sum is implied algebraic: malus, according to the name, negative values.
Now analyze each component of the formula.
2.1 Bonus for the completed task
2.1.1 Hours spent
Details - see the previous series . In short - the developer indicates how many hours he spent to solve the problem.
2.1.2 Developer Tariff Rate
Actually, the basic rate of the hour for the programmer (hereinafter we will call it the internal rate). In the previous series, we looked at how the cost per hour for a client (external tariff) was determined through the choice of qualifications of the required developer. From the point of view of the company, it’s possible to call the first one cost one, and the second - the selling price. The first, of course, is significantly less than the second - it is for these “two percents” that we live.
The internal and external tariffs are naturally connected. But not directly, but through the developer grade table.
One degree of qualification of a programmer for a client (Junior, Developer, Senior) can correspond (and corresponds to reality) to several grades, and within each grade there can exist (and exist in reality) several subgrades, each of which has its own basic hour rate.
Grade developer is the official assessment of its professional level.
In total, we have six grades.
The first grade developer receives after passing the initial training. Transitions between sub-grades and grades occur automatically, as experience in problem solving (experience from Heroes) is accumulated, provided a reasonable level of quality is achieved.
Experience is considered through summing up the enchanting hours, bad estimates and errors go into a minus (trivially - for every mistake so many hours into a minus, for a score lower than X, so many, etc.)
To obtain higher grades beyond the required experience, writing articles for the internal knowledge base is required.
In practice, the developer gets the 5th grade approximately one and a half to two years after employment.
So, the system of internal grades stimulates working more and better by the fact that in parallel with professional growth, the developer gets more money (during the same time of work).
2.1.3Priority Ratio
For the tasks of increased priority, the developer receives an enhanced supply (to cancel) the increased coefficient applied to the base rate resulting from his grade-sub-grade.
2.1.4 Customer Evaluation Ratio
When transferring the task to “completed”, the customer selects the result assessment:
In our internal kitchen, a four is considered a satisfactory rating, respectively, with this assessment, the developer will receive at the base rate of grade.
A score above four - a raising factor for this task, a smaller one - a lowering one.
Evaluation factor is the most important modulating factor in total income.
And the developer knows it.
Accordingly, the attractiveness of the layout of the buttons on the form, the correctness and timeliness of contact with the customer, insight into his thoughts and desires, and so on - there is an incentive to look at it.
Or, at least, not to act “on ... fuck”.
2.1.6 Star Coefficient
Let me remind you that the customer in the application can indicate not only the level of the developer, but also a specific artist for the application.
If one of the developers is in high demand, a multiplying factor can be applied to its base rate resulting from the grade. The coefficient applies only to those applications in which the client selects only this executor and does not apply to applications distributed by the robot from the general queue.
2.1.5 Error Coefficient and 2.2 Malus Error
As I wrote in the last part, “Error” tasks are handled in a special way.
There are two types of errors:
-Created as child applications - that is, at the stage of fixing an error in the online tracker, it is known, as a result of the implementation of which application it arose
- Separately standing applications - when the fact of error is, and the source of origin is not obvious
“Subsidiary” errors go directly to the artist who made the main application. Errors are corrected for free - both for the client and for the programmer.
Separate applications are distributed in the public queue in accordance with the priority.
The contractor to whom such a task is assigned may indicate the culprit of the error - if this is possible. Corrective work in this case will be made at the expense of the latter (at cost).
If it is not possible to determine the author of the shoal, then the cost of the correction is evenly distributed among all the developers who participated in the project in proportion to the amount of enchantment hours.
The sum of the cost of correcting the personal mistakes of the developer and his proportional share of unallocated jambs constitute his personal monthly MalusSaEs.
This practice, despite its apparent severity (and, more precisely, thanks to) uniquely motivates developers to act in accordance with the principle of “accept, not create, not skip marriage”.
Why seeming? It is easy to compare with the practice of liability storekeepers or cashiers. With whom it is taken for granted.
The natural consequence of uncompromising motivation to minimize errors is
-improvement of the output code towards its readability
- writing integration tests
Developers clearly see the connection between clear code, in which it is easy to correct the error (and incur minor losses) and muffled rubbish .
In an incomprehensible code, a developer who has received a task with an error sign can spend a lot of time on the trial. And if the culprit is determined (and the motivation to determine it is the more, the more expensive the correction of the joint is) by task, then ...
In short, it is better to be rich and healthy, that is, to write clear code and learn how to do it from others.
Similar reasoning leads developers to write integration tests.
2.1.7 MalusEdit Execution Applications
Surely not only we are familiar with the question: “What about the application XXX? 3 days how it should be done! ”Very dissatisfied tone.
An important component of customer satisfaction is meeting deadlines.
In practice, compliance or timely postponement of these deadlines.
MalusProslochki Fulfillment of the application is directed just to the awareness of the customer, because in real life there are many objective reasons for the revision of the term.
For example - the task requires integration with the equipment at the customer. And this equipment has broken. We have to wait for his repair or replacement.
Total, we need to motivate the developer to comply with the terms, or at least keep the customer informed about the changes.
After numerous experiences, only negative motivation has earned.
For applications with priority, the Malus Proposal Fulfillment of the application is increased for each day over the planned application date. For urgent and critical tasks - for each hour.
Since the expected time in the application can only be postponed by the customer, the need to properly inform the latter and the justification, if necessary, follow automatically.
2.3 General Disciplinary Bonus
2.3.1 MalusBacking upCoding Standards
At the disposal of each developer is Coding Standard. What how what should be done, and what can not be done.
The document is constantly updated - on the one hand, from the nuclear system engineers when releasing new builds of the platform , on the other hand - from applied specialists when analyzing the causes of emerging jambs (actually, a typical PDCA cycle).
A part of this document contains fairly formal requirements, which we check automatically. For example, all our solutions should work in Russian and English. This means that the program should not have constant strings (except for those specially marked or uniquely defined - for example, SQL queries), all string constants should be taken from resources, and resources should contain values ​​for all supported languages. This and similar checks are performed using Roslyn in automatic mode. They are implemented in such a way that the developer, in principle, cannot hand over the inappropriate work to the customer.
In turn, we strive to formalize the Coding Standard as much as possible in order to minimize the need for manual checks.
Malus is calculated as a fixed amount for each case of detection of a junction code.
Useful recommendations of the developer’s proposal for the development of Coding Standard not only reduce the losses from the free fix, but are also rewarded once.
2.3.2 Negative Correspondence to Working Graphics
In the previous article, I mentioned that developers are free to work on their own, convenient schedule. However, having created your own schedule, the developer must adhere to it and be available at the hours set by him.
If it turns out that the developer was not in touch at the right time, plus sabzhevy malus - X rubles for each case.
Finally
As a result of the long-term evolutionary development of SMRM, we reliably observe a real increase in customer satisfaction, quality and code reliability, there is a motivational platform for introducing code review and further improving the quality of code and service.
The average score for the tasks for 2015 is 4.4, deuce is an extremely rare force majeure.
In the following series - what is a business analyst (in order to create intrigue - we have this concept significantly different from the generally accepted one), why is it needed and its motivation
The author thanks Ultima Consulting for their invaluable assistance, both in the actual construction of the company's business processes and in the creation of this series.
Source: https://habr.com/ru/post/255685/
All Articles