虽然我们的团队很小并且项目生命周期可能也会相对较短（仅3个月），我相信经过这一系列，你将会对发布一个产品需要投入多少精力有个概念，还有为及时发布正确的产品这里的人又投入了多少激情。
好吧， 让我告诉你一些更多的细节,关于近几周让我一直忙碌的事情来开始这个系列吧
项目生命周期
对于每一个项目来说，都会经历一些标准的过程，每个阶段都从前一阶段收益，并且为项目增加价值。毫不奇怪 ，项目要从分析阶段开始，其基本思路是确定项目的范围，确定我们该做哪些，而哪些应该放到下一个版本。 紧接而来的就是规划阶段，项目的发展线路应该如何，(重要里程碑)将会被确定以及划分 这将基本上告诉我们现在项目进行到哪儿了，并且可以在我们和计划的进度不符合的时候，迅速地让我们作出反应。再后来，项目将进入开发等等的阶段。
从最初的两个阶段得到的最重要的两样东西就是项目规格书和项目计划。 没有确定项目范围而进行项目计划是一件很难的事情，所以对于一个项目经理来说首先并且最重要的事情就是确定项目规格书。 因此，这次我将着重介绍项目规格书，并且在以后我将逐渐介绍如何做项目计划。
分析阶段
如果你没有多少写项目规格书的经验，你可能会惊讶与整个团队会为了完成项目规格书花费如此多的精力。 没错，整个团队-写规范是一个团队的努力，如果你认为这是一件只项目经理做的，那么请试着考虑下列各点：
开发团队需要项目规格书以便于开始开发，这样他们才能知道要开发什么，他们最终的劳动成果看上去应该是个什么样子
测试团队需要项目规格书告诉他们所期望的行为是什么，以至于他们可以开始测试 。
整个团队需要项目规格书用以界定任务，优先级，阶段划分，以及项目的发展蓝图，并且估计出该项目交付的时间
各有关方面要规格书以了解哪些功能将在什么时候交付 。
正如你看到的，一个项目经理能是不可能独立完成项目规格书的（任何在微软工作的项目经理）。 原因有太多的人参与，你不能独自一个人完成项目规格书，然后希望其他人全都同意。所以，如何在微软写出适当的项目规格书 ？ 这里是我的基本步骤。
第1步. 做足功课
我一开始将对该领域做一些研究。 我尝试不同的东西;分析各种可能性，验证项目中的概念等等。我花了相当一段时间扮演一个潜在用户的角色，看到底我需要什么，我期待的产品是什么样的。 所以，我要说第一步是通过实验我们要了解项目看上去应该怎样，探索未知的区域。 这个阶段是纯理论的研究，此时你只需要尝试该领域的一些东西并取得一些经验。 我在做Visual Studio系统的项目中学到了很多，所有那些不同的东西你都需要做扩展，VB运行时包括什么，它是如何实现的，还有许多令人兴奋的事情。 事实证明了当我做为项目的项目经理的时候，我学到了多新东西！
第2步. 多和别人交流
我跟很多人交谈过。 在过去几个星期里，我几乎每天都开几个小会议，为了使项目规格书更加完善，我每天要送出数十份电子邮件。 我已花了不少时间与开发人员，测试人员，项目经理以及其他这个项目相关的人。当我需要一些我自己并不在行的技术方面的支持的时候，我也会和VB组之外的很多人进行交流。 我认为这是一个整个项目最酷的部分-实际了解了不同人对于项目的感受，什么是技术上的可行性，等等 。
这个阶段很有趣，但并不是写文档本身让我感到高兴。 当然我乐于看到一份文档变得越来越充实，更多细节以及内容被充实进去。 更令人振奋的是，事实上在你完成项目规格书的同时，你真正明白了整个项目在做什么。 你将知道每一个功能细节，因为这是你的工作。 这是不是不可思议？ 你其实有责任了解这一切，所以，当有人有问题时，你知道答案。 我不知道别人怎么想，但我确实喜欢这种感觉。 在某些点上，你对整件事是如何工作有个完整的理解，如何将不同的模块整合在一起，他们将如何互动，有什么潜在的问题，等等。我想让我开始参与软件开发的想最重要的原因，是有机会去创造，建立，创新。
第3步. 让所有人快乐
好了，我花了一段时间写项目规格书，我终于完成了一个说明项目是做什么的文档。。 最好的部分来了-让所有的人同意我写的东西。
基本上，为了使所有人同意，你可以做两件事：
要么用枪瞄准他们的头:)
或和他们进行会议，这样你就能看到是什么困扰他们，并整理每一个你得到的评论，这样你就能另大家都对产品满意，并且相信项目规格书包含了可使他们开始工作所需要的所有信息。
在微软我们很人性化，所以我们偏向于第二种办法。 我们进行了一系列对项目规格书草案的校阅，这些基本上都是和同事们在项目规格书会议上面进行的。 人们给出他们的意见，对不同的问题进行讨论，并最终得到一个由多数人同意的方案来指引我们将走向何方。
让所有人幸福的最后一步就是来一次项目规格书的总校阅。 这是一次所有同事都会参加，在此你的项目规格书将得到正式批准。 大家都坐着看项目规格书，并且如果你把你的工作已经做的足够好，人在本次会议上不应该有太多的反馈，因为他们应该已经在非正式的时候提出过了。 我们的正式项目规格书校阅是周一，祝我们好运吧！
有趣的是在我来到这里之前，我以为微软（作为一个大公司） 有着大量文档和繁琐的流程，怪异模板等。这不能责怪我，其实许多即使小于微软的公司也有那些流程。 所以当我问： "那么我应该遵循什么样的模板？ "得到的答案是"好了，这些就是你要去做的"时， 我是真的感到很吃惊。当然，基本准则还是有的，但你不一定非要遵照他们不可。 虽然他们是真的很有用，我从它们学到了很多新东西…但事实证明，每一步都严格遵守规范并不比只遵守其中正确的部分好多少。 不错，得到正确的东西，是不是太容易了--对于每一个特性的开发你必须付出很多精力以确保安全性，本地化，性能等，因为人们对这些东西是非常谨慎的。 但只要你有那些，并且大家都同意这里有那些就足够了，你就可以用你喜欢的布局或风格。 我不知道别人怎样，但我真的很喜欢这种自由！
第4步. 不断完善项目规格书
经过对项目规格书的审查，项目规格书将被打印并且文档将被标记为只读的，从此它永远不能改变… …这你只是期望罢了！ :) 规格书是一个动态的文件，并随着时间的推移，要不断改变和更新，项目经理的工作就是让其不断完善。 项目经理有责任了解每一个变化及其影响，让项目组做出正确的决定,这个是否应该改变。
哇，这次已经说了很多，有那么多东西写… … 所以我想我为大家开了个头，如果大家有什么问题，不要犹豫！ 下周见！
[原文作者]：Slavi Marinov
[原文链接]：How do we write software at Microsoft: a PM intern’s perspective #1
