3 ms·

Software developers are incredibly poor at gathering requirements. The best choice for gathering those requirements is to have a management consultant who does

Software developers are incredibly poor at gathering requirements. The best choice for gathering those requirements is to have a management consultant who does nothing but study business process and document the current clinical process. Once that's documented then you can discuss what needs to change from that document to extract the core requirements. Having a software person shadow a medical professional will only lead to the medical professional telling the software person what they think is needed. In other words, decouple system analysis from system design.

protomyth 8y ago
Software developers are incredibly poor at gathering requirements. I've had the opposite experience. Good software developers are good at gathering and understanding requirements. The information loss from management consultants and software developers is pretty nasty. Frankly, if the the people coding the system are going off a requirements document that they didn't have a hand in then you might as well outsource the development. If the software developers don't become domain experts then you should be worried about the correctness of the software. I often wonder if the general dislike of DSLs is caught up in this separation.
sonnyblarney 8y ago
I would opt for a talented experience designer over a consultant. The goal is not to 'document how it's done'. The goal is to understand 'what problems are being solved, and possibly how to do them better'. Someone analyzing horses and coaches might have requested more horses or coaches, when really what was needed was this new thing called 'a car'. So someone who is thoughtful, organized, who can communicate, and who understands technology. Would be a good start. Without any kind of professional discipline however, it's hard to find and evaluate such people.
magicalhippo 8y ago
> Software developers are incredibly poor at gathering requirements. Customers are also often incredibly poor at defining their requirements, at least in my experience. Like having undocumented routines which are only recalled by that one employee once they have to actually perform them, once a year or so. Of course it's usually a really critical, time-sensitive issue when they discover that the routine they never told us about hasn't been implemented and thus cannot be done... almost never fails that.

protomyth 8y ago

Software developers are incredibly poor at gathering requirements. I've had the opposite experience. Good software developers are good at gathering and understanding requirements. The information loss from management consultants and software developers is pretty nasty. Frankly, if the the people coding the system are going off a requirements document that they didn't have a hand in then you might as well outsource the development. If the software developers don't become domain experts then you should be worried about the correctness of the software. I often wonder if the general dislike of DSLs is caught up in this separation.

sonnyblarney 8y ago

I would opt for a talented experience designer over a consultant. The goal is not to 'document how it's done'. The goal is to understand 'what problems are being solved, and possibly how to do them better'. Someone analyzing horses and coaches might have requested more horses or coaches, when really what was needed was this new thing called 'a car'. So someone who is thoughtful, organized, who can communicate, and who understands technology. Would be a good start. Without any kind of professional discipline however, it's hard to find and evaluate such people.

magicalhippo 8y ago

> Software developers are incredibly poor at gathering requirements. Customers are also often incredibly poor at defining their requirements, at least in my experience. Like having undocumented routines which are only recalled by that one employee once they have to actually perform them, once a year or so. Of course it's usually a really critical, time-sensitive issue when they discover that the routine they never told us about hasn't been implemented and thus cannot be done... almost never fails that.