When the Project Starts
The project begins when the customer comes to you with their own (not always understandable) vision of the project. Vision is an essential part of every startup, which is aimed to formulate the idea of what you’re building and why. By the way, if you do not hear the following ones among the wishes, then consider you are lucky.
Frequently said phrases:
- “I saw once…”
- “Just like this (Facebook, Twitter), but better…”
- “It should work a bit faster than previous”
- “It should work everywhere” (On this phrase it is time to jump out the window 🙂 )
In fact, there are many more phrases that clearly show the differences in the ways developers and customers perceive the project. The way the customer think can be called cash-oriented thinking. Yes, they think about how much money the application will bring, and not about how it will do that. The customer has a goal, and this goal should be clearly understood by the whole team, since if the application that did not reach the goal does not make sense for the customer. And then, the team will be able to offer their options of how can these goals be achieved easier and better. It’s about reaching the goal, not about how to write the code easier.
Instead, the developers have code-oriented thinking. Their task is to find out how their code should be structured. Formulating a software requirement specification (SRS), a special documentation that contains information about how the system should behave, it is very important to ask many questions so that no item is left over or misinterpreted. What we sometimes get instead:
Frequently asked questions (bad version):
- Ok, I got it.
The problem is that as soon as the developer gets an idea of how he will write the code, their goal is achieved: they know what to do but this does not mean they understood the client’s goals correctly.
It is very important to achieve a clear team vision of the goal and the integrity of this vision because your project can repeat the same scheme as in this picture:
And after all, more than half of all errors of the project are rooted in errors in requirements, the correction of which costs the project the most.
How to Manage the Differences in Thinking
To make all the things clear it is useful to ask the client to provide a documentation (and control that developers read it to the end), asking for mockups or making them yourself, documenting all the client’s answers (for instance, asking for a confirmation of short meeting review). It is useful to implement such an instrument as backlog. It is a list of features (technical tasks) which are sufficient to complete a project. In fact, it is a single trusted source of “to do” tasks.
So, how should we talk with the customer:
- questions, questions, questions
- mockups and examples
- mind maps
How should we talk with developers:
- prototypes (Axure RP, Balsamiq)
- use cases and diagrams (draw.io, Visio)
- user stories
- detailed requirements (SRS)
- mockups and examples
- mind maps and whiteboard
Many already know why these techniques are useful, so we’ll try to dwell in more detail on what problems can arise and how to cope with them.
What is Wrong With Tools and What is the Best Practice
The prototypes can involve the customer in the development process significantly, but at the same time, they can generate misconceptions about the product. It’s especially dangerous if the customer starts to think the prototype is already the product, that it will work just like the prototype, or that it has already programmed layout. Explain to the customer that this is not true, perhaps show working prototypes of your previous customers – it will show your team’s wide experience, too.
User stories are a quick way to settle customer requirements, without a need to develop extensive formalized docs. They are short descriptions of a feature told by the end user, extremely good in projects with constantly changing requirements but unable to display hidden expectations. Meanwhile, use cases can easily cope with this task, although they do not provide an understanding of the relations between individual diagrams, which complicates the development.
For ourselves, we found a solution – the diagrams. They don’t have the drawbacks of the techniques from above and help to significantly reduce errors in the estimates. The only drawback is that it takes time to master (as well as prototyping, use case do), but it’s worth it.