Was having some beers the other week with a good friend, Hairy Dave. Being hairy, he is one of natures programmers born and bred. Anyhow, having been a librarian who's now converted into an analyst, I have over recent years moved from a position of "Hairy Dave's talking gibberish with long strange words" to being able to hold a fiarly reasonable conversation with him regarding IT. Over recent months, as I have actively tried to develop myself, we've began talking about methodolgies and process generally, and analysis specifically.
You see, as a programmer, Dave is fearful (read "can't see the point) of analyists. He was very much a "just code something". Now, it was excellent, clever code cuz he's a VERY clever man but at no point did the user get involved. They had one user rep at the time, a programmer who developed their system x years ago, and he was too busy to give them more than "it needs to do that" - despite the fact that knowledge was now out of date. Dave used to go on about all the probs they'd created, or solutions they provided which turned out didn't match any problem the users actually had, and I'd expound about analysis, talking to the users, understanding their process, etc. He'd politely nod, quaff more ale, and so the evening would progress with increasing amounts of arm waving.
This weekend, we had a breakthrough. Dave's just started working for a new company and he was instructed to go and talk to the users "for an hour" to find out what they wanted. It sounded to me a bit like "we need to tick that off the project plan, so we can move to coding". Now I've been passing Dave on various useful sites recently, like agile modelling. He even sent me one, for Joel (which I'd read and loved - particularly his stuff on functional specs, which I immediately directed Dave to). Turns out Dave ended up with these users for 4 hours. He discovered that not only was the software they were using a direct barrier to their workflow (e.g. we do this, then this, then this, then this just to do this) or different to their business process (e.g we can't do this, which we do every day), or completely invalid (e.g. we never use this) but actually discovered they were not doing some other things which they should have been. He left and actually wrote code that turned 10 steps into 1 for the users, added tweaks that made a BIG difference to their lives, and reported back that certain "mandatory" tasks the business required just weren't being done.
But the great thing was how he talked about how valuable the expereince was, about how he actually knew he was programming"the right thing" and the reward that bought, about how difficult it was to find out what the user actually wanted and how he wished he had better ways of finding out. He knew he'd done ok, but knew he could do better. And - the best of all - that he wants to recommend they bring a business analyst in because they ADD VALUE.
He got it. Finally. He recognised the analysts role. He realised he could do it, but lacked the skill set, thus acknowledging there WAS a skill set.
I nearly bought him a beer, but remembered he earns more than me, being a programmer. Hmmm, thats another story for another time...
No comments:
Post a Comment