在IT行业混了十几年，从事项目管理（最早管理项目中的一部分业务模块，算是个team leader吧）也有七八年了吧，这十几年差不多也是中国软件行业飞速发展的十几年，软件项目的规模与管理等，也较早期有了质的变化，但总体来说，我对国内的软件项目还是比较失望的，优期是国内的企业，自己带过的项目、公司同事带过的项目、身边朋友带过的项目、客户实施的其他项目，很少有可以按照软件工程的思想去实施项目的，项目的质量、时间执行情况等到最后都会大打折扣，最后写起项目总结时，总能写出一大堆的项目管理过程的改善建议，下次再执行时，又总能出现新的改善建议，看上去似乎每次也都不太一样，但大能有规律可循。以下我根据自己在项目管理中的体会，谈谈自己对国内软件项目管理的一些想法，望各位轻拍~~~

软件项目管理的问题源头

在软件刚开始兴起的时候，国内的软件企业，优期是中小型软件企业，通常都有这样一种现象，几乎没有哪家企业在成立时，先投入大量技术研发力量的，也就是说很少企业是先进行产品研发的，多是先拥有一个或几个有需求的客户，然后给客户做项目化的开发，有的甚至于项目完成后，软件系统也就不会在加以完善了，最多是客户提新需求过来时，再进行完善。如果接到下一个项目，则在老系统基础上进行修改，以满足新客户的需求，如此几个项目下来之后，同一套软件系统便会出现多个版本，由于企业本身技术力量的不足，必然会走向无标准成型软件系统的路子上。最后同一个企业的同一个软件系统，便会出现很多个标准，从而导致在每一次的软件项目实施过程中，都没有一个稳定成熟的软件产品，但却走着实施产品的方式，以此来压缩项目实施周期，从而为项目实施过程增加了风险。

另外，部分相对成熟的企业，在初期的项目实施完成后，慢慢的感觉到，纯项目化实施的成本越来越大，也意识到以产品带动项目实施的重要性，因此便开始投入产品研发，但我们来看看他们的产品是怎么研发出来的，首先产品经理通常都来至于企业内部的项目经理，带过一两个项目，与一两个客户接触过，没有什么市场经验，更谈不上市场洞察力和市场需求分析能力了，并且在做产品前，也没有进行过市场需求调研（这里说的是市场需求，并不是特指一两个客户的需求，市场需求是指产品所面向的整个市场的需求情况，并且是未来若干年内的需求），他们完全是基于已完成的项目基础上，对项目产出物的不足之处的完善，通常会根据产品经理或架构师的个人理解，对软件产品预留一些扩展而已。这样的产品自然会存在很多的不足，一两个客户怎么能代表整个行业的需求呢，把项目产品物加以完善而形成产品，本身伸缩性有限，怎么能应对市场多种需求的变化呢，带过一两个项目的产品经理，他的视野又能有多开阔呢，这些问题必须会导致产品本身并没有什么市场竞争力，同时也会项目实施留下了不可回避的扩展风险。

国内企业有个特点，就是在付钱后，狠不点马上就能用上系统，根本不去考虑项目的实施周期问题，客户总觉得我已经付了首款，你就应该马上把东西给我，这是里所当然的。跟客户谈过工时的人，请问你们有没有遇到过哪个客户跟你说，这么点时间你们实施来的急吗，会不会时间太短了，要不要多点时间，对不起，这么多年来我没有见过一个客户这么问过我。其实一家企业从有需求进行招标开始，到最终的项目上线，周期还是非常长的，但我们回想一下，这么长的时间，项目招标以及产品初步交付到最终上线的过程用了多少时间。所以在项目立项到上线、甚至上线后的一段时间内，项目组的人都会拼命的赶进度、加班、加人等等，但最终还是感觉时间不够用，甚至于不能按计划上线。

上面我从产品质量问题以及项目实施周期的不合理性方面，分析了下国内软件项目管理的源头上所存在的问题，这为后期的项目实施过程带来了不可逾越的困难。后面我会陆续的对以上两点再做详细的分析，敬请关注！

我们都知道，项目是否可以结束，是要由验收情况来决定的，在国内的中小型企业的项目中，对于项目验收这块存在着很多模糊的情况，是导致项目验收过程不能顺利进行、甚至于无法进行验收的首要问题。

