一、前期与客户需求调研阶段：
1） 抓住主要的人物。
这个项目的实际使用者，提出项目需求具有决定权的人。这一点比较难做到。主要是看对方是属于什么单位，如果是政府部门就麻烦很多，因为政府部门等级制度观念很明确，他们是很讨厌越级之类的需求提出。在一个需要找准找对能提出具体需求的人。即使提出了具体需求如果他不能确认需求这样也是一大危险。必须找准可以给你在具体需求书上签字确认的那位领导。不然一旦没有这个环节，那日后的工作量就要成倍的付出，才能挽回。（重点）
2） 不能轻易将需求分析看成是客户提出的要求。
有些项目客户方面可以抽调一些人协助调研需求。但是这些协助的人员只能是大概的说清楚具体使用者的要求。不能详细的说明具体的重点放在什么功能上面所实现的表示。而且他们一般给的需求仅仅是他们能理解到的，还不能完全具体到使用者的上面。项目经理或是需求调研人员需要自己在重新分析作出相应的需求报告，不然一味的拿过来让开发人员去理解，去吃透这些那简直是一种折磨。因为“你”是整个项目的调研人员不是真正的开发人员去理解需求，而是你来吃透需求彻彻底底的将需求转化成你所理解的程序流程，程序中所要涉及到的某些关键点。如果人人都可以拿别人写的需求分析来做为你的需求交给开发人员的话，那么人人都可以做项目经理作调研人员了。（次重点）
3） 分析需求要透彻必须具体到某个点，把握住关键点的控制，不可扩大需求。 项目管理者联盟文章
www.mypm.net
经过前面两点后可能这一点相对来说不时非常重要了。但是如果前面两点都不注意的话后面谈和控制？假设一个项目中也有需求分析了，但是最重要的控制关键点没有名确。那如果别人在已有的需求上面加多几个功能都不为过，主要原因是没有明白的告诉别人在什么时间此类的需求已经明了的确认。并且除了以前提出的需求，其他的需求不能在次提出。所以别人突然想到了什么就是可以提出来让你修改，这是最可怕的。如果明确了关键点的确认，那就算是提出也没有关系，可以做为二次开发来再次签订相应的开发合同。俗话说得好“空口无凭，立字为证”嘛。这是需要建立在需求调研阶段最难最不好控制的地方。（必需做的工作）
二、中期演示工程的编写。 training.mypm.net
1）一旦确认了所有的需求，就需要具体来设计一个演示的模型确认开发效果。 项目管理论坛
（经过了上面的需求调研，具体的需求分析已经彻底明确后，这一步的工作就比较轻松一些）这里就需要公司中一些部门的具体配合协同完成了。完成后又要开始前面第一部分相同的工作了此时将需求更换成了演示工程。这个时候应该是需要客户确认书的，因为一旦确认后以后的开发工作相对就轻松多了，即便是更改某些细节上的需求也是控制在前期。 项目管理培训
项目管理者联盟文章
2）开发文档整理。
经过了这两个阶段，相应的需求全面了，界面明确了。剩下的就是将一些文档性的东西拼补齐全，这是项目经理应该做的大事情，当然如果之前的需求文档都明确签字，这里的工作可以说是复制粘贴了（首先确认你缩写的东西你带领的开发团队（Team）能看的明白）。
三、项目后期开发工程
1）初期阶段的开发 bbs.mypm.net
进入初期阶段的时候就已经不需要再重复的进行相关需求的调研阶段了，还是那句话前期的工作要充分作尽。具体的开发工作就应该是项目经理集合团队（Team）分配工作，将前期自己所做的具体需求分析分发下去，根据需求文档来编写项目了。这时候项目经理所做的就是将自己调研阶段理解透彻的需求分析讲解给每一个开发人员。大家共同协作推进项目进度。此时这个团队里面需要进行必要的沟通，保证每个环节不出现不必要的差错。这时候项目经理就是这个环节的协调者（谨慎行事，这里如果控制不好将对以后的验收带来困难）。这个阶段应该是加快速度开发完成。完成具体模块的功能，经过测试部门测试通过。 项目管理者联盟
bbs.mypm 2）中期阶段开发
项目管理者联盟文章
进入中期，将初期开发的成果交付客户试用，让客户提出应用界面的修改意见（注意：这里是界面的修改意见。如果功能需要修改这时候你就可以拿出以前确认的文档去说事了。所以前期的需求调研客户确认需求开发文档是非常重要的。这时候就是拿来力争的凭据。）如果需要加功能在改动不打得情况下可以做为一种服务性质来更改。如果需要改动项目的底层后台可就要严格控制了。 项目经理博客
4） 后期开发收尾 项目管理者联盟文章
blog.mypm.net
到了这个阶段经过前两个阶段不断的修改，这里应该是离终点线不远的地方了。也应该是准备临门一脚的时刻。这里经过修改后基本上达到了客户的满意是时候可以让客户进行相关的上线测试使用阶段了。这里要坚决杜绝客户的需求提出，能做的仅仅是调试工作。项目组成员开始整理整个项目的开发文档交付项目经理整合，以备验收阶段。
四、项目验收 training.mypm.net
training.mypm.net
项目的验收主要的就是看整个开发过程中是否能严格的按照“代码+注释+文档”的过程来了。如果到项目完成后再去补齐项目文档也是可以的，当然如果可以提前做的工作尽量的提前作好。以免突击出来的文档被打回。
五、项目的经验总结 training.mypm.net
这个就看个人了，看你是否在这个项目当中得到经验的积累，知识技巧的提升了。
项目经理圈子
六、整个项目中项目经理担当的角色
项目经理圈子
在整个项目中，项目经理的位置要摆正，你是一个技术型的经理，还是沟通型的经理。这里的技术型和沟通型是相对而说的。技术型的经理往往自己独裁比较严重，不能有效地听取采纳他人意见（这里注意：毕竟你是经理，是一位协调人不是总裁，不能一味的独断专行。这种做法容易让你很难接受一些新的理念）。沟通型的相对来说容易听取别人提出的建议，但是不能绝对听取，因为你才是最后的决定者。可以通过一些方式和实际的结果来证实你所采用的方案优于别人。 [page]
.net
