|
One of the textbooks I read for the Systems Engineering course presented a list of "Factors that may delay your project". It included "The customer is inexperienced in data processing", and a little further down the list "The customer is experienced in data processing".
This is long ago, when there were people who had no experience with computers and data processing. Today we might add a third option "Customer believes he is experienced, but in fact doesn't understand a sh*t".
On the more serious side : Seeing the customer gradually brighten up and becoming increasingly more eager as he begins to understand what he is really doing, is one of the my great pleasures at work. Actually, one of projects I was involved with didn't include a single line of coding: The task was to create a complete data model (in those days it was an Entity-Relationship model - an excellent modelling tool!) for the total information flow in the city administration of a town of 200.000 inhabitants. Years later they thanked us for helping them clean up their manual procedures!
On a smaller scale, I have had similar experiences several times: Helping the customer understand what he is really doing, is a great pleasure, and is essential to building a system that satisfies the real needs. Plus the customer.
|
|
|
|
|
Member 7989122 wrote: Customer believes he is experienced, but in fact doesn't understand a sh*t A bit worse, now? They think that that using their phone makes them tech-savvy. After all, doesn't the TV, which they stream on their phone, tell them that?
The occasional bit of sparkle is that user who can understand how I need to (actually like to) turn their work into an abstraction. What is it they are doing, in general. What processes are really just the same process with different makeup and shoes. And this few, once they get the idea, also realize that their shiny new application is both robust and extensible, which are two words they can throw out at a meeting, showing how savvy they are.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Shooting the engineer and going into production.
|
|
|
|
|
|
If it's worth doing then it's worth overdoing.
No, go and lie down until that thought passes.
Stick to the spec and if it goes wrong blame the authors.
|
|
|
|
|
My usual problem is that the customer change its mind faster than I can do the app.
At beginning, we have a meeting to make sure what he wants.
But a week later something changed and now he is sure.
But another week later, something changed again or an unknown constraint appear from nowhere.
...
And after, he don't understand the reason why it takes so long to get the app.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
ppolymorphe wrote: My usual problem is that the customer change its mind faster than I can do the app.
This is the part that has made me not enjoy development anymore. The constant mind changing, mixed with the why isn't it done yet...
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
This is totally my personal experience too.
|
|
|
|
|
I know not all companies. But where I work now.. Business can't decide. Then they do, then they change their minds.
Or they give 1 liner specs..
|
|
|
|
|
Sundance Kid wrote: Or they give 1 liner specs..
What do you call a signed check where the amount has not yet been filled in?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I wish.
But salaried employee I can't make more $$ out of this. Just more stress..
But the funny thing is , we as dev/delivery team are held under great scrutiny. But business can do whatever they like... ughh.
|
|
|
|
|
Sundance Kid wrote: But salaried employee I can't make more $$ out of this. Ok.
Sundance Kid wrote: Just more stress.. Why? Do it as it suits you best and have a good laugh at them when they come crying. Rinse and repeat until they finally learn it.
You are doing something wrong if you let them stress you. Just handwave the results back to them and let them stress themselves.
Always be careful what you ask for. You might get it.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Quote: when they come crying
I agree, but they usually blame the delivery team(s). It's a weird scenario here.
But long story short our Sol Arch helped business for years (as a dev). He is not deving anymore, but now business expects all of us to keep "helping" aka doing their work as the SA did for years.
The SA actually almost "run" the business. Now business is clueless...
I don't stress anymore about this. Used to... but not
|
|
|
|
|
Sundance Kid wrote: Now business is clueless... A constant of nature, obviously.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
Sundance Kid wrote: Business can't decide. In my experience it is usually less that the business can't decide and more that the business doesn't know. They think they want the program to do what they call "X" but in reality it is more "Y".
The job of a good BA/BRM/PM/etc. is figuring out what "Y" actually is.
Sundance Kid wrote: then they change their minds. This is what I hate about 'agile' development. The business side tries to use it as an excuse to not think out their actual requirements.
Sundance Kid wrote: they give 1 liner specs Your BA/BRM/PM/etc. is failing the development team. This should not be an acceptable response to any spec request. As far as pet peeves, this goes right up on there with "Doesn't work" for details in a bug report.
|
|
|
|
|
Quote: The job of a good BA/BRM/PM/etc. is figuring out what "Y" actually is.
That is the problem here.. not good BA/Product Owners etc.
|
|
|
|
|
Well, you could have the alternative. No BA and the developer is expected to work directly with the customers and product owners to perform all of the BA/PM/Architect/Designer/Dev/Tester roles.
On the plus side, it has really rounded out my skill set and expanded my options in the job market.
The bad part is that I don't officially have any of those those titles so HR types don't care what I actually know.
|
|
|
|
|
If I had to work directly with customers I would run away... far far away.
This is too much work for 1 person/dev. You would never deliver anything. And we have many customers (> 10 on 1 "product").
|
|
|
|
|
Spot on - I've suffered through too many one-liner "specs", along with CXO's and senior management changing their minds more often in a day then they change their underwear in a month.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
|
There are apps for anything, and they are all invariably useless except for a handful of them, which are ugly. I prefer working in other fields.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
"All of the above"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|