我问个问题，项目验收的标准是什么？大家都会说是需求确认书，那再问一下，需求确认书的标准又是什么？没错，是项目合同。项目合同才是项目验收标准的首先依据，而在国内软件项目合同中，基本都存在着很多的问题，这些项目合同大多都描述了合同的金额、项目名称、交付物、几个关键时间点，对于项目实施的范围有些也会有所描述，但都比较简单模糊。另外一点，对于有些项目经理，有可能连项目合同中仅有的部分项目边界描述也没有机会看到，这样必然会导致软件项目后期验收中的问题。

因此，在签定项目合同时，就应该考虑一下项目验收的问题，为项目验收界定一个明确的范围，比如说项目所涉及到的部门、所需要解决的业务清单、所需要达到的目标、交付物的交付标准与规范等，并且把项目验收计划书作为合同的附件、以后做项目验收时，仅以此验收计划书为基准，这样就可以有效的避免因在项目过程中无限扩大边界而导致的项目无法完成验收的问题。

在项目合同期明确的验收标准之后，在需求阶段，应以项目合同为基础、验收计划书为指导依据进行需求确认，如果有必要，可以在需求确认阶段修订验收计划书，这样也可以保证项目边界与合同不会有太多的出入。

在保证了项目验收计划书的质量之后，后期进行项目验收时，就不会出现这个没实现、那个也没实现的问题（如果真有没实现，那可能真是实施的问题，忘记实现了），因为有法可依了，同时项目经理在准备项目验收时，也可以提前参照一下验收计划书，以免有未达到目标的部分出现，也可提前把问题解决，为项目验收扫清障碍。

在软件项目中（其他类项目也是一样），项目经理的作用至关重要。平均算下来，一个项目的成败、完成质量大约有60%的因素取决于项目经理（也就是说一个很差的项目经理，至少有60%的项目实施失败或完成质量低下）。目前，在国内的软件项目中，项目经理主要有以下几种类型：

1、挂名项目经理

这种情况主要出现在面向客户的时候，由于企业自身项目经理的素质较低，拿不出手，或者是为表示对客户的“重视”（注意，这里只是在官场上的重视），公司选用高层领导担任项目经理，其并不会参与项目过程的实质性工作。此类项目经理因为是挂名，不参与实质性工作，所以对项目过程的影响比较小，可以说是可有可无，所以对能力方面也没有什么要求。

2、实施类项目经理

此类项目经理主要负责对客户的项目实施，一般公司拥有自己产品的时候，会设立实施类项目经理，这类项目经理通常技术水平一般，业务能力较强。实施类项目经理通常出生于项目实施工程师、咨询顾问。所以一般业务能力会比较强，但问题是可能管理能力和技术能力会跟不上，优期是技术能力，因为软件项目中或多或少的都会涉及到客户化的开发，由于技术能力的欠缺可能会导致对方案、工时方面的判断失误。

3、技术研发类项目经理

此类项目经理多为客户化开发或公司内部的项目经理，主要是带领团队从事技术研发工作，本身技术能力较强。该类项目经理通常出生于技术工程师，所以技术能力一般较强，但问题是管理能力不足、业务能力欠缺、优其是技术出生的管理者往往太追求完美或因专注于某项技术而忽略整个项目的管理。

4、全能性项目经理

此类项目经理就比较“利害”了，什么事都能干，可一人兼做商务、技术架构、业务咨询等，通常此类项目经理在小型企业的小型项目中比较多见。此类项目经理通常出生于技术，因为在很多个中小型企业做过，所以练就了一人身兼多职的能力。看似比较“全能”，其实各项能力均不够专业化，也就是大家说的什么都会，但什么都不精。这类项目经理特别适合中小型企业的中小型项目，他们可以在资源严重不足的情况下，完全通过个人的能力完成一个小型项目。这种项目的失败率也比较高，项目经理顶不住，项目必然失败。所以全能型项目经理在稍大些项目中，也很难看到。

为了更好的进行软件项目管理，实质上应该只有实施类项目经理和技术研发类项目经理才能算的上是真正意义上的项目经理，才能担当软件项目经理一职，才能管好项目。这两种类型的项目经理，在其自身能力方面，应该各具特色，其中必备的能力素质如下：

