Paul Stubbs : Program Management

1 Year Microsoft Anniversary

pstubbs — Thu, 29 Jul 2004 18:27:00 GMT

Well it's hard to believe that its been one year already. The time has gone by so quickly. I have learned so much in my first year about the way that Microsoft works. It is totally amazing what it takes to make a product, the thousands of people involved. When I first started the team was just finishing up Visual Studio Tools for Office 2003. Now we just released Beta 1 of Visual Studio Tools for Office 2005. There are so many new features like; a visual designer, view controls, data binding, actions pane, server programming, data caching etc. I have had the opportunity to work with the Visual Studio Express SKUs. I have worked with the Office Team on the next version of Office, I have worked with some cool Longhorn technology. So I am looking forward to many more exciting years at Microsoft.

I'm not sleeping, I'm working

pstubbs — Fri, 23 Jan 2004 00:15:00 GMT

A new study shows that sleeping is the best way to solve a problem . Working on bringing together Visual Studio and Office (VSTO) has its share of extremely difficult problems. How do you mesh fundamentally different users, Professional Developers and Office Information Workers in a way that makes everyone happy? So this I think my boss should give me whole days to sleep, I mean work on a solution, to these problems. You may want to add this blog entry to your favorites so that if you get caught sleeping at work you can point to this article and say that you are working hard.

Redmond, WA 48°/39° MSFT $28.01 -0.29

Spec Writing 101

pstubbs — Thu, 16 Oct 2003 19:46:00 GMT

One of the primary jobs of a Program Manager is to create functional specifications. A functional spec describes “What” a feature is going to do. A functional spec should not describe the “How”, which is described in a developer spec or and architectural spec. So at Microsoft the products are large and complex with many features. Product features are prioritized and divided up to feature teams. A feature team at a minimum consists of a Program Manager, a Developer, and a tester. The PM will write the functional spec. The Dev will write the build spec. The Tester will write the test spec. Functional spec’s purpose is to tell everyone what the feature will do. Early in a product’s design the only thing that exists to tell people about the features of a product are the functional spec. So it is important to completely tell the story about the feature. A good spec may save a feature from being cut at crunch time. So the specs contain many sections. I will point out a few of the important ones. The Summary is the first section and it is the paragraph that tells you what the feature is. This is the elevator section. Which is if you were on the elevator with the CEO this is what you would say to him to sell your feature before the elevator reaches his floor. The scenarios section tells the story of the user using the feature. This is where you describe how the user is going to use the feature. The Requirements section should enumerate the “Must Haves”, “Should Haves”, “Nice to Haves”. These Must Haves are things the feature can ship without. The Nice to Haves are features that are important to the success of the feature but are not critical to the functionality. The Nice to Haves are items that can be done if there is time. These are the first items to be cut when time is short. Functional spec writing is a import role at Microsoft and should be a important role in any project.