Web development traps or web development for fun
I want to raise a topic that is relevant for developers and for customers: development is fun. Is it a myth or reality? Are there companies in which the development process is set up in a way that brings pleasure to both parties: the developer and the customer. After all, in the end, both sides have the same goal — satisfaction with the final product.
I will make a reservation that further discussions will be about web development of relatively complex and time-consuming products.
Consider the standard process. There is a customer company, it needs a product. There is a company of developers, they need to bring this product to life. It would seem that everything is simple, there is no conflict of interest, the goal is the same. But here, of course, there is a but: the customer needs the product in the shortest possible time, this is a market requirement. Again, the developer company’s time is not cheap. In general, the customer needs fast, cheap and high quality.
The customer often already has some experience of communicating with developers behind his back. And quite often, unfortunately, it is negative. The product was made poorly, not on time, or not at all.
Why did this happen? Again, returning to the standard process, how does the first stage of interaction between the customer and the developer take place? The customer sets out, rather abstractly, his idea. The developer gives a rather abstract estimate of the execution time. This is where the first and most important mistake occurs — still knowing almost nothing about the product, about conditions, loads and much more, time is estimated. Although it is quite logical to assume that you can only evaluate what you know about. 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, schedules and a bunch of papers that have nothing to do with developers.
Climax
I will give an analogy from the world of construction: the customer asks to build a four-storey 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 storey buildings. So we will build this one 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. “Wait, which arch?” the builder asks. “Like what,” the customer is still kindly surprised. “In the area where we are building a house, all houses should have arches.” And off it went…
This is an example of one of the options for evaluating a project in conditions of insufficient data about it — an expert assessment, an assessment based on projects already made. But, unfortunately, if we consider fairly complex projects, it is often close to hitting the finger in the sky, since all the “similarity” is only in the appraiser’s head, but in fact the project may be so different from the already ready-made ones that such estimates will not suit him. And how to understand this, does the project fit the concept of “similar” at the stage of “abstract description”? No way!
Interchange
As a result, after such assessments, we get a product that neither the developer likes, “we made it in such a time that it’s a shame to remember what’s inside.” Neither to the customer: “I wanted something completely different, but they constantly postponed the deadlines and in the end I had to agree to what was, since it was too late to hire others.”
So what?
There is a problem, probably no one doubts it. But where is the solution? Unfortunately, there is no silver bullet. It is impossible not to evaluate the deadlines at all, this is understandable, but it is also impossible to evaluate them “right away” before a 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. After all, clarification for the customer is often a change of architecture for the developer, which cannot but affect the timing. 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 have a positive effect on mutual trust.