1、团队管理能力；

2、沟通协调能力；

3、控制能力；

4、执行能力；

5、解决问题的能力；

6、责任心；

7、对于实施类项目经理，必须具备业务能力（可以不熟悉项目所涉及到的全部业务，但必须熟悉一种以上，并且必须熟悉各业务间的耦合）；

8、对于技术研发类项目经理，必须具备很强的技术研发能力（可以是项目所涉及到的一种或多种技术）。

除了以上所描述的项目经理必备能力素质以外，项目经理还必须要有项目上所必须的特殊化技能，如对国外客户时应具备与客户沟通的语言技能等。

项目经理如果存在以下问题，可能会直接或间接的导致项目的失败：

1、实施类项目经理不熟悉项目中的业务；

2、技术研发类项目经理不具备技术研发能力；

3、太专注于某一方面，而忽略整个项目的其他方面；

4、太强调自己的领导地位，让下属对其失去亲和力；

5、过问太多细节，表现出对下属的不信任；

6、做事太过谨慎，当断不断；

7、表达能力差，不能用简短的语言描述清楚一件事情；

8、事事追求完美者。

另外，在国内的软件项目中，项目经理本身的职责权利还没有达到真正意义上的权利，在项目中的很多事情项目经理不能自己做主，如项目实施方法论、项目中的部分关键时间点，甚至于部分项目资源的分配方式等。这也会制约部分有实际能力的项目经理的能力发挥。因此企业在任命项目经理时，除了要选配具备项目经理素质的人才之外，还应提供一定的职权空间。

在软件项目中，通常情况下都会分成以下几个阶段，项目立项、需求调研、需求分析、需求确认、功能设计、设计确认、功能开发、测试、实施推广、试运行、项目验收。这是比较详细的分法，还有一种比较大的分法，如下所示：

1、需求阶段：包括有需求调研、需求分析、需求确认；

2、设计开发阶段：功能设计、设计确认、功能开发、测试；

3、实施阶段：实施推广、试运行、项目验收；

从上面可以看到，可把项目阶段统分为三个大的阶段，从这三个大阶段方面，我们来分析下各阶段的重要性，这里所说的重要性是站上项目风险和控制难易成度的角度来考虑的。
首先来说说需求阶段，需求阶段的目的是为了了解清楚用户现在的情况和未来的一些想法，项目需求人员要通过各种方法把用户了解清楚，并转化为自己的理解，在这个阶段通常会存在以下几方面的问题：

A、怎么样让用户把他们的现状完整、准确的描述给你；

因为对于企业来说，都是分工合作的，每一个人都只会熟悉自己的业务部分，即使对于上层管理者，他们所了解的是大方向上面的东西，对于细节了解不够，所以在需求调研时，想准确、完整的了解到用户现状是非常困难的一件事，优期是各业务间的耦合部分，你有时会觉得找不到一个人可以说清楚这中间是如何衔接的。

B、现状中的问题无人可以承担

在经过一段时间的现状调研之后，你会发现这家企业中存在着各中各样的问题管理上的问题、或业务操作上的问题，这时你可能是为了要把现状陈清，所以希望能有个人出来说，是的，这块是有问题，这实际上也是一件很困难的事， 因为谁也不想承认自己的错误。

C、流程再造后无人愿意定案

在进行完现状调研之后，必然会进行必须流程再造，对于新流程的应用，必须会涉及到原来职责、职能的变更，对于这样的变更必然是要经过相关管理层人员的决策，这是一个长期而又慢长的过程，一般管理者都不会轻易的去改变现有的管理模式，所以这给需求确认阶段带来了不少的困难。

其次来分析下设计开发阶段，该阶段是建立在完成需求阶段的工作基础之上的，需求阶段的成果直接决定了设计开发阶段的工作。在该阶段的主要问题表现为以下几个方面：

A、开发过程中，用户提出的需求变更

在开发过程中，最让人痛苦的莫过与此了，谁也不想辛苦设计开发出的东西，刚完成就被用户否定了。

B、开发出的东西与设计的东西不一致

通常因为开发人员对于需求或设计的理解不够，会导致开发出的东西和设计不辅，从而不得不进行修改程序。

C、开发出的东西有一堆BUG

这是在正常不过的事情了，所以才需要测试啊。

