项目管理总结

一、     项目需求分析

项目的需求阶段需要注意的问题:

1)     项目需求的切入点是“业务层面”的，当选择技术方案、制定项目规划、确定验收标准等环节时，“业务目标”比“技术实现”重要的多，首先搞明白的是客户为什么这样做，而不是怎么做；不能客户说什么就做什么，只有理清客户要拿来做什么，你才能为后续的技术方案的拟定，准确描述项目计划及功能验收奠定基础。

2)     项目干系人确定。不要忽视那些并不关心项目，而且又不直接与你联系项目相关人员，比如客户的领导，在需求拟定之后，一定要相关人员对于项目的目标达成一致。多数情况下，需求并不是技术部门提出的，而是业务部门提出的，技术部门提出的需要，不能直接作为最后的需求，一定要业务部门给予确认，避免不必要的麻烦。

3)     在项目需求阶段，对项目的中可能引起争议的问题给予确认，明确自己的需求范围，避免客户提出超出项目需求范围的功能，这样对于后期项目的进度及技术实现，验收标准等等造成影响。对于需求之外的问题，尽早给予明确的回复。

4)     其中还有一点最重要的问题，是合同问题，其实很多问题，可以在双方达成一致之后，在合同中说明变更控制流程，这样可以有效避免后续客户对于需求变更无底线。

二、      项目计划

1)     项目里程碑节点设置

项目的里程碑比验收节点重要，把握住过程就把握住了结果，对于项目控制来讲，里程碑就是最有效的过程控制手段。设置项目的验收节点，属于“硬性”压力，没有回旋的空间，但里程碑有时候是“软性”压力，但忽视里程碑式是将压力进行积累，将风险做实的过程。

项目管理者对里程碑要给予重视。

a)      计划阶段：合理规划里程碑节点，使其有可行性，有验收价值；

b)     执行阶段：围绕着每个里程碑安排工作，找到项目“节奏”；

c)      沟通过程：项目动起来，让项目成员清楚项目目标，将里程碑的压力传达给项目中的每一个人包括客户；

2)     项目计划中对于现有资源利用

项目计划中要对现有资源进行合理分配，项目的资源分为很多种，人员，相关资源，经费，客户或者业务给予支持的人员及相关材料，将资源落实下来，而不是打招呼，这是个很烦人的事情，当你需要的时候没有了，这样对于项目进度的影响很大，人员的变动，项目的预支是否合理，都要明确。提前预见可能出现的资源冲突问题。以“例会”为单位，讨论并确认未来几周资源变动情况及项目进度。客户和业务人员的工作，我们可能无法控制，但尽早知道可以早作打算。

3)     项目风险的控制

项目开发中会遇到各种问题，如人员变动、资源冲突、对于技术的不熟悉等问题，能够在项目开始前给予风险规划，则对于项目风险的控制更加稳固。如新技术作为风险项，可以对员工进行技术培训，人员变动情况，与员工沟通侧面了解其内心想法，给予提前的人员备份，资源冲突提前的预见及协调等解决有段去合理安排及沟通。

三、      项目控制

1)     项目进入执行阶段，关键要大家找到节奏感，这样才能推动项目，才能占有主动权，如何找到这个节奏感？根据不同的项目成员及项目的性质不同方法不一定，但大体上相差不大，设立里程碑，作为中长期的目标，周报及项目例会保证短期目标的实现。无论中长期里程碑还是短期的项目例会，核心目标是通过这种方式及时的让大家了解项目的情况，预见可能的问题，找到解决问题的方法，同时周期性的与主要项目干系人进行沟通（项目周报+面对面的讨论）。

2)     关于项目的文档

我相信很多程序员及项目经理都不喜欢写文档，但项目文档对于项目的经验延续、体现个人工作价值方面及后期的系统维护有很大的用途。掌握写文档的技巧及养成写文档的习惯可以避免不必要的麻烦。比如：某个功能的修改，没有形成文档，对于功能修改者清楚为什么修改，修改位置，时间已久估计修改者本身都记不得了；写出文档给业务或客户确认他们所提出的问题，并给予解决的问题方法的描述。这样可以避免以后争论。

