A group blog from members of the VB team
Now that you know our team, it is time to get down to the real meat - we are building software here, so let’s talk about software. As I promised to keep you up to date with what is going on here at Microsoft, I decided to start a series of blog posts under the title “How do we write software at Microsoft: a PM intern’s perspective”. Expect to get a flavor of the Dev and QA prospective as well really soon!
Even though our team is small and the project lifecycle will be relatively short (just 3 months), I am sure that throughout the series you will be able to get an idea of how much energy it takes to ship a working product, and how much passion the people here put in delivering the right product on time.
OK, so let me then start the series by telling you in more details what’s been keeping me busy for the last few weeks :)
The Project Lifecycle
As it is with every project, we are going through a set of standard phases, each getting output from the previous and adding value to the project. Unsurprisingly, the project starts with an Analysis phase, and the basic idea is to get the scope of the project, defining what we will be doing, and what we will leave for the next versions. Next comes the planning phase, where the project roadmap is built and the important milestones that we will hit are identified. This basically gives us a great means of tracking where we are, and also enables us to react as quickly as possible if for some reason we are not on schedule. Then the project goes into a development phase, and so on.
The two major outputs from those first two phases are the Project Spec and the Project Plan. It is hard (if not impossible) to do the second without the first, so the first and most important thing a PM has to deliver is the project spec. So I will focus on the spec in this post, and next time I will give you more details on how we do project planning here.
The Analysis Phase
If you do not have a lot of experience with writing specs, you will probably be really surprised how much energy the whole team has to put in getting the spec done. Yes, the whole team – writing a spec is a team effort, and if you think that this is something just for the PM to do, consider the following:
As you see, it is impossible for a single PM (or even all the PMs working at Microsoft) to create the spec. The reason is that there are so many different people involved, that you cannot do this yourself and then just hope that other people will agree with it. So, how do you write a proper spec at Microsoft? Here is my basic, step-by-step approach.
Step 1. Do your homework
I started by doing a lot of research in the area. I tried different things; analyzed alternatives, created proof of concept projects, etc. I spent quite some time in the role of a potential user, trying to see what I would need and how I would expect things to behave. So, I would say that the first step is to try and really understand what the project should look like by experimenting, exploring unexplored grounds. This stage is pure research, where you just try stuff out and get some experience in the area. I learned so much about the project system in VS, all the different things you need to do to extend it, what the VB runtime contains, how it is implemented, plus so many more exciting things. It turned out that while I was doing my job as a PM I got to learn so many new technical things!
Step 2. Talk to people
I talked to a lot of people. In the last few weeks I have literally had a few meetings every single day, in order to get the spec right, plus I sent dozens of emails per day. I have spent quite a lot of time with Dev, QA, PM and all the other stakeholders. I have also talked to various people from other teams outside VB when I needed technical help on something I didn’t quite understand. I think that this is one of the coolest parts of the projects – to actually understand how different people feel about the project, what is technically possible, etc.
This stage is a lot of fun, but it’s not the writing of the document itself that makes me happy. Sure, I love seeing a document get bigger and bigger, more detailed and with more things written inside. What is even more exciting, though, is the fact that as you are working on the spec, you actually understand what the project will do. You get to know every single feature in details, because this is your job. Isn’t this amazing? You are actually responsible for understanding everything, so that when people ask questions, you know the answer. I don’t know about you, but I really, really love that. At some point you have this complete picture of how the whole thing is going to work, how the different pieces will fit together, how they will interact, what the potential problems are, etc. This is one of the first things that made me start working with software, I guess – the opportunity to create, build, innovate.
Step 3. Make everyone happy
So, I spent quite some time writing the spec, and eventually I came up with a document that described what the project would do. This is where the best part came – getting all the people to agree on what I had written.
Basically, in order to get all the people to agree, you can do two things:
We are quite humane here at Microsoft, so we prefer the second approach. We conducted a bunch of pre-spec reviews, which are basically focused-on-the-spec meetings with the stakeholders. People give their comments, different issues are discussed, and eventually people get to a mutual agreement on what we are going to be doing.
The final step to achieving stakeholder happiness is conducting a Spec Review. This is a meeting with all the stakeholders, where you get a formal approval on the spec. Everyone sits and looks at the spec, and if you have done your job well, people should not have too much feedback at this meeting, because they should have already informally singed off. Our official spec review is on Monday, so wish us good luck!
It is funny that before I came here, I thought that Microsoft (being a huge company) is all about big piles of documentation and heavy processes, weird templates, etc. And you can’t blame me; many companies actually do have those processes, even companies way smaller than Microsoft. So I was really struck when I asked “So, what template should I follow?” and the answer was “Well, whatever works for you”. Of course, there are guidelines, but you aren’t forced to follow them. They are really useful though, I learned so many new things from them… But it turns out that getting to a point where the spec is approved is really nothing more than just getting the right thing in it. Yes, getting the right things in is not too easy – for each feature developed you need to pay special attention to security, localization, performance, etc., because people are extremely cautious about all of those things. But provided you have those in, and people agree that what’s in there is enough, you can use the layout or style you prefer. I don’t know about you, but I really love this kind of freedom!
Step 4. Keep the spec up to date
After the spec review, the spec is printed and the document is marked as read-only, so that it can never be changed… You wish! :)The spec is a dynamic document and as time goes by, it is changed and updated, and it is the PM’s job to keep it up to date. The PM is responsible for understanding each change and its impact, so that the team can make the correct decision about whether the change should be made or not.
Wow, this post is already quite long, and there are so many more things to write... So I guess I will just leave the initiative to you – if you are wondering about anything in particular, don’t hesitate to ask! See you next week!
PingBack from http://filipefreitas.net/blog/?p=151
That was a decent write. Gives an insight into microsoft way!! thanks
Very nice insight into the development methodology of a team at Microsoft.
I have a few questions of practical nature.
In what kind of language are the specs written, could you give an example of a feature description?
Do you write the specs in Microsoft Word, or do you use a tailor-made system to do that? How do you version control the specs?
With kind regards,
Kind of surprised to know that PM writes spec. I thought PM was only responsible for schedules.
Hey Patrick, Shaobin
First of all, thank you so much for the interest and for the great questions!
Specs are written in plain English, as everyone across the company needs to understand them :) You can have a look at the online specs here:
Now the MS Word question. As strict as Microsoft is about getting the right things in the spec (e.g. you have to think a lot about security, extensibility, localization, performance, accessibility, etc.), what tool to use is up to you. You like mindmaps - use a mind mapping tool. You prefer HTML - great! Provided you get the right things in there and the team likes that, you are good. Plus, different teams use different tools, so you cannot say there is something really standard to use across the company. For me, however, MS Word works just fine, so this is my tool of preference.
Yes, you are right that one of the very important things PMs are responsible for are schedules. But if you think about it, in order to define or meet a project plan, you need to have really deep understanding of what the project involves. I cannot stress enough on how crucial this is, and this is one of the major reasons PMs are responsible for writing and maintaining the spec.
I think that it is a great discussion item though, so my question is - what is your understanding, who do you think should be responsible for the specs?
Well, I know how do you guys write a software at Microsoft...
I can see that from the number of bugs in VS2005 :-)
However, thanks for your post...
thanks for the great post. It would be wonderful if you could continue to explore the "life and responsibilities of a PM at MS" (you can then collect said posts and publish them under that name as a book ;) ).. good job though .. look forward to more similar posts.
In one of the companies I worked for before(I still think their workflow is one of the best I ever know), there was a product definition group(PD). The group is a bridge between marketing and R&D dept. The PD group is in close contact with marketing group and transform marketing team's idea into product specifications.
BTW, PD writers are NOT necessarily programmers. But they are really good at using the software. After the initial docs are written, R&D managers will have meeting with PD people and discuss the feasibilties and costs of each features they request. The process is iterative and software engineers will provide their own concerns, estimates with respect to the documents.
In brief, the PM usually does not write specs(marketing is supposed to know the market best). But he/she definitely knows how all stuffs are supposed to unfold eventually.
[ 原文作者 ] ： Slavi Marinov [ 原文链接 ] ： How do we write software at Microsoft: a PM intern’s perspective
i'm 3rd year is student in ethiopia niw i'm trying to automate our registrar office using VB & SQL if ucan help me u welcome thank u i look forward