TiAdiMundo wrote:
- a research team says: "IE7 must integrate an RSS reader"
- the IE team is coding the app
- a usability team says: "RSS feeds need an icon and the icon must be located there"
- and the design team says: "the RSS icon is orange and looks like that"
With all due respect, this would be a terrible way to run software development.
The research team gets to sit around and think up good thoughts about what products and features should be written. Everyone wants that job, because they don't actually have to deliver anything other than PowerPoint decks. Really making the product is someone else's job.
The usability team gets to sit around and think up good thoughts about what the most usable design is, again without having to actually deliver it - that's someone else's job. And that usability work is done with what, paper prototypes or Director-ware? That's not really going to cut it, now is it?
The design team gets to sit around and draw pretty and oh-so-consistent pictures about how everything should look. Never mind actually having to implement it, because (tah dah) that's someone else's job. I guess they get to fight with the usability team a lot, too.
Then we get to that coding team - the IE team. They apparently get stuck with making the product as determined by research, usability, and design.
Of course, they have no actual personal buy-in to creating a great app, because the feature set has been determined by the research team, the detailed functionality has been created by usability, and the appearance of the product has been set by design. There isn't a dev or PM who would want to work on the IE team, because they don't have any authority - they just have all the responsibility to actually deliver what everyone else says to deliver.
The right way to deliver software is to flip that around 180 degress and have the IE team actually have the authority to design their product as they see fit, and have the responsibility to deliver it. This makes people accountable for being right about their decisions, because authority and responsibility are connected.
These other teams - research (which we would call product planning), usability, and design - are all supporting teams. They certainly have the local expertise and act as advisors the IE team, but actually have little direct authority. The IE team gets to balance design vs. usability vs. product planning vs. implementability and all the rest, because the IE team is the sole team responsible for delivering they best product they can.