In my limited experience, one of the most common things that I see in working with software development contracts has to do with the friction between developers and customers.
Or, more specifically, it’s about the challenges of communication. challenges that exist between communicating requirements between both us, as the developers, and our customers.
It’s not at all uncommon to hear:
- Customers say something like “my developer didn’t do [whatever it is] I asked him to do,” despite the fact the developer believes s/he did exactly that.
- Developers will also say “I’ve built exactly what the customer asked me to do,” despite the fact that customer doesn’t necessarily agree.
So if both parties are working together to build something together, then why is it so common for conversations like this occur?
Friction Between Developers and Customers
This is a bit of an oversimplification of the issue, but the process by which a problem is solved is typically done like this:
- A person has an problem that they need solved
- The person contacts a developer who’s capable of solving the problem
- The developer requests a set of requirements from the person
- The person provides the requirements to the developer
- The developer gets to work
I don’t think anyone would necessarily disagree with this, but – as far as I’m concerned – the largest place for mistakes to be made is in these two steps:
- The person provides the requirements to the developer
- The developer gets to work
There are a variety of things that can happen in between the “Requirements” and “Gets To Work” phase because there are so many different ways in which software can be built.
But this isn’t about the various ways to write software – this is about the various ways that we can minimize the gap that exists between what the customer wants, and what we deliver.
Stop The Blame Game
First, it’s far too common to hear things like:
My developer did this-that-and-the-other which isn’t even what I asked s/he to build!
Or:
I built this thing exactly to requirements. Apparently, the customer doesn’t know what s/he wants.
The thing is, I believe that both of those statements are true. It’s completely possible for a customer to come to a developer with a set of requirements that s/he thinks is what she wants, then have the developer build it to specification (we are very literal people, you know :)) and still end up missing the mark.
So this problem is created when the customer is articulating what they want using terms they think are the right terms, and the developer doesn’t question each of the requirements.
It’s a mutual problem and no single party is to blame.
What Are We Supposed To Do?
As with most things in software, there’s no silver bullet or single right answer to do, but I do believe that there are things that we – as both developers and customers that we can do to mitigate this situation.
Customers
I believe that customers have the responsibility to provide as much detail as they can about their project. This means that, whenever possible, they should not only list out what they want to have to built, but how they envision it being built.
Pictures help illustrate the terms of the requirements.
This doesn’t mean that the final product will end up looking like that the customer initially presents – more on this in a moment – but it helps solidify the details of the idea.
Developers
On the flip side of the coin, developers have the responsibility to ask questions and to ask a lot of them. As far as I’m concerned, we should be asking several questions for each of the requirements.
On top of that, it’s also our job to help prevent users from aiming for a poor solution. For example, if the user presents an drawing of how they want one screen of their project to look, it’s out job to let them know what’s considered best practices in terms of usability or the best way to present a certain type of information.
Case in point: don’t list long form text in an `input` element, right? Aim for a `textarea`. An oversimplification, perhaps, but this is something that happens; otherwise, it wouldn’t be an issue.
Come Together
Finally, it’s up to the customer and the developer to work together as a team to solve the problem.
I think far too often, we define the relationship as a ‘vendor-client’ relationship, but the truth is that if we’re building something for someone else and the solution is someone else’s idea, then they need to have input in the process.
As such, one of the things that I’ve found to work best when building solutions to others is to include them in the process along the way.
For example, I normally work my projects like this. This isn’t prescriptive (and I’d dig hearing what you guys do…), but it’s what has worked for me during my time of self-employment:
- Take the requirements from the client and generate a list of milestones grouping each set of requirements into a given milestone
- Run the list of milestones by the customer to garner feedback. Adjust the milestones based on the feedback.
- Complete a milestone, deploy to staging, hand off to customer for review.
- Iterate on said milestone until complete.
- Move to the next milestone and repeat.
Obviously, this results in incredibly small feedback loops and projects make take longer to build; however, it prevents a ton of work on the backend and generally keeps customers happy (which, in turn, keeps developers happy).
It Doesn’t Always Work
Of course, because this isn’t the best way (nor do I believe that there is a best way), there are problems that do happen and things do change. This won’t result in perfect projects – they don’t exist.
But again, the problem is not about running perfect projects, but it’s about making sure that we deliver the best products possible to our clients and it’s about making sure that we mitigate as many potential issues as possible.
It doesn’t always work and problems are still likely to crop up, but if we can work to mitigate those on the front end of the project as possible, I think it goes a long way in having the customer and the developer having worked together to build a better project.
Because, again, it’s not about the developer, or the customer, but about the teamwork that exists between the two.
Leave a Reply
You must be logged in to post a comment.