How to organize technical support in web studios
In general, technical support is the pain and tears of the web development market. The most tearful complaints to us come with a request to take a project for finishing touch.
The demand for technical support is now many times more supply. In the near future, it will only grow, because Many companies will cut the cost and maintain their projects in a more or less alive state, without starting work in new directions.
')
Many declare technical support. Units can do systematically and profitably. This text is more for studios (so that they can improve their processes or tell us how to improve ours). But it will be useful to those who are really interested to find out whether there is life after release. We spent dozens of hours discussing and debating inside the studio to decide what our process should look like. And although we can quite flexibly configure some aspects of technical support (for example, to work in a customer's custom track tracker), the framework to which we have arrived, it seems to me, is quite good.
I will make a reservation that I will tell about technical support only from the point of view of programming. Design, creativity and content are also important, but they are much simpler to organize (in about the same way).
We do our projects according to the scrum flexible methodology. This means that in the course of work, the client does not have to adhere to a thick and tedious TK, but you can add / delete / change any Wishlist right on the fly. Pros: flexibility and scope for continuous development of the project immediately. Cons - constantly irrelevant documentation.
Thundercloud: old and new projects.
A team of developers is working on each project. This is important because after the launch of the project at least two or three people are involved in the code and can support it. In practice, this is much better than if the entire development would be done by one “irreplaceable” genius.
Two things also help to fight indispensability: strict coding standards and regular code review, which we carry out on our projects.
I don’t like a temporary connection to the support of additional programmers who did not participate in the project: the risk of launching a progressive poisoning of the project is high. This phenomenon is a manifestation of the human factor and it seems, largely due to the Russian mentality. The desire to create large strokes, and not painstakingly bring the details.
The reluctance of a new developer to climb into someone else's code and his understanding that he is engaged in a project temporarily means that crutches are stuck into the code. After the appearance of crutches in the code of a critical mass, even the team that originally developed the project starts to consider the code as someone else’s and solves problems with new crutches. After a while, no one wants to engage in the project and everyone is whining that he is a shit. It is possible to arrest the poisoning, but it is rather expensive: it is often required to conduct deep code and refactoring. Sometimes two or three times in a row. In general, adding new people to support I consider justified only in three cases:
When planning the load on the developers, we expect that their working day consists of two parts: work on the main project (laying 6 hours) and technical support (the remaining two hours). As a rule, technical support hours are from 16:00 to 18:00. This time is well suited for solving small and simple tasks. The reverse side of the medal - deploy to the productive servers occurs at the end of the working day, and if something happens all night on the productiv can hang like. On critical projects of a warm patch or part of a support, we transfer to the morning. If there are no technical support tasks on a certain day, the programmer deals with the main project.
In the intervals between sprints (for example, when intensive testing is underway and the project cannot be engaged in), we can provide more technical support, if appropriate. In the morning hours we try not to tug the developers (unless absolutely necessary). This is due to the fact that it is important that developers work in a stream and be distracted and switched as little as possible. Reduce entropy. In addition, it allows the developer not to get hung up only on the support of the old (many people dislike it, but here I am severe: any project that is a little bit successful will certainly ask for development), but also try new (new technologies) on new projects.
So, we put in small and urgent tasks at these two hours a day, from 16 to 18 (well, in fact, taking into account teamwork, this could be 4 and 6 hours, depending on whether the tasks are parallel). Large tasks that can be done in a quiet mode, we start the work with sprints (at least 40 hours), during the main hours. The work of sprints is cheaper for the client (in terms of cost per hour) than the urgent and urgent tasks that need to be done yesterday.
In most cases, the same manager is responsible for communicating with the client on technical support, as he worked on the project. Unfortunately, this is not always rational from the point of view of using the most expensive time of managers (expensive ones - not only in terms of costs, but in terms of TOC: managers very often become system bottlenecks, and the idle hour in the bottleneck is equal to the idle time of the entire system).
If a manager is overworked by technical support (we call it “tearing rainbows”) and the losses to transfer the project to another manager will pay off in principle - in this case I can change the manager. In many ways, projects on support get to the younger generation for pumping their own strength and recruiting a client base. We rarely change the manager if there is a conflict with the client on the project and you need to start the relationship from scratch.
Again, in very exceptionally rare cases of lack of managerial time, the programmer works directly with the client’s formulations. However, we try to minimize such communications, since the vagueness of the wording makes the programmers extremely nervous, and the answers of the programmers to the clients' questions without preliminary reading can embarrass the client completely.
Click on the image to go to the interactive map.
Everything else is rather exotic.
Then I’ll simply and boringly go through each of these points and tell you how it works with us, why it’s done so, and in what situations it doesn’t work well or doesn’t work at all.
Here I have to tell you which projects get us to support. Only three types:
I repeat once again that we selected such criteria absolutely deliberately and cut off a lot of applications. If you are ready to work on the support of third-party projects and will be able to competently organize it - you, I am sure, will form a huge queue. We are sharpened for large projects and many small ones will give us the entire conveyor.
So, about proactivity.
For projects in the active support phase, the project manager should take a proactive position. He is motivated in receiving% of projects. For projects for which there are no works, we systematically go through several times a year and try to wake them up. This is a good practice, bearing fruit. Waking sleeping clients, as a rule, account manager. Not always the sleeping client needs to wake up :)
This is an important point that concerns liability. Responsibility - a double-edged thing. There are several principles that we agree on with the client. As a rule, the client will not argue with the principles themselves (they are clear and logical), but will try to find a loophole between the principles. Project Manager, by the way, too.
In total, we reserve the right to clarify and reformulate the client’s productions into clearer ones. Refine and append details. And even to discourage the client from some tasks (if, in our opinion, they make the project worse). However, the client is responsible for the final wording. Those formulations that we have fixed one to one will be sent to the development. And our tester will check for them. And for them we will pass the task.
Yes, but no. Understandable desire, blind indulgence which will create kipish, panic and confusion in the studio and make any technical support project unprofitable. To handle this, the project manager needs to do nothing, but to be on the line all the time. And it is economically inexpedient and morally difficult. For all technical support projects we have a single client task storage system. Task Manager In the same place there is their specification, estimations and statuses are put down. What it will be technically for the system is not so important (operational work can be organized in Google Docs and in the Bitrix portal). The very first thing that is required for the manager and the client to get used to is to persistently but politely teach the client to write and respond to the task manager. It is clear that anyway, in some cases, the client will write on Skype, make phone calls or write 50 letters within an hour in the mail. The task of the manager is here: politely ask to assign tasks to the task manager. You can even refer to the fact that in Skype the task is lost, please put it in the task manager. At first, this may annoy the client, but over time, the advantages of this approach will become clear to him.
However, the discussion of tasks, especially large ones, is inefficient in the tracker. Skype, phone with the obligatory fixation of the results of the conversation in specific tasks. Usually the conversation is summarized by our project manager. The client's task is to verify and approve the correctness of the wording and give the go-ahead to work.
It is clear that there are situations when everything has fallen and you need to call and urgently resolve the issue. For example, we had a case when the online shoe store at the time of currency panic started arriving at 100 orders per hour, and the customer urgently needed to stop sales, because could not cope logistics. It is clear that in cases of force majeure we will drop everything and solve the problem by phone. Even on weekends and after hours. But we cannot afford to arrange a universal panic for every little thing. Almost all clients understand this, if they explain it.
For most technical support projects, the payment goes according to the time actually spent. The task of the manager is to give a preliminary assessment of the complexity and find out from the client whether we are doing the tasks or not. If we start to deviate from the assessment (for example, there was a feature of the project that does not allow us to finish the work on time), the manager’s responsibility is to warn the client, report new forecasts according to estimates and clarify whether we are doing the tasks or not. Inflate the timing and evaluation of the special sense is not, because the customer feels this and will give us that when he asks for satisfaction.
However, for some corporate sector projects, where there is a cumbersome budgeting procedure, this approach is not suitable: all evaluations and budgets must be signed and approved in advance. , , .
, time&material , . , .. ( , , ).
: , , . . , : , , , . , , — .
— .
, . , .
time+material . — . , , , , . , , :
, , . , — (.. ). , .
— , . .
: . — - , . code freeze + ( ), ( - ), , .
, — , . .
— 3- (, ) . .
24 . 97% . , , . , 24 .
, , . :
0-8h . . , . , — , , . , — . , - - . . .
8-16h , , . , , ( 8:45) . , ( , ).
16-24h 8-16 . 8 — .
, — , . 30-40 2 .
, , -, — . - 3-5% — .
:
, . . , . — .
. , . web-. Is always!
, ( , 2-3 , - ). So.
2-3 . . , , . , . , , - .
, . , , , . . , , . .
.
. « », - . , , . , . , . - . .
:)
, !
The demand for technical support is now many times more supply. In the near future, it will only grow, because Many companies will cut the cost and maintain their projects in a more or less alive state, without starting work in new directions.
')
Many declare technical support. Units can do systematically and profitably. This text is more for studios (so that they can improve their processes or tell us how to improve ours). But it will be useful to those who are really interested to find out whether there is life after release. We spent dozens of hours discussing and debating inside the studio to decide what our process should look like. And although we can quite flexibly configure some aspects of technical support (for example, to work in a customer's custom track tracker), the framework to which we have arrived, it seems to me, is quite good.
Internal kitchen
I will make a reservation that I will tell about technical support only from the point of view of programming. Design, creativity and content are also important, but they are much simpler to organize (in about the same way).
We do our projects according to the scrum flexible methodology. This means that in the course of work, the client does not have to adhere to a thick and tedious TK, but you can add / delete / change any Wishlist right on the fly. Pros: flexibility and scope for continuous development of the project immediately. Cons - constantly irrelevant documentation.
Thundercloud: old and new projects.
A team of developers is working on each project. This is important because after the launch of the project at least two or three people are involved in the code and can support it. In practice, this is much better than if the entire development would be done by one “irreplaceable” genius.
Two things also help to fight indispensability: strict coding standards and regular code review, which we carry out on our projects.
I don’t like a temporary connection to the support of additional programmers who did not participate in the project: the risk of launching a progressive poisoning of the project is high. This phenomenon is a manifestation of the human factor and it seems, largely due to the Russian mentality. The desire to create large strokes, and not painstakingly bring the details.
The reluctance of a new developer to climb into someone else's code and his understanding that he is engaged in a project temporarily means that crutches are stuck into the code. After the appearance of crutches in the code of a critical mass, even the team that originally developed the project starts to consider the code as someone else’s and solves problems with new crutches. After a while, no one wants to engage in the project and everyone is whining that he is a shit. It is possible to arrest the poisoning, but it is rather expensive: it is often required to conduct deep code and refactoring. Sometimes two or three times in a row. In general, adding new people to support I consider justified only in three cases:
- I need to introduce a new person to the project so that he will continue to work on it on an ongoing basis.
- For the development of newcomers under the supervision of a curator.
- Very, very rarely (and at the risk of getting minuses for it in karma), but still: as a measure of educating a too ambitious developer with the makings of a gourmet. I mean those rare people who are beginning to rant on any task that they are not interested in it, all the technologies — but%, all the other people's code — in general, but% even their own, which he wrote a week ago, is also outdated. He may well work for the next 2-3 months (or until he calms down or until it becomes clear that we are not working together) projects only for technical support (this is while his colleagues receive new, interesting projects).
When planning the load on the developers, we expect that their working day consists of two parts: work on the main project (laying 6 hours) and technical support (the remaining two hours). As a rule, technical support hours are from 16:00 to 18:00. This time is well suited for solving small and simple tasks. The reverse side of the medal - deploy to the productive servers occurs at the end of the working day, and if something happens all night on the productiv can hang like. On critical projects of a warm patch or part of a support, we transfer to the morning. If there are no technical support tasks on a certain day, the programmer deals with the main project.
In the intervals between sprints (for example, when intensive testing is underway and the project cannot be engaged in), we can provide more technical support, if appropriate. In the morning hours we try not to tug the developers (unless absolutely necessary). This is due to the fact that it is important that developers work in a stream and be distracted and switched as little as possible. Reduce entropy. In addition, it allows the developer not to get hung up only on the support of the old (many people dislike it, but here I am severe: any project that is a little bit successful will certainly ask for development), but also try new (new technologies) on new projects.
So, we put in small and urgent tasks at these two hours a day, from 16 to 18 (well, in fact, taking into account teamwork, this could be 4 and 6 hours, depending on whether the tasks are parallel). Large tasks that can be done in a quiet mode, we start the work with sprints (at least 40 hours), during the main hours. The work of sprints is cheaper for the client (in terms of cost per hour) than the urgent and urgent tasks that need to be done yesterday.
In most cases, the same manager is responsible for communicating with the client on technical support, as he worked on the project. Unfortunately, this is not always rational from the point of view of using the most expensive time of managers (expensive ones - not only in terms of costs, but in terms of TOC: managers very often become system bottlenecks, and the idle hour in the bottleneck is equal to the idle time of the entire system).
If a manager is overworked by technical support (we call it “tearing rainbows”) and the losses to transfer the project to another manager will pay off in principle - in this case I can change the manager. In many ways, projects on support get to the younger generation for pumping their own strength and recruiting a client base. We rarely change the manager if there is a conflict with the client on the project and you need to start the relationship from scratch.
Again, in very exceptionally rare cases of lack of managerial time, the programmer works directly with the client’s formulations. However, we try to minimize such communications, since the vagueness of the wording makes the programmers extremely nervous, and the answers of the programmers to the clients' questions without preliminary reading can embarrass the client completely.
Click on the image to go to the interactive map.
What would ideally like from us
- Get proactive suggestions for improving the project.
- Set the task in any, even in the most insane wording. Understanding with a half-word. Pondering the "obvious." Analysis of the possible consequences of the implementation of the requested. Warnings about possible negative consequences and suggestion of more rational approaches. Sometimes - to shut up with his wise analytics and do, as they said, for a long time to explain why.
- Set a task through any convenient channel (Skype, phone, voice mail, SMS). At any time of the day or night.
- Accurate estimates.
- Responsibility for what has been done.
- Efficiency.
- Well, that would not be expensive.
Everything else is rather exotic.
Then I’ll simply and boringly go through each of these points and tell you how it works with us, why it’s done so, and in what situations it doesn’t work well or doesn’t work at all.
Proactive project improvement suggestions
Here I have to tell you which projects get us to support. Only three types:
- Free technical support for our projects.
These are all projects at the commissioning stage and during the warranty period. This is enshrined in the contract. Support for commissioning (when the project manager is on a hot start and is ready to answer any emerging question from the client), as a rule, it is three months. The warranty period (usually a year) - during the year we are ready to fix any hidden defects found by the client that were not detected when the project was launched. The principal differences between the first and second is that when commissioned, the project is in the manager’s “operational memory” and many issues are resolved easier and faster. In the warranty period, we fix only the obvious bugs for free. In cases of dispute, we reserve the right for the client to explain to us why this is a bug. If it takes time to diagnose and in fact the bug was not a bug - we also reserve the right to invoice for the time spent on diagnostics. Formally, this is fair, but we resort to such measures in isolated cases, since This creates an inevitable conflict situation. - Development of projects developed by us.
Projects that have been implemented in our company often remain with us for many years. Develop and evolve. Usually we add new features to sprints (from 40 hours). It is more convenient and cheaper for us to do one large block of work than 100,500 small-urgent tasks: the manager saves time, less risk to make mistakes, much less control is required, and the process goes more smoothly. However, urgent and minor tasks, when ON, the client should not accumulate (this is bad for his health). Therefore, such tasks can also get on the development, but with a margin for urgency. - Projects that we did not.
We very rarely take on the support of third-party projects. Many small projects do not correspond to the global goals and ideology of our company. Life through IMHO support, more stable, but boring business. No drive and tear, or something. Therefore, third-party projects are extremely rare and reluctant to take. The criteria here are (list in order of priority):
- the project must be (or potentially become) No. 1 or No. 2 in its niche. Or he should like us.
- project code must be literate.
- The project has a sufficient amount of tasks.
- the client adequately understands our principles and limitations of technical support and agrees in principle with them.
I repeat once again that we selected such criteria absolutely deliberately and cut off a lot of applications. If you are ready to work on the support of third-party projects and will be able to competently organize it - you, I am sure, will form a huge queue. We are sharpened for large projects and many small ones will give us the entire conveyor.
So, about proactivity.
For projects in the active support phase, the project manager should take a proactive position. He is motivated in receiving% of projects. For projects for which there are no works, we systematically go through several times a year and try to wake them up. This is a good practice, bearing fruit. Waking sleeping clients, as a rule, account manager. Not always the sleeping client needs to wake up :)
To set a task in any, even in the craziest formulation
This is an important point that concerns liability. Responsibility - a double-edged thing. There are several principles that we agree on with the client. As a rule, the client will not argue with the principles themselves (they are clear and logical), but will try to find a loophole between the principles. Project Manager, by the way, too.
- Shit at the entrance - shit at the exit.
This is understandable. A poorly assigned task with a high degree of probability will be done incorrectly. - Without telepathy.
That is, we generally believe that there is no telepathy by default. “It was obvious,” or “I meant that it would be by itself,” unfortunately, not an argument.
I think this is the right principle. However, it has a flaw. This is a very big loophole for an unscrupulous project manager to endlessly pull money and do the same task. However, firstly, the client intuitively feels when they are milking him, secondly - he does not like it very much, and he will tell you about it. And thirdly, you can implement a formal procedure for debriefing, to catch such insinuations.
But more about that later. - The resulting task must be analyzed in terms of feasibility, appropriateness, completeness and resources.
Thundercloud: customer and studio manager.
Probably, 70-80% of the manager’s working time is spent on entering the task, clarifying the wording, understanding what it can affect, suggesting more effective moves, envisaging all risks or evaluating the task. It is possible that instead of giving the task to work, the manager will call and ask questions. Or even discourage the client from doing it. Yes, we will not pay for what we talked. And sometimes it is very difficult to find arguments to dissuade. But so - karmically correct. However, if our arguments do not help, we will have no choice but to shut up and do as we were asked :). - We understand that double interpretations cannot be avoided.
At the level of common sense it is. Again, there is a loophole for both the manager and the client - “turn on the fool”. But if you work systematically, then lovers of diving into the loopholes can be caught and punished, apply the control action. - In some cases, to clarify the wording will require a paid job analyst or programmer.
This mainly concerns large tasks or those that need experiment or drawing. Or quite confusing productions and obvious dyslexia.
In total, we reserve the right to clarify and reformulate the client’s productions into clearer ones. Refine and append details. And even to discourage the client from some tasks (if, in our opinion, they make the project worse). However, the client is responsible for the final wording. Those formulations that we have fixed one to one will be sent to the development. And our tester will check for them. And for them we will pass the task.
I want to set tasks through any convenient channel (Skype, telephone, voice mail, SMS). At any time of the day or night
Yes, but no. Understandable desire, blind indulgence which will create kipish, panic and confusion in the studio and make any technical support project unprofitable. To handle this, the project manager needs to do nothing, but to be on the line all the time. And it is economically inexpedient and morally difficult. For all technical support projects we have a single client task storage system. Task Manager In the same place there is their specification, estimations and statuses are put down. What it will be technically for the system is not so important (operational work can be organized in Google Docs and in the Bitrix portal). The very first thing that is required for the manager and the client to get used to is to persistently but politely teach the client to write and respond to the task manager. It is clear that anyway, in some cases, the client will write on Skype, make phone calls or write 50 letters within an hour in the mail. The task of the manager is here: politely ask to assign tasks to the task manager. You can even refer to the fact that in Skype the task is lost, please put it in the task manager. At first, this may annoy the client, but over time, the advantages of this approach will become clear to him.
However, the discussion of tasks, especially large ones, is inefficient in the tracker. Skype, phone with the obligatory fixation of the results of the conversation in specific tasks. Usually the conversation is summarized by our project manager. The client's task is to verify and approve the correctness of the wording and give the go-ahead to work.
It is clear that there are situations when everything has fallen and you need to call and urgently resolve the issue. For example, we had a case when the online shoe store at the time of currency panic started arriving at 100 orders per hour, and the customer urgently needed to stop sales, because could not cope logistics. It is clear that in cases of force majeure we will drop everything and solve the problem by phone. Even on weekends and after hours. But we cannot afford to arrange a universal panic for every little thing. Almost all clients understand this, if they explain it.
Accurate estimates
For most technical support projects, the payment goes according to the time actually spent. The task of the manager is to give a preliminary assessment of the complexity and find out from the client whether we are doing the tasks or not. If we start to deviate from the assessment (for example, there was a feature of the project that does not allow us to finish the work on time), the manager’s responsibility is to warn the client, report new forecasts according to estimates and clarify whether we are doing the tasks or not. Inflate the timing and evaluation of the special sense is not, because the customer feels this and will give us that when he asks for satisfaction.
However, for some corporate sector projects, where there is a cumbersome budgeting procedure, this approach is not suitable: all evaluations and budgets must be signed and approved in advance. , , .
, time&material , . , .. ( , , ).
: , , . . , : , , , . , , — .
— .
, . , .
time+material . — . , , , , . , , :
- ;
- , ;
- , — ().
, , . , — (.. ). , .
— , . .
: . — - , . code freeze + ( ), ( - ), , .
, — , . .
— 3- (, ) . .
24 . 97% . , , . , 24 .
, , . :
0-8h . . , . , — , , . , — . , - - . . .
8-16h , , . , , ( 8:45) . , ( , ).
16-24h 8-16 . 8 — .
, — , . 30-40 2 .
, , -, — . - 3-5% — .
:
- , , . .
- ( « , »), .
, . . , . — .
. .
. , . web-. Is always!
, ( , 2-3 , - ). So.
2-3 . . , , . , . , , - .
, . , , , . . , , . .
.
Total
. « », - . , , . , . , . - . .
:)
, !
What to read
Source: https://habr.com/ru/post/283870/
All Articles