English | EN 
One of our customers recently requested an assessment on how their processes were working and wanted suggestions on how to make them better.
The customer had a tricky situation, as they provided infrastructure to several different companies which had very different technological maturity. Some of the companies were less than ten people, other companies had thousands of employees.
Not surprisingly, our customer had a problem with their tools and processes. Some of the processes were so convoluted and heavy that the smaller companies were struggling to use them. Likewise, the bigger customers requested more formality in the processes. It seemed that actually, no one was completely satisfied with the lukewarm compromise in between.
One of the biggest points of controversy was the choice on their issue tracking tool. Some people wanted things to work in a more agile and smart way, others wanted to use the current tool and nothing to change. The customer had spent endless hours discussing whether they should continue using the tool or not.
After the assessment the following things were clear:
1. All the customers were not the same
2. All the customers could not use the same processes
3. All the customers should still sync their issues in the same system
How to fix the problem? Well, forcing people to use a complex process they hated only had proven that the people started going around the process. They started to “forget” to run the tests because getting to the system was so laborious.
We decided to look at the situation from other perspectives. The big companies wanted to use the tool as-is, so in that sense, their problem was solved. They could even add more complexity to their issue tracking should they want it.
But how to make things easier for smaller people? Automation and APIs. It turned out that the issue tracking tool had good APIs to do a lot of the things automatically and instead of asking “why are you not using the process?” we asked, “how would you like the process to work?”
If all test results must be logged into the system, it only makes sense to create automatic reporting for everything that can be reported automatically. Eg. whenever someone deploys something small and their CI pipeline automatically runs regression tests, those tests could be configured to transmit their results directly via API.
It doesn’t all have to be automatic tests, either. Maybe one or two of the smaller companies always do testing and defects on a certain component and require much fewer options than their huge counterparts. Why not create a separate simple UI that uses API to submit the issue tickets?
Case in point: in order to make processes fit better for people, we should be able to steer away from the one-size-fits-all process and make it into more tailored one, even if the projects are working in collaboration.
