曾经有个笑话，说三个软件高级人材等待上帝安排工作，一个说自己擅长抽象思维，上帝说那就做系统分析师吧；一个说自己工作非常细心，上帝说那就做QA；最后一个说，我实在没有更多的才能，那就做项目经理吧。有句项目管理名言则是这个笑话的最好解释：对项目经理的知识要求是要有1英里宽，7英寸深。也就是说，各方面的综合能力是项目经理的首要技能。
项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧？项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。
一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗？项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢？欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了。在这种模式中项目经理不一定要求必须是技术专家，但更强调项目经理的工作经验，一般会要求项目经理有8年以上工作经验。而在中国，尤其是现在一个有三年工作经验的team leader也会称项目经理，当然他也并不需要对成本、人员、采购等众多项目管理领域的关注，这样的team里也根本不会有技术经理或顾问专有角色的配备，项目经理要更多的关注技术因素，所以项目经理一般是与行业和产品同步成长起来的。如何做好质量、成本、沟通、时间、以及更资源参与的全面项目管理是我们的项目经理的课题。
举例说明：以下是我负责的一个项目中，需求开发和管理的流程。
范围管理是项目经理具备的首要能力。范围说明是未来项目决策的基线，也是衡量项目是否成功的标准。在我们软件开发项目中，需求规格就是我们项目的范围的体现。我的经验是项目经理应极端重视需求，成功的需求管理才能保证范围在基线内，需求调查、讨论、分析、归档、review、变更、回溯等一系列活动是我们需求管理的有效活动。
计划能力是项目经理的应具备的另一个技能，其中软件开发任务的估算是一个难点，即使有历史数据达到CMM4的软件企业也会有20%-50%的误差，我的一些做法用三层到四层的WBS模版从底向上进行时间资源的估计，会从自己经验和相似项目的历史数据中进行加权平均，时间资源的平衡，在WBS分解模版中采用自底向上估计，估计时我们采用了三人以上匿名delphi法，设定差值阈值为30%，如果与平均值的差值比小于此阈值，将不在重新估计，如果大于将进行重新估计，重新估计后如果还是超过设定阈值，估计人要写明为什么如此估计的原因。对于阈值内估计值我们采用历史经验数据进行修正即可作为我们WBS工作包的估计值。
合适的软件开发生命周期模式，对软件开发项目尤为关键。根据项目的需求、资源、风险、时间、质量等实际情况，选择合适的软件开发生命周期模式，对软件开发项目尤为关键。印度软件模式中更是提出了流程模式重于项目。在需求不确定、变化较频繁的项目我们可以选用迭代和原型法。在产品按版本递增开发的项目，由于每期需求比较稳定，宜选择瀑布变种的V模型进行测试提前的生命周期。开发模式的选择将影响项目计划，例如V字形，每个过程都有严格的输入输出，上一个过程的输出作为此过程的输入，实际情况中我们会选用改良的V模型，一些过程可以并行，例如需求规格完成后，可以系统测试计划和概要设计并行。在实际项目管理中开发模型生命周期中各过程的输出宜作为milestone(里程碑)设置计划控制点。
时间、质量和成本是衡量项目成功的三要素，时间和成本因为有形比较容易监控，质量控制在软件开发项目中非常重要了，所以我们很多过程和活动（文档review、代码走读、单元测试、集成测试、系统测试、以及各过程的需求反馈追踪等）都是保障质量的活动。现在好多项目都特别重视了系统测试（包括功能测试、性能测试等），但是忽略了单元测试。单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节；是唯一一次有保证能够代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提；单元测试防止了开发的后期因BUG过多而失控；单元测试的性价比是最好的。在项目中我们引入了TDD单元测试实践，并关注了编译检查、代码走读，以及在等价类、边界值、因果图等方法下的黑盒功能测试和达到覆盖率指标下自动单元测试代码的白盒测试。并将XP方法中的Nightly Test实践达到代码和测试代码的每日building。
Review活动在我们的项目中重视度很高，我们的一些评审制度，评审首先进行小组内部预评审，内部评审模版记录提交项目经理和评审组织者；正式评审可以先走email评审，评审对象完成人将评审文档或其他可交付物提前一天email给所有评审人，请评审人各自将意见email给评审组织者，评审组织者按评审人员汇总整理意见，提交第二天讨论。讨论后，评审结果记录和每人评审意见列入文档考核绩效。
软件开发项目中风险管理，风险管理不只是项目经理估计风险，我们风险管理采用了全员的头脑风暴法，并按权重进行TOP10列表管理。针对TOP10风险，制定相应风险应对计划。在软件开发中，主要的风险有技术风险，所以风险应对计划是项目计划前期的技术验证和测试，需求不确定等风险的应对计划是原型和迭代的开发方法。例如在界面越来越重要的今天，需求规格中会做出原型界面并提前得到客户方的review是很好的风险应对计划 。
沟通是监督、控制的基础，是推动项目执行的基础，更是减少冲突的良方。有项调查项目经理90%时间在沟通。的确沟通占用了项目经理的大部分时间，因为项目经理是面对项目干系人最多的角色。在项目沟通方面，作为项目经理应周期性向机构管理层和客户报告项目的技术、进度、费用、质量方面的状况；在客户面前全面代表所在机构，与客户建立和维持友好和开放的关系，直接面向客户的项目经理是客户与所在机构最关键的联系点；做一个项目沟通的推动者、避免项目中出现沟通的遏制者；为项目沟通积极创造环境，包括集中工作；保证所有会议的高效率。项目经理要根据不同人员和不同情况下的问题选择最合适的沟通方式（电话、传真、Email、口头、即时通信工具、报告、会议、私下交流等），来达到好的沟通效果。如果项目中出现与干系人等的问题，首先要检查沟通计划了。现在好多沟通事项是只装在项目经理的脑子中的，如何做好项目的沟通计划，是项目经理要培养成习惯的一个重要技能。这在我们软件项目中尤甚。例如员工流动始终是软件行业的一个显著特征，所以项目经理在处理此类问题时沟通计划就非常重要了。曾经我们一个项目开发中，一个team leader 想离职技术移民到加拿大，由于前期不知是否能办好也不知道什么时候能办好，所以没有声张，等办好后，离离职就只有很短的时间了，而项目到了非常重要的时期，他们team成立不久，其他成员均无太多经验，他的角色暂时无法找到合适的替代者，我做了以下准备，一、通过朋友推荐和参加一些技术交流的机会招聘合适人员；二、通过老总，全公司内部挖潜，并建立推荐人奖励制度；三、由于平时大家关系很好以私人饯行名义和他沟通。告诉他现在他在项目无人替代的重要性，是否他有推荐的合适的人选替代，因为移民过去要保证半年时间在移民地，而找工作可能会有困难，而且他也表示并不想离职，代他和公司人事沟通，以重新修改劳动合同而不离职方式解决了他的后顾之忧，该teamleader 也主动做好安排，延期出国，保障了项目的顺利结项和验收。我想，在奖惩、激励和重要沟通中选择合适的沟通方式会产生迥然不同的结局，尤其是我们好多软件开发人员比较内秀而不善言辞，项目经理更应注意这点，较好的引导和倾听能力是每个项目经理需要具备素质。
使项目成员目标一致，项目成员更好的进行配合和协调，有良好的沟通气氛、适当的竞争，减少冲突，提高项目组的工作能力和效率，团队建设是项目经理需要关注的一个课题，我的一些经验是尽早开始项目团队建设并持续进行；在项目计划、风险等重大决策上鼓励大家参与并取得大家的认同；经常评估团队绩效和效率；最好不要超过每周50小时的工作量；“利用好“老员工和上级领导。
经验分享。一项对项目经理的调查显示，项目经理平均每周参加6个会议，其中25%的时间浪费在无用的讨论上。会议效率低最普遍的3个原因是：会议没有很好的计划、会议没有被适当的领导、无纪律的与会者。我们软件项目也会遇到相同的问题，项目启动会、评估会、大大小小的评审会、技术会、周例会等等一系列会议会随着项目进展而召开，如何保证高效的会议效果，我的一些会议技巧与大家共享：确实需要开会时才开会；订立会议纪律；非常清楚的明确会议目标；提前准备一个会议议程；提倡各会议参与人的会前准备；鼓励参与，但在会议过程中遵守会议议程；把团队建设融入会议、作会议记录、会后跟踪所有安排任务的执行情况。
项目经理对项目成败负责，是项目中承受压力最大的一个，在风险较高的软件开发项目尤甚，项目经理沟通层面和项目可视化的工作繁复冗杂，计划中一定将管理活动列入工作量统计中，以便能使自己有时间和精力处理项目更重要的事情。项目经理应能忠实的反映一些无法力所能及的事情，取得上司的支持，这对项目成败非常重要。
软件项目管理，需要我们不但关注项目管理技术等在软件行业中的应用，还应该关注如何与软件新思想和技术的整合，例如XP等思想，使我们得到更高效益的产出。欲想琢其玉，必先利其器，项目管理和我们软件开发、质量管理等得一系列工具和模版，是我们事半功倍的利器。他山之石可以攻玉，关注一些管理界的发展，例如目前的中国式管理等，将其经验用于软件项目管理实践并总结，将为我们带来更大实效。
以上是软件项目管理的一些思索和经验，欢迎与大家交流共享。
项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧？项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。
一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗？项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢？欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了。在这种模式中项目经理不一定要求必须是技术专家，但更强调项目经理的工作经验，一般会要求项目经理有8年以上工作经验。而在中国，尤其是现在一个有三年工作经验的team leader也会称项目经理，当然他也并不需要对成本、人员、采购等众多项目管理领域的关注，这样的team里也根本不会有技术经理或顾问专有角色的配备，项目经理要更多的关注技术因素，所以项目经理一般是与行业和产品同步成长起来的。如何做好质量、成本、沟通、时间、以及更资源参与的全面项目管理是我们的项目经理的课题。
举例说明：以下是我负责的一个项目中，需求开发和管理的流程。
范围管理是项目经理具备的首要能力。范围说明是未来项目决策的基线，也是衡量项目是否成功的标准。在我们软件开发项目中，需求规格就是我们项目的范围的体现。我的经验是项目经理应极端重视需求，成功的需求管理才能保证范围在基线内，需求调查、讨论、分析、归档、review、变更、回溯等一系列活动是我们需求管理的有效活动。
计划能力是项目经理的应具备的另一个技能，其中软件开发任务的估算是一个难点，即使有历史数据达到CMM4的软件企业也会有20%-50%的误差，我的一些做法用三层到四层的WBS模版从底向上进行时间资源的估计，会从自己经验和相似项目的历史数据中进行加权平均，时间资源的平衡，在WBS分解模版中采用自底向上估计，估计时我们采用了三人以上匿名delphi法，设定差值阈值为30%，如果与平均值的差值比小于此阈值，将不在重新估计，如果大于将进行重新估计，重新估计后如果还是超过设定阈值，估计人要写明为什么如此估计的原因。对于阈值内估计值我们采用历史经验数据进行修正即可作为我们WBS工作包的估计值。
合适的软件开发生命周期模式，对软件开发项目尤为关键。根据项目的需求、资源、风险、时间、质量等实际情况，选择合适的软件开发生命周期模式，对软件开发项目尤为关键。印度软件模式中更是提出了流程模式重于项目。在需求不确定、变化较频繁的项目我们可以选用迭代和原型法。在产品按版本递增开发的项目，由于每期需求比较稳定，宜选择瀑布变种的V模型进行测试提前的生命周期。开发模式的选择将影响项目计划，例如V字形，每个过程都有严格的输入输出，上一个过程的输出作为此过程的输入，实际情况中我们会选用改良的V模型，一些过程可以并行，例如需求规格完成后，可以系统测试计划和概要设计并行。在实际项目管理中开发模型生命周期中各过程的输出宜作为milestone(里程碑)设置计划控制点。
时间、质量和成本是衡量项目成功的三要素，时间和成本因为有形比较容易监控，质量控制在软件开发项目中非常重要了，所以我们很多过程和活动（文档review、代码走读、单元测试、集成测试、系统测试、以及各过程的需求反馈追踪等）都是保障质量的活动。现在好多项目都特别重视了系统测试（包括功能测试、性能测试等），但是忽略了单元测试。单元测试是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节；是唯一一次有保证能够代码覆盖率达到100%的测试，是整个软件测试过程的基础和前提；单元测试防止了开发的后期因BUG过多而失控；单元测试的性价比是最好的。在项目中我们引入了TDD单元测试实践，并关注了编译检查、代码走读，以及在等价类、边界值、因果图等方法下的黑盒功能测试和达到覆盖率指标下自动单元测试代码的白盒测试。并将XP方法中的Nightly Test实践达到代码和测试代码的每日building。
Review活动在我们的项目中重视度很高，我们的一些评审制度，评审首先进行小组内部预评审，内部评审模版记录提交项目经理和评审组织者；正式评审可以先走email评审，评审对象完成人将评审文档或其他可交付物提前一天email给所有评审人，请评审人各自将意见email给评审组织者，评审组织者按评审人员汇总整理意见，提交第二天讨论。讨论后，评审结果记录和每人评审意见列入文档考核绩效。
软件开发项目中风险管理，风险管理不只是项目经理估计风险，我们风险管理采用了全员的头脑风暴法，并按权重进行TOP10列表管理。针对TOP10风险，制定相应风险应对计划。在软件开发中，主要的风险有技术风险，所以风险应对计划是项目计划前期的技术验证和测试，需求不确定等风险的应对计划是原型和迭代的开发方法。例如在界面越来越重要的今天，需求规格中会做出原型界面并提前得到客户方的review是很好的风险应对计划 。
沟通是监督、控制的基础，是推动项目执行的基础，更是减少冲突的良方。有项调查项目经理90%时间在沟通。的确沟通占用了项目经理的大部分时间，因为项目经理是面对项目干系人最多的角色。在项目沟通方面，作为项目经理应周期性向机构管理层和客户报告项目的技术、进度、费用、质量方面的状况；在客户面前全面代表所在机构，与客户建立和维持友好和开放的关系，直接面向客户的项目经理是客户与所在机构最关键的联系点；做一个项目沟通的推动者、避免项目中出现沟通的遏制者；为项目沟通积极创造环境，包括集中工作；保证所有会议的高效率。项目经理要根据不同人员和不同情况下的问题选择最合适的沟通方式（电话、传真、Email、口头、即时通信工具、报告、会议、私下交流等），来达到好的沟通效果。如果项目中出现与干系人等的问题，首先要检查沟通计划了。现在好多沟通事项是只装在项目经理的脑子中的，如何做好项目的沟通计划，是项目经理要培养成习惯的一个重要技能。这在我们软件项目中尤甚。例如员工流动始终是软件行业的一个显著特征，所以项目经理在处理此类问题时沟通计划就非常重要了。曾经我们一个项目开发中，一个team leader 想离职技术移民到加拿大，由于前期不知是否能办好也不知道什么时候能办好，所以没有声张，等办好后，离离职就只有很短的时间了，而项目到了非常重要的时期，他们team成立不久，其他成员均无太多经验，他的角色暂时无法找到合适的替代者，我做了以下准备，一、通过朋友推荐和参加一些技术交流的机会招聘合适人员；二、通过老总，全公司内部挖潜，并建立推荐人奖励制度；三、由于平时大家关系很好以私人饯行名义和他沟通。告诉他现在他在项目无人替代的重要性，是否他有推荐的合适的人选替代，因为移民过去要保证半年时间在移民地，而找工作可能会有困难，而且他也表示并不想离职，代他和公司人事沟通，以重新修改劳动合同而不离职方式解决了他的后顾之忧，该teamleader 也主动做好安排，延期出国，保障了项目的顺利结项和验收。我想，在奖惩、激励和重要沟通中选择合适的沟通方式会产生迥然不同的结局，尤其是我们好多软件开发人员比较内秀而不善言辞，项目经理更应注意这点，较好的引导和倾听能力是每个项目经理需要具备素质。
使项目成员目标一致，项目成员更好的进行配合和协调，有良好的沟通气氛、适当的竞争，减少冲突，提高项目组的工作能力和效率，团队建设是项目经理需要关注的一个课题，我的一些经验是尽早开始项目团队建设并持续进行；在项目计划、风险等重大决策上鼓励大家参与并取得大家的认同；经常评估团队绩效和效率；最好不要超过每周50小时的工作量；“利用好“老员工和上级领导。
经验分享。一项对项目经理的调查显示，项目经理平均每周参加6个会议，其中25%的时间浪费在无用的讨论上。会议效率低最普遍的3个原因是：会议没有很好的计划、会议没有被适当的领导、无纪律的与会者。我们软件项目也会遇到相同的问题，项目启动会、评估会、大大小小的评审会、技术会、周例会等等一系列会议会随着项目进展而召开，如何保证高效的会议效果，我的一些会议技巧与大家共享：确实需要开会时才开会；订立会议纪律；非常清楚的明确会议目标；提前准备一个会议议程；提倡各会议参与人的会前准备；鼓励参与，但在会议过程中遵守会议议程；把团队建设融入会议、作会议记录、会后跟踪所有安排任务的执行情况。
项目经理对项目成败负责，是项目中承受压力最大的一个，在风险较高的软件开发项目尤甚，项目经理沟通层面和项目可视化的工作繁复冗杂，计划中一定将管理活动列入工作量统计中，以便能使自己有时间和精力处理项目更重要的事情。项目经理应能忠实的反映一些无法力所能及的事情，取得上司的支持，这对项目成败非常重要。
软件项目管理，需要我们不但关注项目管理技术等在软件行业中的应用，还应该关注如何与软件新思想和技术的整合，例如XP等思想，使我们得到更高效益的产出。欲想琢其玉，必先利其器，项目管理和我们软件开发、质量管理等得一系列工具和模版，是我们事半功倍的利器。他山之石可以攻玉，关注一些管理界的发展，例如目前的中国式管理等，将其经验用于软件项目管理实践并总结，将为我们带来更大实效。
以上是软件项目管理的一些思索和经验，欢迎与大家交流共享。
来源：https://www.cnblogs.com/wayne-ivan/archive/2006/10/31/545324.html