Doug, Thanks for the clarifications. I guess there are multiple schools of thought on this but your logic makes sense. One issue, though, is with the RFE process itself. I've never worked on applications that were being sold outside of my employer so I haven't had to deal with it before, but it seems like the RFE process is a bit mysterious. We can submit RFEs, but there doesn't seem to be a good way to tell what is going on with them. If I were to submit an RFE that I was passionate about, but there was no way of knowing if BMC engineering were evaluating it or actually going to enhance the feature in the next version, I would be discouraged from submitting many more RFEs after that. It does seem like our RFEs often go into a black hole, which has an impact on those of us that do both ARS development and support ITSM. For example, if I submit an RFE and get no feedback from BMC, I don't have sufficient information to decide whether to go ahead and build the solution myself as a customization, or if I should tell my customers it would be released in a patch in two months or if it will be included in ITSM 8.0 to be released even further out. I think if the RFE process were a little less mysterious, we would be more inclined to submit them.
Thanks, Shawn Pierson Remedy Developer | Southern Union From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 1:49 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) "As designed" response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the "as designed" labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are "as designed" that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are "as designed" but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number of significant cleanups in the applications in the past few releases and we are getting good response to the 7.6.3 release and another wave of consistency is coming in the next few releases. Also, some modularization going on inside the applications is making it more likely that consistent interaction will occur in many areas with more sharing of logic and interaction. This is a good discussion and it is important to keep BMC honest and not just hide behind an "as designed" shield. Please keep up the pressure. But, I hope this note has helped to explain a bit about why there are differences in something not working at all vs. not working best because another way is better and why they are different and why the difference is an important one in deciding how to respond to the report. I hope it also has helped encourage more submissions of RFEs to report consistency problems and ask for better in future releases. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 10:54 AM To: arslist@ARSLIST.ORG Subject: "Working as designed" type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as "working as designed" The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a "Design Defect" classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like "Working As Designed" is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"