I know there are already a few questions on this topic, however I've read a few and wanted to confirm my approach makes sense.
We need to manage a group of products, all of them are applying some predictive models to improve manufacturing processes throughout its different phases. So, overall:
-All products using similar technologies, also using similar User interfaces from a standard template etc.
-The development teams are the same for all of these (there are a few teams that work together on different parts (i.e. Frontend, backend, MLOps)
-No issues with everyone having visibility over everything
-Some developers might even be working on more than one product at a time
-Each of these products is quite lightweight and can be developed in a couple of months
I think using just one project with multiple components is the way to go (one component for each product). This way:
-Prioritization is easier when involving tasks from different products
-Just overall easier for developers
-Easier to follow by managers whose teams work on different products
-De facto standard way to work (easier to manage way of working having to control just one Project vs say, 10 or 15 smaller ones.
The only "con" I can think of is releases, but I think using naming conventions for the releases con be enough to manage them, not a big issue.
If needed we can then create boards to get the details of a project or team if needed, to reduce complexity of looking at all the information. Maybe even create tags to see boards per team (for example creating a tag for team "Frontend" and a board for frontend developers to see all the work they need to do across products, although I guess this you could do with multiple projects too)
I would really appreciate feedback on the approach, and see if anybody sees a better way to do things here, I am open to other ways of working, but main focus is reducing administrative work and making it easy for developers to track and log progress, we really want to keep things lean and simple.
Thank you!
