“Spinning to pimpochka”: how to reduce the number of invalid bugs by half, and why technical support is a friend of the developer

Whatever application your work is related to and in whatever quality you are present in the process, sooner or later the moment will come when the user first comes to you and, blinking confidently, asks: why doesn't my pimp stick? To pimp pimpochka - you say, dying of tenderness (set! Uses!), - you must first twist the twist. By the tenth user, emotion will be reduced. By the fiftieth, you will probably get a couple of templates to answer the most popular questions. By the hundredth, you’ll hire a half-dozen students to the position of technical support engineers and breathe a sigh of relief - right up to the moment when one of them forms at your desktop with a question: but I got a user here and he doesn’t have a pimp - why? Coolie? What is the little twist?

Inhale. Exhale. Have a smoke. Hide the bodies and hire new students if the previous ones are already over. The era of technical support has come, and it is its representatives who will now be the main source of trouble during the developer's working day - but it is worth it. In the end, coexisting with a dozen or so experienced problem guides who get paid for it is much easier than with hundreds of angry users who pay you - and not at all for the problem. I’ll try to talk about how this coexistence can be facilitated without the need to hide bodies systematically.


My tips below are based on experience with cross-platform technical support (Parallels Desktop for Mac, Parallels Access, Parallels Mac Management) and company developers. Support for these solutions is divided into two levels: first-line operators answer primary, standard and, in fact, simple questions from users around the world. Specialists of this line are located in India and China and use the knowledge base to solve user issues , which, incidentally, can be used by any user on their own. The first line handles 96% of all calls. The second line employees are located in Moscow and deal with the rest of the applications, attracting product developers to solve the problems. The process of processing customer requests from Odin products focused on hosters and telecommunications companies is built in a slightly different way.

This post describes the interaction issues between developers and support and offers some tips for improving it.

Problem: how can you not know what?
So, the first and main point at which, in my experience, 99% of the interactions between development and technical support stumble: “Well, how can you not know what?”. You got a bug about pimpochka. You definitely remember that you personally spoke about the pimp at the training for the same damn technical support: “And now, dear colleagues, let me introduce you our latest pimp, made according to the latest trends in the industry! Our pimpochka allows you to pimp at a speed N times greater than the pimp of competitors, according to the PRTCL protocol. The security of data transmission is ensured by level 80 cryptography and personally by the system administrator Ivanov (he gave his word of honor). ”

28 slides, including a portrait of the system administrator Ivanov with an honest word. Have you tried? They tried: they drove two testers to death, measuring the comparative speed of pimp up to the fifth decimal place. And now look at the “do not pimp” bug, and a hand reaches out to call the head of these idiots and demand that they be immediately replaced by some other idiots who will know that for the PRTCL protocol to work, it is necessary that its driver is installed in the system. Because - well, how can you not know what ?!

Tip: all the instructions!
So: it is possible. If you knew the support engineer about all the intricacies of the PRTCL protocol, he probably would have sat in your place and would have received your salary. In the meantime, this is still not the case, the first thing that technical support from the development needs is that any lecture on the charms and subtleties of the product should be completed with an instruction like “So, colleagues, if you don’t have pimp: 1) twist, 2) check, please, have is there any such item in the list of “PRTCL driver”. ”

In this way, we reduced the percentage of invalid bugs from technical support from the initial 18% to 7% in just a month - instructions! Nobody likes to write them, nobody likes to read them, but it works: each component of the product is equipped with a brief instruction on what needs to be checked or obtained in a particular situation. Kernel developers love dumps and boot flags, each time new; If the complaint concerns the operation of the devices, immediately look in the drivers and collect such and such indicators, and also keep in mind the connection method and type of device. And go remember all this by heart, if you are a tech support engineer without saving instructions, it’s time after midnight, and an angry user is raging in the phone.

Problem: Good intentions and where they lead
Almost any area of ​​activity in our society suggests that pretending to be a little more professional than you are is extremely useful - at interviews, at meetings, in everyday communication. This is a fairly basic pattern of behavior - look at least for recommendations on writing a resume. But in some posts, this understandable human inclination, unfortunately, does not bring anything but trouble, and the technical support engineer is just such a case: a slightly misunderstood engineer can do such things on a user computer with a hand that you can’t rake the whole team of developers .

Tip: it’s better to redefine than to underestimate
It is infinitely important to remind both developers and support that the engineer of the latter is not almost a developer, only a little worse. This is a professional (ideally, of course), whose work consists not only of the technical part and requires not only technical skills. It can be a language, for example: for Parallels, operating in the international market, English is extremely important. In Russia, it is not so easy to find people who combine basic technical literacy with the ability to explain over the phone in pure English, like a pimp pimpochka. Nervous client. With the same, possibly non-native English. This may be the ability to simplify and explain. The ability to understand the simplified and described by a person who is in no way obliged to be an expert on at least general computer terminology. Build some assumptions and give advice on the material, from the quality of which any developer would cry for a long time. And, of course, to calm, tell, apologize and promise a bright future, even in those cases when you have just personally set the client bug to Wontfix status.

Problem: and then the galoshes disappear!
From all of the above, morality arises: it will be boring for the developer to communicate with technical support. You can talk about the originality and grace of the PRTCL protocol, and they will probably listen with gratitude, but in the end they will still require tedious instructions with a list of checkmarks. It is desirable that such checkmarks, the exposure of which is quite safe for the client. They will harass and tyrannize you with questions and clarifications, demanding that you acknowledge the right of the harassing ones to not know all this. And here you, the developer, cry out: where, where is the part about my rights and their responsibilities ?! Without panic, we just turn to her.

Tip: document THIS!
The main responsibility of the support engineer in relation to the company and to himself is to document. Everything that has not been documented before should be documented. All bugs must be blocked. All instructions must be written down, verified with you one more time just in case, and published. All your answers to all questions should be streamlined and saved. And here you have every right to say: hey, dear colleagues, why is engineer Masha asking me exactly the same question that engineer Petya asked the third day? Why did I get a bug on the little girl without checking for the presence of a driver in the system, as I definitely mentioned in the instructions? And then let the engineers Masha and Petya cry bitterly, their turn.

Bottom line: and this will also pass
Whatever turn it is to cry bitterly, remember: it will be better over time. Technical support engineers will accumulate enough documentation so as not to plague you with questions. The best of them will rush into the ground and turn into coaches to serve as an additional filter between you and beginners. You, in turn, will master the difficult ability to translate from programming to universal and pluck a free-floating thought to the state of an instruction of five points. And at one point at the corporate party, you will catch yourself telling the engineer Pete about the intricacies of the PRTCL protocol, and he will complain to you: “I'm talking about Friday evening, and he's talking about the hard drive partition!”, And you are completely understand each other.