I feel to urge to make a note on the other side of what I posted yesterday on the value of having bugs in the product - to build a customer relationship through quick fixes and avoid spending time finding them.
First of all, the bugs that I mention as samples in my "since April" timeframe are a small portion of all bugs logged and even smaller portion of all bugs fixed. These are a special category of things that when found - by real end users, and important enough for them to find the hard route in their organization to complain about it to us - will be addressed differently. We talk of them as branch fixes, basically just indicating we'll do single changes in two different versions separately to fix them.
I'm not happy with the amount of branch fixes. Our product managers are not happy with the amount of branch fixes. And most definitely, our developers are not happy with the amount of branch fixes. All I'm saying is that from the product manager's side, they did not actually see the valuable side of these in building the customer relation before they were asked about it. And there are other ways - while my theory still is that maybe not as effective - to get customers to answer the calls when sales people call and build a customer relationship on mutual successes.
Not all of our bugs are quick fixes. We've just been lucky that the ones customers have complained about (perhaps the ones they have understood well enough to complain about) have been that.
Just yesterday we were fixing something that was relevant for the users (internal users complained about it) that wasn't so easy - a browser specific issue on a functionality not working when clicked one way vs. the other. There was a workaround, not everyone would hit that but definitely, not an easy fix. I recognize from my team that if this would be one of those branch fixes, they'd probably first hide it and take more time for the actual resolution.
In addition to only mentioning, intentionally, one category of bugs we deal with, I did not mention that the timeframe I'm looking at is incremental feature addition to an existing architecture. The sister project I also work with is in the early stages of building the frame, and much of the issues there take longer to resolve. The frame for this product has, with all its limitations, been in production for almost two years, and I imagine (and have read from the bug database) that the earlier phases of the product lifecycle were different.
Eventually, all it takes for customers to not recover from finding a bug and getting it resolved quickly is one bug, that is relevant enough. Relevant enough to consider moving to competing products (assuming there was an option...), relevant enough to just make a move where the compensation for the customers losses would be something they seek.
One bug could still bring down important customer relationships. So for the bugs that we'd want customers to find, I still argue that we'd like to be informed - through testing - that none of them is the business-killer -type.
First of all, the bugs that I mention as samples in my "since April" timeframe are a small portion of all bugs logged and even smaller portion of all bugs fixed. These are a special category of things that when found - by real end users, and important enough for them to find the hard route in their organization to complain about it to us - will be addressed differently. We talk of them as branch fixes, basically just indicating we'll do single changes in two different versions separately to fix them.
I'm not happy with the amount of branch fixes. Our product managers are not happy with the amount of branch fixes. And most definitely, our developers are not happy with the amount of branch fixes. All I'm saying is that from the product manager's side, they did not actually see the valuable side of these in building the customer relation before they were asked about it. And there are other ways - while my theory still is that maybe not as effective - to get customers to answer the calls when sales people call and build a customer relationship on mutual successes.
Not all of our bugs are quick fixes. We've just been lucky that the ones customers have complained about (perhaps the ones they have understood well enough to complain about) have been that.
Just yesterday we were fixing something that was relevant for the users (internal users complained about it) that wasn't so easy - a browser specific issue on a functionality not working when clicked one way vs. the other. There was a workaround, not everyone would hit that but definitely, not an easy fix. I recognize from my team that if this would be one of those branch fixes, they'd probably first hide it and take more time for the actual resolution.
In addition to only mentioning, intentionally, one category of bugs we deal with, I did not mention that the timeframe I'm looking at is incremental feature addition to an existing architecture. The sister project I also work with is in the early stages of building the frame, and much of the issues there take longer to resolve. The frame for this product has, with all its limitations, been in production for almost two years, and I imagine (and have read from the bug database) that the earlier phases of the product lifecycle were different.
Eventually, all it takes for customers to not recover from finding a bug and getting it resolved quickly is one bug, that is relevant enough. Relevant enough to consider moving to competing products (assuming there was an option...), relevant enough to just make a move where the compensation for the customers losses would be something they seek.
One bug could still bring down important customer relationships. So for the bugs that we'd want customers to find, I still argue that we'd like to be informed - through testing - that none of them is the business-killer -type.
