Secrets of the Madrid court. Part 2.5: Answers to readers' questions on the previous part
The series of publications “Secrets of the Madrid Court” was conceived in intentions (quote from the first part ):
“... our solutions to sick issues and the technologies used are by no means positioned as the best. On the contrary, with the intention to tell colleagues in the dangerous business about our own developments, we expect to receive constructive criticism and counter ideas in the comments that did not come to our heads . ”
The main part of our readers, in our opinion, perceived the contents of the articles either as an advertisement of the company in the programmer’s vacancies section, or as an opportunity to realize long-time resentment of invaluable talents on ugly stupid bosses.
')
That is, there was no dialogue with the actual “colleagues in the dangerous business” (in the sense of businessmen in the production / implementation of similar software). Apparently, for these colleagues there is an insignificantly small percentage of the Habr audience. Mea culpa.
Thus, we will not continue the cycle in the absence of a target audience of meaning (at least on this site), but, following previously undertaken obligations, we will analyze argued objections below and answer meaningful questions formulated by readers in the comments to the previous part and not answered in full there.
Ultima Consulting answers.
Greesha:
... why customer assessment does not fall under the definition of "corporate-idiotic heresy"? Are customers, by definition, more objective than their team and boss, “sucking on a finger”?
tangro:
the system generally does not involve the development of long-term relationships with the programmer and customer. Imagine a typical huge enterprise project that lasts for years. At the development stage, everything will be fine, but after a couple of years, most of the tasks (80 percent) will be related to support and bugfixing. And what are you - will in every case get to the bottom of who made this bug many years ago and write off expenses for it? Or to allocate the costs to all new programmers who had no relation to this code before, but suddenly, it turns out that they are for some reason fined on% cost_fix% /% number_developers% of money?
The author of the question swaps the cause and effect.
The system, which we have described, is focused not on looking for the guilty, but on minimizing the reasons for this: that is, mistakes. Few mistakes - few bug fixes - few problems - few expenses. An approach in management theory known as “zero defects”.
Generally, an extremely common mistake: adjusting the system so that the shoals are less painful. The approach is easy, simple, and incorrect.
That's right - to adjust the system so that the shoals occur as rarely as possible. And for this it is necessary that they were unpleasant. About how a child learns to pot. Deployed here .
“Bug, many years ago.” If the bug was made many years ago and did not bother anyone, most likely, this is a former feature. And under the error handling scheme does not fall.
Regarding the system, “not involving a long-term relationship with the customer” - most of the regular cash flow we have comes from customers with whom we work more “a couple of years”.
Archon:
Winning algorithm:
1. Overestimate the deadlines for the execution of tasks. Not much, but tangible. As soon as customers start getting used to your deadlines, we blow some more.
2. Lick customers, explaining that by no means it will not work out faster, dear ones. We associate with them well, so that the opposition between white and fluffy you and the standard IT-introvert who sends three letters for any reason can be clearly felt.
3. We do the tasks slowly, we write the code as simply and straightforwardly as possible, formally adjusting it to your standards. On performance, do not care, triketchim every written block, we support everything with crutches, if only to work.
4. For some time we live happily ever after, the prize for inflated hours drips, everyone is happy.
5. As soon as the deductions for mistakes begin to exceed a reasonable limit and the premium ceases to be enough for red caviar, we leave the company, dumping all future deductions equally on the remaining losers.
Again, this algorithm is advantageous if your developer rate plus bonus exceeds the real salary of a similar developer from competitors. If you recruit for a low salary, luring high premiums, after which the salary is leveled to the average market, then the winning algorithm - do not come to you at all.
First a couple of quotes:
“... conspiracy theories share the same compatibility issues with reality: the powers of global control ascribed to the conspirators, coupled with complete secrecy, require the conspiracy mechanism to work perfectly, which, with stated goals (control of the world), available forces (a relatively small group of people) and time actions (decades, centuries, and even millennia) are executable a little less than nothing . ”
“ A person brought up in the traditions of European rational thinking would want terribly that social processes be subordinated to some meaningful plan; let the villainous, man-hating, but still reasonable, in the sense rational. "
There is no need to look for the hidden meaning in the above quotes - it just came to mind. Khm
So, why Archon's logical scheme does not work, at least in our case: because every healthy person (that is, at least 80% of the population), other things being equal, tends to work well.
This is not a frivolous idle talk, but a scientifically established fact: this is how the human (and not only) brain works, in which, in turn, these attitudes are rooted in a billion-year evolution. In particular, therefore, shit-working people are not happy - the necessary precondition for contentment with life is satisfaction with their work and its results. And this, again, the genetic laws of the work of the brain - by an effort of will not to change them, just as a hedgehog cannot by an effort of will turn into an owl.
A healthy person starts to work badly only when he is stimulated by the system for this relatively hard and relatively long time. At the same time, about 20% of people still continue to work well (honest cop from Our Rashi).
If the system stimulates quality work, then everything is easy, good and synergistic. It is not easy just to build a similar system.
This is from the point of view of theory.
Practice confirms it (and ours, and millions of well-functioning companies around the world, and the very fact of the existence of a market economy) - and refutes the Archon's misuse (personal personal) scheme.
Then there are two questions that repeat the Archon's question in minimal variations, and the answer is basically the same:
Manitou:
If the set of parameters and the weight of each of them are known in advance, then, with such a formulation of the question, the employee will think neither about the client, but about how to optimize the ratio of effort / reward, and choose from a possible set of KPIs which it will be easier for him specifically due to some reasons, to close with minimal effort with maximum personal benefit, and it will often be found that goals are not completely closed with the results that the KPI developer expects. The remaining indicators will either be fulfilled formally or ignored altogether. As for the employee will not have any value, how much their chosen indicator is ultimately important. All that we saw when we received the KPI system was that it stimulates well to remain mediocre. Well, savvy develops among employees, it is also worth noting.
dhj:
As soon as I stop thinking about money, I write good code.
If programming, I will think about bonuses / malusov - then what for.
A formal, automatic bonus process will only move the “break the system”, write a straightforward, not elegant code.
This is like Khrushchev / brezhnevka - it seems you can live, but there is no elegance in such houses.
Plus, whenever possible, look for those guilty in colleagues. But what about the collective responsibility for the product? Or, as in the old monologue - “do you have any complaints about the buttons?”, But for the rest - all the same?
Additionally for dhj beyond the universal answer to Archon.
Again the cart before the horse.
A good system is so good that if you do a good job (write good code), you don’t need to think about money, because you will automatically get good money for good work.
And once again we will make a reservation - we do not consider our own work scheme at all ideal. But it is, at the moment, the best of the systems that we, with our modest forces, were able to invent and implement. At the same time, the work on improvement is endless, beyond any doubt (“kaizen”).
Yes, about the “collective responsibility” for the product. There are doubts that the author of the question correctly understands the meaning of this term . “Collective responsibility” is when all Jews are burned for the crime of one Jew. For escaping from the battlefield of one soldier, a platoon is shot. For the joint of one programmer, everyone is fined \ dismissed. A team building gurgle like “we are a team and together are responsible for everything” is collective irresponsibility. “Take every nail from the factory, you are the owner, not the guest.”
craft_brother
Especially, IMHO.
What you measure is what you get.
I always thought that software is a product of teamwork. And in teamwork, the overall result is important, not how many kilometers the forward ran, how many legs the defender broke to the opponent and how many times the goalkeeper jumped after the ball. All this does not matter if the team lost.
Introducing individual KPIs you still stir up competition and kill team synergy.
The author of the question, perhaps - by chance, raised a very interesting question - the right balance between local optima (how many legs the opponent broke) and the final result (won or not). In detail in the popular presentation of this is considered in the works of Goldratt.
The correct balance is the unequivocal priority of the final result. In our case, it is profit. Autocount:
The SMM is structured 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 .
In other words, we take the desired final result (team win) and decompose it into requirements for the actions of specific players. And not vice versa.
Incidentally, it is precisely the “opposite” that is historically characteristic of the Western managerial tradition - this is the reason for the popularity of the local, in general, the very obvious theses of Goldratt, with which he turns logic from head to foot.
Regarding the “incitement of competition” by individual KPIs - well, what is actually bad about the competition between employees, for example, the quality of work? This is not a zero-sum game, winning one does not mean losing the rest.
Even in the dense Soviet Union, they tried to deploy such competition - “socialist competition” and “passing red flag”.
Joshua
I think there are four problems:
1. There is a collective responsibility with bugs. Should reduce motivation.
2. There is a personal responsibility with bugs. All my experience tells me that productivity drops at times. It's like walking on a log on the ground and raised to a height of 100 meters. As soon as responsibility for the error increases, the speed RADICALLY decreases. At the same time, the frequency of errors and the cost of correcting them are not so significant.
Those. code with bug fixes can be written much cheaper if you don’t penalize developers for bugs. And a way to lower the cost of a bug = automatic tests + code + pair programming + Test developers + those testers.
3. No one pays "Technical debt", i.e. will not refactor. Formal CodeStyle rules will be executed but the code will deteriorate.
4. If there is an attempt to make a fair cost of payment, depending on the company's benefits, then why Grades? If I am a junior programmer and do this task as well as a senior programmer, I should receive as much.
“... our solutions to sick issues and the technologies used are by no means positioned as the best. On the contrary, with the intention to tell colleagues in the dangerous business about our own developments, we expect to receive constructive criticism and counter ideas in the comments that did not come to our heads . ”
The main part of our readers, in our opinion, perceived the contents of the articles either as an advertisement of the company in the programmer’s vacancies section, or as an opportunity to realize long-time resentment of invaluable talents on ugly stupid bosses.
')
That is, there was no dialogue with the actual “colleagues in the dangerous business” (in the sense of businessmen in the production / implementation of similar software). Apparently, for these colleagues there is an insignificantly small percentage of the Habr audience. Mea culpa.
Thus, we will not continue the cycle in the absence of a target audience of meaning (at least on this site), but, following previously undertaken obligations, we will analyze argued objections below and answer meaningful questions formulated by readers in the comments to the previous part and not answered in full there.
Ultima Consulting answers.
Greesha:
... why customer assessment does not fall under the definition of "corporate-idiotic heresy"? Are customers, by definition, more objective than their team and boss, “sucking on a finger”?
- Customer evaluation is undoubtedly largely subjective. However, the absolute objectivity of the money that he pays for our services and, consequently, the salary of the programmer.
The more satisfied the customer, the more he pays money (slightly simplifying, and other things being equal). And, recalling Matsushitu, “profit is a measure of the company's utility to society.” - When, again, other things being equal - the customer's assessment is less subjective than the assessment of the boss. Because the customer has an objective need that needs to be satisfied (task to solution). The boss does not.
We can say that the boss needs more money, but then see item 1
It is also relevant to recall Jack Welch: “A hierarchically organized company is turned to face the boss and its back to the consumer.” - If the “other things being equal” principle from the previous paragraph is violated (suppose the customer’s responsible employee is evil, and he puts bad marks on everyone out of hate) the automatic stop will work - our developers simply will not take on his tasks. Who wants to lose money in vain?
Naturally, a problem arises, escalated to the top of both the customer and us, which is resolved in an administrative-personnel manner.
It is resolved because both sides of the theoretical conflict are motivated for a constructive agreement - we need money, the customer needs a solution to the problems.
What if evil customer is the most important person? Extremely unlikely . Plus, the objective motivation for a constructive resolution does not go anywhere in this case either.
tangro:
the system generally does not involve the development of long-term relationships with the programmer and customer. Imagine a typical huge enterprise project that lasts for years. At the development stage, everything will be fine, but after a couple of years, most of the tasks (80 percent) will be related to support and bugfixing. And what are you - will in every case get to the bottom of who made this bug many years ago and write off expenses for it? Or to allocate the costs to all new programmers who had no relation to this code before, but suddenly, it turns out that they are for some reason fined on% cost_fix% /% number_developers% of money?
The author of the question swaps the cause and effect.
The system, which we have described, is focused not on looking for the guilty, but on minimizing the reasons for this: that is, mistakes. Few mistakes - few bug fixes - few problems - few expenses. An approach in management theory known as “zero defects”.
Generally, an extremely common mistake: adjusting the system so that the shoals are less painful. The approach is easy, simple, and incorrect.
That's right - to adjust the system so that the shoals occur as rarely as possible. And for this it is necessary that they were unpleasant. About how a child learns to pot. Deployed here .
“Bug, many years ago.” If the bug was made many years ago and did not bother anyone, most likely, this is a former feature. And under the error handling scheme does not fall.
Regarding the system, “not involving a long-term relationship with the customer” - most of the regular cash flow we have comes from customers with whom we work more “a couple of years”.
Archon:
Winning algorithm:
1. Overestimate the deadlines for the execution of tasks. Not much, but tangible. As soon as customers start getting used to your deadlines, we blow some more.
2. Lick customers, explaining that by no means it will not work out faster, dear ones. We associate with them well, so that the opposition between white and fluffy you and the standard IT-introvert who sends three letters for any reason can be clearly felt.
3. We do the tasks slowly, we write the code as simply and straightforwardly as possible, formally adjusting it to your standards. On performance, do not care, triketchim every written block, we support everything with crutches, if only to work.
4. For some time we live happily ever after, the prize for inflated hours drips, everyone is happy.
5. As soon as the deductions for mistakes begin to exceed a reasonable limit and the premium ceases to be enough for red caviar, we leave the company, dumping all future deductions equally on the remaining losers.
Again, this algorithm is advantageous if your developer rate plus bonus exceeds the real salary of a similar developer from competitors. If you recruit for a low salary, luring high premiums, after which the salary is leveled to the average market, then the winning algorithm - do not come to you at all.
First a couple of quotes:
“... conspiracy theories share the same compatibility issues with reality: the powers of global control ascribed to the conspirators, coupled with complete secrecy, require the conspiracy mechanism to work perfectly, which, with stated goals (control of the world), available forces (a relatively small group of people) and time actions (decades, centuries, and even millennia) are executable a little less than nothing . ”
“ A person brought up in the traditions of European rational thinking would want terribly that social processes be subordinated to some meaningful plan; let the villainous, man-hating, but still reasonable, in the sense rational. "
There is no need to look for the hidden meaning in the above quotes - it just came to mind. Khm
So, why Archon's logical scheme does not work, at least in our case: because every healthy person (that is, at least 80% of the population), other things being equal, tends to work well.
This is not a frivolous idle talk, but a scientifically established fact: this is how the human (and not only) brain works, in which, in turn, these attitudes are rooted in a billion-year evolution. In particular, therefore, shit-working people are not happy - the necessary precondition for contentment with life is satisfaction with their work and its results. And this, again, the genetic laws of the work of the brain - by an effort of will not to change them, just as a hedgehog cannot by an effort of will turn into an owl.
A healthy person starts to work badly only when he is stimulated by the system for this relatively hard and relatively long time. At the same time, about 20% of people still continue to work well (honest cop from Our Rashi).
If the system stimulates quality work, then everything is easy, good and synergistic. It is not easy just to build a similar system.
This is from the point of view of theory.
Practice confirms it (and ours, and millions of well-functioning companies around the world, and the very fact of the existence of a market economy) - and refutes the Archon's misuse (personal personal) scheme.
Then there are two questions that repeat the Archon's question in minimal variations, and the answer is basically the same:
Manitou:
If the set of parameters and the weight of each of them are known in advance, then, with such a formulation of the question, the employee will think neither about the client, but about how to optimize the ratio of effort / reward, and choose from a possible set of KPIs which it will be easier for him specifically due to some reasons, to close with minimal effort with maximum personal benefit, and it will often be found that goals are not completely closed with the results that the KPI developer expects. The remaining indicators will either be fulfilled formally or ignored altogether. As for the employee will not have any value, how much their chosen indicator is ultimately important. All that we saw when we received the KPI system was that it stimulates well to remain mediocre. Well, savvy develops among employees, it is also worth noting.
dhj:
As soon as I stop thinking about money, I write good code.
If programming, I will think about bonuses / malusov - then what for.
A formal, automatic bonus process will only move the “break the system”, write a straightforward, not elegant code.
This is like Khrushchev / brezhnevka - it seems you can live, but there is no elegance in such houses.
Plus, whenever possible, look for those guilty in colleagues. But what about the collective responsibility for the product? Or, as in the old monologue - “do you have any complaints about the buttons?”, But for the rest - all the same?
Additionally for dhj beyond the universal answer to Archon.
Again the cart before the horse.
A good system is so good that if you do a good job (write good code), you don’t need to think about money, because you will automatically get good money for good work.
And once again we will make a reservation - we do not consider our own work scheme at all ideal. But it is, at the moment, the best of the systems that we, with our modest forces, were able to invent and implement. At the same time, the work on improvement is endless, beyond any doubt (“kaizen”).
Yes, about the “collective responsibility” for the product. There are doubts that the author of the question correctly understands the meaning of this term . “Collective responsibility” is when all Jews are burned for the crime of one Jew. For escaping from the battlefield of one soldier, a platoon is shot. For the joint of one programmer, everyone is fined \ dismissed. A team building gurgle like “we are a team and together are responsible for everything” is collective irresponsibility. “Take every nail from the factory, you are the owner, not the guest.”
craft_brother
Especially, IMHO.
What you measure is what you get.
I always thought that software is a product of teamwork. And in teamwork, the overall result is important, not how many kilometers the forward ran, how many legs the defender broke to the opponent and how many times the goalkeeper jumped after the ball. All this does not matter if the team lost.
Introducing individual KPIs you still stir up competition and kill team synergy.
The author of the question, perhaps - by chance, raised a very interesting question - the right balance between local optima (how many legs the opponent broke) and the final result (won or not). In detail in the popular presentation of this is considered in the works of Goldratt.
The correct balance is the unequivocal priority of the final result. In our case, it is profit. Autocount:
The SMM is structured 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 .
In other words, we take the desired final result (team win) and decompose it into requirements for the actions of specific players. And not vice versa.
Incidentally, it is precisely the “opposite” that is historically characteristic of the Western managerial tradition - this is the reason for the popularity of the local, in general, the very obvious theses of Goldratt, with which he turns logic from head to foot.
Regarding the “incitement of competition” by individual KPIs - well, what is actually bad about the competition between employees, for example, the quality of work? This is not a zero-sum game, winning one does not mean losing the rest.
Even in the dense Soviet Union, they tried to deploy such competition - “socialist competition” and “passing red flag”.
Joshua
I think there are four problems:
1. There is a collective responsibility with bugs. Should reduce motivation.
2. There is a personal responsibility with bugs. All my experience tells me that productivity drops at times. It's like walking on a log on the ground and raised to a height of 100 meters. As soon as responsibility for the error increases, the speed RADICALLY decreases. At the same time, the frequency of errors and the cost of correcting them are not so significant.
Those. code with bug fixes can be written much cheaper if you don’t penalize developers for bugs. And a way to lower the cost of a bug = automatic tests + code + pair programming + Test developers + those testers.
3. No one pays "Technical debt", i.e. will not refactor. Formal CodeStyle rules will be executed but the code will deteriorate.
4. If there is an attempt to make a fair cost of payment, depending on the company's benefits, then why Grades? If I am a junior programmer and do this task as well as a senior programmer, I should receive as much.
- “Collective responsibility” with bugs applies only when it is not possible to identify the author of the bug. Perhaps (and certainly) this practice reduces motivation - which is bad.
However, the absence of such responsibility (it did not immediately appear) - affects the final results even worse. Fortunately, we have something to compare.
Actually, a complete analogy with collective material liability in a warehouse is easy to imagine what will happen to the safety of inventories without such responsibility. The author of the answer, in fact, is not necessary to submit - it is known from practice. - Instead of it is necessary to lift a log on 100 meters. One meter, most likely, is quite enough. And in general (to question 1), it is not the severity of the punishment that is important, but its inevitability.
The optimal value of the height of the log is selected from the analysis of statistics and accurate (!), Preferably in a sandbox, experimentation.
“ And a way to lower the cost of a bug = automatic tests + code + pair programming + Test developers + those testers ” - here, with all due respect, I want to dodge. You write in the logic characteristic of the internal development teams of non-specialized organizations sitting on a virtually unlimited budget and unlimited deadlines.
Otherwise, it is difficult to understand the logic in which you reduce the cost of a bug through a multiple (!) Increase in the regular cost of the workflow. Moreover, as already mentioned in the first part (“why we do not have testers”), these costs are mostly worthwhile.
Moreover, in the long run, in the absence of personal developer motivation, they lead to the opposite effect - the quality of the code decreases monotonically. - Due to the fact that the task execution time is not limited by anything, there is no reasonable conscientiousness and the consent of the customer to pay for it, there are no systemic obstacles to refactoring. At least we do not see them. In contrast, better code contains fewer errors and, thus, increases revenue. This is on the one hand.
On the other - see above answer Archon'u. - About fair pay and grades.
You know, “justice” is a very bad word, only suitable for duping losers (such as “society / state of social justice” etc) by demagogues of all stripes.
It was under the slogan of justice that the most disgusting and mass atrocities in human history were committed (and the history of our country is the clearest of examples).
So, for example, comrades from ISIL consider that it would be extremely fair to cut out all the readers of this blog. But Lenin believed that the bourgeois is more fair to cut. But Stalin believed that the fair state of the world - when "the last Paraguayan socialist republic will be part of the USSR." And George W. Bush believed that Saddam was fair to hang, because he repeatedly tried to make an attempt on his father's life.
And Comrade Kadyrov believes that the Russians are dumb drunken rednecks, whose fair fate is to collect and send money for the carefree prosperity of true warriors. And comrade Putin as a whole agrees with comrade Kadyrov, plus iron (!) Knows that the Russians don’t know how to work and don’t want to, and the only thing they can live through is distributing the oil freebies to a good king. And the fact that terrible geopolitical enemies, corrupted geo-Europeans pay 100% of this oil freebie, is also more than fair, and the picture of the world does not violate.
Translated into Russian, “rightly” means “I personally like it.” No more.
We prefer the term "efficiency."
Grade scheme is quite reasonable. As already mentioned, customers pay less money for “junior programmers”. And not just like that - a more competent and experienced programmer will do the task in less hours with at least a not lower quality level.
It makes sense to discuss the quality of the parameter settings in the grade scheme - about the height of the log. But this goes beyond, as they say.
Source: https://habr.com/ru/post/258171/
All Articles