|
in reply to Musings: Why do well-intentioned projects go so wrong, so often?
Take the time to define “what does it do, and for whom does it do it?”
I think there's more to it than this -- it's an issue of managing expectations. and knowing your audience. Many programmers aren't willing to roll out without the full functionality, for fear they'll be forever judged by first impressions. (and I admit, I've done it more than a few times) For many larger projects, you need to get some of your intended audience involved early, and have them test incrementally, rather than to tell you that the whole thing sucks 2 weeks (or 2 days) before you're supposed to go live with it. Giving them a chance to interact with the system early and make recommendations can help get their buy-in, and they can champion the project to their peers. You need to really know what it is that people want from the system, and be realistic about what you can deliver given the resources available. If there's something that people really want, but won't be available 'til version 2.0, let them know, and let them know early -- you don't need them badmouthing they system because it's missing some (seemingly minor) functionality that they really wanted. If there are things they truly need, then you either need to make sure it gets into the first public release, or only roll it out to a subset of the audience that doesn't require that function. (which means it also has to play well without whatever systems already exist, and hopefully, people won't have to keep switching back and forth between the old and new systems)
Programmers need to talk to their users -- they know what they want, normally. They might want stuff that we can't give them, but they can let us know what is critical for their work. If we don't understand what the purpose of our systems are in the larger context of their work, we're doomed to fail. |
Re^2: Musings: Why do well-intentioned projects go so wrong, so often?
by Jenda (Abbot) on Dec 04, 2007 at 22:58 UTC
|
I would dare to reword and redirect the last paragraph:
Programmers need to be allowed to talk to their users -- they know what they want, normally. The users might want stuff that the programmers can't give them, but the users can best let the programmers know what is critical for their work. If the programmers don't understand what the purpose of their systems are in the larger context of the users' work, we are all doomed to fail. "Send your questions to our project manager, who will tell it to the secretary, that'll mail it using her own words to the secretary of the (whatever level) boss within the client, who'll eventually forward it to someone who may eventually end up using the system being built and whose response wil travel the same way and end up in the developers mailbox within mere two or three days" doesn't cut it. Don't protect the developers from the potential users and the potential users from the developers!
| [reply] |
|
|
Just to reemphasize your rewording and redirection, the delays and paraphrasing that you mention are just the tip of that iceberg. In my experience, lack of direct contact with the actual end users tends to end up with the software being built to do what the end users' manager thinks they need (or, still worse, what the manager thinks they should need), which often has little or no connection to the reality of what the end users will be doing with it.
Design-by-management-proxy also tends to lead to the software being created solely to duplicate the existing process(es), but with newer, flashier technology, while allowing the developers to get in there, talk to the users, and actually gain at least a rudimentary understanding of not only what the end users are/will be doing, but also why will often allow for better processes to be developed.
| [reply] |
|
|
I know where you're coming from, but I think we're in two slightly different situations here ... you're likely dealing with a case where people are forced to use the project. I've been in that situation, and people complain about what they don't like, but they might not send it to the right people, and might take days for it to reach the developers (if ever).
On my more current work, I'm building software that is completely optional. It's intended to help people, but no one's being forced to use it. When I built the system for Fark -- if people weren't happy, they'd leave ... we had no idea why, and really, we didn't care. (this was well before Drew was selling advertising) The submission queue was just to make it easier on the admin, so we could weed out the crap people were submitting.
Now, I'm working on software to help scientists find data. They have other ways to find their data, so most don't bother using what we have ... if they use it, and aren't instantly happy with it, they don't fill out the feedback forms or e-mail us ... they just go away. So, once or twice a year, I go to conferences to tell people about new features and try to get the scientists to tell me what they want as new features ... some aren't willing to tell you what they're looking for, as it might tip their hand on what sort of research they're trying to get funding for, others are just happy with their current methods and don't care.
... Of course, in some ways, I've probably harmed the users by taking to them. I tried sending out an explanation of what's wrong with some of the catalogs, and someone asked 'what's "normalized data"'? We speak completely different languages when talking about the same problems, but I can't design an interface for their use without understanding how they think about their problems and the words they use to discuss concepts within their specialty. But, anyway, I think jenda and I both agree -- developers and the users need to interact, so we can understand what the users want and can fix the problems they find.
| [reply] |
|
|
