How do I develop good spec's for a system? Good question.
My brother headed an IT department in a subsidiary of Sara Lee. Even as a programmer, he always approached programming assignments differently than anyone else. He didn't know he wasn't supposed to do that. When they told him to write an inventory control system to be used in one of the food freezers, his approach to it was, "I need to go spend a week in a freezer with a clipboard and a pencil."
He tells the story: "When we talked about the system, we first came up with these little hand held radio frequency devices for the fork lift drivers to operate when they were in the freezer. But we didn't know, we didn't think about it, when we were back in the programming shop, these guys have big, thick gloves on. They can't operate one of these little hand held devices, they'd be pushing four buttons at the same time. But when I spent the time in the freezer, I had to put the gloves on and I had to hold this little thing and say, "How am I going to do this? Am I going to do it with a pencil?" So that's how I approached things. You had to do it. You had to be a part of it. You had to understand it before you could write any programs for it."
It's the people component that is the critical aspect of a system. Coming up with the ideas, just as coming up with the technology and the techniques or the methods, is really only half of the equation. It's having it be used in a day to day environment and having it function well, that completes the picture.
Part of the secret to productivity is that it gets used; it gets adopted. You can't really talk about the success criteria without talking about the adoption factor. If it's adopted, that's a key aspect of it.
Think about this. Grab a clipboard and stand behind your users for a day. Watch what they do. Discover the pain points and the hidden factors. Then write your specs. |