最后来说说实施阶段吧，在经历前面的需求和设计开发阶段后，总算可以拿出东西给客户看了，实施阶段往往并没有想象中的那么顺利，在该阶段主要有以下问题影响的实施进度。

A、用户进行系统验证时发现自己看到跟当初想象的不一样

这个每个项目经理都会有体验吧，不管前期做了多少次变更，总规有那么些节点跟用户想的不一样。

B、上了系统后，用户不知道怎么做业务了

系统都是按照用户的要求进行设计的，即使有些流程跟以前不太一样，但也是通过用户确认认可了的，但在新的系统上，用户就是不知道该怎么做业务了。

C、有些人始终停留在老的操作模式上，不愿意改变

在实施推广阶段我们总会遇到一部分人，不管你怎么说，他总是坚持自己的想法，有的可能真的是不知道怎么改变，而有的也会是因为各种原因不愿意去改变，他们不改变你就永远无法完成系统的实施。

实施项目实质上也可以看成是一种投资，站在投资的角度来考虑，投资分析最重要的一点是前期的准备工作，真正的投资实施过程并不特别难，因为你只要按照前期计划的去做就可以了。所以说在软件项目中， 需求阶段是最为重要的，其次应该是实施推广阶段，最后才是设计开发阶段，为什么要这么说呢，可从以下几个方面来分析。

A、需求阶段的目的是为了搞清楚后面的工作该怎么做的，如果你都不知道用户的现状是什么样的，都不知道用户想要什么样的的东西，那后面的设计和开发出的东西可以说不可能满足客户的要求，也必然会经历一次又不一次需求变更，即使到了实施推广阶段你也一样无法进行推广，因为跟他们现在的业务完全不辅，你让人家怎么去用。

B、需求阶段因为是与客户进行交流互动的过程，因为你对客户的不了解（如果你了解，可能就不需要调研了），所以交流上会存在各种困难，有个事情，你甚至不知道该找谁去问。了解客户的现状还需要客户在时间和人员上的配合，改造他的流程，也需要相对领导的审批，这些都可能不是调研人员所能控制的，难道你想让客户停止现在的业务来配合你，这不可能；难道你想让客户的领导不要出差、不要开会，来给你签字确认，那更不可能。

所以需求阶段有很多因素是你不能控制的，所以是有风险的，所以是最困难的。

C、设计开发阶段其实并没有想象中的那么困难，假如说你已经知道了你要做一个什么的东西，你对的你团队又很了解，你应该可以控制他们，可以安排他们，那么接下来你要做的就是安排一步步的去实现就可以了，如果有难度那可能就是人力资源不够吧，那也没关系，你还可以安排加班呢，如果还不行，那你就应该提出来了，即使是简单的实现工作，算上加班，你现在的人手也不够，那只能增加人手或延长时间了。

这里你不要说中间可能会存在很多技术上的问题，或者进行二次开发时的一些切入点问题，这些我认为不是关键性的问题，作为一个项目团队，如果连一些技术问题都解决不了，还怎么去实施项目呢，再说现在对于业务功能的实现也不局限于一种技术，为什么你一定要选一个你实现不了的技术呢。

所以说设计开发阶段应该更多是量化性的工作，并且是可控制的，所以说风险应该也是最小的。

D、实施推广阶段，因为在需求阶段不管如何做，总规会存在一些需求变更的情况，其中在实施推广时表现的也最为强烈，并且实施推广阶段要涉及到用户业务操作方式的变化，所以说需要一些时间给用户进行转换与适应。另外在实施推广阶段中，因为所涉及到都是客户人员，有些时候还会是客户的客户，所以在应用推广时，会存在很大的障碍，主要还是业务切换上面的问题。

综上所述，在项目管理的三大阶段中，需求阶段最为重要，也重困难，其次是实施推广阶段，设计开发阶段应该是最容易的，因此我们在项目总的时间分配上，应根据各阶段的具体情况来制定时间计划。在通常情况下，应该三个阶段所有时间比例想近才对，你不要介意前期花太多的时间去做需求，那绝对是值得。对于设计开发阶段的时间可以压缩的话，可尽量压缩，把时间留给需求和实施推广阶段，不要把太多的时间花在内部上，而应该花在客户身上，不可控的才是风险，可控的算不上什么风险。