Express offer for the development of a fast online store for 7999 UAH details...

Attention, pitfalls! Is this a “bug” or “paid revision”?

In the process of performing tasks that most often relate to atypical tasks (more on this here: it happens that Clients do not fully understand the difference between the concepts “Bug” and “flaw”, which subsequently causes disagreement when paying the invoice.

In fact, the Client can be understood, because he doesn’t encounter software developers every day and if something doesn’t work as he expected, he has the right to think:

- “guys, it doesn’t work - this is a“ bug ”, correct it!”, Expecting that we should do this at our own expense, because the time for the task was paid for earlier ...

But in fact, in 95% of cases, it does not work NOT because we spent the paid time on this task and now we need more time to redo this work, because we treated it in bad faith and it was not done as it was promised. Most often it does not work because:

a) The client did not indicate this in the TK.

b) The specialist did not spend his time on it to work in the “right way”.

What is a “bug” and in which cases we fix it at our expense?

The concept of "bug" is valid to use only in cases where the claimed functionality does not work, as originally promised. For example, in the description of the module it is stated that the Buyer will be able to go to the checkout page after clicking on the “Confirm order” button. If after clicking on this button, nothing happens or the Buyer redirects to another page - this is exactly the “bug” and, of course, we will correct it at our own expense.

Consider situations where it is not a “bug”, but the need for “refinement”.

The first situation is when the Client considers a “bug” something that shouldn’t be in nature at all, since such functionality was simply not provided or the availability of such functionality was not specified.

The classic situation when moving from another CMS, because Customers think that what worked on the old site should be on the new one. But this is not the case. this may be, but not necessarily. Just imagine an analogy, if you, after buying a new car, would begin to argue that the absence of a hatch in the roof is a marriage, because there was a hatch in the old car! :)

Conclusion. It is incorrect to call a “bug” what was not stated and provided for in the TK.

The second situation is when we again work on an atypical task, for example, the individual design of the main page of the online store and its layout.

As you already know, for such tasks we provide an indicative assessment since it’s not at all obvious how long it will take to complete it due to the additional wishes and corrections of the Client. And so, we rendered, approved the layout, began to impose, spent a total of 15 hours. Tested on all popular devices and browsers, everything is viewed cool, we give to the Client. And here it turns out that on some browser or under some device that uses 1% of users, layout, suddenly, it looks “crooked”. The client has the right to think - “guys, it does not work as expected, look, this permission is not displayed as it is drawn on the layout - this is a“ bug ”, correct”, expecting that he has already paid for it and it should work ... But this is not a “bug,” namely, a “flaw”. This means that this work on the adaptation of the layout for such a browser or for such a device was not carried out and time was not spent on such work. Naturally, to fix the layout for this device or for this browser, you just need more time. You have to understand that if a specialist tester found this “flaw” of the layout on such a device earlier, he would return the task to the layout specialist and he would spend time eliminating this “curvature” anyway! - i.e. the time for the task in any case would be no longer 15 hours, but more.

Conclusion. Tasks for which the specialist did not waste his time - this is not a “bug”, which we must fix at our own expense, but an ordinary “flaw”, which requires the removal of just extra time.

The article will be supplemented with other cases, but in conclusion we want to remind you that we are always open for our Clients. We write and publish all these cases in the public domain on our website, so that not a single Client even has the feeling that it was suddenly decided to deceive him here. Unfortunately, in our professional field, such situations arise and we consider it right to discuss them with Clients in advance so that they do not have any illusions and bitterness from unjustified expectations.

We prefer to deal with knowledgeable, advanced Clients and be the first to tell you about all the “pitfalls” in our field so that, first of all, you don’t stumble about them and don’t spoil relations with perhaps not perfect, but the best web studio on the market :), the developer of the correct, optimized online stores and modules for {SEO-Shop} and OpenCart.

As always, with the hope of productive collaboration,

Team NeoSeo.