写文档有几个注意点：

a)      搞清楚文档给谁看的？目的是什么？客户或者领导想看到什么样子的文档？即使同一份文档，对已不同对象，所关心的侧重点也不同。例如：一份功能需求规格说明书，业务人员（客户）不管你怎么做，只关心你做出的效果及完成日期；程序员关系的是如何实现这个功能；

而项目经理可能关心的是所需投入的人员及其它资源成本。

b)     要善于把复杂问题简单化，让不懂技术的业务人员（客户）、管理层，通过文档明白关键点的所在。比如：可通过图表，插图之类的可视性强视图文档给予说明。枯燥的文字很难让所有人都认真去读的。

3)     项目变更问题

没有完全按照最初的计划执行的项目，或多或少都会发生需求变更的，用户的想法有时候是不确定的，我们完全控制不住了。想尽一切办法避免需求变更，估计也是不现实的，但至少有几点我觉得可以力求做到：

a)      在需求阶段，尽可能的把需求搞清楚；

b)     在执行阶段，严格遵循变更控制流程；

c)      对于发生了的变更，相应的调整文档；

问题也许发生在执行阶段，但根还是在需求过程中，要了解用户为什么要做（业务动机），以及什么是可行的方案，而不是业务说做什么就做什么。

4)     项目验收及最终投产

项目的验收标准是根据最初的业务需求编写的，而且由业务部门给予确认，项目组完成相关项目功能的开发，提交给业务测试及修复业务反馈的问题，待最后业务验证通过后，进行最后的投产，投产中需要注意的在根据开发阶段积累下的脚本进行梳理时，尽量多人参与防止遗漏，造成上线失败。

四、      项目团队与沟通

1)     团队成员的选择。对于经验重要还是工作热情重要，我想对于项目管理者而言，项目组成员的工作热情相对更重要。留下工作经验相对多的人不易过多，因为公司不会同时满足所有有经验者的要求，从而也调动不了所有人的热情，留下几个经验丰富，给予一定的物质上的满足，同时加入一些新鲜血液，这样的团队才能更好的完成项目。当然这都是因为公司资源不足的情况下才采取的方法。

2)     项目团队的成员从技能、性格，甚至是地域上的不同，给沟通带来了不便，你认为正确的方法不一定所有人都这样认为，这样的情况下，项目组管理者要起到协调各个人员，和睦相处的前提下高效的完成任务。比如：一个不善于沟通的同事，要了解到他的爱好，给予不定期的鼓励，让其慢慢适应去说出自己的想法；一个多动爱说的人，就让其主动担起组织活动的任务；

同时项目经理要及时沟通，要了解每个同事所遇到的   困难，及时给予帮助，给予支持。要在不压制每个人    个性的情况下，融合整个团队，让他们在团队中都能   体现其存在的价值。

3)      如何与客户沟通，让客户和老板满意？

客户满意是项目达到预期目标？是按时完成？老板满意是盈利？这些似乎都是满意的答案。但是实际的项目中多多少少会有不如意的问题出现，但问题本身是否解决并不重要，而在于你是否与客户与老板进行了充分的、良好的沟通。

4)     项目经理整合团队力量

项目中每个成员要让自己有价值，无论是领导者还是普通员工，只有自己在团队中体现自己的价值，才能立足于项目之中，作为项目经理，要通过良好的沟通能力，理解每个人的处境、动机；力所能及，提供团队成员所需的；通过合理的渠道，向上级领导反馈成员的工作绩效。总之要了解每个成员，为项目风险提供消息，做出进一步的判断。

5)     对于里程碑的认可度的检验

不管平时项目组怎么样，关键里程碑还是要准时完成，保证了过程了才能有好的结果，期间要明确我们的里程碑及验收标准，传达到每位成员，项目开始阶段及执行阶段要检验每位成员对里程碑的理解是否准确无误。