Forget about what customers want—or at least, what they say they want—for a minute.
People with software development experience will want to talk about non-functional attributes, such as performance, scalability, capacity, usability, flexibility, maintainability, etc. They may not be familiar with Tom Gilb’s "Principles of Software Engineering Management,” a favorite book of mine (see Amazon.com), but they would probably agree with his statement on the importance of managing critical, non-functional attributes:
The Achilles’ Heel Principle:
Projects which fail to specify their goals clearly, and fail to exercise control over even one single critical attribute, can expect project failure to be caused by that attribute.
Software architects often struggle to convince other stakeholders that strict attention to non-functional attributes is vital to project success. But even architects and senior developers often miss one of the critical attributes. In fact their regard for it sometimes resembles the sales team’s regard for something as meaningless (to them) as maintainability.
The neglected nonfunctional requirement?
Operability: i.e., the ability to actually support the software after it has been launched.
To consider whether operability is being overlooked on your project, think about your answer some questions—there are more, but here’s a starter:
- Are operations specialists (network and database administrators, customer support teams, any others who will be running the show when it’s in the hands of its users) involved throughout the entire development process?
- Do they gain frequent experience with the software by deploying it into production-like environments?
- Are you delivering functionality to customers in small increments? (Just as “big bang” doesn’t work well for customers, it’s usually a disaster for operations.)
- Do developers need permission in the production environment to see data, logs, etc., on a regular basis (or, heaven forbid, to “fix” data or configurations)?
- Is deployment to the production a nail-biting experience?
- Does customer support know how to use the software?
- If customers need training, has it been done, and using what materials? Has the customer support team (and the development team) gotten feedback feedback from these sessions?
Like most of the other nonfunctional requirements, operability provides no "business value" to the marketing team.
Until you have actual customers, that is.
Then we find that everyone wants operability.