다음을 통해 공유

Taxonomy of a Product Team's Roles at Microsoft

  • 아티클

I started posting this as a blog response elsewhere, and then I decided that I was having way too much fun composing it to leave it stranded as a mere comment... so here is my take on Product Team Roles at Microsoft.

Yes, read it with a grain of salt, good humor, and enjoy the self-deprecating satire... ;-)

For those of you who aren't aware of the typical Product Team Roles at Microsoft, they are (in no particular order of preference):

  • Development
  • Test
  • Program Management
  • Management
  • Documentation

Now, the first role, Development, is pretty obvious - you don't have a software product without code. Developers deal with writing code; lots of code. They prefer to not deal with Testers who keep filing bugs against their code, Program Managers who keep changing the code's supposedly intended behavior, and Management who keep changing the schedule... because they all prevent him from writing lots and lots of code. Hmm, I guess that's what makes Open Source appealing - no Testing, no Customer design, and no Schedules... and lots of code of dubious value. ;-)

But what the heck about the remaining roles?

Test

Well, you want to make sure that software does not crash and format your hard drive all the time, right?

Testers deal with validating Developer's code against Program Manager's ideas that have never been written down and in the insanely short amount of time that Management schedules.

They prefer to not deal with Program Managers that keep changing their ideas (and hence require tests to be updated), Developers that do not want to fix anything and pile up bugs, or Management who want the testing completed yesterday... because they all prevent him from having a work/life balance.

Program Management

Well, you want that software to actually do what you want and not what the developer THINKS you want, right?

Program Managers deal with ideas and never writes it down because it immediately changes and is out-of-date.

They prefer to come up with ideas and want to just get their way, so they prefer to not deal with Developers and Testers who do not cooperate and want a life. Some of them are actually smart and interact with customers to get ideas via mediums like blogs... instead of just dreaming up features in a vacuum and arguing about customers in the abstract...

Management

Ok, they perform a necessary but thankless job. They like:

  • Getting in the way of Test/Dev/PM of doing their jobs by asking them what they are doing with weekly TPS status reports
  • Deciding what bugs to fix when they often have no context on the bug's issue
  • Making up and breaking schedules
  • Making/Enforcing "mandates" and "rules"
  • Holding all the team funds
  • Oh, and they have to heard cats to move in one direction and on-time. :-D

Documentation

Ok, they also perform another necessary but thankless job. They like:

  • Getting in the way of Test/Dev/PM of doing their jobs by asking them what they are doing (so that they can presumably "document" it)
  • Deciding on what information to keep/remove in documentation when they often have no context on the raw information involved
  • Alter schedules all the time because the product schedule changes
  • Making/Enforcing mandates and rules for what should be documented
  • Oh, and they have to perform "technical edits" of raw information into the sanitized forms you see on MSDN and KB

I find amazing similarities between Management and Documentation, where one is a project of code and the other is a project of words that accompany the code. But if you think about it, both are really just "overhead". ;-)

If I had my way, I would simply pay the Developer/Tester/Program Manager to write Documentation as a Wiki or Blog entries. Do you want more things like my blog entries or more things like "sanitized" KB articles or MSDN/Technet articles? Can you imagine the changes when we can actually write Documentation which does not get filtered by someone else?

In Conclusion...

Hehe... sometimes, I am amazed that in the middle of all this, we actually find time and energy to ship useful software. But, we all definitely try our best to navigate through the madness and red-tape.

Now that I've done my bit of satirical insight into the organization that is Microsoft... I would love to hear about your favorite job euphemisms. :-)

//David

Comments

  • Anonymous
    May 13, 2006
    I work with a group developing tools/services "on" SharePoint and the set-up is much the same except a much smaller team, and some of us have overlapping roles and can often be found writing code or customizing a UI one day, and documentation the next.

    That being said I can definately understand the effort that goes into the "grande scheme" of things at least from a smaller level.

    If it is any consolation we think you have been doing a great job (WIth the evolution of SharePoint Technologies) - we are particularly excited about MOSS 2007.

    We joked yesterday during a 'review meeting' about the BDC - mostly because it's a "feature" of MOSS 2007 when in fact it could easily be a self sustaining application in itself.

    I think people are going to be simply blown away when they start to realise the capabilities of the BDC.