Work with a client or “why didn’t you do what we asked for?”
Foreword
This is not to say that I am very straightforward such a seasoned web developer, but in my very busy year as a professional developer I went through fire, ice, flame, copper pipes, and the code in the database performed by Indians. Especially great impressions of the Indians. But all this fades compared to customers. As it turned out, the most difficult thing to develop is to please all those people who hire you and even pay you money. You can be impossibly proud of your offspring, but he doesn’t care what you are proud of there. And during this time I learned a lot of life hacks and subtleties. Until a certain point in time, I thought that all the tough guys know all these features, but lately I have been increasingly convinced that some things should still be conveyed to the masses.
Episode I: The Beginning
You’re sitting idle, reading articles on some well-known news resource, or making toys on Unity, and your manager suddenly runs in and says: “We have a new project, guys, wow!” And runs away. Anyone who knows English at a conversational level] (in this case, my team lead), get blown up on the spot, quickly turn off all their chromes with articles on exchange rates and other meaningless husks, pull on headphones with a microphone and hear a familiar call Skype
"Hi, Michael. I want to introduce you our team ... "
The manager, cleverly speaking in words, makes the client feel the seriousness of our company. He will never know who drank how much on Sunday at the corporate party and why there is a lot of mat on our task board (an ordinary white board with a marker). Further, after all capitalist familiarities, the process of discussing the project begins. At this point, the team lead starts recording sound in the computer and records the entire process of discussing the project . Subsequently, the poor girl manager will have to make a complete transcript of this conversation. In the process of discussing the project, the customer
Episode II: "Snowballing"
After the girl manager completed the transcript and, together with the team lead, identified the main aspects of the future project, the whole team gathers at the task board and discusses each item from this long list. This process is called a feature (from the English. Feature cut - "cutting" of parts). All features requested by the client are discussed and belong to three groups:
- required / core features
- optional / useful features
- crutch / useless features
The first group includes the main features requested by the customer. This is the project’s skeleton, the main functionality that will be implemented on the project. The second group includes features that are not mandatory for the site’s functionality from our point of view, and we can refuse them if it is technically difficult / disadvantageous. The last group is those features that in our experience are absolutely unnecessary and may even create difficulties in the future. To everything else, based on the analysis of these points, you can add some features in the second and third paragraph. For example, tight integration with a specific database (Oracle DB) will be in the third paragraph. But in the first paragraph there will be such a feature as "the implementation of work with many other types of databases."
And where is the customer specification, you ask? Didn't he send it? Of course I sent. In this customer specification, we make our changes and provide it for confirmation . If he agrees, we are lucky. And if he doesn’t agree, we will persuade him to agree until he crushes us, and we will not bend. Well, govnokodit so govnokodit, we did everything to avoid this.
Episode III: Diving
The project is gaining momentum! After the final approval of the TOR, it is divided into tasks (tasks) and put estimates (estimates, estimates). The more adequate the requirement, the more adequate the estimate. For example, all the features from the third paragraph will be inadequately vested. And this is very important and correct, more about that a little later. Then the team gathers, discusses the general architecture, tasks are distributed and all that, in short, the work is in full swing. If in the process the customer makes any corrections, they are evaluated and also estimated. About edits, too, a little later. In short, the horses plow the developed, and all is well.
Episode IV: “Submission of the Project”
There can be a lot of problems and in general everything. The whole project is done entirely in accordance with TK and only according to TK. There are no more documents that set goals for you. Neither correspondence, nor “I told you on Skype”, nor “well, they did it like this, but you’re not like that at all.” Nothing. On the other hand, everything should be strictly on TK. In order to prevent such situations from occurring, we will shorthand communication with the customer and revise the statement of work, make corrections. And still, the horse is vigorous, these situations arise. Someone did something wrong, someone misunderstood something and away we go. Once we received a letter in which the word “f * ck” and derivatives amounted to 70-80 percent of the entire text. Let the customer swear. Let the steam out. And then we form a new TK for “file cutting”: styles to fit, color as needed, configure SEO and so on. We set an estimate, modest, but obligatory, the customer pays and we bring everything to the ideal. In the end, 90% of customers are satisfied. The remaining 10% are customers from Russia or Ukraine.
Episode V: "The Empire Strikes Back"
Developed? So go and support. Firstly, an estimate is again put up for support. On average, support-team of one project consists of one developer, he spends 30 hours a week on this. He delves into the site, raises the base, if it falls, makes small fixes. If you are planning at least some kind of big bug - immediately to the estimate. At this time, the customer comes up with more and more features. Who will make them? We! For each feature - estimate. Change the photo on the site - estimate. Add a table to the database - estimate. He wants to spit on us - estimate. Yes, yes, yes, estimate for every spit. Let him pay money for it.Because if at least once let him spit on us for free - he will spit us to death. Money is a very good deterrent for the customer, so it’s worth putting pressure on the money. In our team, the estimates are put up for hours, and one hour costs about 30-40 dollars. To pay $ 100 for a photo or an extra and very useless checkbox? Yes, please, as much as you want! Any whim, but pay the money. That is how we live. Unfortunately, many customers are very unhappy with this and some things can really be done for free. But this is already purely individual in relation to the client, based on what kind of person he is and what he eats with. Sometimes it’s possible to bend under a good client, but in no case should anyone give a hint of what you will do for free.
Episode VI: "Return to the Articles"
After going through all these development circles, the customer runs out of ideas (at the end you get some kind of commercial project with an API, SDK, a module for magento and woocommerce, two repositories on the github and a designed design for the circle. Nothing more to do. There remains to be done. just read the article to the next project. with horror, remembering the times of formation of the company, when you take any freelance projects at everybody (even the Ukrainians), and with pleasure again and again to consider a new draft ready made for any American.
N great tips for developers:always a very long, tedious and painstakingly disassembled with the customer TK. Let him write everything he wants there and pay for everything. Only in this way and nothing else. Then begins "I once told you, here we talked on Skype and you said that you can lalala." Only TK.
Small tips for customers: in most cases, you yourself do not know what you want. Our company provides a service for the processing of TK. Not for free, as it might seem, but for money. It’s just that you break this amount per hour when we ask for some money. I advise you to discuss TK with your developers for a long time, tediously and painstakingly, or hire a programmer who will help you to prepare a ready-made TK based on your ideas.
Thanks for attention!
PS I have nothing personal to Ukrainians, just statistically projects with customers from the yellow-blakitnaya pass the worst. I apologize if suddenly someone was offended. We will drink beer and recall with laughter all past grievances.