Who's paying for this?
...so why are we talking to the users?
I like working with users as they often give really good feedback. They're the ones who have to live with the software every day so tend to be very clear about how it helps/hinders their work.
Is it naive to think that making users happy by meeting their requirements is the primary goal of a software delivery, though? In my experience, which is not in COTS software development, the end users are not paying for the software - their boss is. Yet we often grant users great import, perhaps because their feedback is more immediate and tangible. Granted, it is unlikely that giving users unusable software is going to prove successful. Conversely, giving users exactly what they want is also unlikely to be a success. For a start, it could well prove financially prohibitive (eg, technically difficult)!
I consider one of my responsibilities as an architect that of keeping delivery focused on what matters. Sometimes this may mean giving the users what they want, sometimes it may mean telling the users what they're getting (and helping smooth the transition). After all, change isn't always just about transparently replacing the technology.
I'm sure I'm not the only person who's worked on software that has delivered what users wanted but has never seen the light of day. Were the users wrong or were we simply speaking to the wrong people?
About the author
Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan developing front-office trading solutions.
While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).
E-mail : kevin.seal at codingthearchitecture.com
Re: Who's paying for this?
Re: Who's paying for this?
There are a lot of factors at play, especially in larger projects and organisations.
In your post, I interpret 'users' as a subset of 'stakeholders'. Depending on the political situation, users may or may not be important to overall viability of a solution.
Into the mix of stakeholders you of course include the sponsors, but also the IT staff (if that department is particularly influential they can even reject the entire solution) and others seemingly on the periphery, but who often wield big sticks.
Another problem can be around ineffectual sponsors - especially important if you're replacing an existing system. Getting the code done is often the easy bit; getting a department of 200 users who currently use a combination of X, Y, Z and manual processes to adapt the new system takes a hell of a lot of energy, influence and political bravery (you'll naturally be answerable to any cockups or problems). You can be sure that at least some of those users will hold influence with management and they will waste no time in complaining about the new system's problems; real or imagined.
One more thing, related to the adaption issue, is that version 1 of any release invariably contains a bunch of tradeoffs, compromises and 'TODOs'. Getting that balance right, in terms of features required to attract and keep users' attention is never easy.