Almost three months ago, with Jean-Francis Ochs , we made a simple observation: in many missions, the problem does not immediately come from the technical solution. It starts much earlier, when the need must be understood, challenged and formalized.
01A problem encountered in many missions
With each new mission, we often encounter the same difficulties: an expression of need that is too general, insufficiently detailed documents or important decisions that have never really been formulated.
The client generally knows his business and knows what problem he wants to solve. On the other hand, he does not always identify all the consequences of his request: exceptions, user roles, necessary data, management rules, dependencies with existing tools or even the criteria which will allow the project to be considered successful.
In certain cases, better framing would have made it possible to reduce the cost of the mission. It would also have avoided some of the frustration felt when the team discovers too late that a request was poorly worded, incomplete or interpretable in several ways.
This is not necessarily the fault of the client, the AMOA or the developer. The need evolves naturally over the course of the discussions. The problem appears when this development is not sufficiently structured and the gray areas are not identified before the start of production.
02The search for a solution
Once this observation was made, we set out in search of a solution capable of helping the people responsible for collecting and formalizing the need.
Our goal was not to replace the AMOA, the functional analyst or the project manager. On the contrary, we wanted to provide them with a tool capable of strengthening their work: helping them to ask the right questions, identify missing information and delve deeper into subjects that seem obvious at first glance.
We naturally turned to artificial intelligence. A conversational model is particularly suited to this type of situation: it can analyze an initial formulation, ask for details, question certain assumptions and help to gradually structure the need.
03An assistant for the AMOA and the analyst
The idea of AskLeopold is simple: to become the companion of the AMOA or the analyst throughout the scoping phase.
The tool must be used from the first exchanges, when the need is still imperfectly defined. Its role is to ask useful questions, including those that may seem disturbing or premature:
- what problem are we really trying to solve?
- which users will be affected?
- what are the exceptions to nominal operation?
- what data is needed and who is responsible for it?
- what technical or regulatory constraints must be respected?
- how will we measure the success of the project?
These questions may seem simple. However, their absence is often the cause of the most costly misunderstandings.
04Why create a real tool?
At the start of the project, two possibilities were available to us. The first consisted of producing a guide to good practices: a method, a list of questions and some model documents intended for those responsible for framing.
This approach would have been simpler and faster. However, it had an important limitation: a guide remains a static document. It may be forgotten, partially applied or not adapt to the particular context of a mission.
The second possibility was more ambitious: developing a tool capable of truly supporting the user, adapting to the answers obtained and making their questions evolve over the course of the discussion.
As is often the case in our joint projects, we chose the most complex path: building the product that we would have liked to use ourselves.
05Why vibe coding?
For several years, Jean-Francis and I have been carrying out what we call our evening and weekend projects. These are projects developed for ourselves or for some of our clients, outside the usual formats of large IT projects.
Their scale rarely interests large ESNs. However, these applications can bring strong added value to the companies that use them. They often respond to a specific need, with a limited budget and a strong expectation of speed.
AskLeopold is not a small project, however. Without the support of AI-assisted development tools, we would not have had the capacity to produce an application of this scale only in the evenings and weekends. The project would probably have required much more time, to the point of becoming difficult to compatible with our other professional activities.
The vibe coding allowed us to accelerate production while maintaining control of the design. We were able to define the architecture, formalize the development rules, control the technical choices and direct the agents towards the product we had in mind.
The important point is this: we did not ask an AI to decide alone what AskLeopold should become. We gave it a framework, requirements, a product vision and a working method.
06Three months to make the idea a reality
In three months, we went from a shared observation to an application available online. We had to transform a general idea into a user journey, organize the operation of the assistant, structure the project and build an interface simple enough not to add complexity to a framing phase which is sometimes already a lot.
AI-assisted development has allowed us to significantly reduce the time required for implementation. It also gave us the opportunity to iterate quickly: try an approach, evaluate it, question it and then improve it without waiting several weeks between each version.
We are proud to have brought this project to a first usable version in just three months. This doesn't mean the work is done. A product continues to evolve through contact with its users, their practices and their feedback.
We are nevertheless convinced that a tool like AskLeopold can change the way certain teams approach their projects. Not because it would replace their expertise, but because it helps them spend more time on the right questions before the wrong answers become costly.
07And now?
The next step is to confront AskLeopold with more real-life situations, to listen to users and to gradually improve its support.
We want the tool to remain simple to use, demanding in its questioning and useful both to experienced professionals and to people who occasionally have to formalize a need.
The starting point remains the same: a few good questions asked at the right time can avoid weeks of unnecessary development.
Comments
0 commentsNo published comments yet. Be the first to respond.