Web development traps or web development fun

Outset

I want to raise a topic that is relevant for developers and for customers: development is fun. What is it, myth or reality? Are there companies in which the development process is put in such a way that brings pleasure to both parties: the developer and the customer. After all, in the end, the goal of both sides is the same - satisfaction with the final product.

I’ll make a reservation that further reasoning will be about web development of relatively complex and time-consuming products.

Consider the standard process. There is a company - the customer, she needs a product. There is a company of developers, they need to implement this product. It would seem that everything is simple, there is no conflict of interests, the goal is one. But here naturally appears but: the customer needs a product in the shortest possible time, this is a market demand. Again, the time of the company-developer is not cheap. In general, the customer needs to quickly, cheaply and efficiently.

The customer often has some experience of communicating with developers behind his back. And quite often it is, unfortunately, negative. The product was made poorly, not on time, or not at all.
')
Why did it happen? Again, going back to the standard process, how does the first stage of customer interaction with the developer occur? The customer sets out, rather abstractly, his idea. The developer gives a fairly abstract estimate of the execution time. This is where the first and most important mistake happens - without knowing anything about the product, about the conditions, the loads and much more, time is estimated. Although it is quite logical to assume that you can only evaluate what you know. But developers and customers have already fallen into the first trap - the assessment needs to be done as quickly as possible. After all, you need to approve business plans, graphs, and a bunch of papers that have nothing to do with the developers.

Climax

I will give an analogy from the world of construction: the customer asks to build a four-story house with a certain number of windows and two entrances. “Well,” the builder thinks, “it's pretty simple and we have already built 8 and 9 floor houses. So this will be built in half the time from the 8-storey one ”. The customer is also satisfied with the deadlines and advises to carve them on the arch of the door of the future house. “Stop, what arch?” Asks the builder. “Like what”, the customer is still kindly surprised. "In the area where we are building a house, all houses should be with arches." And it started ...

This is an example of one of the options for evaluating a project in the context of insufficient data on it — an expert assessment, an assessment based on already completed projects. But, unfortunately, if we consider fairly complex projects, it is often close to hitting the sky with your finger, since all the “similarity” is only in the appraiser’s head, and in fact the project may be so different from the ready-made ones that such estimates will not work for him. And how can this be understood if the project fits the concept of “similar” at the stage of “abstract description”? No way!

Decoupling

In the end, after such assessments we get a product that neither the developer likes, “we did it in such a time that it’s embarrassing to remember what’s inside”. Neither to the customer: “I wanted something completely different, but they constantly postponed the deadlines and eventually had to agree on what was, since it is too late to hire others.”

So what?

The problem is, probably nobody doubts it. But where is the solution? Unfortunately, there is no silver bullet. It is impossible not to estimate the deadlines at all, this is understandable, but it is also impossible to evaluate them “at once” to close, heart-to-heart, communication with the customer. Find out all the details, whether there are subcontractors, whether further “clarification” of the task is planned. Indeed, clarification for a customer is often a change of architecture for a developer, which cannot but be reflected in terms. A very important point is to communicate with the customer already during the execution of the order, and not only to clarify the details. Explain why you make certain decisions, it will positively affect mutual trust.