You’ve delivered a new or improved software application. Congratulations! Now you find that the software is not receiving the enthusiastic reception you expected. Some people are complaining about defects. Others are whining about missing features. Something seems to have gone wrong.
Unfortunately, this scenario is more common than not in software development. We can try our best to do the right things and still end up with a less than satisfactory result. Let’s explore some reasons why this happens by asking a few questions.
1. Who is your customer?
It’s not enough to say the typical user of your software is a finance professional or a trendy clothing shopper. Those statements are broad and boring. Be more specific. You need a persona or perhaps several. You can appeal to multiple personas as long as the software is configurable such that it wows each defined persona.
To build personas, think about a user’s age, sex, education, expertise, interests, location, etc. These characteristics will help the team build better software.
2. What do you expect from each member of the development team?
It’s great to have team members who can switch hit — they can fit into more than one role. But in the end, everyone must excel at something. Everyone must be held accountable for something. Be clear about what skills you need on the team. Assign clear roles and responsibilities to every member of the team.
For example, the user experience, the database design, the system architecture, and the data structures have to be controlled. You can’t have everyone on the team doing it their way.
3. Do you have the right people on your team?
Great software developers build great software systems. Mediocre developers build junk. No amount of management, development process, or documentation can overcome mediocrity. Hire good people. Train them; motivate them; reward them; repeat!
You can train a good software engineer to excel in many areas. However, someone who lacks a strong work ethic and is unwilling to cooperate with the team will never succeed. Weed them out.
4. What are the most important features of the software?
Many software systems have too many features. It can often be a nightmare trying to install, configure and use a new software application. Yet most buyers have a targeted use for the software. Be sure the critical features are front and center. Relate those features back to the personas you defined.
If you’re building a shopping application, you’ll be pushed to add social media features because everyone else is doing it. That’s fine but never lose sight of the primary purpose of the application. People will use the software to shop not socialize!
5. What are the critical non-functional requirements of the software?
Sometimes it’s easy to imagine the software at a high level. It may even be simple to get basic software functions up and running quickly. What really sets great software systems apart from all the rest are the non-functional aspects — performance, reliability, navigation, security, resource utilization, installation, and configuration.
Emphasize the non-functional needs in your user story acceptance criteria. No story is truly done until it can deliver results fast, securely and reliably.
6. What feedback are you getting about the software?
You are collecting specific user feedback, right? There will be lots of noise in the feedback stream. Some people can never be satisfied. Sift through the feedback and get to the focused comments from people who take the time to respond in depth. Read their comments carefully. Engage them in a dialog if possible. You may find that a few simple software changes will make a huge difference in user acceptance.
Tie these comments back to personas and important features. If you’ve missed the mark, fix it — fast. Don’t chase every user request. Stay focused on what really matters.