In English, there's a saying: "There is a difference between doing the right thing and doing the thing right."
In software estimation, and the negotiation process necessary for a consultancy to build software for a client, the difference between one and the other is tremendously important.
To "do the right thing," we must clearly understand what the client really needs (regardless of what they ask for), whereas to "do it right," it's not relevant whether what we do will actually be useful to the client or not; what's important is whether what we did is well-built.
An extreme example:
A client comes to you and describes a single-passenger transport vehicle that allows them to travel anywhere. You build them a bicycle, but they were thinking of using the vehicle in Alaska, in the snow—they were looking for a snowmobile.
Ultimately, it doesn't matter how well you built the bicycle (done correctly) because it's not useful to the client since what they needed (doing the right thing) was for you to build them a snowmobile.
During the negotiation process carried out during the construction of software, the difference between "doing the right thing" and "doing it correctly" has an important peculiarity: Who has the information required to achieve one objective or the other changes drastically.
For "doing it correctly," all the knowledge is with the consultancy that builds the software, in the technicians, the developers, the designers, who, if they are good, will make the most usable screens, and will use the best architecture and algorithms, strictly adhering to a process that helps ensure a well-built product.
Conversely, for "doing the right thing," the information is with the client. Only they can, although often not at the beginning of the software development, determine if what is being built for them is ultimately what they need. Yes, and only if the client is willing to go through this process of self-discovery, in which their assumptions will be carefully examined, can they finally conclude whether that nebulous idea in their head is really what they need, or if instead, they should have asked for something else from the beginning.
Of course, the consultancy, with its analysts, developers, architects, testers, etc., must seek to facilitate dialogue with the client and help them quickly enter the cycle of assuming, implementing, validating, and re-assuming until they construct "the right thing," but it's important to remember that ultimately the information comes from the client, not the consultancy, and if the client, due to some problem of their organizational culture, is not willing to invest the time required to clearly define "the right thing," the consultancy will not be able to build it (you can lead a horse to water, but you can't make it drink).
There is a prayer that says "God, grant me the serenity to accept the things I cannot change, the courage to change the things I can change, and the wisdom to know the difference." Well, in this case, we need to be very clear about the difference: Only the client has the power to help us build "the right thing," the consultancy is just a facilitator, it's very important to remember this because when we are constructing the proposal, we must ensure it helps to build "the right thing," but at the same time, our responsibility must not go beyond "doing it correctly."
I have had to deal with multinationals, who give me just a few hours to prepare a proposal for months of development. The amount of effort wasted in such developments is absurd, and yet, it was useless for me to insist that 3 to 6 hours are not enough to estimate a project of 3 or 6 months duration, too much remains unspecified. At first, when I faced this situation, my attitude was "it can't be done," "avoid assuming," "ask the client for the missing information, or if not, do nothing." Sounds very nice from an abstract perspective, but that attitude doesn't pay the bills... so I changed it.
I still tell the client whenever I can that the time they are giving me is not sufficient, and that it is very risky to do a project with so little time to plan, but once the client indicates that my warnings are falling on deaf ears, I immediately change strategy: This client isn't interested in me "building the right thing," what they care about is having something built that "comes as close as possible to that," and I'd better "do it correctly," because in the end, if the approximation isn't close enough to what the client realizes they needed to receive (minutes after receiving it), recriminations and attempts at penalties will follow.
Fortunately, "doing the right thing" is subjective, whereas "doing it correctly" is completely objective. If you needed a snowmobile, and I built you a bicycle, and the very limited assumptions of the proposal are met by the bicycle, there will be no way for you to penalize me, or refuse to pay me, and in the event of a lawsuit, you will lose, because I will be fulfilling the contract.
The Agile Manifesto says "Customer collaboration over contract negotiation," which is another way of saying "prefer doing the right thing over doing it correctly," but the Agile Manifesto clarifies: "while there is value in the items on the right, we value the items on the left more." It's the same with "doing the right thing" vs. "doing it correctly," both are valuable, and certainly the best would be to do both, "the right thing, correctly," but we must have the wisdom to know the difference between what we can change... what is in our hands, and what is a shared effort, and that if the other party outright refuses to cooperate, it will not be possible to achieve.
It is very important to do this with a cool head and an enthusiastic and cheerful attitude. If a client is difficult in the first place, and we also treat them rudely, we will get nowhere; the warmth of kindness has more impact than the coldness of aggressiveness. As much as possible, we should seek common ground, empathize with the client, and move forward together, but we must also have clear boundaries drawn so that if things get out of control, we can cut cleanly, without irreparable losses to the continuity of our business, otherwise, we'd fall into Stockholm syndrome...
Don't miss the upcoming episodes of this exciting series on estimation, where we'll see different examples of real-life situations you might face, and how you can emerge victorious from them...
Update: I came across this article on InfoQ, which I see as very related to the topic I'm discussing here and I loved this example, so I take the opportunity to share it with you:
People buy a hammer to drive a nail to be able to hang a picture - they know they can achieve their goal (hang the picture) with the acquisition of the hammer.
Unfortunately, in the context of software development, things are not so straightforward between what is delivered (the software) and the business objective that is desired to be achieved. Many people do not even try to reach the business objective. This creates a significant risk that the provider only delivers what the client asked for - software that satisfies a vague set of requirements - instead of what the client really needs, which is to achieve their business objective.
Unfortunately, it is the same clients who tell the provider: Do exactly what I asked, stick to the contract, do it correctly, I have already decided that this was the right thing... without realizing the harm they are doing to themselves. As providers, we have the responsibility to ask: Why do you want me to make you a hammer? But if the client ultimately refuses to explain the purpose, we must accept that the client is ultimately responsible for their own well-being, and make their hammer, even if their plan is to hit themselves with it... imagine if knife manufacturers spent their time stressing about "what if someone cuts a finger," or stove manufacturers about "what if someone gets burned," practically all industries would end, since there is no limit to the misuse that can be given to things...
Clients are not children, and while we must clearly warn them of the consequences of their actions, the responsibility for their actions lies with them.
In the next part of this series, I will talk about techniques for dealing with performance requests (or demands) in situations where apparently there is not enough contextual information.
Originally published in Javamexico
No comments:
Post a Comment