UML软件工程组织

　　有人说中国软件企业和美国、爱尔兰，甚至日本（我这里不提印度，因为我认为中国和印度的软件企业发展思路是不一致的）相比最大的差距不是在技术层面上，而是在软件的项目管理上。我完全同意。

　　我也曾经参加过一些软件项目经理的聚会，在谈话中我发现，中国的软件项目经理真的是读了很多软件工程、项目管理类的书，很多人都参加过PMP（PMP是由美国项目管理协会发起的项目管理专业人员资格认证）的培训和考试，但在中国企业环境下解决软件项目中实际问题的能力存在不足，我们暂且抛开哪些"老外"们写的软件项目管理的经典论著，谈几个基本问题，希望对从事软件项目管理的PM们有所启发。

　　为什么要有项目管理？

　　没有项目管理，项目也有可能成功。但没有管理的项目，很难保证项目的利润空间，对公司来说，亏损的风险就大。所以我们要有项目管理，以保证公司在总体上是盈利的，注意不是每一个项目都要盈利。

　　另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：一个是人，特别是各级管理者；另一个是利益。关键是"利益"，准确的说是"利益的分配"，在权责利明确的前提下，人才能充分的发挥作用。还需要指出的?quot;利益"是多元的，这里的多元不仅指利益的具体形式，而且指利益的受众是多元的，包括客户方相关人员个人的利益。

　　为什么要有专职的项目经理？

　　专业化是一个趋势，因为在专业化的条件下，可以有效降低成本，提高利润率。项目经理的工作内容归根到底只有一项：识别并管理风险。这项工作的目的是控制项目成本。

　　由于项目的风险是多方面的，而且风险的表现形式也是多种多样的。从风险范围上来说，既有公司内部风险，也有和客户交流、合作的风险；从风险的类型上来说，既有管理风险，也有技术风险；从风险产生的阶段来说，包括了从业务分析到上线后维护的项目周诟鞲鼋锥巍?

　　我认为一个项目经理是否优秀，主要是看他/她能在多大程度上提前识别并消除风险，而不是弥补和解决了多少问题（风险未被及时识别或妥善处理，就会转换成问题）。当然能弥补和解决问题的项目经理也是相当合格的，但还不够优秀。

　　项目组的范围界限在哪里？

　　我认为项目组的范围界限可以有三种划分：

1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员，包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员；

2、包括客户方项目经理、业务需求提出人和测试人，包括开发商具体负责该项目开发的人员；

3、仅包括开发商具体负责该项目开发的人员。

　　大部分人在思想上可以接受范围1，而在实务中接受的是范围3。而我个人认为项目经理，特别是开发商方面的项目经理应该采用的是范围。

　　对项目组范围理解不同，将影响项目经理对工作的处理方式，范围1实际上是很虚的，在项目管理实务操作中没有太大的意义；而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来，也就是所谓的甲方、乙方。在这种对立的前提下处理项目的分歧和矛盾，效果肯定要打折扣。

　　而按范围2来理解，在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点，从而拆除双方之间的"障碍"，达到相互信任、相互尊重、共同协商解决问题的良性氛围，以达到降低项目外部风险的目的。当然，这样就增大了项目经理工作的难度，但对项目的成功则是很重要的。

　　怎样才能算是一个成功的项目？

　　对"成功项目"的标准解释为：项目范围、项目成本、项目开发时间、客户满意度四点达到要求。我认为其实只有一点--利益。项目范围、客户满意度主要代表客户的利益，项目成本主要代表开发商的利益，项目开发时间同时影响双方的利益。但每一个人关心?quot;利益"是不同的。

　　如何看待项目管理流程？

　　"项目管理流程"是管理项目的工具之一，不是管理本身，更不是项目管理的目的。

　　项目经理不能为了流程而流程。项目经理的工作内容我前面说过是"识别并管理风险"，而"项目管理流程"是在项目经理识别风险后作出的管理风险的选择。

　　不同的项目，项目风险也不同。

　　同样的项目，不同的项目经理，识别出的风险也不同。

　　同样的项目，同一个项目经理，面对不同的客户方负责人，面临的风险也不同。

　　同样的项目，同一个项目经理，同一批客户方负责人，不同的项目组成员，包含的项目风险也不同。

　　所以，我认为管理同一个项目可以有不同的流程。但不是要项目经理每次接手一个项目就创建一套全新的流程，而是根据不同的项目风险，选择适合的流程。事实上，项目流程的基本框架可以变化的地方并不多。另外还要能理解，即使采用完全相同的项目流程，处理流程各个环节中所涉及的具体问题的方法和时机仍然有很大的不同，所以即使采用同样的项目流程，也不能保证一定会降低项目风险。最重要的是"活学活用，融会贯通"，流程、项目管理软件、文档等等都是项目管理的工具。

　　如何确定项目资源投入量？

　　一个项目投入的资源有很多不同的内容，我只想谈谈关于开发人员的投入。有些公司的做法是项目经理、系统分析工程师根据客户需求估计一个人数，公司根据资源情况确定投入哪些人、什么时候投入、投入多少人。

　　我有几点是不理解的：项目经理、系统分析工程师确定项目组人数的标准是什么，仅仅凭需求就可以估算需要的人数吗？在公司不把成本控制指标下放给项目经理的前提下，项目经理凭什么决定要用多少人？在项目经理和系统分析工程师不了解开发项目组有哪些可用人、他们的具体技术背景、性格、合作默契度等情况下，凭什么决定要用多少人？需要给客户报价是另一回事。

　　我希望项目经理能够明白，项目人员的匹配有一个最佳的匹配范围，超出这个匹配范围的人数对项目是有害的，而且多要人可能比少要人对项目的风险更大，一次性投入和分阶段投入人员采用的管理方法是完全不一样的，实践证明用追加人员的方式来追赶已经延期的项目进度往往会造成延期的更久。

　　大家可以思考一下，为什么项目经理和系统分析工程师在确定开发人数时倾向于尽可能的多要？而在项目延期时，项目经理采用最多的方式是追加人员？

　　如何看待客户不断的需求变更？

　　首先要明白两点：一是，需求变更是不可避免的；二是，客户是理性的。

　　关于第一点，应该没有异议。第二点实际说了两层含义，一是，客户提出的需求变更是有理由的；二是，实现需求变更的方式和方法是可以和客户沟通，达成一致的。

　　如何理解"沟通"？

　　从某种意义上说，相当大的一部分需求变更和项目问题都是由沟通不充分产生的。影响沟通的主要原因为：

1、信息不对称。提出需求的客户和系统的最终用户信息不对称（甚至有时候，我们从一开始就得到的是错误的需求），我们和客户之间信息不对称，业务分析人员和项目组其他人员信息不对称，系统分析人员和程序开发员信息不对称等等；

2、人的惰性。人的惰性决定了：有些客户不会认真看业务分析文档和需求分析文档，甚至不会认真参加讨论；有些程序员不会认真看设计文档，不努力去理解业务知识；我们的文档没有记录所有的重要信息，没有根据变化进行时时的修改和更新；

3、选择了不恰当的沟通方法。我们没有选择有效的沟通方法与客户进行沟通；项目组内部没有有效的沟通机制。

4、时间约束。项目是在一定的时间约束的前提下开发的，而另一方面是客户往往没有专职人员，客户的时间不是随时都可以被占用的。