var blog = new ThoughtStream(me); RSS 2.0
 Thursday, August 28, 2008

The one and only goal in software development is to provide useful, functional software that creates value for the customer or consumer. Period. End of story. Not open for discussion or opinions.

If you want to deliver software that the customer or consumer wants to use, likes to use, and ultimately does use to help solve problems and/or automate business process, etc, then you must know what the customer or consumer values. In other words - you can't identify your software's 'value' if you don't know who/what ALL of your customers are.

I'd put money down to say that most software developers - perhaps most software development companies - have no clue how many customers and consumers there really are for any given software project. The one consistent answer that I would expect from every developer or company is that the person, group, or company paying money for the software is the customer. This is 100%, absolutely true. In addition to the paying customer, though, there are many other customers or consumers that need to be identified.

As a starter, consider the following list for the customers / consumers of your software:

  • The paying customer
  • Integrated external systems
  • API consuming systems
  • Software Testers and Test Lab personnel
  • Technical and documentation writers
  • Software developers (the ones writing the code!)

I know, I know... how could a software developer possibly be considered a customer or consumer of the software that they are writing? The answer should be obvious - who reads and writes the code? who maintains the code and needs to understand how the code is structured so it can be maintained? If you don't believe that your software developers are first class consumers of the system that they are writing, I would bet that you have a horribly complex kludge of code that no one wants to work on. If your developers are considered first class consumers of the code they are writing, I would bet that your team is happy and is constantly working toward better code - simple, readable, maintainable systems that are fun to work on.

So, who are your customers or consumers? What value do they need in your system and from your system? And, how are you and your team responding to those value needs (if at all)?

Thursday, August 28, 2008 7:33:54 AM (Central Standard Time, UTC-06:00)  #    Comments [2]. Trackback 
Tags: General | Lean Systems | Management
Tracked by:
"Re: Quality and code coverage" (ThoughtStream.Create(me);) [Trackback]

Thursday, August 28, 2008 8:04:51 AM (Central Standard Time, UTC-06:00)
At the beginning of a project, I start with the following exercise, that is Essentially, we set a time-box (usually 5-30 minutes, depending on the sheer number of stakeholders in the system), and we enumerate all of the stakeholders, one per card. For each stakeholder, we list the goals and concerns that they have relative to the system under discussion. Finally, we prioritize them. Everything else we do, we try to vet against this set of goals and priorities. As we dig in, we often find that we misunderstood the priorities and goals, but it is great to have them framed.

I want to take it one step further and develop lightweight (cooper-esque) personas for the higher priority stakeholders, but I haven't done that in practice yet. I am a little concerned about the potential for analysis paralysis in that process, so I would want to time-box it tightly at the risk of reducing the fidelity of the personas.

Great post!
Thursday, August 28, 2008 1:38:37 PM (Central Standard Time, UTC-06:00)
@jef,

100% on board with that! I've been introducing the same process and concepts into my team(s), with the help of our UX team lead (who is a huge Alan Cooper fan, and now an agile convert). It's been a huge help for us in understand our roles for user stories, the needs of the business and users of the system, etc.

What I really want to see is developers, api consumers, testers, etc. included in the list of stakeholders with their value needs defined. These team stakeholders can probably have some cookie-cutter, copy & paste values across projects - they just need to be identified and accounted for.
Comments are closed.
Navigation
About Me
View Derick Bailey's profile on LinkedIn

Send mail to the author(s) Contact Me
Archive
<July 2010>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010
Derick Bailey
Sign In
Statistics
Total Posts: 115
This Year: 0
This Month: 0
This Week: 0
Comments: 44
Themes
Pick a theme:
All Content © 2010, Derick Bailey
DasBlog theme 'Business' created by Christoph De Baene (delarou)