A Microsoft project typically has at least three different types of leads working directly on the development of the product:

* Project Lead. The project lead is ultimately responsible for the Code. He or she is also responsible for developing and monitoring the schedule, keeping the project on track, training the Programmers, conducting program reviews for upper management, And so on. The project lead is usually one of the most experienced programmers on the team and will often write code, but only as a secondary activity.

* Technical Lead. The technical lead is the programmer on the Team who knows the product's code better than anyone else. The technical lead is responsible for the internal integrity of the product, seeing that all new features are designed with the existing code in mind. He or she is also usually responsible for ensuring that all technical documents for the project are kept up-to-date: file format documents, internal design Documents, and so on. Like the project lead, the technical lead is usually one of the most experienced programmers on the Project.

 Program Manager. The program manager is responsible for Coordinating product development with marketing, documentation, Testing and product support.

 In short, the program Manager's job is to see that the product—everything that goes into the box—gets done, and that it gets done at the Level of quality expected by the company. The program manager usually works with the product support team to coordinate External beta releases of the product and works with end Users to see how the product might be improved.

Program Managers are often programmers themselves, but they limit their programming to using the product's macro language (if one exists) to write "wizards" and other useful end user macros. More than anyone else, the program manager is responsible for the "vision" of what the product should be.

The name "program manager" can be misleading because it implies that the program manager is superior in rank to the project lead, the test lead, the documentation lead, and the marketing lead. In fact, the program manager is at the same level as the other leads. A more appropriate name for The program manager would be "product lead" since the program Manager is responsible for ensuring that all the parts of The product—not just the code—get done on schedule and at An acceptable level of quality.

On a typical project, the program manager (or managers if the Project is large enough) works up front with the marketing, development, and product support teams to come up with a list of improvements for the product. After the list of features has been created, the Program manager writes the product specification, which describes in

Detail how each feature will appear to the user—providing, for instance, a drawing of a new dialog box with a description of how it will work, or the name of a new macro function with a description of its arguments. As soon as the product spec has been drafted, it is passed out to all of the Teams involved with the product for a thorough review.

Once the final Spec has been nailed down, the teams go to work. The program manager meanwhile uses mock-ups of features to Conduct usability studies to be sure that all of the new features are as intuitively easy to use as everybody originally thought they would be.

If a feature turns out to be awkward to use, the program manager proposes Changes to the spec. The program manager also works on sample Documents for the product disks and on those end user macros I mentioned earlier.

As features are completed, he or she reviews each to ensure that it meets all the quality standards for shipping the product In particular, that the feature is snappy enough on low-end machines. Development continues and eventually reaches a point known as "Visual freeze," meaning that all features that will affect the display have been completed. Once the code reaches the visual freeze point, the User manuals are finalized with screen shots of the program.

Consequently, from that point on, developers have to be careful not to affect the display in any way so that the screen shots in the manuals won't differ from what the user sees in the program. The programmers, of course, Would prefer that the screen shots be taken only after all the code is finished, But the manuals need a long lead time and have to be sent to the Printer well before the code will be finalized. In some cases, in order to reach visual freeze on all the features in time for the manuals to be ready

 At The release date, the programmers will only partially implement the Features—for instance, displaying a nonfunctional dialog good for Screen shots but not much else.

The programmers come back to the features and fully implement them later. Once all of the features have been completed—the "code complete" Stage—the programmers put their effort into fixing all outstanding bugs in the bug-list and making any necessary performance improvements.

When the code is finally ready to be shipped, the project lead or the technical Lead creates the "golden master disks." The program manager Sends the golden masters off to manufacturing for duplication, and the Software gets stuffed into the boxes with the manuals, the registration Cards and other goodies. A little bit of shrink-wrap, and the product is Ready for an end user I've left out a lot of details, but this brief overview should be Enough to enable you to put the occasional example in this book that Might otherwise be too Microsoft-specific into context. I should also mention that e-mail is the lifeblood of Microsoft. All Internal business is conducted over e-mail, and, at least in development Circles, you have to have a really good reason to interrupt someone with A telephone call. Most interaction among developers goes on over e-mail and in the numerous hall meetings that spring up spontaneously. This Corporate sensitivity to interruptions accounts for Microsoft's policy of giving everyone a private office with a door. If you're working and you don't want to be interrupted; you simply close your door.