But this message needs to be widely understood across the company.
Scenarios that I have frequently encountered:
- Software Engineering develops features because they are 'cool' or based on the CEO saying, 'Wouldn't it be great if ....'
- Software Engineering spends ages crafting out a solution to a long-tail problem where an 80/20 approach would be much more valuable
- Testing validates the product feature based the product specification from Engineering (see previous point), not based on how the product would be used in an operational environment.
- As a tester in Dallas, Texas, I recall spending days testing a product feature only to be told that this particular narrow shard of functionality gets used about 5 times a year and only as a tool of last resort and only by highly experienced users who didn't need all the defensive protection from poor data entry or illogical data flows that had been tirelessly testing.
- Research teams working on the functionally interesting problem and NOT on the biggest risk to the overall commercial success of the suggestion - which is frequently customer adoption in a competitive market. Poor research (or usually no research) is a HUGE waste of Development's team - a topic worthy of another blog post.
Post a Comment