http://qs321.pair.com?node_id=115784


in reply to Specify, Specify, Specify

I grew up in programming in very small shops, where formal requirements were seldom, if ever used. I prided myself on my "customer service" and flexibility. If the customer wasn't happy with my guess, then I'd be happy to fix it. And fix it again ...As time went by the constant re-work that this mindset doomed me to began to wear on me. Projects didn't get done well, or even done. I began to see the users as adversaries, something I happen to believe is the kiss of death in this field.

A few years ago I started working with an App Development Manager who insisted that end users come up with clear specifications before work began. Many of the end users were used to the previous style and would say things like "Oh, you just throw something together for me and I'll change what I don't like" This manager would politely point out that our (the IT departments) time was a scarce resource and was not going to be used in guessing games. And that, to me was a new way of thinking.

Our time, knowledge, and talents are a scarce resource, whether we are more admin/DBA monks like me, or design wizards like Ovid. We need to use this resource wisely so we can be people who are smart, and get things done. Requirements cut down on re-work by exposing flaws in the business rules, or shortages of resources needed, before we attempt the first line of code.

I've had end users react in various ways to the requirement of clear specifications. Some think I'm shirking my responsibilities and are making them do my job. Some become treasured allies in the design/build process. Some get lost in the details. Some never come back with a spec!

In the end I can say we have less re-work, less finger-pointing, and more productivity. We also have much clearer communications between the users and IT staff. It's been a win for all.

Replies are listed 'Best First'.
Flexibility and Politics
by Ea (Chaplain) on Oct 01, 2001 at 18:31 UTC
    I still am in the small shops and we have taken advantage of the fast turn-around inherant in Perl to produce 0.1 style versions of what is requested. This prompts the user to respond with more details. A rapid developement cycle gets to the end result faster with more end-user satisfaction (especially if they feel they've been in on the consultation process). It's also a defensive manouver in an environment where we get a lot of spurious requests.

    The politics of the situation is that we have to be seen to deal with poorly thought-out demands, with few staff, or be labeled obstructionists to management by those with an axe to grind. Our best weapon is a quick response, placing the onus back on the user to specify what they really want. That, and a web-based requisition system that users are encouraged to use to track progress on their whim^Wrequests.

    Ea :wq