In a world where everything goes quick, a lot of people and companies tries to go further quickly as possible to be the first one to have a new feature or product. However this speed brings a certain precipitation which can add some trouble to your project, which can bring some feature redevelopment, being late on schedules or an instability in production.
Between what I lived, everything I red and what I've learned from other people in IT, I saw that it happens frequently, too much frenquently. It doesn't mean that the people/teams/companies will fail in their project. A lot of them succeeded since and some of these products are still used.
But at this point some questions can be asked :
- What was the cost of this ?
- How much time did they took to redirect their solution ?
- Do they keep the confidence and satisfaction from their clients?
Without talking about the direct impact of the time and money lost to redevelop the product, it can have an indirect impact from your customers because some of them will stop to use your product or will lose their confidence in your solution. May be they won't directly leave, but they may check if is there something else to replace your product.
(For sure this is not something which can be easily mesurable as a lot external things can lead to this too.)
And that's why we will talk about some questions that will help you to be sure of the direction you will take with your project.
What are the prerequisites for my product?
Start with the Customer Experience, then work back to the technology
Citation Steve Jobs
This question should be ask to think first at what we want to offer to the client. Which features? Do we want to be fast? secure? ...
Having a precise idea of this is really important, and it's a major cause of rewriting projects. And it happens everywhere. For example if you decide to add after a year of development a duration requirement to have all the processes done in less than a second and you don't have any similar requirements before.
If your project is very large and containts a lot of features, be focused on features with the most contraints and/or the one with particular needs. Indeed if you have one crucial feature and all the other are only managing data in a database without any contraints, they won't need to be a priority because they will fit any context.
In which context are you building this solution ?
Here we want to know which kind of architecture, tools, technologies we want to use.
For example :
- Doing microservices for a small todo app won't be interesting
- Having a huge system with multiple shops in a monolith knowing that you will have to increase and decrease the number of shops regularly won't be interesting too
Also you must check the context of your company. If all the dev masterize Java, it won't be interesting to take something else if perfomances are correct for your requirements.
BUT you must check that it matches with your requirements. Indeed it's easier to take the same technologies and architectures from all the other projects of your company. But doing this can be a huge trap as it won't fit at all your needs. In that case it can happen that you will only see it too late.
What is the long term vision for the product?
This question is really important as it can prepare the product for futur features. The idea is not to analyze the future features but thinking about what can be asked later and see if some things can be done or prepared now.
For example :
- Is there some features which will be reused? If yes, which ones? How they will be shared? (package, microservice...)
- Do we expect a huge usage increase in the future ?
- Do some criterias will be more strict in the future? (like the latency)
Are we going into the right way ?
A simple question which can challenge you to check if everything is correctly defined and if you are sure about the architecture and the tools to use.
If you are not completly sure, you can :
- ask an expert in the domain
- do some Proofs of Concepts on the points you are not sure
It can take a bit of time but at the end will reassure you about your choices.
At the end, we saw that there is no miracle receipe to create a project. But we saw that we can prepare and check a lot of things to build great things without losing time by recreating thing.
I hope it will help you and if you have any questions (there are not dumb questions) or some points are not clear for you, don't hesitate to add your question in the comments or to contact me directly on LinkedIn.
Top comments (0)