Why we need to be more than just programmers
Programming
How do you handle new job request? It seams to me that people in a fast moving company tend to run with things before they truly understand what is really needed.
Example:
The director of creative services wanted to put some graphs and charts on a web site that is used to support our dealers. Later they would do the official project that would result in quality print material. So for 20 min, every one threw around ideas of how this should be done. All of which would require lots of reprogramming to an old application that we are trying to phase out.
So I decided to speak up. I asked what are we trying to do, who are we really trying to support, can it be public or private. Once every one decided to answer, it became clear that all we needed to do is take the art work and turn it into PDF's that we could place on our public web sites. Turns out this would provide for our dealers and their customers which is more than they originally planned for. This took about 5 min.
My question for you is do you try to strip every request down to its lowest common denominator or do you just run with what ever the client thinks they need?
We need to be more than just programmers. We need to be a counselor and mediator. We need to counsel our clients just like a therapist counsels a patient. You ask open ended question that help to gather the information your looking for. We also have to play mediator when there is some conflict amongst the clients. Most of the time it turns out to be a misunderstanding or lack of knowledge that causes the conflict.
I know there are the fortunate programmers out there that have project managers to do this sort of thing. Those programmers have their own issues to deal with. I'm not one of them. I have to play all the rolls and I think there are more like me than not.
I guess my point is if an average programmer develops these skills, even he will become successful.
--
Phil
Example:
The director of creative services wanted to put some graphs and charts on a web site that is used to support our dealers. Later they would do the official project that would result in quality print material. So for 20 min, every one threw around ideas of how this should be done. All of which would require lots of reprogramming to an old application that we are trying to phase out.
So I decided to speak up. I asked what are we trying to do, who are we really trying to support, can it be public or private. Once every one decided to answer, it became clear that all we needed to do is take the art work and turn it into PDF's that we could place on our public web sites. Turns out this would provide for our dealers and their customers which is more than they originally planned for. This took about 5 min.
My question for you is do you try to strip every request down to its lowest common denominator or do you just run with what ever the client thinks they need?
We need to be more than just programmers. We need to be a counselor and mediator. We need to counsel our clients just like a therapist counsels a patient. You ask open ended question that help to gather the information your looking for. We also have to play mediator when there is some conflict amongst the clients. Most of the time it turns out to be a misunderstanding or lack of knowledge that causes the conflict.
I know there are the fortunate programmers out there that have project managers to do this sort of thing. Those programmers have their own issues to deal with. I'm not one of them. I have to play all the rolls and I think there are more like me than not.
I guess my point is if an average programmer develops these skills, even he will become successful.
--
Phil
fro said:
You are not alone. I often find myself in many roles at the same time. It can be very frustrating, but the one thing I always try to do, as you've stated, is break down the request to the lowest common denominator.
For most of my clients, this isn't a problem. They don't mind talking about what they want, and how we can make it better. The hard part comes into play when the request is coming from your boss (or higher). They don't see things the same way that we do, and they often don't care to. I can't even count how many times I've been told to "just get it done". Dealing with these situations have probably been the most difficult for me. You know what you're doing isn't going to be utilized, or you know that it can be so much better if you could get down to the meat of the request. It's just frustrating.
Anyway, back to your point. I strongly encourage programmers to truly understand what the client wants. The end result will be much better, and your client will more than likely be thrilled.
For most of my clients, this isn't a problem. They don't mind talking about what they want, and how we can make it better. The hard part comes into play when the request is coming from your boss (or higher). They don't see things the same way that we do, and they often don't care to. I can't even count how many times I've been told to "just get it done". Dealing with these situations have probably been the most difficult for me. You know what you're doing isn't going to be utilized, or you know that it can be so much better if you could get down to the meat of the request. It's just frustrating.
Anyway, back to your point. I strongly encourage programmers to truly understand what the client wants. The end result will be much better, and your client will more than likely be thrilled.
Phill said:
My boss was the way. It took me about three years to get him to listen and trust me. It just about killed me. I basically became confident enough in myself and started telling what was going to happen if we "just got it done". After a few things blew up in his face, he realized I was trying to cover his butt as much as I was trying to cover mine.
Loading....