In software engineering, we are often asked to deliver value. Yet, what exactly is software value?
The following questions and answers might help explain it:
What truly constitutes value?
Serving the customer true business needs as opposed to only responding to customer requests, thus providing true customer satisfaction in the long term.
Isn't value subjective?
Value can be subjective, thus requiring a lot of business analysis and usability research to figure out the best software to build. For example, in usability engineering, user testing involves observing users and discerning what serves their needs independently of what they say.
Isn't value the sole concern of the business?
Employees serve the business, and so business concerns become their own too, but each plays a specific role towards attaining software value. For example, in baseball one may think that winning is the sole concern of the team's head coach/general manager, and yet every player must keep that concern in mind while playing their specific role; pitcher, batter, or catcher.
Isn't value a vague term?
All terms are vague if you don't share context with others. Nonetheless, keeping value delivery in mind focuses us on doing what's right to truly serve the customer. Otherwise, we risk getting lost in copying the competition or offering people what they say without addressing their real concerns.
Isn't delivering value as obvious as doing what the manager asks you to do?
It could be if you're a junior software developer unable to discern value yet. As you grow and progress in the field though, you start bringing your own perspective regarding what value is and better discerning what serves the customer and business.
How about value being as obvious as making people feel good?
Feeling good is not the same as customer satisfaction. For example, if a user is getting work done with a piece of software, what serves their needs is doing work correctly and fast, which might not necessarily feel good as it's hard work. As such, you wouldn't target good feelings or else you risk falling into the trap of offering irrelevant features. For example, imagine online spreadsheet software that offers music playback as a feature because it feels good to listen to music while working. Obviously, this is useless for work software not concerning music and might even distract from a good job. Instead, target offering the best business and customer value by figuring out how to best serve business needs (e.g. cloud storage of spreadsheets instead of requiring upload/download on every use).
Always stay open-minded about the perspectives of your colleagues to come up with the best value. I like to share just enough of my opinion, while listening to other developers as well as other team players like usability designers, software architects, and quality assurance folks.
In summary, deliver software value, keep the business and customer in mind, and learn to focus on customer needs not wants.
The following questions and answers might help explain it:
What truly constitutes value?
Serving the customer true business needs as opposed to only responding to customer requests, thus providing true customer satisfaction in the long term.
Isn't value subjective?
Value can be subjective, thus requiring a lot of business analysis and usability research to figure out the best software to build. For example, in usability engineering, user testing involves observing users and discerning what serves their needs independently of what they say.
Isn't value the sole concern of the business?
Employees serve the business, and so business concerns become their own too, but each plays a specific role towards attaining software value. For example, in baseball one may think that winning is the sole concern of the team's head coach/general manager, and yet every player must keep that concern in mind while playing their specific role; pitcher, batter, or catcher.
Isn't value a vague term?
All terms are vague if you don't share context with others. Nonetheless, keeping value delivery in mind focuses us on doing what's right to truly serve the customer. Otherwise, we risk getting lost in copying the competition or offering people what they say without addressing their real concerns.
Isn't delivering value as obvious as doing what the manager asks you to do?
It could be if you're a junior software developer unable to discern value yet. As you grow and progress in the field though, you start bringing your own perspective regarding what value is and better discerning what serves the customer and business.
How about value being as obvious as making people feel good?
Feeling good is not the same as customer satisfaction. For example, if a user is getting work done with a piece of software, what serves their needs is doing work correctly and fast, which might not necessarily feel good as it's hard work. As such, you wouldn't target good feelings or else you risk falling into the trap of offering irrelevant features. For example, imagine online spreadsheet software that offers music playback as a feature because it feels good to listen to music while working. Obviously, this is useless for work software not concerning music and might even distract from a good job. Instead, target offering the best business and customer value by figuring out how to best serve business needs (e.g. cloud storage of spreadsheets instead of requiring upload/download on every use).
Always stay open-minded about the perspectives of your colleagues to come up with the best value. I like to share just enough of my opinion, while listening to other developers as well as other team players like usability designers, software architects, and quality assurance folks.
In summary, deliver software value, keep the business and customer in mind, and learn to focus on customer needs not wants.
No comments:
Post a Comment