以下是个人心得：
一、接手项目阶段
项目经理在接手项目时，应该进行项目干系人分析，得出哪些人员对项目起积极推动作用，哪些人员对项目持有消极抵抗态度。随后，客户及公司领导会要求制订一份项目整体计划，此计划往往是需要根据客户方要求的结束日期进行倒推，此份计划比较粗，只需要按时间点列出进度计划安排、相应可交付物、投入人力资源。（其实我个人理解这时候的整体计划更像是里程碑计划）
除此之外，我觉得还应该准备一份项目范围说明书，明确项目范围描述、项目验收标准等，这在后期范围变更以及项目验收时是一个依据。
二、需求阶段
此阶段需要反复跟客户方业务员及相关关系人进行沟通，明确需要开发的需求。此时需要制订需求说明书，并与客户方进行确认。
在与客户方确认需求的同时有可能有些需求暂时无法确认，为了进度不受影响，此时需要项目经理先确认能够确认的需求，并同时安排项目组成员进行功能设计，这二个过程往往是同时进行的。
确认需求的过程中项目经理需要提交需求说明书、未确认需求的清单说明。
项目经理安排项目组员进行设计过程中需要设计人员提交设计说明书（一般都是界面原型设计），完成设计说明书后有必要提交给客户方相关人员进行确认。
三、任务分配阶段
根据已确认的需求，项目经理需要进行任务分配，任务分配前需要结合需求及设计进行工作分解，将需要完成的工作分解到每个按钮功能，尽量做到能分解成能在3天内完成的工作。我个人很不赞成项目经理“独裁”完成任务分配(现实中会出现实施过程中有很多工作任务不在计划中，而且会出现死命加班的情况)，此过程需要考虑项目组员的业务及技术能力，所以分解过程需要让项目组员参与，分解完成后提交任务清单文档。
任务分解完成后，根据任务清单及任务优先级关系分配任务到人，提交任务进度计划表。
四、定期沟通及监控阶段
此阶段需要根据项目组员的工作情况进行跟踪监控，包括工作过程及结果完成情况，需要监控任务完成情况、任务完成与需求匹配情况、代码编写的规范性，找出实际与计划的偏差，分析偏差，并采取相应措施，提交项目实施过程日检表、需求矩阵跟踪表、项目进度跟踪表、阶段性项目进度报告表
监控过程需要做的工作比较多，项目经理往往需要将部分工作交给项目组员完成，比如代码编写的规范性审查可交给技术稍好些的组员协助完成。
监控项目实际完成情况项目经理往往需要通过组员的周工作日志、项目例会、项目周报来了解，根据实际完成情况与计划进行对比，找出偏差原因，并采取相关措施，提交进度偏差控制表、纠正预防措施记录表文档。
监控任务完成与需求匹配情况项目经理往往需要通过组员完成需求监控清单，将需求落实到代码。
定期将可交付物给客户方进行演示。
此过程还需要制订出与团队内部及客户方进行沟通的计划，加强沟通，重视沟通。针对会议等形成的决议要定期进行跟踪，形成会议决议跟踪表。
五、范围变更控制阶段
在项目实际开发过程中，客户往往会有需求的调整或变更，这时候需要妥善处理好客户提出的调整意见或变更要求。
项目经理可根据调整的工作量及业务对系统的整体影响情况与客户进行沟通，如果调整工作是必须开展的那么必提交调整或变更申请、评审意见报告，那怕是形式也得提交，因为如果项目因此延期则有理由说不是因为我们的原因；如果调整可放到后期进行则可先把问题记录下来后期再调整。
此外，变更对项目造成了影响，需要更新项目进度计划表。
六、团队建设阶段
项目开始项目经理需要制度一些制度，比如上下班制度，会议制度、周工作日志制度。
项目开发工作繁忙而紧张，团队成员压力增大，情绪因此受影响导致工作效率下降在所难免，项目经理要经常观察团队成员的情绪，要与团队成员经常沟通谈心，遇到问题要与其一起解决。此外，定期组织团队活动，如聚餐等。
我个人更喜欢人性化的管理方式，能多照顾团队成员的尽量多照顾，而不是一味只想着自己。
要想把一个项目做好真的不容易，或多或少会与客户方产生矛盾。我个人觉得我们作为乙方，应该站在甲方客户的位置多思考问题，找到双方都能较为认可的解决方案，做到“尊重、聆听、理解、共赢”。
