1C, do not hurt

    I have seen in my life two types of businesses that are developing the worst of all - 1C franchisees and Christmas tree sellers. This is not about developing in breadth, when just the number of programmers is growing, but about internal development. On efficiency, in short.

    Although, probably, sellers of Christmas trees can be excluded from this list, they managed to surprise me before the New Year by selling me a real fir-tree. Previously, only fir and pine have been. I even looked on the Internet how to distinguish a Christmas tree from a fir - really, it was spruce.

    So, only 1C franchisee remains in the list of “The most non-developing companies”. A lot of wonderful people work there, but whether this is the environment or the place is damned - something is wrong with them.

    They think only about today. Perhaps the fault is tied to a single vendor that develops both the framework and application solutions. Nobody in their right mind in the 21st century will build a long-term business, tied to one programming language, one development environment, one market? But to strike while the iron is hot - please. When it cools down, then it will be possible to think about something serious.

    But for some reason, it seems to me that all is not lost. You can do better.

    Different methods of increasing efficiency are, of course, interesting. But much more interesting is the combination of these methods for a specific activity - the case. It includes processes, motivation, automation, goals and control system. Not always all the components at once - just what you need.

    Let's try to form a case for a specific part of a business we know - 1C: Franchisee. He is familiar to us because there is experience in other francs for several years, plus - we are constantly confronted with francs, in a formal and informal setting.

    We will form the case on the basis of aggregate experience - almost everything we have written has been tested on ourselves. We do not convince anyone of anything, the interest is purely academic. Although, there were large franches who took this case into service, and they themselves are introducing something there.

    If you do not know what 1C: Franchisee is, then read as if it were a question of a certain company providing software development, maintenance and development services.

    The purpose of the case is simple - to increase the production of programmers and, if possible, revenue. Or exhaust, he has different options. Go. I warn you - longrid.

    initial situation

    Take not the whole franch, but its part, which we call the development department. These guys, 1C programmers who sit in the office, receive tasks through the system or from consultants, decide, pass the result to consultants or a client, remotely.

    There are several such departments in large network franchises, there is competition between them, and they, when there are not enough resources, actively exchange both specialists and tasks. Perhaps not at will, but this is not the point - we look at the development department as a business unit, and not as a bunch of “real programmers”.

    Suppose our development department consists of five people. Total average monthly production is 500 hours. Of these, 200 closes a champion - the most experienced and intelligent coder. 100 hours closes Second, 80 each - Third and Fourth, 40 - Beginner.

    For example, an hour of work for a client costs 2000 rubles. Suppose we have a single internal rate for programmers - 500 rubles per hour. Simple calculations say that the revenue of the department is 1 million rubles a month, the department's payroll is just 25% of the revenue, in this case 250 thousand rubles. Total, the company receives 750 thousand rubles, of which pays taxes on the same programmers, well, all their other expenses. We will not consider the profit structure, we just understand that it is non-linear, since contains fixed costs, such as renting an office and buying cookies.

    The output, for example, is relatively stable, does not jump much. Is that when the Champion goes on vacation, we have a failure of 40 percent. Sometimes it happens and 700 hours - when there was a good project, and programmers work on weekends.

    Case Purpose

    Immediately the purpose of the application case will tell, so as not to create mystery. We want our development department to give out not 500, but 1000 hours per month, i.e. twice as much. For the same hourly rate, with the same fixed costs, with the same number of working hours. We can allow a small temporary cost of this project - for example, in the range of 30-50 tr.

    It is important to immediately decide what we will do in the target situation. On the one hand, we sell time specialists - hours that they spend on solving problems. On the other hand, we sell solved problems, evaluating them in hours. It seems everything is clear, but the difference between these two rating systems is quite significant.

    Suppose our 500 hours per month is 500 real hours of work of specialists. For these 500 hours, they solve, say, 200 problems, with an average price tag of 2.5 hours. It turns out that each task costs an average of 5,000 rubles. The client is quite willing to pay that kind of money, he knows the market, the rest of franchises have the same price.

    And so we learned how to solve a problem not in 2.5 hours, but in 1.25 hours. The key question is how to sell it to a customer?

    If we sell time, then it is logical to sell in 1.25 hours. The customer will be damn satisfied - and cheaper, and faster. But we, as a business, have almost no benefit from such a scheme - only a satisfied client and free time of specialists who need to do something. Suppose we have found more customers, and also sell them a task for 1.25 hours. As a result, in a month, what will we get? The same 500 hours for 2000 rubles. There's no point.

    One option is to raise the hourly rate. We solve problems faster than competitors? Nobody will notice this especially on small works, but on tasks at 40 hours the difference will already be noticeable.

    But the price of an hour is a noticeable change for the outside world that can discourage new customers from us. They do not know what we are doing twice as fast? Slogans written on the site are not particularly convincing.

    It seems more correct to continue selling the task in 2.5 hours. The client does not notice anything, but we get a normal, target result - by doing twice as many tasks, we get twice as much money.

    You can choose a compromise option - sell, for example, in 2 hours. Then the client sees tangible savings (especially on large volumes), gets results faster, and we are in the black. Moreover, even with the preservation of the internal rate of programmers.

    For simplicity, we will consider the option when we continue to sell for 2.5 hours. Evaluation of the incoming task is based on a slightly more complicated algorithm - it is necessary to estimate the real time and multiply it by 2. But more on that later.

    Yes, there are still exotic ways to use the released time, for example, strengthening internal development. This will be the end.

    All right, the goal is clear, now let's move on to analyzing the necessary changes.

    Key issue

    They say there is always a point of application of force into which the lever must be inserted and get the maximum effect. I disagree with this - in the sense that such a point is always there. But in this case it is - a system of motivation.

    Our motivation system is an individual, hourly rate for work performed.

    There are a lot of advantages for programmers in it, a little for business, but there are plenty of minuses.

    A specialist has no reason to share his knowledge and experience. The only thing for which it is worth doing is to raise your importance. If everything is in order with importance, then sharing experience, and all the more helping in solving tasks, is contraindicated. Teach a fool - he will become your competitor, and you will not even thank you.

    If you know well, for example, salary (this is a program), while others do not know, you will always have bread and butter. As soon as the second salary worker appears, you will have to make an effort to get the most tasty sections of work.

    What's in it for business? If specialists do not share competencies, then the concern for training falls on the shoulders of the company. It is necessary to organize courses, or pay third-party organizations (such as 1C). The second is the bottlenecks in the form of key specialists. If out of 5 people only one knows ERP (this is also a program like this), then you physically cannot take work on ERP more than this employee is able to digest. Even if it is a champion, there will be no more than 200 hours per month. Well, either take the risk - take the work to figure it out later on.

    Making the sharing of competencies is not very possible. Visibility can be done. But, who was a programmer, he knows - there are ways to assist in such a way that they no longer turn to you for her. You can make the Champion even a seminar, or training to hold. He honestly reprimand the material - the one that is so available on the Internet. He will still keep real, practical knowledge with him.

    An individual hourly rate is like a business within a business, and this “internal business” is always an entrepreneur, not an LLC.

    Competences are important, especially in epochs of change that occur periodically. It happens, of course, a lull in a couple of years - for example, before the release of ERP, when everyone has already figured out SCP (this is also a program, an old, but vigorous). But in 2004-2010, for example, the “projectors” who had the best knowledge of SCP lived the best. Now, probably, ERP experts live best of all - I don’t know for sure.

    Individual piecework payment kills the ability to share work decisions and developments, because this, again, makes no sense. Well, you gave your processing or subsystem to a person, he closed 40 hours in a day agreed with a client, raised 20 tr. What do you want from this? You can, of course, agree, and generate a black market within the department, but it makes no sense. Simply say, “give me the task, I will solve it”. In a hopeless situation, of course, he will give up, but rather he will leave it to himself, out of principle.

    You can look at competencies differently: who is their owner? Suppose your Champion has been with the company since 2010. Performed a lot of work on the ERP, received competence. Who do they belong to?

    The company will say - we own it. Our clients, our projects, our tasks. Give back competence. And how to pick them up? Do not ticks the same? This is not a tangible asset. Psihanet, go away, and crying competence.

    What are competencies? Product. Or not - the income from the sale of the product. Shipped 200 hours of ERP, got two profits - 400 tr. and competencies. Money - it is clear, here they are, on the current account. You can translate, spend, invest. Where are the competences? Get out in that bald head. What can you do with them? In fact - nothing.

    So, the guy learned at our expense. Not that we invested money in his training - no, it just happened. But we can get this profit only in one way - to continue to exploit these competencies, i.e. for all work on ERP to put it alone. Well, or risk and put a beginner to get another non-recoverable resource.

    The reason for this situation is simple - the wrong system of motivation. It does not really encourage - it directly prohibits a person from sharing competencies.

    Motivation system - what is it for? So that the person himself, on his own will, and with all diligence did what is beneficial to the company. The system of motivation should replace the leader who every day goes, kicks and tries to indicate something.

    How to make the person himself, of his own will, do what is beneficial to the company? Well, first, of course, understand what is beneficial to the company. Secondly, to make the company benefit to the person. Not in the form of missions and slogans, but for real.


    For the case, I chose the methods that, in my understanding and experience, are most suitable for achieving the goal of doubling the output. In general, there are a lot more methods, but we are not engaged in writing here, but in deed. Also, it is worth noting that in order to double the output, it is not necessary to introduce all the methods - often just one is enough.

    The difference in the initial conditions of a particular company, about which I know nothing. Probably, there is in the world the moronic franch, which has the lowest output per employee. You are not from this french, therefore your metric is higher. But how much higher - I have no idea. But the fact that you can double the output is a fact.

    So, what to do with :

    • Select, automate and add initial balances to the rating system;
    • Automate and add initial balances to the competency system;
    • Decide on a motivation system, automate;
    • Select the parameters of the competence strategy;
    • Assign duty officer;
    • Talk to programmers.


    • General discussion of incoming tasks;
    • Selection of the executor according to his competences in accordance with the strategy
    • Management of mutual assistance and its accounting;
    • Manage task status.

    Now summarize each item. But first - an explanation of automation.


    The point that is present in almost all variations of the case is automation. All changes that you make to processes, management and motivation, you need to quickly automate.

    “Quickly automate” is really fast, i.e. during the day (including waiting for the opportunity to update the database configuration). Hence the need to immediately realize this automation by the same team, the production of which you are increasing. If you are a big franch, and you have another department that is not subservient to you, then you are not very lucky, but there is a solution - covert automation.

    For all that is in the case, enough made on the knee samopisannogo configuration. Then, someday, you will improve it, integrate it into your corporate system, make an ergonomic interface, etc. Now we need almost bare data, without beautiful and convenient. Therefore, if you do not have access to the refinement of the overall system, make your own and share it within the team.

    If your task management system is not on 1C, then, alas, you are not lucky - you will most likely have to throw it out. Or use it as a proxy for 1Snoy, if clients stick out in it - let them drive tasks in there, but for now you make yourself a system, on 1C, and upload data to it. Otherwise, nothing happens - the developers of bitrix24, JIRA, Github and other systems, I apologize, they wanted to shit on your needs. If add. there is still a possibility to add a property to the task, then the tabular part is unlikely, and even more so - the report.

    To automate the work of internal teams sitting next to each other, the best platform, alas, is 1C.

    Rating system

    We need a new rating system - a task that we are doing in 2.5 hours, we have to do in 1.25 hours, and sell in 2.5 hours. It turns out that the problem in our target state will have two estimates - 2.5 and 1.25 hours. One is a real investment of time, the other is a certain estimate for a client. Now, in the current state, we believe that these estimates are equal (on average).

    I personally do not like to keep two marks in one unit (clock). I can't stop wondering how anyone can like her at all. In reality, there are even more evaluations: the clock to the client, the clock, called by the programmer when planning, the actual clock. How then to reduce it all, somehow analyze - the devil knows.

    I recommend the Scrum system - poker scheduling. Each task is scored in points taken from the Fibonacci series - 1, 2, 3, 5, 8, 13, 21, 34, etc. Evaluation reflects your comprehensive vision of this task - and the complexity of the execution, and labor, and uncertainty, and the problem of the client on the delivery of work.

    The easiest way to start with an “anchor” is to determine that there is a task of 1 point. This is the simplest, atomic problem that you solve. Accordingly, the task of 2 points is twice as difficult.

    Estimates are made when processing the incoming stream, i.e. when a new task appears. Each member of the team puts his or her assessment, in the end we have - 5 ratings (for the example we described). If there are assessments that differ by more than one element of the series, then we need to talk and understand why there is such a big difference, and to eliminate it - either one overestimated it or the other underestimated it. When all disagreements are resolved, the average is considered (the sum of evaluations divided by the number of evaluations) - it will be the evaluation of the problem.

    If you implement the system “from above”, then it is quite possible not to arrange the polls, but to put the marks yourself. We do not have Scrum, we write the rules ourselves.

    If in the process of solving the problem it turned out that the assessment is too low or too high, then we can safely change it. Of course, by the time the task is closed, the final grade should be known.

    Evaluation must be entered into the system, and stored in the form of a task requisite.

    If you do not like points, then you can use some kind of standard hours. I do not recommend this option, but my opinion can be ignored. For example, at the dawn of practice I came up with such an assessment as “for the best” - how many hours would the best programmer who knows everything about the task, context, client, functionality, etc., spend on solving the problem ... Everything that is needed by such a “best” - write code.

    Now it is extremely important to introduce the initial balances - assess the tasks for 1-2 months that you have already decided, and enter the estimates into the system. First, practice and develop your rating system. Secondly, and most importantly - get the current speed and "price point".

    For example, it turns out that you sell 500 hours for 2000 rubles per month, and this is 500 points. Then your score at the moment is 2000 rubles. After the changes are introduced, you have to generate 1000 points, sell them at 2000 rubles and receive twice as much income (both the company and the employees).

    The initial balances are extremely important, because without them you will not answer the elementary question - did it work or not? Do not be lazy, please.

    It will be tempting not to evaluate old tasks, but to start with new ones. Unfortunately, the dynamics of changes is such that you can double the output in a month, and in a month you will learn how to work with estimates. In this case, you will sell your doubled output for the same amount - deceive yourself.

    If you implement the system “from above”, then the ideal option is to make input of the initial residues secretly from programmers.

    Competency system

    The system of accounting competencies is as important as it is not widespread. Records of the number of certificates, of course, are not a system of competency accounting (as well as certificates are not competences).

    Competences are a hierarchical reference. Its structure and detail depends entirely on your needs and diligence. It is not necessary to crush, because you are tortured to enter data. Just define what is important to you in competencies, what you really need to know.

    The analyst in accounting competencies is only two - the task and the person. They should be guided while filling the reference book - the answers to the questions “what competences a task requires” and “what competences a person has” issued by the system should suit you.

    I divided competences into two principal parts - technique and methodology. Technique is about programming and platform. For example, work with external data sources, or exchange with bitrix, or complex data composition schemes. Methods are specific subsystems, documents, and accounting sections. For example, closing a month in SCP, budgeting, order management, production scheduling, etc. You can use my experience, you can create your own.

    In the information system, a tabular part should appear in the object of the task - competences. It lists the elements of the directory, and put the assessment. What kind of assessment - I do not know, it's up to you. I myself put one, and considered the competence confident after recruiting 10 ones. You can put interest, and consider the competence confirmed, if accumulated 100%.

    Then everything is clear. You can enter the remnants of the old solved problems. In all new tasks it is necessary to fill this tab. Well, it is necessary, a bit later, to plant programmers, so that they draw a petal diagram and a bunch of reports on competencies.

    You can add a “Competence Plan” to the system, in which you list development priorities and the proper level of competencies for each employee. Well, the report in addition, which the plan-fact will do. It is especially interesting to watch the variance of growth of competencies - it is quite possible that your champion works only in the main, or only, studied area, which is currently popular among clients.

    Such a system will measure only real competences - those that have been confirmed by the solution of problems. Certificates, courses and tales at the interview - this is not about us.

    Motivation system

    This item is for bosses only. In principle, the piece-rate system of motivation, when the programmer receives, in fact, a percentage of the work, is quite acceptable (compared to the systems of motivation in other professions). But there are downsides that I talked about at the beginning of the publication - pushing towards individualism.

    There may be several solutions, I offer the simplest - KTU. You have a task “Artist” in the task, you need to add the table “Artists” to it, then everything will fall into place.

    Details tab.chast - employee and percentage. Accordingly, the charge for the task goes not to one person, but to several (usually not more than two). The amount is the same, only divided by percentage, i.e. the company does not pay anything extra.

    Such a system is often found in sellers, when one, for example, dragged a client, and the second accompanied the transaction.

    In our case, the main motive for using KTUs is to “unleash” the champions, and indeed everyone, on cooperation. Suppose a person got the task, but he doesn’t have a good understanding of either a technique, a technique, or everything at once. But he knows that the other guy solved a similar problem (or does not know, but he is sure if he looked at the report on competencies).

    That second one, it seems, can help, but there is no reason for him, except for “brotherly help”. The performer, as a result, can spend 10 hours on the task, although it is solved in 2.

    Now it will be different. The contractor is coming to the "knowledgeable", offers cooperation. "Aware" says - there is a business for a couple of hours, I have an example, I need to do a little bit, that's all. As much as you want? - asks the performer. Well, come on 40% - says "knowledgeable". The performer agrees, in 15 minutes he receives a tip and an educational program, and at the same time he receives code examples, solves the problem in 2 hours, gets 500 p. x 2 h. x 60% = 600 rubles, i.e. on this segment, for himself, he worked at 266 rubles per hour (600 rubles for 2.25 hours). If I did it myself, I would have worked at 100 rubles per hour (I would have spent 10 hours, I would have received 1000 rubles).

    The Knower worked at 1600 rubles per hour (spent 15 minutes, received 400 rubles). Well, that's what he knows. Routine work, i.e. his work and his time, he sells for 500 rubles per hour, and his real knowledge - for 1600 rubles per hour. No one is in the red, most are in the black. The client received the solution quickly, without losing anything in money. The company did not lose anything in money, received two satisfied employees and a satisfied customer. The performer is glad to the ears, and who knows, at last, he began to receive dividends from his investments in self-education.

    It is clear that all proportions will vary. Sometimes a knowledgeable person will need an hour to explain, and sometimes one minute. The performer, too, when he does in 2 hours, when 5 is still drowned. But, nevertheless, the average exhaust will be positive, and very significant.

    The main thing, in my opinion, is to completely give the percentage distribution to programmers, and not interfere with it. Let them agree, because they are adults.

    The second thing is that if you are a boss, then do not try to take these “free” watches from the champions. After all, there is such a temptation to pay only to the performer, and even with the reduction factor for dullness. We at the beginning of the publication agreed that the percentage of payroll does not change - neither in plus nor in minus. When saving interest and doubling the output, the company will get its own.

    Competency Strategy

    Once you have a system of real accounting competencies, you need to decide how to use it. Basically, there are two vectors - to distribute tasks to those who can do them and those who do not.

    The first vector gives the maximum solution speed, but does not give the development of competencies. The second vector gives the minimum solution speed, but the maximum growth of competencies.

    It is clear that the best way is somewhere between vectors. On the one hand, we have a business, not a university, and we cannot deal only with competencies. On the other hand, if competences are not developed, then there will be restrictions in the form of champions that reduce overall production.

    Actually, the ratio of these vectors is the strategy parameters. Here it is important that: you do not need to choose these parameters once and for all. The main thing is that you understand that you now have them, these levers and sliders that regulate speed and development, and in numbers.

    For a start, you can set the following values: 70% for tasks according to developed competencies, 30% for tasks for new areas of knowledge. It is clear that we are talking about the sum of the estimates of the tasks. Although it is possible to divide time as a percentage. Even for simplicity, highlight the day in the week for developmental tasks.

    There is a temptation to think that the percentage of tasks for development will gradually decrease - will the programmers figure out, after all, in everything that is needed? No, alas. First, the platform and solutions are evolving. Secondly, people come and go. You will develop one, he will move to Moscow, you will have to take another. But the question “how to develop it” now will not bother you - there is a system with a slider “speed - development”.

    It is clear that the parameters of the strategy depend on who you are - the boss, owner, or programmer. The balance of development and production, as well as the system for maintaining this balance, is beneficial to the owner and some managers. Boss profitable development. Programmer champions are more likely to develop and little development. Ordinary programmers, rather, development.

    I myself - for the balance, because it is more important for me to build a self-developing system, than to get a momentary result. In our case there is the main thing that is needed for the system - accounting and control of the development of competencies, in numbers.

    Assign duty officer

    Consciously avoid using the word "manager" because, I repeat, I do not know your situation. If you are inside the team, and the boss is not with you, then it will be the duty officer, chosen democratically. If you are the boss, decide for yourself whether you are on duty or appoint someone from the team. I recommend to be the person on duty.

    The duty officer is a person who will monitor the implementation of the rules and perform the routine work of administering the system. Part of the responsibilities will be for programmers, but the most important part - regular management - will be in the hands of the duty officer.

    The attendant will, for example, organize a discussion of the incoming task flow. It is not difficult, you just have to get up and say something like, “So, that's it, we quit the job, we discuss the tasks. Come on, there are only three for today. Fedya, good, then you have a smoke. Kolyan, then finish it. In the sense of "better not to be distracted now"? Will we all be waiting for you? Damn, guys, we agreed, you all nodded our heads off that at 9-00 we had a discussion of tasks. Come on, do not swing. We decided to do it, otherwise there is no point. ”

    The duty officer is responsible for the quality of the data in the system - for example, for the correct indication of competencies (and generally for their indication). The attendant manages task statuses.

    Principle you understand. The duty officer is responsible for the fact that the system works. It does not bring results, namely, it is running, running, running as intended. This is extremely important, because if no one follows the rules, they will not be executed. And if the rules are not fulfilled, then the result will not be, the development will not double, but rather decrease, and you will drop it all in a week, without starting.

    After some time, the implementation of the rules will become a habit, and it will be easy to be on duty. In a team of 5 people, it will take about 15 minutes a day. Along the way, you will figure out how to automate part of the rule control - you are programmers.

    Talk to programmers

    This item is optional, the need for it depends on who you are. Personally, I still recommend talking to programmers, explaining the perspectives and the essence of the changes. Be sure to let them read about the dismissal kit . Well, if you manage to inspire programmers. If you have not engaged in verbal motivation before, you will get a rewarding experience, especially if you are not doing it “for the first and last time”.

    Most likely, you will not be able to inspire them the first time, regardless of your role. The 1C programmer is a special person, with a strongly pronounced dialectic in assessing his place in the world. On the one hand, he understands that he benefits the world. On the other hand, he is worried that he is not a real programmer, he receives a lot of money in vain and, in general, he is someone like “survivors” who hooked up to a temporary, but profitable topic. Why the programmer 1C does not leave the feeling that all this will ever end.

    Such a dialectic leads to a mild form of professional schizophrenia, therefore, convincing the programmer of something, you will have to communicate with two individuals sitting in it. The vector is as follows: maintain and develop the positive part and neutralize the negative.

    If you fail to inspire - do not worry. Decide in advance that you will not be able to convince programmers, then do not be upset. They will inspire themselves when they see the result - the growth of output and, accordingly, of income. Then they will help you.

    Alternatively, you can apply isolation - to take in an experiment not the whole team, but only its loyal or neutral part. Negative champions can be left aside, let them work as they worked. It is important not to put pressure on them, not to introduce changes “to the argument”, and not to try to prove something to them.

    When you succeed, for example, to raise the incomes of isolated average programmers to the level of champions, these same champions will have to decide something. If you pressed them all the time, or poked them in the nose with your successes, then they will resist to the last, or they will simply leave to maintain a sense of their own importance.

    Therefore, be extremely careful and restrained in communicating with the champions. Although, I repeat, if the champion is real, then all these court ceremonies are not needed - he will follow the changes in the front row. Psevdocampions, which is more important to maintain the role and position, will resist.

    Main principle

    Many are wondering - how is it even possible that production will double? Due to what? Are we able to write the code faster? Or reduce its quality? Tyap-bang and in production? Many, of course, do not ask, but simply deny and reject. After all, it is impossible that there was somewhere a proven technique of double acceleration, and no one knew about it?

    The problem, in fact, banal - the wrong vector of attention. Or, more simply, you are not looking there. Suzim topic to programmers, although the principle is universal.

    What do you think is the ideal speed for solving a client's problem by a 1C programmer? It's about the task of developing or refining. Think while you read, the answer will be slightly lower.

    Let's look at the work of the 1C programmer. What do you think, how many percent of the time does he actually program (including all aspects - writing code, creating metadata, layouts, etc.)? 100 %? 50 %? 20 %?

    Practice shows that there are 3%. If you do not believe, check for yourself - there are specialized programs for such measurements. But there is a simpler way - look at the amount of code written by the programmer for the day, and divide by its print speed. The resulting figure may surprise you.

    The mind of the programmer will be indignant - well, how, and where is the total amount of code and print speed? There are tasks where it is necessary to write stupidly and a lot. And there are those where you have to read a lot, think, analyze and try, debug for a long time.

    Ok, let's go on the other side. All day the programmer thought, analyzed, tried. As a result, wrote 50 lines of code, and the problem is solved. Good, correct code, everything is checked and works. Spent 8 hours.

    Now the question is: how much time will he solve the exact same problem from another client? If you just take a ready-made solution, then 5 minutes, right? Well, while there the configurator opens, while the second, while it copies, etc. And if you re-write, pens? Half an hour? On the way, I will also do a review, on the machine, and the code will improve. 16 times faster.

    Well, to hell with copying the code. Another example. You, instead of giving the programmer one task, gave 10-20 - said: here's a tracker, choose any and do it. What will happen next?

    The programmer will choose. In the program code, the select statement works in a fraction of a millisecond (if not a very complicated condition), but the person is not a machine. For him, choice is a process that sometimes goes oooooochen slowly.

    Sometimes this process is reminiscent of reconnaissance by force: the programmer not only reads the title of the task and a detailed description, but also comments, and then climbs into the configurator to understand the context. Look, poke it - fu, say, this is a task about working clothes, there the devil’s leg breaks, in this UPP. No, let Kolya do. 15 minutes lost. Multiply by 10-20, how much will it? Till 5 o'clock?

    This is fine if the programmer is intelligent, and he has enough context to make a decision. And he, for example, a big fan of the Internet, and went to look for a ready-made solution - on the same Infostarte, or affiliate conference, or wherever. The selection time starts to grow at an awesome rate.

    Half day will choose, half day will work. Losses - 50%, i.e. it is sufficient for someone to correctly issue a task in order to double the output.

    Well, we do not have such a problem as a choice. It is chosen by the manager, or the main programmer, and he says - so, do this. No, I don’t want to, I can’t, Kolyan does a better job, the programmer answers. Do it, I said! - insists the main one.

    Further, on understanding of the main thing, the programmer sat down and does. Let not very effective, but it does. What does he do? Sometimes - yes, it solves the problem. Sometimes - sits and takes offense. Or looking for reasons not to do the task. For example, it prepares a list of questions, “without the solution of which it is pointless to begin.” Or the Internet tupit, because the world is not fair.

    Examples finish, although they are, in fact, dozens. It turns out that there are two states for the programmer - he writes the code or tupit. The word “tupit” was used without negative connotation, simply did not find a more appropriate verb from the noun “stupor”.

    Here and the main principle was drawn: look there, where. It makes little sense to start the growth of efficiency with the process of writing code, choosing another development environment (such as EDT), any kind of coding to speed up coding, etc. Consider that when a programmer writes code, it is effective. That's right when your fingers on the keyboard knocks, or draws a mouse with a form and adds details.

    The main time is lost where the programmer tupit, and not where he writes the code. I told several options.

    If you're a programmer, stop looking at writing code, look at downtime. If you are a programmer, look at yourself, at your downtime. This is the key to increasing development speed.

    We return to the question - what is the ideal time for solving a client's problem by a 1C programmer? The answer is obvious - zero. Well, okay, absolutely zero does not happen, let it be 5 minutes. How is such time achieved? You already understand: the issuance of a ready-made solution. The client came, said his task, and you immediately told him - a solution that you already have. I don’t know how much to take money, well, not in 5 minutes of a specialist’s work, that’s for sure. You can argue with this statement, but you can think about it. How many times have you solved identical tasks? What is the percentage of tasks that you solve for the first time, and have never heard of such a thing? I have a small practice - only 13 years old, but even with such a modest figure, I understand and see that I have already solved half of the problems.

    If you arm yourself with this approach, you will need quite a bit - to write abstract custom tools (instead of contextual, momentary govnokod) and store them somewhere. The first we discussed, the second has a lot of solutions.

    Then I went a bit out of the case. I do not urge you to give up everything and engage in ready-made solutions, I just wanted to show the ideal - acceleration is, in fact, not development, but sales tens and hundreds of times. Accordingly, the acceleration of the generation of income in the hundreds of times. For now let's do something smaller - we’ll double our speed.

    The principle you understand, then everything will be clear and simple. I will describe the actions that need to be included in the process of the department, with one goal - to reduce the time stupid, replacing it with programming.

    General discussion of incoming tasks

    Simple and trite. The duty officer, whom we discussed in the last article, gathers all programmers together every morning, and they look at new tasks together.

    The first thing to find out is whether someone has solved a similar problem. If you decide, then appoint him a consultant, or curator - no matter what to call. It is important that the performer knows who to contact.

    If no one has done this, then we simplify the criteria a bit - we are looking for those who have worked with this subsystem, or this document, or this platform mechanism. Well, you understand - if the task is about drawing a Scheduler, then anyone who has already managed to master this incredible mechanism will do. He will be a consultant.

    If the task is new at all, and is not familiar to anyone even close, then you need to choose a smoker - someone who will be the first to understand this topic. There are two key tasks: to solve the problem and develop competence. Next time to become a consultant for similar tasks. Of course, it is clear to everyone that it can take longer to get smoked than agreed with the client - this is normal, you invest in your team.

    Having a consultant is especially important for beginners. Even if you, in your competence development strategy, prohibit a newcomer from asking a curator, the very fact of its existence will provide tremendous moral support to the newcomer.

    Well, do not forget to give an assessment of the problem, in points - to play poker planning.

    Selection of the executor according to his competences

    Everything is simple. You made a choice - adjusted the slider between the development and increase of competencies. So choose the artist in accordance with your strategy.

    For example, you decide that beginners should solve unfamiliar tasks 30% of the time. In the system you already have a report that shows the percentage ratio - how many acquaintances, how many unfamiliar tasks he solved. Look at the numbers and decide at what point to issue a new, unfamiliar task.

    Having a consultant will remove the excess potential of importance from the task, and give the process elements of the game. It will be interesting for a beginner to deal with new mechanisms, because he will know about the presence of support, feel it. If you stipulate in advance the limits of application of this support, it will be generally wonderful: for example, you will give a beginner no more than one day to work independently, after which the consultant will decide.

    Choose the degree and format of support from the consultant yourself; there is nothing complicated here. If the newcomer is a completely new one, then it makes no sense to give him a link to an affiliate conference, a thick book on development and to cheer on "come on, get it clear, son." Such a big piece, he simply can not digest, choke, and you can lose an employee. He will not quit, but will receive a significant blow to its significance, it may become closed and inert.

    Unambiguous advice on the choice of "piece size" is not, because everything is strictly individual. One principle is universal: you need to follow this size. Of course, if you want efficiency to increase, not self-importance. Such a way of self-expression as setting unsolvable tasks is too widely used among 1C programmers to not talk about it.

    There are exceptions - employees who want to figure everything out on their own. They want so much that they absolutely refuse any help. This is their way of increasing significance - “I can figure it out myself,” and the wider the context into which he penetrates, the greater the reward — self-satisfaction. This is a useful quality, but it sometimes goes into mania - it is better to follow this, putting boundaries (in time, for example).

    If the task is urgent, or the client is important to you, then the experiments are turned off, and the one who understands the best sits on the task. Well, it's clear to everyone.

    Management of mutual assistance and its accounting

    Once there is a consultant, it would be nice to motivate him - to give a percentage of the hourly payment for solving the problem. The percentage depends on the degree of participation.

    Of course, it is necessary to make sure that the consultant does not become impudent and does not pull the blanket over himself when the task is assigned to the novice. Do not forget that our goal is not short-term gain, but long-term success.

    Well, for a newcomer need to follow. If you decide that he knows only the work with the Scheduler in this task, do not allow him to take over the rest of the task context - let the consultant tell him.

    Actually, there is nothing more to add.

    Task Status Management

    There was a separate article on this topic , I will not repeat everything. The article, by the way, was not particularly interested in 1snikov, but was liked by representatives of other races of developers - we are actively working with them now. This is me to the fact that in the world of 1C programming, all is not well with efficiency improvement methods.

    When you choose a person on duty, give him a link to the article above. The main thing is that he should understand, accept and execute - the status of tasks should be monitored.

    His every morning must begin with a ritual - managing task statuses. It is very simple and easy to automate. In the first window - new tasks that have not yet been accepted into the work. This is a discussion list with the team we reviewed above. The outcome of the discussion should be the devastation of this window.

    In the second window there are tasks accepted for work, but not having a contractor. It is also degraded after a general discussion. As a result of the discussion, both lists should be empty. The allowable time for a task to be in the “Not Accepted in Work” and “Not Performer” status is not more than one working day.

    If the task is not clear, and the customer needs clarification - the task, together with the list of questions, moves to the window / status “Required clarification” or “Sent for revision” - it doesn’t matter what you call it. Determinacy is important.

    After discussion (or in front of it), the duty officer checks the list of those sent for revision so that there are no overdue statuses. For example, to clarify the production is given three days. Three days have passed - you need to write to the customer, so as not to slow down. He, with a high probability, simply forgot to answer.

    During discussion with programmers, we look at the “In Work” window. It is ranked: everyone understands who is engaged in what task. Accordingly, there is a time for the task to be in the “In Work” status, with reference to the performer, and this time must be controlled.

    Trite - in order not to miss the time limit of knowledge for a beginner. If he was given a day for an independent decision, and these days have passed, then he, with a high probability, will not raise his hand and will not say that he has failed. It will be stupid to the last. We do not need this, so the banal control over the lifetime of the status will save from unnecessary losses, and the beginner from guilt for his stupidity.

    The last window - completed tasks that require acceptance from the customer. Here the principle is the same as in those sent for revision - we set a time limit, for example, three days, after which we begin to remind ourselves. Calm, confident, but persistent. I repeat, the customer could simply forget, he has enough of his affairs.

    The final

    All right, finish the case. The main figure in question is the intrinsic value of a unit of work, i.e. points I argued that it is possible to reduce this cost by half - to produce the same amount of work in half the time.

    Here is our schedule, according to one of the clients (the key one at the moment):

    As you can see, before the application of the case (ie, until April), the value of the score hung at about the same level. This means that, spending the same number of hours, we produced the same amount of result - an average of 1 point in 0.9 hours.

    In the first month of application of the case, the cost of the score dropped sharply, to 0.22 hours, which is about four times. The first month, of course, should be taken into account, but it cannot be trusted completely, because there was a sharp jump in the delivery of work - several “expensive” tasks were closed, which, due to the uncontrollable life cycle of tasks, dragged out like rubber.

    The second month is more indicative and correct. Firstly, there were no old tasks that would be closed - all tasks closed in May were born in the previous two months, i.e. during the application of the case. Secondly, the use of the case has settled down and has become a habit. The result is 0.33 hours for 1 point, which is three times better than it was before the case.

    Well, after that the figure began to hang out in the area of ​​the promised average - half of the original.

    Of course, positive results were obtained not only for this client, but in general for all the work. Including - internal, which we have quite a lot - more than for external customers.

    Here, for example, a graph of the total number of points produced:

    As you can see, before the case we averaged 400-500 points per month, and then this figure rose to 1,400 - an increase of 3 times.

    Both graphics were cut off in October, alas - we used to do tasks in the githaba, and then moved to Flowcon. The general schedule, from two sources, to draw laziness.

    It is interesting to understand the dependence of numbers. We, Oknosoft, try to engage in little services for customers, our priority is development. Before the application of the case, we had a problem - it took too much time for the customers, and there was very little development left.

    The use of the case allowed us to get out of this trap - we had, if not enough, but much more time for development. The result was not long in coming: we implemented several very important products for us.

    The first is the site of our business programming project (I will not give you a link, but again I will receive a letter with the subject “nmivan, let's go ...”). The key word is the site, because before we did only business applications running over the Internet. The site is made on the metadata.js platform, but the key success is not the site itself, and not the content, but the refinement of the platform and its components. Now on metadata.js you can also make sites. Moreover, the site contains the functionality of CMS and microservices.

    The second project, to which hands did not reach for a long time, was a paperless, i.e. shop floor dispatching functionality that works through the browser and with cool visualization (this is important for window production, for example). Work paperless through the browser - for example, using a barcode scanner connected to a TV set - will significantly expand and simplify the use of metadata.js solutions in production. Especially given the simplicity of working with external events in the code metadata.js - they can be caught anywhere, and not only in the active form, as in 1C.

    About the third project told - Flowcon.Life . For us, it is extremely important, because gave a bunch of useful tasks for the development of the platform. This is the first project for people, not for business.

    The fourth is hardly interesting for you - this is Flowcon, the configuration for 1C + a task / team / business management service.

    Well, a few more - either smaller and duller, or bigger and more secret. Total, let's say, six pieces.

    Is it a lot or a little? I will clarify - for two people. Who also work with clients on implementation projects, articles write, they quarrel a lot with each other and with the whole world, and even lazy to hell.

    Everything is relative. Six projects in 9 months - a lot or a little? If we recall that in the previous 6 months there was one project (parametric orders service), then the increase is significant - from 0.15 projects per month to 0.66 projects per month.

    For us, these projects are more valuable than the shipped watches, because they develop us - all that we put into the concept of Oknosoft. Platform, product line, sales channels, functionality of lottery solutions. Unlike the shipped watch, the only exhaust of which is money.

    Of course, projects are all different in complexity and effort, and it is difficult to judge only by their number. Therefore, we use several figures that I gave to understand my condition and dynamics as adequately as possible.

    Seeing a comprehensive assessment, we understand that the case works and brings real benefits to the business, moreover, very quickly. In our case, this case is not enough, because, as you understand, our priority is design.

    By the way, this is the very exotic scenario of using acceleration. We have not begun to sell more services to our customers, but have spent the vacant time on new products. I don’t know if we are right or not, time will tell - maybe the truth needs to be thought only about today? Like most franchises do.

    Well, talked about us, now about you. I am sure that you have any questions when reading the article. The topic of acceleration is not new for me, so I heard some of the questions you want to ask, and I will answer them immediately. I will group the questions.

    "I do not believe"

    Faith is not required. If you think you need faith, then something is wrong with you.

    Faith would be needed if I tried to sell you something - consulting, a book, a seminar or club membership. Then I would have the motive to cultivate your faith. But I do not sell you anything, so the question of faith is purely your personal, it is subjective and in no way connected with me.

    Well, in general, we have a case here, not a sect. We have a business, you too. Our business does not owe anything to yours, just like yours to ours. Moreover, he should not believe either.

    That's when one 1C programmer came up with how to speed up the holding of documents in half, and outlined this method, does the second 1C programmer need faith to try the same method? I do not exclude, of course, that someone is needed, but most do not.

    You put a copy of the database, make the proposed changes, look at the result. It turned out twice - cool. It turned out 1.5 times - cool. Has not changed or become worse - you write to the author. He will either try to help, and will make his method more abstract, or he will say “pf, I have what I did.”

    What is wrong with the second programmer 1C? Nothing. Even if the result is not, he will simply spend a little time - and, with benefit.

    With the case, the situation is exactly the same. As I said in the first article, the costs of its implementation are negligible. Most methods are generally implemented for free. Buy is not required, including from us.

    Why then faith?

    “And you show, prove”

    What could - showed. About “prove” - see above, about faith, the meaning is the same.

    Proof is a very laborious process, and its purpose is, in fact, a proof. I do not have such a goal, but I do not defend my dissertation. You can prove yourself if you try. I can't prove anything to you.

    I can't even prove that our case worked. Elementary - you will say that I drew graphics from the bald. And whatever the numbers, reports, statements from the account or from the tax, I did not cite, you can say - “pf, and where does the case in general?”.

    Do you understand? Proof, faith, etc. - this is your personal, internal, not having nothing to do with me. This stereotype is such an inner conviction, a feature of perception, and, most likely, a way of self-defense: I will not change anything and do it until they give me faith and prove it. It sounds clear and correct, but completely cuts off the possibility of change, for one simple reason - no one is going to prove anything to you.

    "It makes no sense, nothing happens"

    If you do not try - yes, it will not work. Also a way of self-defense. It is not clear only from whom.

    "Nonsense is all this, a kindergarten of some kind, it does not work"

    This is the most fun, in my opinion. Who are you trying to convince that it doesn't work? Me? So it works for me.

    If I wrote a case about how “it would be possible to work”, then the point in such statements would be to warn me that I am engaged in this nonsense.

    If you are trying to convince the rest of the readers, then your goals are not clear to me. I will not dispute their importance and value, I just do not understand. You care about the rest?

    If you are trying to convince yourself, then you are doing great.

    “We have a completely different problem - this and this”
    Excellent and very useful comments. I will surely take them into account in my work - it is important for me to know about what is bothering you and what is the problem.

    “The author should watch a movie / read a book / sleep / shut up / program”

    What the author has to do is irrelevant. For links and tips, of course, thanks.

    "It is necessary to solve completely different problems, but not indicated"

    If you remove the opposition, then - an excellent comment. It is necessary to solve all the problems, one way or another. The issue is priorities, and they are subjective for every business and person.

    Case is aimed at solving a specific problem in specific conditions. Recommendations are given with variations and options to accommodate differences. Turning relatively general recommendations into concrete ones is already your task as an implementer.

    Well, what I explain, if you are a 1C programmer, then you are only engaged in that you adapt the typical, general and universal to specific realities. It's the same here.

    “Speech only about multiple sale of solutions? Is that the point? ”

    No, not in this. Multiple sales - this is one of the examples to which efficiency can be reached, but not with this case. Consider this to be an example from another practice.

    It is important that you understand that 1C: Franchisee has a lot of options for improving business efficiency, and they can give a huge result tens and hundreds of times. This case is only one of the options, with a very modest result - twice.

    "In general, this is not the way to work, but this is how ..."

    Fine, only better as a separate article. I will carefully study and try to apply if the experiment is understandable in terms of time and inexpensive - as in this case.

    “Is it about projects or one-time work?”

    There is no fundamental difference. On the project there is a specificity - the presence of interrelated stages, within which - interrelated tasks. But the atomic essence remains the same - the task.

    Project tasks can always be turned into a stream. In a sense, they are even easier than one-time, because the context and interrelations are preserved - therefore, it is possible to get an even more impressive result on acceleration, since there is not only the exchange of experience between programmers, but also the accumulation of experience by solving related problems.

    By the way, we checked the design work for two months. Only the project was made "flat" - in the form of a list of tasks separated by certain milestones.

    "Speech on the development of one or more programmers?"

    The greatest effect is achieved if you apply the case to the team. I will explain in basic terms of systems thinking.

    And one programmer, and five, and one hundred is the system. The system has elements and links. In our case, the programmer is an element. Interaction, automation, motivation, goals, management are connections.

    To increase the overall performance of the system, it is possible to influence both the elements and the connections. It is very important to understand this is the key. Because everyone is trying to influence the elements - i.e. on programmers. Something to do with the programmer to make it work better. This is useful, but not very promising.

    Because both the elements and the connections have the ultimate performance. It is impossible to infinitely improve only a specific programmer, or only a motivation system, or only management. In any case, you will see a plateau, after a temporary increase in productivity.

    Roughly speaking, you have little leverage. If the programmer is one, then the limit of the system is equal to the limit of the element. If you go deeper, you can also imagine a programmer as a system and find connections in it, but the principle remains in place.

    If you look at your system as a set, i.e. a bunch of atomic elements - programmers - then you have almost no opportunity to increase productivity. If you see connections and begin to influence them, then you will discover a whole unknown world full of new opportunities.

    "What for?"

    If you are a business owner, the answer seems to be obvious. If you want growth, you need to change something.

    In business 1C: Franchisee, however, you can not change anything, because there is a "mother" who will do something for you. New products, markets, services. Then you can grow without changing anything - simply following the growth of the market, keeping your share in it.

    If you have enough growth rate of the market, then everything is in order. It is not enough for us, we want to overtake these rates. And creating new markets, and increasing their share of the old, and changing the structure of markets.

    If you remember (for some reason, I remember), 1C had such a position: do not compete with price, but quality. Quality is an internal characteristic, moreover, specifically of your business. The quality of your work does not depend on the "mother" and competitors.

    The whole case is about performance. Productivity is one of the indicators of the quality of the system. Everything, as the "mother" ordered.

    Also popular now: