Krutelochka to Pimp: how to reduce the number of non-valid bugs by half, and why technical support is a friend of the developer

Whatever application your work is associated with and in whatever capacity you are present in the process, sooner or later the moment will come when a user will appear to you for the first time and, trustingly blinking, will ask: why doesn’t I have a pimp? In order for a pimple to pimpal, you say, dying of emotion (set! Use!), You first need to twist the cruel. By the tenth user of affection diminished. By the fiftieth, you will probably have a couple of templates for answering the most popular questions. By the hundredth, you hire half a dozen students for the position of technical support engineers and breathe a sigh of relief - just until the moment when one of them comes up on your desktop with a question: does the user come to me and he has a pimp? - why? Prank? What krutelochka?

Inhale. Exhale Smoke. Hide the body and hire new students, if the previous ones have already run out. The era of technical support has begun, and it is their representatives who will now be the main source of trouble during the developer’s working day - but it is worth it. In the end, it is much easier to coexist with a dozen or so experienced problem guides who are paid for it than with hundreds of angry users who pay you — and not at all for problems. I will try to tell how this coexistence can be facilitated without the need to systematically hide bodies.


My tips below are based on the interaction between the technical support service of cross-platform products (Parallels Desktop for Mac, Parallels Access, Parallels Mac Management ) and the company's developers. Support for these solutions is divided into two levels: first-line operators respond to the primary, typical and, in fact, simple questions from users around the world. Specialists of this line are located in India and China and for solving the questions of users they use the knowledge base , to which, by the way, any user can resort independently. The first line processes 96% of all hits. Employees of the second line are located in Moscow and deal with the rest of the applications, attracting product developers to solve problems. The processing of customer calls to Odin products, hosters and telecommunications companies, is built a little differently.
')
This post describes the problems of interaction between developers and support service 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, stumbles 99% of the interactions between development and technical support: “well, how can you not know what?”. You got a bug about pimp. You just remember that you personally told about the pimp at the training for the same cursed technical support: “And now, dear colleagues, let me introduce to you our newest pimp, made according to the latest industry trends! Our pimp allows you to pimpat at a speed N times greater than competitors pimp under the PRTCL protocol. The security of data transmission is ensured by level 80 crypto-encryption and personally by sysadmin Ivanov (I gave my word of honor) “.

28 slides, including a portrait of a sysadmin Ivanov with an honest word. Did you try? Tried: two testers were driven to death, measuring the comparative speed of pimpania with an accuracy of five decimal places. And now look at the bug "does not use it," and the hand is drawn to call the chief of these idiots and demand to replace them immediately with any other idiots who will know that for the PRTCL protocol to work, it is necessary that the driver be installed in the system. Because - well, how can you not know that?

Tip: all instructions!
So: you can. If you knew the support engineer about all the intricacies of the PRTCL protocol, he would probably be sitting at your place and get your salary. In the meantime, this is still not the case; the first thing that technical support needs from development is that any lecture on the charms and intricacies of the product ends with instructions like “So, colleagues, if you don’t have: 1), 2) check, please, have Is there such a point “PRTCL driver” in the list. ”

This is how we reduced the percentage of invalid bugs from technical support from the original 18% to 7% in just one month - instructions! No one likes to write them, no one 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 given situation. Kernel developers love dumps and boot flags, new ones every time; if the complaint concerns the operation of the devices, immediately look into the drivers and collect such and such indicators, and also keep in mind the connection method and the type of device. And go and remember all this by heart, if you are a technical support engineer without saving instructions, it's past midnight, and an angry user is raging in the receiver.

Problem: good intentions and where they lead
Virtually any area of ​​activity in our society suggests that it is extremely useful to pretend to be a bit more professional than you are - at interviews, at meetings, in everyday communication. This is a fairly basic pattern of behavior - look at least recommendations for writing a resume. But in some positions, this understandable human inclination, alas, does not bring anything but trouble, and a technical support engineer is just such a case: a slightly misunderstood engineer with one hand movement can mess things up on a user’s computer that you can’t rake out .

Advice: it is better to re-clarify than to clarify
It is infinitely important to remind both the developers and the 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 does not consist solely of the technical part and requires not only technical skills. This may be the language, for example: for Parallels, operating on 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 by telephone in pure English, like pimpochka. Nervous customer. With the same, perhaps 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 at least in computer-wide terminology. Build some assumptions and give advice on the material, 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 where you have just personally set the Wontfix status to the client bug.

Problem: and then the galoshes disappear!
From all of the above, morality arises: it will be boring for a developer to communicate with technical support. You can talk about the originality and elegance of the PRTCL protocol, and they will probably listen to you with gratitude, but in the end they will still require tedious instructions with a list of checkmarks. It is desirable that such checkboxes, the display of which is quite safe for the client. You will be harassed and tyrannized with questions and clarifications, demanding that you recognize the right to izvodayuschih all this not to know. And here you, the developer, will cry out: where is it, where is the part about my rights and their duties ?! Without panic, we just go to it.

Tip: Document THIS!
The main responsibility of the support engineer in relation to the company and to himself is to document. Everything that was not previously documented should be documented. All bugs must be filled. All instructions should be recorded, checked with you once more just in case and published. All your answers to all questions should be streamlined and saved. And here you have the full right to say: hey, dear colleagues, why is this engineer Masha asking me exactly the same question that engineer Petya asked the third day? Why did I get a bug on the driver without checking for the presence of a driver in the system, which I definitely mentioned in the instructions? And here let engineers Masha and Peter, their turn, cry bitterly.

Bottom line: this too will pass
Whose turn was to cry bitterly, remember: over time it will be better. Technical support engineers will accumulate enough documentation in order not to harass you with questions. The best of them will burst into the ground altogether and turn into coaches in order to serve as an additional filter between you and the beginners. You, in turn, will master the difficult ability to translate from a programmer to a human, and to pluck a freely floating thought to the state of five-point instructions. And one fine day you will find yourself at the corporate party that you are telling engineer Petya about the intricacies of the PRTCL protocol, and he complains in response to you: "I told him about Friday evening, and he told me about the hard drive partition!" understand each other.