January 29, 2015 at 12:09How to organize technical support in a web studio
In general, technical support is the pain and tears of the web development market. The most tearful complaints come to us with a request to pick up a project for completion.
The demand for technical support is now many times more than the supply. In the near future it will only grow, because many companies will cut bones and maintain their projects in a more or less lively state, without starting work in new directions.
Many declare technical support. Units can do systematically and cost-effectively. This text is more likely for studios (so that they can improve their processes or say how to improve ours). But it will be useful for those who are really interested in figuring out whether there is life after the release. We spent tens of hours discussing and arguing inside the studio to decide that our process should look something like this. And although we can quite flexibly configure some aspects of technical support (for example, work in the customer’s favorite task tracker), the framework we came to seems to me to be pretty good.
I will make a reservation that I will talk about technical support only from the point of view of programming. Design, creativity and content are also important, but it’s much easier to organize them (according to approximately the same scheme).
We do our projects according to the flexible scrum methodology. This means that in the process of work the client does not have to adhere to a thick and tedious TK, but you can add / remove / change any Wishlist right along the way. Pros: flexibility and an aim for the continuous development of the project immediately. Cons - constantly irrelevant documentation.
Thundercloud: old and new projects.
A TEAM of developers works on each project. This is important because after the project is launched, at least two to three people are involved in the code and can support it. In practice, this is much better than if one “irreplaceable” genius would do all the development.
Two things also help to fight against indispensability: strict coding standards and regular code review, which we carry out on our projects.
Temporary connection to the support of additional programmers who were not involved in the implementation of the project, I do not really like: there is a high risk of starting a progressive poisoning of the project. This phenomenon is a manifestation of the human factor and seems to be largely due to the Russian mentality. The desire to create in large strokes, and not painstakingly bring the details.
The reluctance of the new developer to get into someone else's code and his understanding that he is engaged in the project temporarily leads to crutches being stuck into the code. After the critical mass of crutches appears in the code, even the team that originally developed the project begins to consider the code a stranger and solves problems using new crutches. After some time, no one wants to deal with the project and everyone whines that he is a govnokod. It is possible to stop poisoning, but it is quite costly: often it is necessary to carry out deep coding and refactoring. Sometimes two to three times in a row. In general, the addition of new people to support, I think is justified only in three cases:
When planning the workload for 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 come from 16:00 to 18:00. This time is well suited for solving small and simple tasks. The flip side of the coin is the deployment to productive servers at the end of the working day, and in which case the whole night can hang on the product like that. On critical projects, we transfer the deployment or part of support to the morning. If on some day there are no technical support tasks, the programmer is engaged in the main project.
In between sprints (for example, when intensive testing is in progress and you can’t deal with the project), we can put more technical support, if appropriate. In the morning hours of developers we try not to pull (unless absolutely necessary). This is due to the fact that it is important that developers work in a thread and get as distracted and switched as little as possible. Reduce entropy. In addition, this allows the developer not to focus only on the support of the old one (many dislike it, but here I am harsh: any project that is more or less successful will certainly ask for development), but also try new (new technologies) on new projects.
So, we wedge small and urgent tasks in these two hours a day, from 16 to 18 (well, in fact, taking into account team work, it can be 4 and 6 hours, depending on whether the tasks are parallel). We launch large tasks that can be done in a quiet mode by sprints (at least 40 hours each) in the main hours. Sprinting is cheaper for the client (in terms of the cost of an hour) than urgent and urgent tasks that need to be done yesterday.
In most cases, the same manager is responsible for communication with a client on technical support, who worked on the project. Unfortunately, this is not always rational from the point of view of using expensive time managers (expensive - not only in terms of costs, but in the sense of TOC: managers very often become bottlenecks of a system, and an hour of downtime in a bottleneck is equal to the hour of downtime of the whole system).
If the manager is overloaded due to technical support (we call it “rainbow-tearing”) and the loss of transferring the project to another manager will pay off in principle, then I can change the manager. In many ways, support projects fall into the younger generation to pump their own strengths and recruit a client base. It’s extremely rare to change the manager if there is any conflict with the client on the project and you need to start the relationship from scratch.
Again, in very extremely rare cases of lack of managerial time, the programmer works directly with the client’s wording. However, we try to minimize such communications, as the vagueness of the wording is extremely unnerving for programmers, and the answers of programmers to customer questions without preliminary proofing can embarrass the client on the spot.
Click on the picture to go to the interactive map.
Everything else is rather exotic.
Next, I will simply and boringly go through each of these points and tell how it works for us, why it was done and in what situations it works poorly or not at all.
Here I have to tell you what projects come to our support. Only three types:
Once again I repeat that we selected such criteria absolutely consciously and cut off a lot of applications. If you are ready to work on supporting third-party projects and are able to competently organize this, you, I am sure, will have a huge queue. We are imprisoned for large projects and many small ones will unravel the whole conveyor for us.
So, about proactivity.
For projects in the active support phase, the project manager should take a proactive position. He is motivated to receive% of projects. For projects for which there is no work, we systematically go through several times a year and try to wake them up. This is good practice bearing fruit. Wakes up sleeping customers, usually an account manager. Not always a sleeping client needs to be woken up :)
This is an important point regarding liability. Responsibility is a double-edged thing. There are several principles here that we agree with the client. As a rule, the client will not argue with the principles themselves (they are clear and logical), however, they will try to find a loophole between the principles. The project manager, by the way, too.
Total, we reserve the right to clarify and reformulate the client’s statements in a more clear-cut. To clarify and add details. And even dissuade the client from some tasks (if in our opinion they will 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 development. And our tester will check for them. And on them we will pass the task.
Yes, but no. A clear desire, blind indulgence which will create kipish, panic and confusion in the studio and will make any technical support project unprofitable. To handle this, the project manager needs to do nothing, but be on the line all the time. And it is economically inexpedient and morally difficult. For all technical support projects, we have a unified customer task storage system. Task Manager. There they are clarified, evaluated and statuses are affixed. What it will be technically for the system is not so important (operational work can be organized both 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’s clear that anyway, in some cases, the client will write via Skype, to call or write 50 letters within an hour in the mail. The manager’s task here is: to politely ask to put tasks in the task manager. You can even refer to the fact that in Skype the task will be lost, please put it in the task manager. At first, this can annoy the client, but over time, the advantages of this approach will become clear to him.
Nevertheless, the discussion of tasks, especially large ones, is inefficient in the tracker. Skype, a phone with the obligatory fixation of the results of a conversation in specific tasks. Usually our project manager summarizes the conversation. The client’s task is to verify and validate the wording and give the green light to the 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 in an online shoe store at the time of a currency panic, 100 orders per hour began to arrive, and the client needed to urgently stop sales, because logistics could not cope. It is clear that in cases of force majeure we will give up and solve the problem by phone. Even on weekends and after hours. But we cannot afford to panic over every little thing. Almost all customers understand this, if they explain it.
For most technical support projects, payment is based on the time actually spent. The task of the manager is to give preliminary estimates of the complexity and find out from the client whether we are doing tasks or not. In the event that we begin to deviate from the assessment (for example, there was a feature in the project that does not allow us to complete the work on time), the responsibility of the manager is to warn the client, inform new forecasts about the estimates and clarify whether we are doing the tasks or not. There is no point in inflating the deadlines and estimates. the client feels this and will tell us this in a satisfaction survey.
Nevertheless, for some projects of the corporate sector, where there is a cumbersome budgeting procedure, this approach is not suitable: all estimates and budgets must be signed and approved in advance. In this case, our assessments will include the maximum number of risks that we can foresee for each of the tasks.
I note that work on time & material in practice is faster and cheaper for the client, however, it is possible only if the client trusts and is satisfied. This is also beneficial for us, because reduces the cost of management and bureaucracy (and the manager, I remind you, we have a bottleneck of the system).
On the issue of accurate grades: although there are good grading methods, accurate estimates do not exist. This idea is difficult to convey to the client and it is very easy to go into demagogy. I prefer not to get carried away with the client discussing this topic, but simply outline two schemes of work: with assessments that contain our risks and assessments where all the risks are borne by the client, and give a choice. In the end, we must understand that the client’s budgets are limited, and the client - that it makes no sense for us to work without profit.
If you are seriously interested in the question of accurate estimates - at the end of the article I’m there as far as links.
According to the scheme of work on finalized estimates, all the coding risks lie on our side. I note that we are not ready to serve any project according to such a scheme.
With the time + material scheme, essentially all the risks lie with the client. If there are many errors and their correction is exposed to the client, he will be unhappy and will tell you about it. As a rule, it is economically more profitable not to enter into a dispute and correct your mistakes at your own expense, without escalating the situation, even though the work schedule for the actual hours has been agreed upon. I adhere to correcting errors at our expense if:
The last paragraph provides an occasion for insinuations of both the customer and the developer, therefore, cannot be described formally. For example, if the reason for the error was the incompleteness of the problem statement - the responsibility for this lies with the client (since it is he who is responsible for accepting the final formulations). Moreover, this means that they did not take money from the client to complete the task in full.
If the joint is frankly ours, we take it and fix it without composting our brains. So in the end it’s cheaper.
Exception: very complex systems with a lot of dependencies. If you change the comma in the product card, some tricky import will break, which starts once a month. Here you either need code freeze + a full system test for each change (which is very expensive), or full code coverage with tests (which is also very very expensive), or humility that such situations are possible.
I note that for the scheme to work, it is necessary that disputes arise as rarely as possible. Otherwise, the client will be dissatisfied with the support or support will be unprofitable for the studio.
Another nuance - we do not bear responsibility for 3 persons (for example, hosting) or lost profits. This is usually perceived adequately.
In our staff contracts, we guarantee a reaction time of 24 working hours. In 97% of cases, this is a suitable option. I draw your attention to the fact that we are talking about the reaction time, and not about the readiness time of any task. This is all at the level of common sense, and there is no particular reason to require us to shove the foam into our mouth at 24 o'clock with foam.
Basically, the actual speed of work depends on how quickly the task gets to development. What it consists of:
0-8h for acceptance and clarification of the task. The manager is notified of the creation of a new task. Banal business etiquette and the principle of an empty boxrequires that all such requests be processed within 24 hours. Further, depending on the urgency, the task can either be postponed until the sprint is formed, or urgently put into operation, or planned in the plan of work for the programmer the next day. Or, if the wording is unclear, we begin work on clarifying the wording. Formally, here the manager has a loophole to turn on the fool and for a long, long time not to understand and clarify something. However, customers feel this and become extremely unhappy in such situations and will certainly tell you about it. It remains only to understand the causes and apply the control action.
8-16h, usually a day after the task fell to the project manager and all the wordings are clear, it falls into development. This is due to the fact that we plan what projects each programmer will do in the morning meetings (at 8:45) and then we try not to deviate from this plan. As a rule, the task from the client falls into the development plan the day after setting (but it happens that the same day).
16-24h in most cases, small tasks tasks are completed and shipped to the client in the first 8-16 hours. Another 8 hours is a reserve for aligning our workflow or testing.
For large and time-consuming tasks, either a sprint is formed, or a performance schedule, depending on their urgency and client priorities. It is absolutely unproductive to do 30-40 hour tasks in fits and starts for 2 hours a day.
It is clear that where force majeure, everything broke down and you need to quit and fix everything - we drop it and repair it. If the level of force majeure is above 3-5% of all tasks - this is an occasion to look for flaws in the organization of the project itself or our work on it.
We have two tariff networks:
The increase in cost is due to the fact that small and urgent tasks can break down the entire conveyor for us and put at risk the timelines for other projects. We try to minimize urgent tasks. Customers also do not like the double tariff, but they have a conscious choice. The task of the project manager is to offer the client this alternative.
This is the most important part of the technical support system. Without it, mutual latent discontent will accumulate, which will one day develop into a conflict. The web developer will always be to blame. Is always!
I note that in the long term, a client’s bout is almost inevitable (well, or I don’t know of cases where the client would have been completely satisfied with the 2-3-year result of the support, had no complaints and would not have looked at the side from time to time). So.
It’s quite right to do a review with a client in 2-3 months. Formally analyze the list of tasks and look at the causes of errors. These may be formulations, and in this case you must decide together how to improve your problem statement. These may be too frequent programming errors, and here you need to look for reasons on your side. Finally, the client may be unhappy that he was not dissuaded from any of his ideas and this led only to an extra waste of money.
You should systematically check whether the client is satisfied with the work with you. Meet in person, talk, discuss project prospects, client business prospects and his plans for the coming year. You should be especially careful when changing the manager on the client side. It is important to tell the client where you can meet him and where not, and why. It adds openness and manageability.
Without it, in the long run you will be merged.
Demand for technical support now far exceeds supply. Especially in times of crisis, many will seek to “patch up the site,” rather than start some serious work. Nevertheless, organizing the work competently, clearly and cost-effectively is VERY difficult here. First of all, because high and versatile competencies of managers and developers are required. Efficiency, multitasking and frequent switching. Many, many routines. And all this against the background of a highly conflicting atmosphere.
Click on the picture to go to the interactive map. All this is counterbalanced with the ability to calmly do new and interesting projects using new unknown technologies :) Perhaps I can only wish you good luck in finding a balance between creating a new one and supporting the old one!
The demand for technical support is now many times more than the supply. In the near future it will only grow, because many companies will cut bones and maintain their projects in a more or less lively state, without starting work in new directions.
Many declare technical support. Units can do systematically and cost-effectively. This text is more likely for studios (so that they can improve their processes or say how to improve ours). But it will be useful for those who are really interested in figuring out whether there is life after the release. We spent tens of hours discussing and arguing inside the studio to decide that our process should look something like this. And although we can quite flexibly configure some aspects of technical support (for example, work in the customer’s favorite task tracker), the framework we came to seems to me to be pretty good.
Domestic kitchen
I will make a reservation that I will talk about technical support only from the point of view of programming. Design, creativity and content are also important, but it’s much easier to organize them (according to approximately the same scheme).
We do our projects according to the flexible scrum methodology. This means that in the process of work the client does not have to adhere to a thick and tedious TK, but you can add / remove / change any Wishlist right along the way. Pros: flexibility and an aim for the continuous development of the project immediately. Cons - constantly irrelevant documentation.
Thundercloud: old and new projects.
A TEAM of developers works on each project. This is important because after the project is launched, at least two to three people are involved in the code and can support it. In practice, this is much better than if one “irreplaceable” genius would do all the development.
Two things also help to fight against indispensability: strict coding standards and regular code review, which we carry out on our projects.
Temporary connection to the support of additional programmers who were not involved in the implementation of the project, I do not really like: there is a high risk of starting a progressive poisoning of the project. This phenomenon is a manifestation of the human factor and seems to be largely due to the Russian mentality. The desire to create in large strokes, and not painstakingly bring the details.
The reluctance of the new developer to get into someone else's code and his understanding that he is engaged in the project temporarily leads to crutches being stuck into the code. After the critical mass of crutches appears in the code, even the team that originally developed the project begins to consider the code a stranger and solves problems using new crutches. After some time, no one wants to deal with the project and everyone whines that he is a govnokod. It is possible to stop poisoning, but it is quite costly: often it is necessary to carry out deep coding and refactoring. Sometimes two to three times in a row. In general, the addition of new people to support, I think is 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 beginners under the supervision of a curator.
- Very, very rarely (and at the risk of getting minuses for karma for this), but still: as a measure of educating an overly ambitious developer with the makings of a gourmet. I mean those rare people who are beginning to rant about any task that they are not interested in, all the technologies - well, all the code of others - even their own, which he wrote a week ago - is also outdated. He may well get himself ready for the next 2-3 months (or until he settles down or until it becomes clear that we will not work out) projects only for technical support (this is while his colleagues get new, interesting projects).
When planning the workload for 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 come from 16:00 to 18:00. This time is well suited for solving small and simple tasks. The flip side of the coin is the deployment to productive servers at the end of the working day, and in which case the whole night can hang on the product like that. On critical projects, we transfer the deployment or part of support to the morning. If on some day there are no technical support tasks, the programmer is engaged in the main project.
In between sprints (for example, when intensive testing is in progress and you can’t deal with the project), we can put more technical support, if appropriate. In the morning hours of developers we try not to pull (unless absolutely necessary). This is due to the fact that it is important that developers work in a thread and get as distracted and switched as little as possible. Reduce entropy. In addition, this allows the developer not to focus only on the support of the old one (many dislike it, but here I am harsh: any project that is more or less successful will certainly ask for development), but also try new (new technologies) on new projects.
So, we wedge small and urgent tasks in these two hours a day, from 16 to 18 (well, in fact, taking into account team work, it can be 4 and 6 hours, depending on whether the tasks are parallel). We launch large tasks that can be done in a quiet mode by sprints (at least 40 hours each) in the main hours. Sprinting is cheaper for the client (in terms of the cost of an hour) than urgent and urgent tasks that need to be done yesterday.
In most cases, the same manager is responsible for communication with a client on technical support, who worked on the project. Unfortunately, this is not always rational from the point of view of using expensive time managers (expensive - not only in terms of costs, but in the sense of TOC: managers very often become bottlenecks of a system, and an hour of downtime in a bottleneck is equal to the hour of downtime of the whole system).
If the manager is overloaded due to technical support (we call it “rainbow-tearing”) and the loss of transferring the project to another manager will pay off in principle, then I can change the manager. In many ways, support projects fall into the younger generation to pump their own strengths and recruit a client base. It’s extremely rare to change the manager if there is any conflict with the client on the project and you need to start the relationship from scratch.
Again, in very extremely rare cases of lack of managerial time, the programmer works directly with the client’s wording. However, we try to minimize such communications, as the vagueness of the wording is extremely unnerving for programmers, and the answers of programmers to customer questions without preliminary proofing can embarrass the client on the spot.
Click on the picture to go to the interactive map.
What ideally would like from us
- Receive proactive suggestions for improving the project.
- To set the task in any, even in the craziest wording. Understanding at a glance. Thinking "obvious." Analysis of the possible consequences of the implementation of the requested. Warnings about possible negative consequences and suggest more rational approaches. Sometimes - shut up with your wise analytics and do as they say, for a long time to explain why.
- Set a task through any convenient channel (skype, phone, mobile, SMS-ku). 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.
Next, I will simply and boringly go through each of these points and tell how it works for us, why it was done and in what situations it works poorly or not at all.
Proactive project improvement proposals
Here I have to tell you what projects come to our 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 fixed by contract. Support for commissioning (when the project manager is on a hot start and is ready to answer any question the client has), as a rule, this is three months. Warranty period (as a rule, this is a year) - within a year we are ready to correct any hidden defects found by the client that were not found at the start of the project. The fundamental differences between the first and second are that upon commissioning the project is located in the “RAM” of the manager and many issues are resolved easier and faster. In the warranty period, we fix free only obvious bugs. In disputed cases, we reserve the right for the client to justify 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 bill for the time spent on the diagnosis. Formally, this is honest, but we resort to such measures in isolated cases, because this inevitably creates a conflict situation. - Development of projects developed by us.
Projects that have been implemented in our company often stay with us for many years. Develop and evolve. Usually we add new features to sprints (from 40 hours). It’s more convenient and cheaper to do one large unit of work than 100,500 small-urgent tasks: manager’s time is saved, there are fewer risks to make mistakes, much less control is required, and the process runs more smoothly. However, urgent and minor tasks, when it is BURNING, the client should not accumulate (this is bad for his health). Therefore, such tasks can also be developed, but with an extra charge for urgency. - Projects that we did not do.
We very rarely take third-party projects to support. Many small projects do not meet the global goals and ideology of our company. Life through IMHO support, a more stable, but boring business. There is no drive or strain, or something. Therefore, we take third-party projects extremely rarely and reluctantly. The criteria here are (listed in order of priority):
- the project should be (or could potentially become) No. 1 or No. 2 in its niche. Or should he like us.
- The project code must be competent.
- the project has a sufficient scope of tasks.
- the client adequately understands our principles and limitations of technical support and fundamentally agrees with them.
Once again I repeat that we selected such criteria absolutely consciously and cut off a lot of applications. If you are ready to work on supporting third-party projects and are able to competently organize this, you, I am sure, will have a huge queue. We are imprisoned for large projects and many small ones will unravel the whole conveyor for us.
So, about proactivity.
For projects in the active support phase, the project manager should take a proactive position. He is motivated to receive% of projects. For projects for which there is no work, we systematically go through several times a year and try to wake them up. This is good practice bearing fruit. Wakes up sleeping customers, usually an account manager. Not always a sleeping client needs to be woken up :)
Set the task in any, even in the craziest wording
This is an important point regarding liability. Responsibility is a double-edged thing. There are several principles here that we agree with the client. As a rule, the client will not argue with the principles themselves (they are clear and logical), however, they will try to find a loophole between the principles. The project manager, by the way, too.
- Shit at the entrance - shit at the exit.
It’s clear here. A poorly posed task with a high degree of probability will be done incorrectly. - Without telepathy.
That is, in general, we believe that by default there is no telepathy. “It was obvious” or “I meant that it would be by itself”, unfortunately, not an argument.
I think this is the right principle. However, there is a flaw in it. This is a very big loophole for an unscrupulous project manager to pull money endlessly and do the same task. However, firstly, the client intuitively feels when he is milked, and secondly, he really does not like it, and he will tell you about it. And thirdly, you can implement a formal procedure for the analysis of flights in order to catch such insinuations.
But more on that later. - The received task should be analyzed in terms of feasibility, feasibility, 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 influence, suggesting more effective moves, foreseeing all the risks or evaluating the task. It is possible that instead of giving the task to work, the manager will name and ask questions. Or even dissuade the client from doing it. Yes, they will not pay us for what we dissuaded. And sometimes it’s very difficult to pick up arguments to dissuade. But so - karmically more correct. However, if our arguments do not help, we will have no choice but to shut up and do as requested :). - We understand that double interpretations cannot be avoided.
At the level of common sense, this is so. Again, there is a loophole for both the manager and the client - “turn on the fool”. But if you work systemically, then lovers of snooping through loopholes can be caught and punished, and a control action can be applied. - In some cases, the paid work of an analyst or programmer will be required to clarify the wording.
This mainly concerns large tasks or those where an experiment or drawing is needed. Or absolutely confusing productions and overt dyslexia.
Total, we reserve the right to clarify and reformulate the client’s statements in a more clear-cut. To clarify and add details. And even dissuade the client from some tasks (if in our opinion they will 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 development. And our tester will check for them. And on them we will pass the task.
I want to set tasks through any convenient channel (skype, phone, mobile, SMS). Any time of the day or night
Yes, but no. A clear desire, blind indulgence which will create kipish, panic and confusion in the studio and will make any technical support project unprofitable. To handle this, the project manager needs to do nothing, but be on the line all the time. And it is economically inexpedient and morally difficult. For all technical support projects, we have a unified customer task storage system. Task Manager. There they are clarified, evaluated and statuses are affixed. What it will be technically for the system is not so important (operational work can be organized both 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’s clear that anyway, in some cases, the client will write via Skype, to call or write 50 letters within an hour in the mail. The manager’s task here is: to politely ask to put tasks in the task manager. You can even refer to the fact that in Skype the task will be lost, please put it in the task manager. At first, this can annoy the client, but over time, the advantages of this approach will become clear to him.
Nevertheless, the discussion of tasks, especially large ones, is inefficient in the tracker. Skype, a phone with the obligatory fixation of the results of a conversation in specific tasks. Usually our project manager summarizes the conversation. The client’s task is to verify and validate the wording and give the green light to the 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 in an online shoe store at the time of a currency panic, 100 orders per hour began to arrive, and the client needed to urgently stop sales, because logistics could not cope. It is clear that in cases of force majeure we will give up and solve the problem by phone. Even on weekends and after hours. But we cannot afford to panic over every little thing. Almost all customers understand this, if they explain it.
Accurate estimates
For most technical support projects, payment is based on the time actually spent. The task of the manager is to give preliminary estimates of the complexity and find out from the client whether we are doing tasks or not. In the event that we begin to deviate from the assessment (for example, there was a feature in the project that does not allow us to complete the work on time), the responsibility of the manager is to warn the client, inform new forecasts about the estimates and clarify whether we are doing the tasks or not. There is no point in inflating the deadlines and estimates. the client feels this and will tell us this in a satisfaction survey.
Nevertheless, for some projects of the corporate sector, where there is a cumbersome budgeting procedure, this approach is not suitable: all estimates and budgets must be signed and approved in advance. In this case, our assessments will include the maximum number of risks that we can foresee for each of the tasks.
I note that work on time & material in practice is faster and cheaper for the client, however, it is possible only if the client trusts and is satisfied. This is also beneficial for us, because reduces the cost of management and bureaucracy (and the manager, I remind you, we have a bottleneck of the system).
On the issue of accurate grades: although there are good grading methods, accurate estimates do not exist. This idea is difficult to convey to the client and it is very easy to go into demagogy. I prefer not to get carried away with the client discussing this topic, but simply outline two schemes of work: with assessments that contain our risks and assessments where all the risks are borne by the client, and give a choice. In the end, we must understand that the client’s budgets are limited, and the client - that it makes no sense for us to work without profit.
If you are seriously interested in the question of accurate estimates - at the end of the article I’m there as far as links.
Responsibility for the done
According to the scheme of work on finalized estimates, all the coding risks lie on our side. I note that we are not ready to serve any project according to such a scheme.
With the time + material scheme, essentially all the risks lie with the client. If there are many errors and their correction is exposed to the client, he will be unhappy and will tell you about it. As a rule, it is economically more profitable not to enter into a dispute and correct your mistakes at your own expense, without escalating the situation, even though the work schedule for the actual hours has been agreed upon. I adhere to correcting errors at our expense if:
- support project;
- it is clear in steps how to reproduce the error;
- it is obvious to both parties that this is a development (implementation) error.
The last paragraph provides an occasion for insinuations of both the customer and the developer, therefore, cannot be described formally. For example, if the reason for the error was the incompleteness of the problem statement - the responsibility for this lies with the client (since it is he who is responsible for accepting the final formulations). Moreover, this means that they did not take money from the client to complete the task in full.
If the joint is frankly ours, we take it and fix it without composting our brains. So in the end it’s cheaper.
Exception: very complex systems with a lot of dependencies. If you change the comma in the product card, some tricky import will break, which starts once a month. Here you either need code freeze + a full system test for each change (which is very expensive), or full code coverage with tests (which is also very very expensive), or humility that such situations are possible.
I note that for the scheme to work, it is necessary that disputes arise as rarely as possible. Otherwise, the client will be dissatisfied with the support or support will be unprofitable for the studio.
Another nuance - we do not bear responsibility for 3 persons (for example, hosting) or lost profits. This is usually perceived adequately.
Promptness
In our staff contracts, we guarantee a reaction time of 24 working hours. In 97% of cases, this is a suitable option. I draw your attention to the fact that we are talking about the reaction time, and not about the readiness time of any task. This is all at the level of common sense, and there is no particular reason to require us to shove the foam into our mouth at 24 o'clock with foam.
Basically, the actual speed of work depends on how quickly the task gets to development. What it consists of:
0-8h for acceptance and clarification of the task. The manager is notified of the creation of a new task. Banal business etiquette and the principle of an empty boxrequires that all such requests be processed within 24 hours. Further, depending on the urgency, the task can either be postponed until the sprint is formed, or urgently put into operation, or planned in the plan of work for the programmer the next day. Or, if the wording is unclear, we begin work on clarifying the wording. Formally, here the manager has a loophole to turn on the fool and for a long, long time not to understand and clarify something. However, customers feel this and become extremely unhappy in such situations and will certainly tell you about it. It remains only to understand the causes and apply the control action.
8-16h, usually a day after the task fell to the project manager and all the wordings are clear, it falls into development. This is due to the fact that we plan what projects each programmer will do in the morning meetings (at 8:45) and then we try not to deviate from this plan. As a rule, the task from the client falls into the development plan the day after setting (but it happens that the same day).
16-24h in most cases, small tasks tasks are completed and shipped to the client in the first 8-16 hours. Another 8 hours is a reserve for aligning our workflow or testing.
For large and time-consuming tasks, either a sprint is formed, or a performance schedule, depending on their urgency and client priorities. It is absolutely unproductive to do 30-40 hour tasks in fits and starts for 2 hours a day.
It is clear that where force majeure, everything broke down and you need to quit and fix everything - we drop it and repair it. If the level of force majeure is above 3-5% of all tasks - this is an occasion to look for flaws in the organization of the project itself or our work on it.
Well, that would not be expensive
We have two tariff networks:
- Normal, for tasks, and which do not burn. They can be sprinted or done as part of our schedule.
- urgent (when “we drop everything, do it at any cost”), at a double rate.
The increase in cost is due to the fact that small and urgent tasks can break down the entire conveyor for us and put at risk the timelines for other projects. We try to minimize urgent tasks. Customers also do not like the double tariff, but they have a conscious choice. The task of the project manager is to offer the client this alternative.
The most important. Retrospectives. Debriefing
This is the most important part of the technical support system. Without it, mutual latent discontent will accumulate, which will one day develop into a conflict. The web developer will always be to blame. Is always!
I note that in the long term, a client’s bout is almost inevitable (well, or I don’t know of cases where the client would have been completely satisfied with the 2-3-year result of the support, had no complaints and would not have looked at the side from time to time). So.
It’s quite right to do a review with a client in 2-3 months. Formally analyze the list of tasks and look at the causes of errors. These may be formulations, and in this case you must decide together how to improve your problem statement. These may be too frequent programming errors, and here you need to look for reasons on your side. Finally, the client may be unhappy that he was not dissuaded from any of his ideas and this led only to an extra waste of money.
You should systematically check whether the client is satisfied with the work with you. Meet in person, talk, discuss project prospects, client business prospects and his plans for the coming year. You should be especially careful when changing the manager on the client side. It is important to tell the client where you can meet him and where not, and why. It adds openness and manageability.
Without it, in the long run you will be merged.
Total
Demand for technical support now far exceeds supply. Especially in times of crisis, many will seek to “patch up the site,” rather than start some serious work. Nevertheless, organizing the work competently, clearly and cost-effectively is VERY difficult here. First of all, because high and versatile competencies of managers and developers are required. Efficiency, multitasking and frequent switching. Many, many routines. And all this against the background of a highly conflicting atmosphere.
Click on the picture to go to the interactive map. All this is counterbalanced with the ability to calmly do new and interesting projects using new unknown technologies :) Perhaps I can only wish you good luck in finding a balance between creating a new one and supporting the old one!