“If you have always done it that way, it is probably wrong.”
If you have a goal of creating the world’s best OSS tool, where do you start?
Do you try to understand the competition and do it better than they do? How would you prove that it’s better than them in a competitive bid situation? [I could say try using OSS use-case benchmarking studies but this is a whole separate discussion.]
A common approach, as follows, is somewhat flawed
- Products are specified by business analysts (BA) who work closely with the customer but who have never operated a network, certainly not for long periods of time, and generally don’t have the strong technical background to deeply understand the operator’s daily activities. This makes it difficult to propose something alternative to what the customer is requesting
- The BA then hands their spec to developers who often have brilliant programming and IT skills but are even further removed from an operator’s daily experience.
- Once developed, testers test the new OSS products with data / scenarios that have been provided by developers and test without an actual network operator’s context around test cases and data
The alternative is to identify the best operator in the world (not just any old operator) for the particular function that you’re creating (eg fault management). Then send your creative and technical lynchpin/s to shadow them, and benchmark their activities, understanding their thought processes and getting to know what they do differently from all the other operators. Learn from the best and design a solution around it.
The challenge for you is finding out who the best operator in the world is. Afterall, we don’t have an OSS / Telco Olympics or World Championships… not yet at least.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email