Web studio optimization. Application of the theory of restrictions in the production of sites



    In the article “12 thousand rubles per site. Is there a business outside the Moscow Ring Road? ”I wrote about our approach to developing sites based on technology developed within the company. At the time of this writing, we were producing turnkey 24 sites per month. This is more than one site per day by a team of 8 people.

    After a story on our technology on the hub, the number of requests for website development has increased several times. In March 2012 alone, about 60 commercial offers were put up, and most of them turned into contracts.

    And then our production cracked at the seams. Almost immediately, applications began to queue, managers began to get confused in projects, designers began to ask for a vacation. The situation was becoming really tense ...

    Problem awareness


    The first thing we had to do was temporarily increase the promised development period from 5 to 8, and sometimes 10 days. We just had no choice. Clients were sympathetic and were ready to wait. But we were not ready to wait until the situation became even more tense. It was necessary to do something. For all indicators (and standards) we had to cope, but this did not happen.

    We did not want to refuse customers. We could not expand the staff either. It takes time. We needed to increase our own effectiveness, find hidden resources. We all calculated, they should be! In addition, it was urgent to return a calm atmosphere in the team.

    Continuous improvement process


    Let's look at website development as a production. Production is a chain where all links are interconnected. In our case, the links in the chain are: sales manager, executive manager, designer, content manager, programmer, tester. I do not paint the functions of each, I think they are so understandable.



    One link accepts applications, the other accepts a project for work, design, assembly, refinement ... another is engaged in testing and calculation, and so on. If at least one link fails, then the whole process is slowed down or stopped. And there is an important point. What determines the strength of a chain? Naturally, the weakest link. It should be noted that the “most” weak link in the chain is one, and this is a key point in the approach to production management. This approach in the industrial world is described by Theory of constraints.

    I will explain in more detail. Let's say your role in the production chain is to assemble a site from a finished design. You are not the weakest link. As a result of your own genius and ability to work, you began to collect 2 times more. How much did you increase the performance of the entire chain? That's right, no matter how much. Absolutely no matter how much. Most local improvements do not help the performance of the entire team. This means that “the more the better” is not the path that will lead to an increase in the overall efficiency of the chain.

    If we want to strengthen overall performance, the first step is to find and strengthen the weakest link. If the weakest link is politics or technology, we must accordingly change policy or technology.

    In our case, at the time of realizing the problem, the weak point was the sales manager. Its functions included not only the sale of projects and the conclusion of contracts, but also the conduct of certain projects. We completely freed him from conducting projects, and the problems with timely response to applications were gone. It was the most logical and simplest.

    We have strengthened the link, and it is no longer weak. Now you need to go back to the first step and restart your search for the weak link. This is a continuous improvement process that we have been following (and are following) in search of the team’s hidden resources.

    We synchronize work speed, balance production


    You need to understand that when we have determined and increased the throughput of a weak link (if it still remains weak), it is necessary to subordinate all other processes of the speed of this link. For example, it doesn’t make sense for the designer to draw 2 designs per day, if we can issue no more than one site daily at the assembly. The client is interested in the final result within the declared time period, and not in the intermediate stage, done ahead of time.

    So, by the forces of our chain, we, as before, had to ensure the creation of the site in 5 days. Technologically, we learned how to do this, but ... now, on some projects, our production chain began to look not as favorable as before:



    Projects began to drag out, and the managers had many reasons for this. But there can be many reasons. The root cause, as a rule, is one.

    Parallelizing projects reduces the speed of the entire chain and increases costs.

    Our bottlenecks became project managers at the stage of formation of TK. We also began to observe how at the development stage some of our projects were stretched to 2 months, while the real term was 5-8 days. It turned out that managers had to take new projects without releasing the current ones. By that time, the number of projects "in work" per manager exceeded two dozen.

    Let's look at a simple example to see how parallelizing projects affects productivity and costs. Suppose the manager has several projects that he serves sequentially (parses materials from the customer and generates a task). For each project for this operation, we can spend no more than one working day (according to our standards) in order to meet the deadline. If the manager will switch from project to project, what will it lead to? The picture clearly shows that one switch to the next project, without completing the previous one, increases its length by 2 times.

    There was a clear understanding that jumping from task to task has the greatest negative effect on the timely execution of projects. Everyone suffers from this. It does not matter in what form this jumping takes place. It can be meetings, “fires”, loss of information, inconsistency of actions - exactly what began with us after a multiple increase in requests for the creation of the site. We realized that starting up everything at once, we jeopardize all projects and significantly increase our own costs.

    Obviously, it was necessary to take measures in order to limit the number of projects per manager and achieve a reduction in the time to release one project to the promised customers 5 days.

    5 projects per manager

    The number of projects per manager is determined by the duration of the project’s release cycle and the time that the manager can spend on one project. Project release time is 5 days, and the time that the manager can spend on the project is 5 hours (with a margin of one working day). Accordingly, the manager should have no more than 5-7 projects in his work.



    5 days for the project

    Now you need to provide the manager with a guaranteed opportunity to complete projects in 5 days. To do this, you need to understand that in addition to a large number of projects in the work, it is difficult to fulfill these obligations.

    Not surprisingly, one of the main problems was the layout of projects on the client’s hosting. The client doesn’t remember the passwords or they don’t work, the domain and hosting are not connected, the “exotic host” cannot make friends with our management system ... there were very different problems. Not having time to deal with problems, I had to switch to new projects.

    The second problem was the lack of materials for the preparation of texts and design. During operation, it surfaced that there was no part of the materials. Their receipt turned out to be just as difficult and extended the execution time of projects.

    Everything else is insignificant in comparison with the first two.

    As a result of the analysis of the situation, we make decisions not to put the project into operation until we are sure that we can fulfill our obligations on time. For this, the status of the project is “information collection”, which means that they are involved in the project, but it is not yet in work. This is provided for in the contract and inform the client when we start work (sending notifications through the system).

    This is how the chain looks now:



    These are interim solutions so far. They have not passed the proper test of time. But, for the most part of the projects, we returned the promised 5 days to our customers and restored calm to the team. The productivity of the central office (main) has so far grown to 36 projects per month (according to the results of May 2012).

    Everyone benefits from such a scheme. Customers who have provided all materials on time receive the result at the promised time. Customers who are not in a hurry are at a preliminary stage (collecting information), knowing that work has not yet begun. Accordingly, they do not claim a delay in the deadlines. Production works in a quiet mode (compared to how it started) on projects where there is a minimum of uncertainty. Managers have the opportunity to focus on the delivery of projects on time.

    Here are some simple observations regarding the current optimization of our streaming production. I hope someone will be helpful.

    Summary


    Briefly summarizes the approach to continuously improve streaming production.
    1. The first step is to find a system limitation. What currently sets its maximum performance?
    2. The second step is to optimize the system constraint. Get the most out of the narrow link without additional investment.
    3. The third step is to subordinate the speed of all production to the speed of work of a narrow link.
    4. The fourth step is to expand the narrow link.
    5. Step Five - Return to Step One, but Remember Inertia

    These are five steps from Goldratt 's theory of constraints , which has been successfully applied in industrial production. Why not apply it in the production of sites?

    Continuing the theme of improving production efficiency, we are now collecting detailed statistics on all operations on the conveyor. We plan to use this in further analysis and the search for bottlenecks.

    Let me remind you that the technological features of our production were described earlier in the article “12 thousand rubles per site. Is there a business outside Moscow? " . She answers many questions.

    PS There were requests to write about the "mortality" of low-cost projects, their real benefits to customers, etc. For now, we collect feedback and statistics. Soon there will be a little analysis.

    Vasily Churanov and web-canape.ru team

    Also popular now: