In pursuit of the best
I do not know about you, but I like to experiment with people. Usually I don’t ask people's opinions, but this time the experiment was carried out at their own request. People wanted me to make them a new system of motivation. Well, I did.
The article is somewhat long, because I tried to explain not only the input and output, but also the process of developing the system, the issues that arise along the way and how we solved them. Perhaps our experience will be useful to you - if not entirely, then some of it.
So, at the entrance - a small team of 1C programmers of three people working on fix. Plus, I, their leader, on key competence, is also a 1C programmer.
The business process is the most common:
1. Programmers are assigned tasks from any departments;
2. Tasks are negotiated, if required. The list of coordinators is different for different tasks;
3. Tasks have a time limit, it is possible to transfer it (no more than two times). Prior to the start of the deadline agreed upon by both parties;
4. There are automation projects executed on a cascade basis. Tasks in the project live the same life as the others - there are deadlines, there is agreement, etc .;
5. There is technical support in the form of duty - programmers take turns sitting on it for 1 week.
Motivation system :
1. Programmers have a salary, depending on their qualifications;
2. There is demotivation for unfulfilled tasks;
3. There are awards for the implementation of projects.
Automation of all this good - the most common. For setting tasks, a common enterprise system is used, like 1C: Document circulation. It has assignments and office notes in which tasks live. There is a small automation of cascade project management. There is an automatic calculation of demotivation in violation of the terms.
It seems to be - live and rejoice, work - do not beat lying. Deadlines are not difficult if you participate in their production. Work - without too much difficulty, nothing supernatural. I, as a manager, do not stand out among the others - in the other services, the management of tasks, deadlines and projects is conducted according to the same principles.
But we were not bothered by one question - how to make more money?
The current system had two levers - to seek an increase in salary or project bonuses . Companies usually do not like to increase the salary of a 1C programmer, since hardly understand why this guy needs to pay more money .
For advanced training, or some kind of categorization, such as grades? It is not particularly clear why you need to pay more for this if the qualification does not affect the results. And if the programmers have different results, is this due to formal qualifications? How much to increase the salary, if you still go this way? Current salaries were approximately equal to the average for the market.
A couple of times to increase the salary of programmers still happened. For example, one was driven through certification by the forces of attracted French specialists. They increased it to another, because it was good in the market, it was worth more (according to a subjective assessment). But this path can not be repeated often, so as not to hear "yes you are there at the end ohreneli, or what?".
It is also impossible to work hard on increasing project premiums, since The topic is rather slippery. Whatever one may say, the premium for the project is an extra payment for the work for which it has already been paid . Of course, it is possible to paraphrase it somehow, for example, a surcharge for premature implementation, or for active participation in implementation, or for quickly bringing automation to customer requirements.
But sooner or later the manager starts asking the question - if a person does projects all the time ahead of time, why should I pay extra for it? Maybe the term is incorrectly calculated?
After thinking about it, the programmers and I decided to make ourselves a system of motivation and change our work so as to obviously bring more benefits to the company. Assuming that for the greater benefit we will get a lot of money.
About the benefits for the company to properly talk with the company itself, which I did. I talked with managers, director, owner. Opinions were different, but if we grouped and ranked them, the central thought was this: we want what you are already doing, only faster . Or in a different way: we want to get more for the same time.
Obviously, talking aboutprogramming speed and implementation . It should be noted that at that time we did not know anything about the Scram as a method accelerating the work of programmers.
For me, as a manager, such a moment was very important: I wanted the programmers to take care of their results themselves . I did not want to kick them, stand above the soul, control the process and timing. I needed an autonomous system that can do without me, and without a manager at all.
The closest payment system suitable for our purposes seemed to be piecework payment for work performed. It sounded promising and easy to prove: here is a man, here is a job done, here is an income. It is not necessary to motivate - if a person does not want to work, he will not earn, and this will become obvious. With such a person it will be possible to part without remorse.
There was a key question - how to evaluate the work and how much to pay for them ? In French, this question is solved more simply - there is an estimate of the labor intensity in hours, for which the client pays. The programmer, in fact, receives a percentage of the hourly rate. We did not have clients and monetary relations, but we need to somehow evaluate the work.
The idea came quickly, as well as its implementation and evidence base. I decided to evaluate the tasks in the hours of the best programmer .
If the best programmer solves the problem in 1 hour, then it costs 1 hour. Another programmer who solves this problem in 4 hours will receive 1 paid hour for it.
In order to evaluate tasks “by the best programmer”, you need to understand who this is. We decided this: the best programmer has all the necessary knowledge about how to solve the problem . He knows the methodical area, knows the necessary mechanisms of the platform, knows the metadata and "where what lies." In general, he sits down and does it without wasting time.
The key objective of this assessment is to strive to minimize the loss of time, making them unprofitable. Losses in the programmer’s work are weight, and in terms of volume, losses often exceed half the working time.
I personally did the assessment “for the best”, and this is perhaps the bottleneck of the whole system. It was immediately clear that it was necessary to make an assessment system, if not transparent, then verified retrospectively. Therefore, I decided to make a job evaluation classifier — an uncomplicated guide containing standard components for solving the problem and their evaluation. It was filled gradually, we called the assessment of the work “precedent” - the items tested in practice with measured execution time fell into the classifier.
The classifier contained, for example, the following items:
Execution time included development and testing by the developer. If there was an error in the working base due to the changes created in this task, then the errors were corrected by the executor at his own expense.
Each task that programmers performed was given such an assessment prior to execution. It is clear that some of the tasks contained several items of the classifier - for example, a register, plus several details, plus a report, plus an autotask. Time in this case was summed up.
Now it was necessary to determine how much to pay per hour of work of the best programmer . This question we decided on the forehead. The average good programmer then got on the market 60 thousand rubles. We decided that the best programmer should receive 100 tr. It is clear that later this figure can be changed in any direction.
Simple calculations and rounding gave us the hourly rate of the best programmer: 600 rubles per hour .
The figure is quite good, because it is half the hourly rate of local francs, and lower than the cost of freelancers, who then asked for 700-900 rubles per hour.
But the main thing - only direct work was part of our hourly rate . There was no thinking, modeling, decision analysis, etc.
However, knowing that the conversation about this bid with the management will take place anyway, we decided to make sure that we were right. To do this, talked with friends and strangers franchami and freelancers. We gave these guys a few tasks to assess, and asked a simple question - how much will you take the money for such work? The result was predictable - the guys asked for work 2-3 + times more than we (including taxes on salary). At this calmed down - ass covered.
Now it was necessary to balance the system by the amount of monthly accruals in order to avoid errors in both directions. The first side is the programmers. You never know, suddenly it turns out that the programmer has earned 10 tr. - he will have nothing to feed his family with. The solution is simple, I saw it when I was working in France - to set the minimum monthly payment, less than which the programmer will not receive. Without thinking twice, they decided that this would be the current salary.
The second side is the company. Just the irreducible payment is unprofitable, because With its help, you can deceive the system. For example, to complete 20 tasks a month before the state of “almost ready”, to receive a salary, and to make a breakthrough next month, close 20 unfinished tasks and another 30 new ones, and get a deal. By the way, it was in the same way in France, and everyone used it.
The way out is also simple - “memorize a minus” . Made work on 40 tr., Received a salary of 60 tr. - ok, remember the "minus" 20 tr. Next month you should. Do in the next month of work on 80 tr. - you will receive 60 TR, and you should not.
At the same time, just in case, the payment ceiling was set - 100 tr. Agree that work performed in excess of this amount will be reckoned next month as a “plus”.
Now it was necessary to figure out how to deal with projects. The project, if simplified - is a set of tasks related to each other in some sense or purpose. But companies are interested in not only accelerated implementation of each of these tasks, but also the fastest possible accomplishment of the entire list of project tasks and the achievement of results.
The output is also simple, and again spied on by others - a part of the piecework wage to accumulate and issue at the end of the project . We decided that it would be 20%. While the project is underway, the programmer receives 480 rubles per hour, and receives the remaining 120 rubles from each hour at the end of the project.
Well, everything seemed to be thought out and thought out, it is necessary to begin the test operation.
First of all, it was necessary to change the business process of the work of programmers:
1. Tasks should now be set not personally by the performer, but by me, the manager;
2. I now have to evaluate each task in hours;
3. After acceptance and evaluation, the task becomes available for execution.
Ok, the business process has changed, you need to automate . In order to have more creative freedom, we stopped using assignments and service notes (everyone used them), and in 1-2 days we made two new objects for ourselves:
1. Application to the IT department, with all the necessary fields for our assessment;
2. Simplified system of accounting projects and tasks in them, with the same evaluation system.
And they immediately made a report that showed the output in hours and the money earned, so that programmers could see their results every day.
We started to work, and immediately faced with the complexity - programmers began to whine that the task estimates are too low . “I need to think out”, “and I have never come across processing, I need to understand”, “I once did an auto task, do I have instructions to read?”, Etc.
I listened to them, and began to reflect on the philosophical depth of the question: should the company pay for its employees to get knowledge?
It seems the answer is obvious - should. But is it all so obvious? What happens?
One of the programmers has the task to complete the subconto Warehouse in the posting on account 003 (for some reason, it is not filled in a typical SCP). And he doesn't know how to recycle, either on the side of the supplier or on the side of the processor.
Like - sit down and figure out what this and that, they always did. In the traditional salary system, the employer will pay you for the time while you pick around there.
But it's not that simple. Of the four people (three programmers + I, the manager) two are well versed in processing, and the task went to someone who does not understand. When did we understand recycling? The programmer is at the last job, I am at the current place, because previously was not in the practice of davaltsev / processors. It turns out that the current company has already paid for obtaining this competence.. And it seems like paying a second time, at least in the same amount, is wrong. What needs to be done now? That's right, to transfer the competence to the one who received the task.
There was another question - and what for it needs a carrier of competence? He also has piecework wages, and instead of transferring knowledge, he will do a better job.
I began to reflect on an even more philosophical question: should the company pay for the transfer of competence between employees? Traditionally it is believed that the transfer of knowledge is a matter of course. But we all know that the quality of such a transmission leaves much to be desired. The exception is adaptation and mentoring programs, but they are not very common.
So, the decision became obvious to us:
1. For the transfer of knowledge and help each other have to pay;
2. For obtaining new competencies you have to pay.
The second point is about knowledge that none of the team possesses. For example, we had a task to constantly drag in 1C data from an external system by direct requests to MS SQL. The task is simple, but no one has done this before. I did this - I made out an application on my own behalf, the essence of which was to smoke work with external data sources at a level sufficient for solving a specific task. Task assessment - 1 hour (and you can sit at least a whole day).
As a result of solving the problem, we get a specialist who can solve problems with external data sources, and we will not pay more for this competency . Only for its transfer to other programmers.
We decided to pay for the transfer of competencies and mutual assistance, and for this we came up with the appropriate term - the costs of analysis and design. In order not to waste time on a big bureaucracy, we drew a table in the Word containing the data:
1. A question that was discussed / projected / transmitted;
2. The time of the beginning and end of the discussion, up to minutes;
3. Participants.
A separate document was added to the accounting system, and the results of such discussions were added once a week. Usually discussions were stacked in 5 minutes , occasionally reaching 15 minutes. For a week it worked at all 3-5 hours .
What is important: the time of discussions was paid to all of its participants.i.e. It was beneficial to both acquire and transfer knowledge. It was beneficial to assist colleagues, because human laws have not gone away - if you help, then they will help you, and if you keep knowledge with yourself, then be ready, faced with an unfamiliar task with an estimate of 1 hour, sit with it for 2 days. Of course, there were exceptions when I myself deleted from the list of participants who sat and considered the raven.
Yes, all such meetings should have been held in my presence, because to the outside world I was responsible for the quality of the system. All the issues discussed were reflected in the system, and if necessary it was possible to go back and see if the money was legally spent.
There was one more "nasty" question - tech support. Unclean - because I do not like the presence of technical support, it dulls the mind of users, takes up valuable time of specialists, without bringing special benefits to the company.
Formally, tech support from us then is a dedicated duty officer who should help people during the week. How much to pay a programmer who is on tech support?
At first there was a thought not to pay at all, but to reduce the base for calculating the salary when calculating the payment. For example, if a programmer has a salary of 60 tr, stayed 2 weeks in a month for technical support, then, when calculating, take half as a salary - 30 tr, and for the rest of the time, consider a transaction.
But it is immediately clear that some kind of nonsense is obtained - the company is not very large, and objectively technical support does not take a whole day. Accordingly, the programmer manages to solve problems and can use the scheme with a “jerk”.
There is a way out that is much easier - to calculate how much time a day is spent on technical support from the best employee , and to pay these days to the programmer in the same amount. Because I was considered the best in this gang, I measured it myself. Just sat for a few days on the support with a stopwatch and the goal - not to smear snot, but quickly to help people. Correctly redirect their questions to the tasks. Provide links to instructions if the person has not read them and requires online training that everyone knows about. Well, etc.
According to the measurement results, it turned out thatTech support takes an average of 2 hours per day . Well, that’s the number. We agreed that it would be paid by the duty officer at that rate - 2 hours per day, or 10 hours per week.
It is clear that it is unprofitable to engage only in technical support - it is about 25 thousand rubles a month.
So that the duty officer would not be bored, we gave him a piece of paper and made him write down all those who address him - just his last name. In the accounting system, a document was created in which the attendant on the end of the day contributed all the "converts". Why - see at the end of the article, under the heading "Pleasant bonus".
Actually, on this picture has developed, and we continued the test operation of the system .
There was unprecedented enthusiasm among programmers.. They grabbed at the task, the smoke was a pillar in the performance.
A programmer began to work in silence, who used to like to discuss “what a difficult task, there are so many pitfalls”, he could spend hours sucking on these pitfalls, charging himself a price (it is not clear, however, why the salary is the same).
Immediately, the programmer, who used to like to sit for hours and “think over the optimal solution,” began to issue optimal solutions, because now the optimal solution was issued by a team brainstorming session in 5 minutes.
At times, the introvert programmer, who could sit for two days over an already solved task, was often more likely to communicate with customers, because he was embarrassed to talk to the customer.
A lot more intelligent, high-quality tasks from users began to appear, because programmers began to help with their design.
The novice programmer stopped sitting for hours and stupid, who used to be embarrassed to ask his colleagues a question, because “it’s inconvenient to distract, they will be annoyed” (I must say, they used to be really annoyed before).
Programmers have become gambling and greedy , in the good sense of the word. I, as a manager, achieved my goal - the system began to work, though not entirely without me, then with my minimum participation.
My participation has become transparent and understandable, these are just points in the business process:
1. Acceptance and evaluation of tasks, I did it once a day, for about 15 minutes;
2. Participation in meetings on analysis and design (this is ~ 3 times a day for 5 minutes).
Total for managing three programmers - 30-60 minutes per day. No one needs to kick, follow the execution and deadlines, motivate, check the quality - everything was done by itself . I could look at the results at any time through the system. It is impossible to say that complete self-government came out, but we were as close as possible to him.
We conducted test operation for 3 months. During this time, the output in hours has doubled , and the salary calculated for the new motivation - by 30%. The difference is clear - now I had to work out the salary . According to the programmers themselves, they have never had to work so intensively before. It was intensive, not long or long - I was always against a more than 8-hour working day.
But here it is important to not thatthey talked about the intensity of the work, and how they said it. They spoke with pride in themselves . Not only because the new system made their work more efficient, but also because they themselves were the authors of this system. They themselves made themselves more efficient, they themselves made their work transparent and measurable, they themselves began to look differently at the company, its managers and employees.
I explain success as follows:
1. If you look through the prism of theses on the development of motivation systems, it becomes clear that we have defined the product well. The product is a solved problem. Clear money is paid for this product. Everything else - at their own expense (reflections, the Internet, chatting on messengers, smoke breaks, whining, depression, etc.).
2. If you look at the development process through self-management, you can see that the system was created with the direct participation of the people who work in it.
3. We made the system as measurable as we could - according to the requirements of controlling. The mere measurement of the work done made people move faster and not engage in nonsense.
After the test operation, I went through several iterations to protect the new system: HR director, financial director, director, owner, external HR consultant (Moscow, very well known). Everyone liked the system.
I, as the head of its development, was especially interested in the opinion of the HR consultant, since He knows world practice well and has completed hundreds of projects on the development of motivation systems. His assessment of my system turned out to be very high, especially he liked the contours of protection (“remember minus” and the maximum payout limit).
Subsequently, the principles of this system became the basis for other systems of enterprise motivation.
A nice bonus.
So, we had an estimate in rubles for all works, including analysis, design and technical support. Sin was not to take advantage of this opportunity, and not to make the calculation of the cost of automation in the context of customers and projects . After all, we now knew for sure how much money a company devours through automation, and if you look at this datain the context of utility , we get just a gorgeous picture.
For example, we learned that the technical support of the Deputy Chief Accountant, who, according to the job description, should know SCP best of all in the accounting department, leaves more money than this person receives in the form of a salary.
We also learned that people who always whine “do not deal with us” consume 40% of all money for automation.
It was interesting to look at the growing budget from month to month of projects that did not have a host (this is when the director, for example, says - automate this service, and the automation service has not rested anywhere, but they have to write the tasks themselves, so they go in circles) .
The apotheosis was a report at a strategic session with a disappointing outcome -more than half the money the company spends on meaningless automation . Meaninglessness is quite a meaningful description. For example, the functionality is developed, there are no comments, but it is not used (“yes, somehow all hands do not reach”). Or the functionality that is designed to help improve the management process, through a change in the value of the indicator - and the value of the indicator either stands still or worsens (and at the beginning of the project it was said - this will not help you, guys, you have another problem).
What is the result? We have become more and more attentive to listen, especially before the start of work. Because now we were able to predict the results of projects, relying not only on systems thinking, but also on statistics in numbers. The volume of meaningless work in the first months decreased to 30%, while the structure of “meaninglessness” has improved. But that's another story.
There are people who repeated my experience - well, that is, they also built a system of management and motivation on the basis of certain normal hours. They say they are fine. Although, who is recognized ...
I do not know about you, but I am stupid. The experience described in the article happened about 4 years ago, if I remember correctly. Then I found out about scrum - or rather, I bought a book at a sale - and I got carried away, and abandoned everything old. Because stupid.
You always want not to think, but to take ready. Scrum, PMBOOK, CORE PM, Kanban, TOC or something else, “implement” or, to put it more modernly, “implement”. And some assholes, like the developers of the scrum guide, also heat up the situation, saying something like “if you’re not doing it by the manual, then you’re not scared.” Although in the book they themselves wrote that they should think with their heads.
The experience described in the article is invaluable. For me, of course. If only because he showed the importance of evaluating tasks in some more or less stable units. Then, on the scrum, it turned into points. More experience has shown that doing the right motivation system with people. He also showed that with the right system of management and motivation, people do not need a leader. And a lot of things showed.
How are you? Helpful? Or beee, I do not work, it's about 1snikov.
The article is somewhat long, because I tried to explain not only the input and output, but also the process of developing the system, the issues that arise along the way and how we solved them. Perhaps our experience will be useful to you - if not entirely, then some of it.
So, at the entrance - a small team of 1C programmers of three people working on fix. Plus, I, their leader, on key competence, is also a 1C programmer.
The business process is the most common:
1. Programmers are assigned tasks from any departments;
2. Tasks are negotiated, if required. The list of coordinators is different for different tasks;
3. Tasks have a time limit, it is possible to transfer it (no more than two times). Prior to the start of the deadline agreed upon by both parties;
4. There are automation projects executed on a cascade basis. Tasks in the project live the same life as the others - there are deadlines, there is agreement, etc .;
5. There is technical support in the form of duty - programmers take turns sitting on it for 1 week.
Motivation system :
1. Programmers have a salary, depending on their qualifications;
2. There is demotivation for unfulfilled tasks;
3. There are awards for the implementation of projects.
Automation of all this good - the most common. For setting tasks, a common enterprise system is used, like 1C: Document circulation. It has assignments and office notes in which tasks live. There is a small automation of cascade project management. There is an automatic calculation of demotivation in violation of the terms.
It seems to be - live and rejoice, work - do not beat lying. Deadlines are not difficult if you participate in their production. Work - without too much difficulty, nothing supernatural. I, as a manager, do not stand out among the others - in the other services, the management of tasks, deadlines and projects is conducted according to the same principles.
But we were not bothered by one question - how to make more money?
The current system had two levers - to seek an increase in salary or project bonuses . Companies usually do not like to increase the salary of a 1C programmer, since hardly understand why this guy needs to pay more money .
For advanced training, or some kind of categorization, such as grades? It is not particularly clear why you need to pay more for this if the qualification does not affect the results. And if the programmers have different results, is this due to formal qualifications? How much to increase the salary, if you still go this way? Current salaries were approximately equal to the average for the market.
A couple of times to increase the salary of programmers still happened. For example, one was driven through certification by the forces of attracted French specialists. They increased it to another, because it was good in the market, it was worth more (according to a subjective assessment). But this path can not be repeated often, so as not to hear "yes you are there at the end ohreneli, or what?".
It is also impossible to work hard on increasing project premiums, since The topic is rather slippery. Whatever one may say, the premium for the project is an extra payment for the work for which it has already been paid . Of course, it is possible to paraphrase it somehow, for example, a surcharge for premature implementation, or for active participation in implementation, or for quickly bringing automation to customer requirements.
But sooner or later the manager starts asking the question - if a person does projects all the time ahead of time, why should I pay extra for it? Maybe the term is incorrectly calculated?
After thinking about it, the programmers and I decided to make ourselves a system of motivation and change our work so as to obviously bring more benefits to the company. Assuming that for the greater benefit we will get a lot of money.
About the benefits for the company to properly talk with the company itself, which I did. I talked with managers, director, owner. Opinions were different, but if we grouped and ranked them, the central thought was this: we want what you are already doing, only faster . Or in a different way: we want to get more for the same time.
Obviously, talking aboutprogramming speed and implementation . It should be noted that at that time we did not know anything about the Scram as a method accelerating the work of programmers.
For me, as a manager, such a moment was very important: I wanted the programmers to take care of their results themselves . I did not want to kick them, stand above the soul, control the process and timing. I needed an autonomous system that can do without me, and without a manager at all.
The closest payment system suitable for our purposes seemed to be piecework payment for work performed. It sounded promising and easy to prove: here is a man, here is a job done, here is an income. It is not necessary to motivate - if a person does not want to work, he will not earn, and this will become obvious. With such a person it will be possible to part without remorse.
There was a key question - how to evaluate the work and how much to pay for them ? In French, this question is solved more simply - there is an estimate of the labor intensity in hours, for which the client pays. The programmer, in fact, receives a percentage of the hourly rate. We did not have clients and monetary relations, but we need to somehow evaluate the work.
The idea came quickly, as well as its implementation and evidence base. I decided to evaluate the tasks in the hours of the best programmer .
If the best programmer solves the problem in 1 hour, then it costs 1 hour. Another programmer who solves this problem in 4 hours will receive 1 paid hour for it.
In order to evaluate tasks “by the best programmer”, you need to understand who this is. We decided this: the best programmer has all the necessary knowledge about how to solve the problem . He knows the methodical area, knows the necessary mechanisms of the platform, knows the metadata and "where what lies." In general, he sits down and does it without wasting time.
The key objective of this assessment is to strive to minimize the loss of time, making them unprofitable. Losses in the programmer’s work are weight, and in terms of volume, losses often exceed half the working time.
I personally did the assessment “for the best”, and this is perhaps the bottleneck of the whole system. It was immediately clear that it was necessary to make an assessment system, if not transparent, then verified retrospectively. Therefore, I decided to make a job evaluation classifier — an uncomplicated guide containing standard components for solving the problem and their evaluation. It was filled gradually, we called the assessment of the work “precedent” - the items tested in practice with measured execution time fell into the classifier.
The classifier contained, for example, the following items:
- Development of a simple report, such as "Sales", in one register, on ACS in user mode. Score - 15 minutes;
- Creating a register of accumulation, with a simple record of movements, fully determined by the context of the document. Score - 15 minutes;
- Developing a role, without RLS, with a small list (up to 10) of allowed objects. Score - 10 minutes.
Execution time included development and testing by the developer. If there was an error in the working base due to the changes created in this task, then the errors were corrected by the executor at his own expense.
Each task that programmers performed was given such an assessment prior to execution. It is clear that some of the tasks contained several items of the classifier - for example, a register, plus several details, plus a report, plus an autotask. Time in this case was summed up.
Now it was necessary to determine how much to pay per hour of work of the best programmer . This question we decided on the forehead. The average good programmer then got on the market 60 thousand rubles. We decided that the best programmer should receive 100 tr. It is clear that later this figure can be changed in any direction.
Simple calculations and rounding gave us the hourly rate of the best programmer: 600 rubles per hour .
The figure is quite good, because it is half the hourly rate of local francs, and lower than the cost of freelancers, who then asked for 700-900 rubles per hour.
But the main thing - only direct work was part of our hourly rate . There was no thinking, modeling, decision analysis, etc.
However, knowing that the conversation about this bid with the management will take place anyway, we decided to make sure that we were right. To do this, talked with friends and strangers franchami and freelancers. We gave these guys a few tasks to assess, and asked a simple question - how much will you take the money for such work? The result was predictable - the guys asked for work 2-3 + times more than we (including taxes on salary). At this calmed down - ass covered.
Now it was necessary to balance the system by the amount of monthly accruals in order to avoid errors in both directions. The first side is the programmers. You never know, suddenly it turns out that the programmer has earned 10 tr. - he will have nothing to feed his family with. The solution is simple, I saw it when I was working in France - to set the minimum monthly payment, less than which the programmer will not receive. Without thinking twice, they decided that this would be the current salary.
The second side is the company. Just the irreducible payment is unprofitable, because With its help, you can deceive the system. For example, to complete 20 tasks a month before the state of “almost ready”, to receive a salary, and to make a breakthrough next month, close 20 unfinished tasks and another 30 new ones, and get a deal. By the way, it was in the same way in France, and everyone used it.
The way out is also simple - “memorize a minus” . Made work on 40 tr., Received a salary of 60 tr. - ok, remember the "minus" 20 tr. Next month you should. Do in the next month of work on 80 tr. - you will receive 60 TR, and you should not.
At the same time, just in case, the payment ceiling was set - 100 tr. Agree that work performed in excess of this amount will be reckoned next month as a “plus”.
Now it was necessary to figure out how to deal with projects. The project, if simplified - is a set of tasks related to each other in some sense or purpose. But companies are interested in not only accelerated implementation of each of these tasks, but also the fastest possible accomplishment of the entire list of project tasks and the achievement of results.
The output is also simple, and again spied on by others - a part of the piecework wage to accumulate and issue at the end of the project . We decided that it would be 20%. While the project is underway, the programmer receives 480 rubles per hour, and receives the remaining 120 rubles from each hour at the end of the project.
Well, everything seemed to be thought out and thought out, it is necessary to begin the test operation.
First of all, it was necessary to change the business process of the work of programmers:
1. Tasks should now be set not personally by the performer, but by me, the manager;
2. I now have to evaluate each task in hours;
3. After acceptance and evaluation, the task becomes available for execution.
Ok, the business process has changed, you need to automate . In order to have more creative freedom, we stopped using assignments and service notes (everyone used them), and in 1-2 days we made two new objects for ourselves:
1. Application to the IT department, with all the necessary fields for our assessment;
2. Simplified system of accounting projects and tasks in them, with the same evaluation system.
And they immediately made a report that showed the output in hours and the money earned, so that programmers could see their results every day.
We started to work, and immediately faced with the complexity - programmers began to whine that the task estimates are too low . “I need to think out”, “and I have never come across processing, I need to understand”, “I once did an auto task, do I have instructions to read?”, Etc.
I listened to them, and began to reflect on the philosophical depth of the question: should the company pay for its employees to get knowledge?
It seems the answer is obvious - should. But is it all so obvious? What happens?
One of the programmers has the task to complete the subconto Warehouse in the posting on account 003 (for some reason, it is not filled in a typical SCP). And he doesn't know how to recycle, either on the side of the supplier or on the side of the processor.
Like - sit down and figure out what this and that, they always did. In the traditional salary system, the employer will pay you for the time while you pick around there.
But it's not that simple. Of the four people (three programmers + I, the manager) two are well versed in processing, and the task went to someone who does not understand. When did we understand recycling? The programmer is at the last job, I am at the current place, because previously was not in the practice of davaltsev / processors. It turns out that the current company has already paid for obtaining this competence.. And it seems like paying a second time, at least in the same amount, is wrong. What needs to be done now? That's right, to transfer the competence to the one who received the task.
There was another question - and what for it needs a carrier of competence? He also has piecework wages, and instead of transferring knowledge, he will do a better job.
I began to reflect on an even more philosophical question: should the company pay for the transfer of competence between employees? Traditionally it is believed that the transfer of knowledge is a matter of course. But we all know that the quality of such a transmission leaves much to be desired. The exception is adaptation and mentoring programs, but they are not very common.
So, the decision became obvious to us:
1. For the transfer of knowledge and help each other have to pay;
2. For obtaining new competencies you have to pay.
The second point is about knowledge that none of the team possesses. For example, we had a task to constantly drag in 1C data from an external system by direct requests to MS SQL. The task is simple, but no one has done this before. I did this - I made out an application on my own behalf, the essence of which was to smoke work with external data sources at a level sufficient for solving a specific task. Task assessment - 1 hour (and you can sit at least a whole day).
As a result of solving the problem, we get a specialist who can solve problems with external data sources, and we will not pay more for this competency . Only for its transfer to other programmers.
We decided to pay for the transfer of competencies and mutual assistance, and for this we came up with the appropriate term - the costs of analysis and design. In order not to waste time on a big bureaucracy, we drew a table in the Word containing the data:
1. A question that was discussed / projected / transmitted;
2. The time of the beginning and end of the discussion, up to minutes;
3. Participants.
A separate document was added to the accounting system, and the results of such discussions were added once a week. Usually discussions were stacked in 5 minutes , occasionally reaching 15 minutes. For a week it worked at all 3-5 hours .
What is important: the time of discussions was paid to all of its participants.i.e. It was beneficial to both acquire and transfer knowledge. It was beneficial to assist colleagues, because human laws have not gone away - if you help, then they will help you, and if you keep knowledge with yourself, then be ready, faced with an unfamiliar task with an estimate of 1 hour, sit with it for 2 days. Of course, there were exceptions when I myself deleted from the list of participants who sat and considered the raven.
Yes, all such meetings should have been held in my presence, because to the outside world I was responsible for the quality of the system. All the issues discussed were reflected in the system, and if necessary it was possible to go back and see if the money was legally spent.
There was one more "nasty" question - tech support. Unclean - because I do not like the presence of technical support, it dulls the mind of users, takes up valuable time of specialists, without bringing special benefits to the company.
Formally, tech support from us then is a dedicated duty officer who should help people during the week. How much to pay a programmer who is on tech support?
At first there was a thought not to pay at all, but to reduce the base for calculating the salary when calculating the payment. For example, if a programmer has a salary of 60 tr, stayed 2 weeks in a month for technical support, then, when calculating, take half as a salary - 30 tr, and for the rest of the time, consider a transaction.
But it is immediately clear that some kind of nonsense is obtained - the company is not very large, and objectively technical support does not take a whole day. Accordingly, the programmer manages to solve problems and can use the scheme with a “jerk”.
There is a way out that is much easier - to calculate how much time a day is spent on technical support from the best employee , and to pay these days to the programmer in the same amount. Because I was considered the best in this gang, I measured it myself. Just sat for a few days on the support with a stopwatch and the goal - not to smear snot, but quickly to help people. Correctly redirect their questions to the tasks. Provide links to instructions if the person has not read them and requires online training that everyone knows about. Well, etc.
According to the measurement results, it turned out thatTech support takes an average of 2 hours per day . Well, that’s the number. We agreed that it would be paid by the duty officer at that rate - 2 hours per day, or 10 hours per week.
It is clear that it is unprofitable to engage only in technical support - it is about 25 thousand rubles a month.
So that the duty officer would not be bored, we gave him a piece of paper and made him write down all those who address him - just his last name. In the accounting system, a document was created in which the attendant on the end of the day contributed all the "converts". Why - see at the end of the article, under the heading "Pleasant bonus".
Actually, on this picture has developed, and we continued the test operation of the system .
There was unprecedented enthusiasm among programmers.. They grabbed at the task, the smoke was a pillar in the performance.
A programmer began to work in silence, who used to like to discuss “what a difficult task, there are so many pitfalls”, he could spend hours sucking on these pitfalls, charging himself a price (it is not clear, however, why the salary is the same).
Immediately, the programmer, who used to like to sit for hours and “think over the optimal solution,” began to issue optimal solutions, because now the optimal solution was issued by a team brainstorming session in 5 minutes.
At times, the introvert programmer, who could sit for two days over an already solved task, was often more likely to communicate with customers, because he was embarrassed to talk to the customer.
A lot more intelligent, high-quality tasks from users began to appear, because programmers began to help with their design.
The novice programmer stopped sitting for hours and stupid, who used to be embarrassed to ask his colleagues a question, because “it’s inconvenient to distract, they will be annoyed” (I must say, they used to be really annoyed before).
Programmers have become gambling and greedy , in the good sense of the word. I, as a manager, achieved my goal - the system began to work, though not entirely without me, then with my minimum participation.
My participation has become transparent and understandable, these are just points in the business process:
1. Acceptance and evaluation of tasks, I did it once a day, for about 15 minutes;
2. Participation in meetings on analysis and design (this is ~ 3 times a day for 5 minutes).
Total for managing three programmers - 30-60 minutes per day. No one needs to kick, follow the execution and deadlines, motivate, check the quality - everything was done by itself . I could look at the results at any time through the system. It is impossible to say that complete self-government came out, but we were as close as possible to him.
We conducted test operation for 3 months. During this time, the output in hours has doubled , and the salary calculated for the new motivation - by 30%. The difference is clear - now I had to work out the salary . According to the programmers themselves, they have never had to work so intensively before. It was intensive, not long or long - I was always against a more than 8-hour working day.
But here it is important to not thatthey talked about the intensity of the work, and how they said it. They spoke with pride in themselves . Not only because the new system made their work more efficient, but also because they themselves were the authors of this system. They themselves made themselves more efficient, they themselves made their work transparent and measurable, they themselves began to look differently at the company, its managers and employees.
I explain success as follows:
1. If you look through the prism of theses on the development of motivation systems, it becomes clear that we have defined the product well. The product is a solved problem. Clear money is paid for this product. Everything else - at their own expense (reflections, the Internet, chatting on messengers, smoke breaks, whining, depression, etc.).
2. If you look at the development process through self-management, you can see that the system was created with the direct participation of the people who work in it.
3. We made the system as measurable as we could - according to the requirements of controlling. The mere measurement of the work done made people move faster and not engage in nonsense.
After the test operation, I went through several iterations to protect the new system: HR director, financial director, director, owner, external HR consultant (Moscow, very well known). Everyone liked the system.
I, as the head of its development, was especially interested in the opinion of the HR consultant, since He knows world practice well and has completed hundreds of projects on the development of motivation systems. His assessment of my system turned out to be very high, especially he liked the contours of protection (“remember minus” and the maximum payout limit).
Subsequently, the principles of this system became the basis for other systems of enterprise motivation.
A nice bonus.
So, we had an estimate in rubles for all works, including analysis, design and technical support. Sin was not to take advantage of this opportunity, and not to make the calculation of the cost of automation in the context of customers and projects . After all, we now knew for sure how much money a company devours through automation, and if you look at this datain the context of utility , we get just a gorgeous picture.
For example, we learned that the technical support of the Deputy Chief Accountant, who, according to the job description, should know SCP best of all in the accounting department, leaves more money than this person receives in the form of a salary.
We also learned that people who always whine “do not deal with us” consume 40% of all money for automation.
It was interesting to look at the growing budget from month to month of projects that did not have a host (this is when the director, for example, says - automate this service, and the automation service has not rested anywhere, but they have to write the tasks themselves, so they go in circles) .
The apotheosis was a report at a strategic session with a disappointing outcome -more than half the money the company spends on meaningless automation . Meaninglessness is quite a meaningful description. For example, the functionality is developed, there are no comments, but it is not used (“yes, somehow all hands do not reach”). Or the functionality that is designed to help improve the management process, through a change in the value of the indicator - and the value of the indicator either stands still or worsens (and at the beginning of the project it was said - this will not help you, guys, you have another problem).
What is the result? We have become more and more attentive to listen, especially before the start of work. Because now we were able to predict the results of projects, relying not only on systems thinking, but also on statistics in numbers. The volume of meaningless work in the first months decreased to 30%, while the structure of “meaninglessness” has improved. But that's another story.
PS
There are people who repeated my experience - well, that is, they also built a system of management and motivation on the basis of certain normal hours. They say they are fine. Although, who is recognized ...
I do not know about you, but I am stupid. The experience described in the article happened about 4 years ago, if I remember correctly. Then I found out about scrum - or rather, I bought a book at a sale - and I got carried away, and abandoned everything old. Because stupid.
You always want not to think, but to take ready. Scrum, PMBOOK, CORE PM, Kanban, TOC or something else, “implement” or, to put it more modernly, “implement”. And some assholes, like the developers of the scrum guide, also heat up the situation, saying something like “if you’re not doing it by the manual, then you’re not scared.” Although in the book they themselves wrote that they should think with their heads.
The experience described in the article is invaluable. For me, of course. If only because he showed the importance of evaluating tasks in some more or less stable units. Then, on the scrum, it turned into points. More experience has shown that doing the right motivation system with people. He also showed that with the right system of management and motivation, people do not need a leader. And a lot of things showed.
How are you? Helpful? Or beee, I do not work, it's about 1snikov.