We’ve been on the market for six years now and so far, we’ve never had a requirement coming from a machine. The image is quite surreal but it is what we were expecting from requirements when we first started. Machine-like printed feature requirements ready to transform into code. Even more so, almost every requirement that ever got into a contract started in the most non-machine like way you can imagine. A human form of sorts. Hence, we chose to take care of that kind of client, the human client.
When we first started developing software projects we were all about the deliverable. Our quoting process was feature centric and during-project conversation with the client was not a factor.
That changed.
The most important reason for all that to change was our decision. We took the deliberate option to take care of people’s expectations, and that, made all the difference.
Every client is at some point in need of expressing themselves, they have at least a day or two with some doubt about what they want, there is always a moment when they fear what they don’t know, it is rather common that they are in love with their idea and, probably the most important ingredient, anxiety is part of some of the choices they make.
So how can we choose to ignore all this? It is after all what makes people tick that makes our services necessary. We wouldn’t need Twitter without a yearn for communication. Facebook would probably have never existed if the need for recognition (and self promotion) was not as strong as it is. Tinder… well, you catch my drift all right I’ll say.
We chose to be a human company and to acknowledge that software is a human thing. We learned that innovation is conversation driven, and that’s how we take care of our common expectations.
It is really easy to say that this item or that feature do not meet the requirement. It is even easier to deliver just what the client asked for, no more no less. But that builds an ugly relationship. What you are expecting, as a result of your investment and your time, should be near what you get. Regardless of scope documents and blueprints.
I’ll say it just one more time to take down any uncertainty about what I mean: It is easier to stick to the book. Much more easier. It just does not happen. The world keeps spinning while lines of code are piling up and no market, solution or competitor is waiting for our sprint to close until they do their move.
It is only natural for you as a client to want to have a handle on things. It is only natural to have some pivots along the road. What is not that natural is sticking to a plan that you no longer feel will work.
That is what a living human being is all about, you read the scene you are in and then make a plan to get what you want. Sometimes that plan is given to you, sometimes it is your responsibility to edit it, to cure it, to transform it. But let’s face it, once on stage, things tend to get their own plot line. And we are here to help, not to criticize the fact that you are going off character.
This takes enormous effort in a Tech service industry. But results are worth it. We don’t want to argue that documentation and Functional Analysis sheets are not really important (and most times irreplaceable) tools. Au contraire. This choice is made to work with the best results in mind, taking care of the client’s expectations while doing it and always using the best tools available. It is something you do because you want to be closer, you want to make the imprint durable. You want not only to deliver and make a buck, but also to matter.
That’s why you choose to be human.
Cincelar 