I was recently discussing an upcoming project with the VP of our group, part of the discussion went to process (as I am the process wonk in my group) and inevitably it drifted to Scrum and Agile methods as they are something I have been talking about over the past year. We do have a good methodology that works well for the development and testing we need to do, its not Agile and potentially could be, but would take a lot of restructuring that upper management is not yet convinced we need since we still deliver very stable software. The next project has a PRD that was coming out, and the teams were reviewing the document I asked who was going to play the part of the Customer Advocate? Who were our domain experts for the product?
The answer - QA.
I was a little dumbfounded, while I will admit we know the product and have a good idea of what a Customer is going to do with our software, were we really in tune with the day to day usage of the product? Were we too close to see some things? Was Development equally as capable since they do some design, which even our lab manager questions and he is representative of the Customer, but the response is the Customer wants it that way. Which makes no sense to some of us, especially the lab manager as he is as close to a Customer as we get, but the response is sometimes that if we needed improvements or changes like we have mentioned they would come through support. To date few have. Still I kept coming back to the real question - is QA really the Customer? Do we really have a good grasp of the Customer's needs and wants and know how they will use the product day to day?
I was not so sure.
Individually the QA Team has an understanding of how the product works, and what it should do, one or two of us have a wide grasp of the product while the rest know our areas really well and have some pockets of knowledge in others. Its a complex product, but would a Customer really use all its features or just those that help them resolve their problems? What were the problems we were trying to solve? Those problems were stated and we knew them, and knew the areas of the product that solved those problems, the new PRD was more on topic with not only stating the problems but gave more detailed User Scenarios than we've had before. Did that close the knowledge gap? Not really, because we have a good grasp of the high level issues and stated problems, we know the solutions for them and how to test them - but something still nagged at me and it was historical.
Last year we had some discussions on how to improve things, we split into teams that discussed how to improve our process and product more - one item showed up on multiple lists - more meetings and discussions with Customers. We don't often know who our Customers are, and in the two years I have been asking I have yet to get anything that shows what platforms our Customers run software on, the only time I know is when I get an issue escalated from a Customer. Since "more meetings with Customers" kept showing up, were we really meeting the Customer's stated needs, or were we meeting the needs as filtered through the Product Managers who talked to the Customers about their needs? Sort of like playing Operator, need A gets said to Product Manager A who then tells Need A to Product Manager B who is also hearing Need B from Product Manager C and its all filtered up into a document that states Need C, an amalgamation of Need A and Need B. But does that make it a real example of the Customer Need or is there still a disconnect? I'm of the opinion that regardless of how much a Product Manager discusses needs with the Customer there is a gap in either experience, knowledge or use that is not quite bridged.
When the same question came up later with a different group of people and there were discussions about the PRD and what we need, some said it was a good document while I and others said its nice but we need Customers to look at it. Regardless of how much we know about the product and its use we often can't bridge the How, this is why people use the mantra of "eat your own dog food", if you cannot get the product to work in your environment for its intended use then no one else will. Customer Advocates are good, and this is what I am trying to bring in for Agile because I think it will improve our product, we can have Customer Advocates at all levels and test or develop with that in mind, but sometimes you need someone outside all of that who will use the product and give you honest feedback.
In otherwords, a Customer.
No comments:
Post a Comment