Sanding our assholes with 150 grit.

Requirements review over and over and over....

This is something that always drives me insane - customer has a somewhat complex business model (don't they all).

So you go through requirements analysis to understand the model. After a week or so you pretty much have a mental handle on how everything works.

Then the DBA's need to do a requirements analysis to understand the business model, so you sit through another session of Q&A to understand the same thing.

Then some random manager needs to understand the model, so it's another session with the customer...

You get some other senior person involved in the project and arrange a proof of concept analysis with the customer. Senior guy starts off with "why don't you tell us about your business process so we make sure we're on the right foot..."

I think somewhere around the tenth iteration I start sitting in the back of the room and posting notes on message boards...

Philo
Permalink Philo 
January 5th, 2006
You need a technical writer. :)
Permalink Flasher T 
January 5th, 2006
Philo,

Why do you think it's like that? Are there things that could be changed to make that less likely to happen? Or, is that just the price of being in a Large Company?

I ask because with a lot of the agile stuff I've been working with the goal is to keep everyone involved to not have to waste time over and over. (Well, the goal is to provide running, quality software that provides value to the customer, but the above is a side effect of the overall goal).

I know MS has been trying to be more agile, and I'm curious if they have the flexibility to make that happen.

OR is it that this is a mix of third parties that you don't have any control over?
Permalink Cory Foy 
January 5th, 2006
The latter. :)

The way to manage it is to have a central, easy to browse repository of project information. I don't care if it's SharePoint, or a wiki, or dotnetnuke, or some Rational beast - the key parts are that
- it's easy to add information (stuff that has to be structured, meta-tagged, or approved never goes into a repository; make it as easy as "Upload and add a title")
- it's easy to find. Index it with a search engine and link the heck out of it
- discourage using email as a storage medium
- if you're a manager, encourage your team to keep up on the site by putting info *only* on the site (schedule a meeting on the site; see who shows up)

New people to the project - day one you sit them down, show them the site, tell them to start reading *and* posting questions.

Philo
Permalink Philo 
January 5th, 2006
" The latter. :)"

Gotcha. Then I totally understand. Sometimes there is nothing you can do, because people don't want to read their Wiki or Email or the Huge Poster On The Wall (c).

It always amazed me the level of detail you can get into with requirements and *still* get it wrong. And I could understand the first time. But why people drag themselves through that over and over amazes me.
Permalink Cory Foy 
January 5th, 2006
1. Video tape the conversations.
2. Bring people in from the start.
Permalink son of parnas 
January 5th, 2006
3. If management asks you to explain in detail, run away.
Permalink Mat Hall 
January 5th, 2006
Again - you need a technical writer. And you need to re-read Joel's ramblings about specs. :)
Permalink Flasher T 
January 5th, 2006
I'll agree with Flasher T. It's not easy to get "ideas" documented. But it eliminates a whole class of problems.

I am not talking about specifications yet. That's a distant milestone in time. Induction docs - anyone heard that before?

Once again, its difficult, I understand because of many reasons -

a) people already onboard don't have time;
b) no one wants to do it;
c) there's a lot of other _interesting_ things we keep for our free time; (anyone heard of forums? ;-))
d) documenting "ideas" is more nebulous than documenting "requirements" or "a techncial specification". It's also something that one needs conditioning to do. I'll quote Rory Blythe on that one, "Like you need to be conditioned to like yeast."
Permalink Sathyaish Chakravarthy 
January 5th, 2006
Philo is right. You use some easy to add/amend system that everyone has peer rights over and you dump everything into it.

Unfortunately you also need a leather whip and a pair of ankle cuffs to make them use it.
Permalink Simon Lucy 
January 5th, 2006
How does having a peer-managed system make learning the business model easier than asking someone to explain it to you?
Permalink MarkTAW 
January 5th, 2006
Because its in the interest of the stakeholders to have it understood. Peer involvement means users (and real users not just managers of managers) as well as suppliers, specifiers and the rest of the clutch of hangers on.
Permalink Simon Lucy 
January 5th, 2006
Nobody likes to take anyone else's word for anything. Ever notice when you're in the hospital every nurse/doctor/technician/orderly comes into the room and asks the exact same questions, then writes the information into the chart.

No one ever reads what the other people wrote; they just reinvent the wheel. I suppose project specs are the same way. Gotta get it straight from the horse's mouth (or in some projects, the other end of the horse).
Permalink Dana 
January 5th, 2006
It's because SOME FOLKS need to be seen as having the clout to request personal briefings.

What confers more prestige?

Scheduling a meeting (bring all your stuff) or reading the stuff online.

Push back (gently).
Permalink trollop 
January 5th, 2006

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: January, 2006 Other topics: January, 2006 Recent topics Recent topics