Customer-Executor: avoid accidents
Instead of an epigraph.
“Are you deaf-mute?
-Yes"
k / f "Diamond Hand"
I somehow got into an accident - one good man hurried home to her mother-in-law for pancakes so much that he didn’t notice my car in front of me. I arrived at the station, they made a “defect repair”, determined what to do and the repair period - 3 weeks. Of course, I wanted to quickly, but they explained to me that the service station is loaded, plus a couple of parts have to wait, plus the technological process: straightening, priming, drying, painting, drying again. “Just like in our projects,” I thought, “design, implementation, testing, fixing bugs, acceptance testing by the customer, fixing bugs again.”
Three weeks later, having yearned for my “swallow”, I come to the service station in a tedious wait. And ... And, you guessed it, the car was not ready. The project “Ride through the Wind” quickly ended with a packer. After long trials, it turned out that the service station re-registered the parts, there were no mine, they were ordered again. But in a week everything will be ready: “Mom is a klyanus, daragoi,” the hundred-shnik convinced me. To my regret, mom was not aware of the oath of the assurances of her son. I don’t know how my mother acted and what her state of health was after three more promises, but after 7 weeks I took the car. In the process there were my calls, redirection to one or another manager. My plans were already thwarted, a number of trips had to be postponed indefinitely. “But we set the mud flaps for you free of charge,” the stationary smnik smiled stupidly, handing me the keys.
')
Nevertheless, the fact of the return of the machine pleased inexpressibly, and in a great mood on the same day I went to the customer. The customer, a very pleasant person, when he saw me, changed for some reason in his face: “Why the fuck are you doing nothing? When will the results? We have been working for the second month, there are no shifts in the project! Your managers do not understand where they are gone. Are they going to work or not? ” The machine suddenly ceased to please. “How is this nichrome not doing?”, - fever in the brain. “Yesterday there was a meeting, we looked at the system, everything was going according to plan.”
- Dear customer, we are fine, most of the functions are ready, the site is hosted on a test server, you can watch at any time. Yes, we had questions on a number of functions, but we dismantled them with your staff.
- Dear Maxim, - said the customer indulgently, - it’s good that you and my staff decided everything. But I know nothing about it. I pay for the development! I, my employees, in particular, our financial director, say that there are problems. Imagine: you gave the car to be repaired ...
And the retelling of my story went on: about the promised dates, that they were being broken down, that there was no information. “Congratulations, Sharik, you are a dunce,” this thought huddled in the walls of the skull. “Now, Max, you will be a hundred. Welcome to role-playing games. ”
We nevertheless ended that meeting on a positive note: I showed the system, the customer called his analyst, we discussed controversial issues and parted with smiles.
Gathered in the office team, we began to disassemble the problem. First of all, an interesting detail emerged: communicating with different employees of the customer in different information planes, we ourselves gave the customer a false impression of the real state of the project. The issues of technical organization of work we solved with the system engineers and they were difficult to solve. Requirements were discussed with business users, training tasks were discussed with the department, which was located in another office. There was no uniform policy of information exchange. “But we have Jira,” the guys were justifying. "There are all statuses, all tasks." But the question of whether the customer knows about Jira and what is in it is hanging in the air. The customer was in the information field, and we were in the information trench.
The second aspect was interference in communications. Simply put, we chose the wrong means of communication and the wrong way to provide information. And most importantly, having sent the information, we were not convinced that it was not only accepted, but correctly understood: from our side, the bullets flew out. Later, we found a description of the problem in the PMBOK book (Guide to the Body of Knowledge on Project Management) useful for familiarization.
In PMBOQ terminology, encoding is the presentation of thoughts or ideas in a language that is understandable to others, and decoding is the transformation by the recipient of the message into thoughts or ideas that are understandable to him. A kind of game in the " crocodile ".
The third aspect is the number of communication channels. Here RMVOK helped us again. It (or, oddly enough - “it”, the guide) gives a simple calculation formula: the number of communication channels is n (n-1) / 2, where n is the number of stakeholders in the project. Here I will allow myself to quote: “the key element in planning the actual communications of a project is the definition and limitation of who will communicate with whom and also who will receive what information”. Only on the customer’s side, 8 people were involved in the project, and these are 28 channels! Moreover, not all participants received adequate, understandable information. One can imagine what the financial director might have thought when he saw our correspondence with admins, in which there were descriptions of system errors and other Chinese hieroglyphs ...
As a result, we came to several simple tools (hello, Cap !), Which allowed us to keep a customer in our information field:
At the same time, the main advantage of the protocols is the solution of the “snowball paradox” problem.
We all know very well that a small “snowball” that was launched down from the mountain turns into a large snowball at the foot. In the corporate environment, the opposite effect exists: a minor issue becomes a big problem, rising from the level of performers to the level of executives. And the larger the company and the higher the hierarchy, the greater the amount of coma we have at the output of the customer. And where the customer has a way out, what about us? That's right - the entrance;). This lump clogs our entrance, forcing us frantically to break through it, to be able to return to the project and eliminate the causes of the formation of coma.
Let's add a picture with the number of communication channels in the project (and this is also an opportunity to stick around our com with additional details) and get. How painfully we get depends on the weight category and the degree of irritation of the customer. The protocols allow to keep all parties on the same informational level, thereby reducing the volume of coma, and in the ideal case not to create it at all.
Instead of an epilogue.
"Information, unlike resources, is conceived to be shared."
Robert Kiyosaki
"The less we know, the more we suspect."
Henry Wheeler Show
As if hinting;)
“Are you deaf-mute?
-Yes"
k / f "Diamond Hand"
I somehow got into an accident - one good man hurried home to her mother-in-law for pancakes so much that he didn’t notice my car in front of me. I arrived at the station, they made a “defect repair”, determined what to do and the repair period - 3 weeks. Of course, I wanted to quickly, but they explained to me that the service station is loaded, plus a couple of parts have to wait, plus the technological process: straightening, priming, drying, painting, drying again. “Just like in our projects,” I thought, “design, implementation, testing, fixing bugs, acceptance testing by the customer, fixing bugs again.”
Three weeks later, having yearned for my “swallow”, I come to the service station in a tedious wait. And ... And, you guessed it, the car was not ready. The project “Ride through the Wind” quickly ended with a packer. After long trials, it turned out that the service station re-registered the parts, there were no mine, they were ordered again. But in a week everything will be ready: “Mom is a klyanus, daragoi,” the hundred-shnik convinced me. To my regret, mom was not aware of the oath of the assurances of her son. I don’t know how my mother acted and what her state of health was after three more promises, but after 7 weeks I took the car. In the process there were my calls, redirection to one or another manager. My plans were already thwarted, a number of trips had to be postponed indefinitely. “But we set the mud flaps for you free of charge,” the stationary smnik smiled stupidly, handing me the keys.
')
Nevertheless, the fact of the return of the machine pleased inexpressibly, and in a great mood on the same day I went to the customer. The customer, a very pleasant person, when he saw me, changed for some reason in his face: “Why the fuck are you doing nothing? When will the results? We have been working for the second month, there are no shifts in the project! Your managers do not understand where they are gone. Are they going to work or not? ” The machine suddenly ceased to please. “How is this nichrome not doing?”, - fever in the brain. “Yesterday there was a meeting, we looked at the system, everything was going according to plan.”
- Dear customer, we are fine, most of the functions are ready, the site is hosted on a test server, you can watch at any time. Yes, we had questions on a number of functions, but we dismantled them with your staff.
- Dear Maxim, - said the customer indulgently, - it’s good that you and my staff decided everything. But I know nothing about it. I pay for the development! I, my employees, in particular, our financial director, say that there are problems. Imagine: you gave the car to be repaired ...
And the retelling of my story went on: about the promised dates, that they were being broken down, that there was no information. “Congratulations, Sharik, you are a dunce,” this thought huddled in the walls of the skull. “Now, Max, you will be a hundred. Welcome to role-playing games. ”
We nevertheless ended that meeting on a positive note: I showed the system, the customer called his analyst, we discussed controversial issues and parted with smiles.
Gathered in the office team, we began to disassemble the problem. First of all, an interesting detail emerged: communicating with different employees of the customer in different information planes, we ourselves gave the customer a false impression of the real state of the project. The issues of technical organization of work we solved with the system engineers and they were difficult to solve. Requirements were discussed with business users, training tasks were discussed with the department, which was located in another office. There was no uniform policy of information exchange. “But we have Jira,” the guys were justifying. "There are all statuses, all tasks." But the question of whether the customer knows about Jira and what is in it is hanging in the air. The customer was in the information field, and we were in the information trench.
The second aspect was interference in communications. Simply put, we chose the wrong means of communication and the wrong way to provide information. And most importantly, having sent the information, we were not convinced that it was not only accepted, but correctly understood: from our side, the bullets flew out. Later, we found a description of the problem in the PMBOK book (Guide to the Body of Knowledge on Project Management) useful for familiarization.
In PMBOQ terminology, encoding is the presentation of thoughts or ideas in a language that is understandable to others, and decoding is the transformation by the recipient of the message into thoughts or ideas that are understandable to him. A kind of game in the " crocodile ".
The third aspect is the number of communication channels. Here RMVOK helped us again. It (or, oddly enough - “it”, the guide) gives a simple calculation formula: the number of communication channels is n (n-1) / 2, where n is the number of stakeholders in the project. Here I will allow myself to quote: “the key element in planning the actual communications of a project is the definition and limitation of who will communicate with whom and also who will receive what information”. Only on the customer’s side, 8 people were involved in the project, and these are 28 channels! Moreover, not all participants received adequate, understandable information. One can imagine what the financial director might have thought when he saw our correspondence with admins, in which there were descriptions of system errors and other Chinese hieroglyphs ...
As a result, we came to several simple tools (hello, Cap !), Which allowed us to keep a customer in our information field:
- communication management plan. He answered the questions who, when, how much and in what volume should receive information about the project. Here we plan the frequency of meetings, reports, meetings. It is important to convey to the customer that the communication management plan is a two-way road and the rules are the same for everyone;
- records Try to remember when the last time members of the project team came to the meeting with a notebook and pen. Vooot. By introducing a simple rule “Who came without a notebook is not cool,” we solved the problem of forgotten questions and forgotten answers. Here we also assign an agenda (agenda), without which the meeting does not make sense to appoint. But this is a completely different story, described by Patrick Lensioni in the remarkable book “Death from Meetings” ;
- means of communication. The question is not in the tools, but in the approach. E-mail has already firmly entered consciousness as the fastest and most convenient way of communication. It's easier for us to type three sheets of text than pick up the phone and call. All that can be discussed by voice, should be solved over the phone. Working in the field of website development, we used the “3-click” rule: any information should be available in these three clicks. We used the same rule for electronic correspondence: if a discussion of a question requires more than three letters, this is a reason to call. Otherwise, the message flame will exceed the permissible level of sanity by a little more than completely ;
- communicating about problems and solutions. Oh, we love it - to write about the unavailability of the release on the day of delivery (at best, a day or a couple of hours). And it's not only bad that we reported late. It’s bad that we don’t offer any solutions! We leave the customer one on one with our facs and mimic vigorous activities to save the world in a project taken separately by the throat.
A good guy, Kaoru Ishikawa, who worked out a chart of the name of himself in the 1960s, helped us a lot in solving this issue (more precisely, in its visualization to the customer); - meeting minutes (recap, meeting minutes). It sounds very bureaucratic, however, they are an indispensable tool. The protocols allow you to fix the agreement and not forget about these promises. We did not invent a bicycle. One click - and a dozen simple templates are available for download.
At the same time, the main advantage of the protocols is the solution of the “snowball paradox” problem.
We all know very well that a small “snowball” that was launched down from the mountain turns into a large snowball at the foot. In the corporate environment, the opposite effect exists: a minor issue becomes a big problem, rising from the level of performers to the level of executives. And the larger the company and the higher the hierarchy, the greater the amount of coma we have at the output of the customer. And where the customer has a way out, what about us? That's right - the entrance;). This lump clogs our entrance, forcing us frantically to break through it, to be able to return to the project and eliminate the causes of the formation of coma.
Let's add a picture with the number of communication channels in the project (and this is also an opportunity to stick around our com with additional details) and get. How painfully we get depends on the weight category and the degree of irritation of the customer. The protocols allow to keep all parties on the same informational level, thereby reducing the volume of coma, and in the ideal case not to create it at all.
Instead of an epilogue.
"Information, unlike resources, is conceived to be shared."
Robert Kiyosaki
"The less we know, the more we suspect."
Henry Wheeler Show
As if hinting;)
Source: https://habr.com/ru/post/146282/
All Articles