Work with a client or "why did you not do what we asked for?"

Foreword

I can’t say that I’m very straightforwardly such a solid web developer, but in my very busy year as a professional developer I went through fire, ice, flame, copper pipes, and code in a database performed by Hindus. Especially great impressions of the Indians. But all this pales in comparison with customers. As it turned out, the most difficult thing in development is to please all those people who hire you and even pay you money. You can be impossible to be proud of your child, but he doesn’t care what you are proud of. And during this time I learned a lot of life hacks and subtleties. Up to a certain point in time, I thought that all the cool guys know all these features, but lately, I am increasingly convinced that some things should still be brought to the masses.

Episode I: "The Beginning"

Here you sit idle, read articles on some well-known news resource or make toys on Unity, and suddenly your manager runs in and he says: "We have a new project, guys, uhuuuuu." And runs away. Anyone who knows English at a conversational level] (in this case, I and my tmlid), are undermined on the spot, quickly fold all their chromium with articles on exchange rates and other senseless husks, put on headphones with a microphone and hear the already familiar bell skype

“Hi, Michael. I want to introduce you to our team ... "

The manager, deftly using the words, makes the client feel the seriousness of our company. He will never know who drank so much on Sunday at a corporate party and why there is a lot of checkmate 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, a team leader starts recording sound in a computer and records the entire process of discussing a project . Later, the poor girl manager will have to make a complete transcript of this conversation. In the process of discussing the project, the customer draws out all the ideas known to him that he only wants to see realized. We reply to him that we will proceed to the preparatory part of the project, and, satisfied, we end the conversation. Next, the manager goes to do the transcript, and developers return to reading articles. This is the last quiet hours, the calm before the storm ...
')

Episode II: "Snowballing"

After the manager has finished the transcript and together with the team leader identified the main aspects of the future project, the whole team meets at task-boards and discusses each item from this long list. This process is called featurec (from English. Feature cut - "cutting" parts). All features that are requested by the client are discussed and fall into three groups:

• required / core features
• optional / useful features
• crutch / useless features

The first group includes the main features that are requested by the customer. This is the skeleton of the project, the main functionality that will be implemented on the project. The second group includes features that are not mandatory for the functionality of the site from our point of view and we can abandon them if it is technically difficult / unprofitable. The latter group are those features that, in our experience, are absolutely not needed and may even create difficulties in the future. Everything else, based on the analysis of these items, 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 appear such a feature as “implementation of work with many other types of databases”.

And where is the TZ of the customer, you ask? Didn't he send it? Of course I sent. We make our changes to this customer's TZ and provide it for confirmation . If he agrees - we are lucky. And if you do not agree - we will persuade to agree until he crushes us, and we do not bend over. Well, govnodit so govnodit, we did everything to avoid it.

Episode III: "Developing"

The project is gaining momentum! After the final approval of the TK, it is divided into tasks (tasks) and set estimeyty (estimates, estimates). The more adequate the requirement, the more adequate the estimate. For example, all features from the third paragraph will be inadequately zesmeteycheny. And this is very important and correct, this will be a little later. Further the team gathers, discusses the overall architecture, assigns tasks and so on, in short, the work is in full swing. If in the process the customer makes any changes, they are evaluated and also estimeyyat. About edits too later. In short, developed are plowing like horses, and everything is good for everyone.

Episode IV: Project Delivery

There can be a lot of problems and everything. The whole project is done entirely on the TZ and only on the TZ . There are no more documents that set goals for you. Neither the correspondence, nor "I told you on Skype," nor "well, here they have done it like this, and you are not like this at all." Nothing. On the other hand, everything must be strictly according to TK. It is to ensure that such situations do not arise, we shorthand the communication with the customer and revise the TK, make changes. And still, yadren horse, these situations arise. Someone did something wrong, someone misunderstood something and it started. Once we received a letter in which the word “f * ck” and derivatives made up 70-80 percent of the entire text. Give the customer a curse. Let him let off steam. And then we form a new TZ for “finishing the files”: adjust the styles, decorate as necessary, adjust the SEO and so on. We set estimeyt, modest, but obligatory, the customer pays and 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, again, estimeyt is put up for support. On average, a support project of one project consists of one developer, he spends 30 hours a week on this. He delves into the site, raises the base, if she falls, makes small fixes. If you plan to at least some more or less big bug - immediately in the estimate. At this time, the customer comes up with more and more new features. Who will do them? We! For each feature - estimate. Change the photo on the site - estimate. Add to the base table - estimate. He wants to spit on us - estimeyt. Yes, yes, yes, estimate for every spit. Let him pay money for it. Because if you ever give him a spit at us for free, he will spit to death. Money is a very good deterrent for the customer, so it’s worth the money. Our team estimates are set for hours, and one hour costs about 30-40 dollars. Pay $ 100 for a photo or an extra and very useless checkbox? Yes, please, as you like! Any whim, but the money will pay. That's how we live. Unfortunately, many customers are very unhappy about this and some things can really be done for free. But this is purely individual in relation to the client, based on what kind of person he is and what he eats with. Sometimes you can bend under a good client, but in no case should anyone give a hint at 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 commercial project with an API, SDK, a module for magento and woocommerce, two repositories on the githabe and a designed design for the circle. Nothing else can be done. Remains just read the articles before the next project. With horror, remembering the times of the company's formation, when you took any freelance projects from everyone (even Ukrainians), and with pleasure again and again consider the new finished project made for some American.

Small tips for developers: always very long, tedious and painstakingly dealing with customer TK. Let him write there everything he wants and pay for everything. Only in this way and nothing else. Then it will start "I once told you, so we said on Skype and you said that you can lalala." Only TK.
Small advice for customers: in most cases, you yourself do not know what you want. Our company is a service for processing TZ. Not for free, as it seemed, but for money. Just this amount you break in hourly, when we ask for some money. I advise you to discuss TK with your developers for a long time, tediously and painstakingly, or to hire a programmer who will help you create a ready TK based on your ideas.

Thanks for attention!

PS I don’t have anything personal to the Ukrainians, just statistically projects with customers from yellow-blakitnoy are the worst of all. I apologize if someone is offended. We will drink beer and with a laugh recall all past insults.