软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有60％的软件项目的失败是因为估算偏差引起的，而不是因为技术实力不够。因此，估算偏差已被列为软件项目失败的四大原因之一。 从软件工程学上，我们知道软件需求和估算是软件项目的基础。因为只有准确的了解客户的需求，以之为基础，并使用科学的方法对目标软件系统的规模、工作量和进度做出合理的估算，我们才能在预算内按时按质顺利的完成项目。然而，软件估算作为软件项目的基础领域却常常被人们所忽视。我在近期的一个开发项目中就尝到忽视软件规模估算带来的苦果，结果是项目进行到一半时就发现不但工期严重滞后于计划，而且项目的各种资源也严重的不足和缺乏，项目被迫暂停下马。 常见的项目规模估算失准原因 一直以来，软件项目的规模估算（Size Estimation）是个争论不休的问题。不论是对软件开发团队还是对软件用户，软件规模估算的重要性都是不容置疑的。因为它能极大的影响着甲方对发包软件的成本估算，乙方对自身开发成本的预测，以及乙方对开发过程的量化管理等诸多方面。而且，只有相对合理和相对准确地估算软件规模，才能对项目的进度安排、资源分配等各个环节进行合理的部署。所以，软件项目的规模估算是软件项目中相当重要的一环。但是，以下的原因却使到我在这次项目的实际操作中对项目规模估算失准了： （1）对项目规模估算认识不足 项目规模估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。因此，如果对规模估算认识不足的话，将可能会在这两种应用场景中估算失准。例如，如果项目规模低估的话就会造成人力估算低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算。最后为了完成项目不得不赶工，不但会影响到项目质量，甚至会导致项目失败。而如果规模高估的话，就会因估价过高而降低了招投标时的竞争力，或在进度安排时提高了开发成本和浪费资源。由于对规模估算的认识不足，使到我在这次项目中就尝到一个大苦果，就是低估项目规模导致项目需要多次的追加预算。我不但多次受到公司领导的批评，而且还受到客户的多次投诉。 （2）个人经验估算法带有一定的局限性 一般来说，依靠历史或个人经验的规模估算方法都有一定的局限性。原因是很难在项目分析和计划阶段就对软件的规模进行相对准确的估算。因为估算是依靠评估人员的经验，所以对评估人员的能力要求比较强，并且难以由第三方对评估人员的工作偏差作出修正。在这次项目的初期，我片面的只是根据个人经验进行估算，结果是轻率的估算了项目规模。这是最后导致项目失利的原因之一。另外，不同软件项目使用的技术不一样，这一点也非常影响到软件规模的估算。例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行，甚至数百行。即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样。 （3）对项目估算时缺乏数据支持 因为在软件开发初期时对规模估算都是很难准确量化的，所以到底需要多少资源、多长时间或者规模估算到什么的程度才算是合理的是没有一个标准的。但一个好的项目估算，是离不开一个准确的、可信的、客观的数据作为基础。如果在项目规模估算时只凭项目管理人员的经验进行估算，而缺乏大量的数据支持，那么估算最终就会变成常见的”三拍”现象：”首先是项目经理拍脑袋估算，然后是项目经理估算失准时拍马屁的补救，最后是项目失败时拍屁股走人”。当然，这只是个玩笑。不过由此可见项目规模估算不能只依靠经验来估算，而应该是要有大量的数据来支持。 什么是软件项目的规模估算？ 软件开发项目管理中的一项重要任务是开发项目的规模估算，这是极其重要但却很容易被忽视的一项内容。因为没有正确的规模估算，项目计划就会失去成功的基础。可惜大部分的开发团队都很难做到对项目规模进行准确的估算。 （1）什么是项目规模估算？ 做好软件项目管理的基础是要做好项目的规划工作，而做好项目规划的前提是要做好软件估算。也就是说，就是没有好的软件估算，项目的规划、跟踪和控制就根本无从谈起。因此，软件估算是项目计划活动的基础之一。 软件估算一般是通过主观经验和客观分析两种方法进行，包括有四个重要方面：规模估算、工作量估算、进度估算和成本估算。其中，对规模进行估算是为了将项目范围进行量化。规模估算是整个软件估算中最核心、最基础的环节，也是整个软件估算的第一步。规模估算有两个主要作用：一是通过规模估算建立项目基线；二是利用基线对项目生产率和状态进行评价，并确定软件过程的进度目标。也就是说，规模估算是一切估算的基础，是能直接决定和影响到其它三个估算的决策。 [...]]]>

软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有60％的软件项目的失败是因为估算偏差引起的，而不是因为技术实力不够。因此，估算偏差已被列为软件项目失败的四大原因之一。
从软件工程学上，我们知道软件需求和估算是软件项目的基础。因为只有准确的了解客户的需求，以之为基础，并使用科学的方法对目标软件系统的规模、工作量和进度做出合理的估算，我们才能在预算内按时按质顺利的完成项目。然而，软件估算作为软件项目的基础领域却常常被人们所忽视。我在近期的一个开发项目中就尝到忽视软件规模估算带来的苦果，结果是项目进行到一半时就发现不但工期严重滞后于计划，而且项目的各种资源也严重的不足和缺乏，项目被迫暂停下马。
常见的项目规模估算失准原因
一直以来，软件项目的规模估算（Size Estimation）是个争论不休的问题。不论是对软件开发团队还是对软件用户，软件规模估算的重要性都是不容置疑的。因为它能极大的影响着甲方对发包软件的成本估算，乙方对自身开发成本的预测，以及乙方对开发过程的量化管理等诸多方面。而且，只有相对合理和相对准确地估算软件规模，才能对项目的进度安排、资源分配等各个环节进行合理的部署。所以，软件项目的规模估算是软件项目中相当重要的一环。但是，以下的原因却使到我在这次项目的实际操作中对项目规模估算失准了：
（1）对项目规模估算认识不足
项目规模估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。因此，如果对规模估算认识不足的话，将可能会在这两种应用场景中估算失准。例如，如果项目规模低估的话就会造成人力估算低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算。最后为了完成项目不得不赶工，不但会影响到项目质量，甚至会导致项目失败。而如果规模高估的话，就会因估价过高而降低了招投标时的竞争力，或在进度安排时提高了开发成本和浪费资源。由于对规模估算的认识不足，使到我在这次项目中就尝到一个大苦果，就是低估项目规模导致项目需要多次的追加预算。我不但多次受到公司领导的批评，而且还受到客户的多次投诉。
（2）个人经验估算法带有一定的局限性
一般来说，依靠历史或个人经验的规模估算方法都有一定的局限性。原因是很难在项目分析和计划阶段就对软件的规模进行相对准确的估算。因为估算是依靠评估人员的经验，所以对评估人员的能力要求比较强，并且难以由第三方对评估人员的工作偏差作出修正。在这次项目的初期，我片面的只是根据个人经验进行估算，结果是轻率的估算了项目规模。这是最后导致项目失利的原因之一。另外，不同软件项目使用的技术不一样，这一点也非常影响到软件规模的估算。例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行，甚至数百行。即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样。
（3）对项目估算时缺乏数据支持
因为在软件开发初期时对规模估算都是很难准确量化的，所以到底需要多少资源、多长时间或者规模估算到什么的程度才算是合理的是没有一个标准的。但一个好的项目估算，是离不开一个准确的、可信的、客观的数据作为基础。如果在项目规模估算时只凭项目管理人员的经验进行估算，而缺乏大量的数据支持，那么估算最终就会变成常见的”三拍”现象：”首先是项目经理拍脑袋估算，然后是项目经理估算失准时拍马屁的补救，最后是项目失败时拍屁股走人”。当然，这只是个玩笑。不过由此可见项目规模估算不能只依靠经验来估算，而应该是要有大量的数据来支持。
什么是软件项目的规模估算？
软件开发项目管理中的一项重要任务是开发项目的规模估算，这是极其重要但却很容易被忽视的一项内容。因为没有正确的规模估算，项目计划就会失去成功的基础。可惜大部分的开发团队都很难做到对项目规模进行准确的估算。
（1）什么是项目规模估算？
做好软件项目管理的基础是要做好项目的规划工作，而做好项目规划的前提是要做好软件估算。也就是说，就是没有好的软件估算，项目的规划、跟踪和控制就根本无从谈起。因此，软件估算是项目计划活动的基础之一。
软件估算一般是通过主观经验和客观分析两种方法进行，包括有四个重要方面：规模估算、工作量估算、进度估算和成本估算。其中，对规模进行估算是为了将项目范围进行量化。规模估算是整个软件估算中最核心、最基础的环节，也是整个软件估算的第一步。规模估算有两个主要作用：一是通过规模估算建立项目基线；二是利用基线对项目生产率和状态进行评价，并确定软件过程的进度目标。也就是说，规模估算是一切估算的基础，是能直接决定和影响到其它三个估算的决策。
软件项目的规模估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。 因此，估算错误已被列入软件项目失败的四大原因之一。
软件工程师经常会被问到，编一个什么什么样的软件需要多长时间、多少钱。面对这个问题，有不少人很犯难，因为，第一用户的需求太不具体，第二，自己缺乏一个科学的估计方法。这里向大家介绍几种软件项目规模的估计方法。
概念介绍先介绍一个衡量软件项目规模最常用的概念——LOC（Line of Code），LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：Job Control Language）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。
例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（。c和。h文件）约为250K.某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为：（240×10000）/150000＝16元/LOC改项目的人月均代码行数为：150000/240=625LOC/人月方法一、Delphi 法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家”专”的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。
Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6， 直到达到一个最低和最高估计的一致。

方法二、 类比法类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
其基本步骤是：1、整理出项目功能列表和实现每个功能的代码行；2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；3、通过步骤1和2得出各个功能的估计值；4、产生规模估计。
软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：等价代码行 = [（重新设计% +重新编码% +重新测试%）/3]× 已有代码行比如：有10，000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：[ （30% + 50% + 70%）/3 ]× 10，000 = 5，000 等价代码行。
意即：重用这10000代码相当于编写5000代码行的工作量。
方法三、功能点估计法功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。通常的步骤是：1、计算输入，输出，查询，主控文件，和接口需求的数目。
2、将这些数据进行加权乘。下表为一个典型的权值表。
功能类型 　权值
输入 　　　4
输出 　　　5
查询 　　　4
主控文件 　10
接口 　　　10
据发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。然而，在了解产品越多后，功能点可以转换为软件规模测量更常用的LOC.方法四、PERT估计法PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E， 和标准偏差SD.详细的估计方法，读者可参考笔者所写的《应用PERT进行项目工期估计》一文

虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行……因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》 1、估算前的规划 当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。 软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。 1．1、规划的第一步：确定软件范围 确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势 ，等等。 获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述： 在供电站总部每天结束前要审核下属节点操作员（30~40个）的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号（MODEM）用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据（一旦审核完毕的数据，就进行归档）总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。 通过上面的描述，我们通过提炼和简化，得到软件的一下功能： ◆ 节点数据录入、查询、上传 ◆ 总部数据汇总、查询、反馈 ◆ [...]]]> 虽然估算是一门科学，更是一门艺术，这个重要的活动不能以随意的方式来进行……因为估算是所有其他项目计划活动的基础，而项目计划又提供了通往成功的软件工程的道路图，所以，没有它我们就会搭错车。——Roger S. Pressman 《软件工程——实践者的研究方法》
1、估算前的规划
当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
1．1、规划的第一步：确定软件范围
确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术（如需求诱导），从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势 ，等等。
获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：
在供电站总部每天结束前要审核下属节点操作员（30~40个）的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号（MODEM）用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据（一旦审核完毕的数据，就进行归档）总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。
通过上面的描述，我们通过提炼和简化，得到软件的一下功能：
◆ 节点数据录入、查询、上传
◆ 总部数据汇总、查询、反馈
◆ 总部与节点的互联
◆ 总部数据库存储
◆ 节点数据的本地存储
在本例中，软件的性能是潜在的。客户虽然没有明确提出，但是由于数据本身的重要性，要求系统在数据上传、反馈、存储过程中安全可靠。客户要求使用MODEM进行拨号连接，那么鉴于MODEM连接过程中可能会出现，由于拨号断开而道导致的数据丢失，在节点本地存放一份数据副本是有必要的。由于系统要求每天上传数据，总部数据库应当是7X24小时不间断服务的，再加上目前总部只有该系统运行接受数据任务，各节点数据量并不大，那么在建议用户选择服务器时，应当考虑性能稳定可靠，但并不一定要购买大容量磁盘阵列和高性能双CPU主机。由于每天上传数据接近下班时间，那么总部汇总数据应当是自动进行的，一旦分析发现重大问题，可以通过与外部网络的设置，向值班人员发送手机讯息、E-MAIL或其他警示。由于不同人员对于上报数据的权限不同，对于系统用户实行分级管理。不同级别的用户，具有对数据的不同管理权力，从而保证在软件使用过程中不发生混乱。
那么现在一个较为清晰的软件模型已经构造完毕，接下来我们需要进入计划的第二步：确定工作所需资源。
1．2、规划的第二步：确定工作所需资源
软件工作所需资源包括：工作环境（软硬件环境、办公室环境）、可复用软件资源（构件、中间件）、人力资源（包括不同各种角色的人员：分析师、设计师、测试师、程序员、项目经理……）。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比例最小的，最下面的是组成比例最大的部分。
■ 人力资源
一个项目到底需要多少种职务的人员构成、多少数量的人员总量，再能成为最有创造力的团队呢？这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。

■ 可复用软件资源
这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。根据不同的应用、时间、来源，可复用软件资源被分为以下几种：
可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。
具有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险相对较小。
具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这类构件进行所需的修改会有相当程度的风险。
新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构件。
在采用构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂亮的构件的应用，可能会带来潜在出错的风险或者必须经过复杂修改或者效率低下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满足项目的需要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使用的构件。
■ 环境资源
“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。
站在人件的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工，产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。
到此为止，估算前的项目计划已经完成，我们已经形成一个工程开发框架。这是一个有界限的框架，虽然还不够精确，但足以进行估算的工作。
2、估算的对象
目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。
估算主要包括以下几个重要内容：
◆ 规模估算
软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。
◆ 工作量估算
这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。
◆ 进度估算
进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。
◆ 成本估算
包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。
3、估算的策略
在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。
3．1、自顶向下的策略
这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。
当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。
3．2、自底向上的策略
与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。最后将估算加起来就是项目的估算值。
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。
4、估算的方法
显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。
估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。
4．1、FP功能点估算法
功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等；技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。
4．2、LOC估算法
这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码（LOC）作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：
PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。
类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长。
系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS（系统分解结构），它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。
4．3、IBM模型估算法
该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。
4．4、COCOMO估算法
Boehm在其经典著作“软件工程经济学”(software engineering conomics)中，介绍了一种软件估算模型的层次体系， 称为COCOMO(构造性成本模型，COnstructive COst MOdel)，它代表了软件估算的一个综合经验模型。
COCOMO 模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序)；(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。
4．5、软件方程式估算法
软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。
4．6、WBS估算法
这是一种基于WBS（工作任务分解）的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：
对项目需求作出一个完整的限定。
制定完成任务所必需的逻辑步骤。
编制WBS表。
项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。
5、估算的戒律
记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确?? ——亚里斯多德
对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们不是用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。
不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。更何况估算的太精确，反而会失去灵活机动的空间。

不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。

不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。
客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。

客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。
不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现客户的需求。但我们要实现的是合理的目标，况且不能为了完成目标而去堆积数字，这样岂不是因果倒置了。
不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。现在风险就会带来潜在的成本，如：突然一位程序员离职，导致工作进度路落后。我们不可能估算到任何一种可能发生的情况，但有责任把可能出现的一些关键环节列出来。

久而久之，项目变成了你一个人的项目，项目成员成了看客，你天天埋怨底下这帮人真笨，没本事，什么都要靠你自己；项目成员天天想这个项目经理实在没水平，根本不会安排工作，跟着这样的人，完全是在浪费时间，一点成就感也没有。

项目经理，为什么你总是项目工作进展的瓶颈？

我刚开始做项目经理的时候也有同样的烦恼，也完全束手无策，现在好多了。因为从心态上，我知道自己一定不是这个世界上把事情做得最好的人，我相信就在我的项目组里一定有做得比我好的人，只是我没发现，或者我没告诉别人要做什么，怎么做。

作为项目经理，如果你还没把你能干的事情交给别人干，那你实在是太可怜了，或者说你根本不会当项目经理。就好像我们很多管理者整天忙于业务一样，总是忙于喂“猴子”，帮所有的人喂“猴子”，自己饿死了，底下的人却一身轻松地潇洒而去。

刚做项目经理的时候，事情往往不太容易想明白，而事情没想明白就觉得任务无法分下去，即便勉强分下去了，拿出来的东西也不是自己要的。于是很烦，觉得还不如自己干。咨询就是这么奇怪的一件事情，等你完全想明白的时候，事情也做完了。这样反反复复几次，顾问成员觉得你总在变，让人无所适从，于是开始质疑，在你分配工作的时候，问了几个问题你就被问倒了，所以你也不敢再指挥了。于是你威信扫地，无法指挥了，你觉得指挥别人比自己干还累，也不愿意再指挥了。就这样陷入了恶性循环，你只好自己单干。

项目经理永远要记住的是：项目总体的质量是你控制的，项目内容的质量是靠项目成员保证的。项目总体的质量是指项目边界，项目内容核心关注的点，主要观点的正确性等。

所以，项目经理首先要判断的是该做什么，不该做什么？一旦决定要做，就开始和项目成员讨论思路，如果自己没有思路，就让项目成员拿思路，讨论到一定程度，就分头去干，干了再讨论，反复几轮就清楚了，而不要等待，等待没有结果，行动才有结果，有些弯路是必须要走的。

而对于项目成员，永远不要期待在咨询项目中，项目经理告诉你一个明白无比的思路和做事的方式，除非你撞大运了，遇到了一个巨牛无比的项目经理，所以，从项目成员来讲，该忍受的还得忍受，互相帮助才可能把项目做好。

对于项目经理而言，如果你想得明白，工作模版是你控制项目质量的好工具，所以你的工作是和项目成员讨论模版，并且让他们理解模版，至于根据模版完成的内容，一般而言，你就无能为力了，得靠你的项目成员了。

对于咨询项目而言，项目经理必须要有一个本事，能抓住重点，当你的项目成员给你100页的报告时，你清楚地知道最关键的是什么？一句话能说清楚，一页PPT能说清楚，十页PPT能说清楚，100页也能说清楚，这是真本事。反过来说，当你分配任务的时候，你要清楚地告诉项目成员里面的关键点在哪里，如果你实在不知道，就让项目成员告诉你，如果他也不知道，那就讨论，实在讨论不清楚了，就开始做，做了再讨论，反反复复，总有清楚的一天。

项目经理该做什么？

如果一个4个以上项目成员的项目团队，项目经理还在做具体的事情，花很多时间写具体的文档，那这个项目肯定存在问题了。因为你已经花了太多的经历在具体细节上，意味着更重要的事情你没有关注。在我看来，项目经理最应该做的三件事情是：项目总体计划和控制、沟通和协调资源、处理项目之外的事情。

• 项目总体计划和控制

计划只是控制的一个手段，你必须想清楚整个项目的大阶段，在项目进度出问题的时候，如何快速推进。我一般会列出大的阶段性计划和关键要求，具体的阶段的详细计划，我都会安排一个项目成员来总体负责这个阶段的事情，因为我已经没精力了。有问题我们可以讨论，但必须有一双眼睛盯着这件事情。

另外，我常用的一个手段是文档模板，通过文档模板来控制项目内容和质量，这个非常有用，如果把文档模板只是理解为格式，那就没意思了，文档模板是框架的确立，至少要细化到3级目录，有时候甚至具体的表格、具体的问题和关键字段，详细程度视重要程度而言，这个工作对项目经理而言是非常重要的，会花很多时间。当然，对我而言，我也不会自己写一个扔出去，而是通过讨论，拿笔划划，让项目成员准备初稿，然后一轮一轮的讨论，通过讨论使大家明白这个过程和内容要求。

• 沟通和协调资源

有人说项目管理的工作就是沟通、沟通、再沟通。一点没错。项目经理需要沟通的人太多了，客户、项目成员、公司、家里人，一堆人，不花时间怎么能解决问题？所以你必须花大量的时间去沟通。我判断一个项目的成功状态是你到底花了多长时间和客户在一起沟通，对一个项目经理而言，比较理想的状态是你随时可以推开客户方任何一个人的办公室的门去聊，除了有秘书挡架的之外（有秘书挡架的要通过mail、书面材料来补）。一个好的项目经理，在两到三周就能达到这个状态。这个状态的背后意味着你能帮助客户解决问题或者给他帮助和启发，否则就是推门进去了，客户也会把你踹出来。

另外一个重要工作当然是协调资源，这方面内容很多。最重要的一点是，如果你发现某个问题项目组所有人都搞不定了或者不经济了，想别的办法吧，找别人吧，客户方的，公司的，外面的都可以。这个工作比较难，也很烦琐，所以总体上往往还是要自力更生，艰苦奋斗。借助项目外的资源来解决目标明确的具体问题，协调资源的次序一定是：客户、自己的公司、外部资源，搞错次序了，就复杂且麻烦了。

• 处理项目之外的事情

项目经理还有一个很重要的工作就是控制项目范围，怎么控制？要敢于向客户说“不”，但这个“不”不是乱说的，如果你拒绝客户，你就拒绝了自己。这远远不是一个说话的艺术问题，而是是否能站在客户立场上，帮助客户解决问题的问题。即使项目无法很好解决，你需要告诉客户怎么解决，给人一条出路，而不是堵回去。在此基础上再分析在项目的时间、成本、质量和范围约束下，我们能做什么。给客户解决方案，小到参考文档，大到运作项目、整合资源都不是简单的事情，需要投入很多的精力，而不要让项目成员在这方面花太多的时间。所以从这个意义上讲，项目经理的职责是让项目成员在一个相对安全的项目环境中工作。

做该做的，充分调动项目成员的能力，让他们也参与项目管理的过程中来，决不是推卸责任，对于项目工作和人员培养都是很有好处的，项目经理的眼睛如果只盯在项目本身，项目很难有好的结果。总之，你始终要清醒地认识到，你带领的是一个团队，而不是你自己。

项目经理需要攘内安外，对外眼观六路，耳听八方，为项目组营造良好的大环境，对内管理有度，控制有法，给项目成员有发挥的空间，又不至于失控。

一句话，项目经理首先是一个负责任的人，同时又要给项目成员以责任。 项目推进不动，项目经理往往是关键。要当好项目经理就要多思考，同时必须应用正确的方法。否则事倍功半，几头受气（风箱中的老鼠？）。 扼守承诺，善于沟通，抓住重点，排除干扰，控制主线。控制好这几点，也基本能胜任项目经理。学会中庸之道，不走极端。

项目推进不动，项目经理往往是关键。要当好项目经理就要多思考，同时必须应用正确的方法。否则事倍功半，几头受气（风箱中的老鼠？）。 扼守承诺，善于沟通，抓住重点，排除干扰，控制主线。控制好这几点，也基本能胜任项目经理。学会中庸之道，不走极端。

例舉一個項目管理的場景，請幫忙分析一下。 1 基本組織架構為部門式，人力資源歸屬各部門。 2 項目管理辦公室成員牽頭各項目的推動，依照任務性質分派到其他部門，項目依據項目經理之職級呈現為弱矩陣項目，或平衡矩陣。 部分項目推動過程的缺失表現為，進度不良，質量不良。項目經理分派任務本身說明不詳細，或者未按照組織要求提供文檔。

先謝謝

现代企业管理模式，大家都逐步在探索矩阵式的管理。为的目的是加快市场反馈速度，提高管理效率。但如何平衡项目管理和部门管理的职责分配，有效的调动资源而不出现多头领导，是一个值得研究的地方。 以我的经验，是企业必须建立一套科学的考核体系，平衡项目和职能部门之间的权利，从利益上找到共同点。而且更强调项目的重要性，对项目经理的授权要充分，当然对项目经理的考核和奖惩都是最严格的。这样才能提高效率，让大家都做实事，而不要相互扯皮

矩陣式項目管理優勢在于人力等資源的共享，但是發揮優勢是需要團隊合作等企劃文化支撐。否則只能降低管理效率。

弱矩陣模式下的項目經理其職能類似跟單，其工作的完成一部分是自己的努力，大部分是依靠其他團隊成員的合作。哪些工作需要自己去完成，哪些工作可以指派其他成員完成，是需要依據環境思量的。指派給別人完成的任務，要要盡力準備，創作出容易完成的環境，如果只是自己圖清閑，把任務一概推給別人處理，效果可想而至。

這也是對你4樓關于項目經理職能論述的一個側面補充吧。 补充得不错，

还有矩阵式管理中，横向（项目管理）管理更强还是纵向（职能部门管理）权利更强，是由公司的战略和运营模式决定的。而一个公司的战略和运营模式，又是根据内外环境，比如自身资源优势，行业市场环境，竞争者分布而影响的。作为一个初创的公司，生存为最重要的前提，所以强调以项目为导向，其他部门全力配合项目经理完成项目，尽快产生现金流。做到一定规模，生存不是首要问题后，就要解决规范，体系和稳定性问题。此时应该职能管理和项目并重。当发展比较顺利，市场定位准确，产品日益成熟，有稳定的客户群后，要解决的就是如何大量复制的问题。此时对稳定性和标准，规范提出了高要求。有时不得不拒绝一些非标准化的特殊需求。以标准化推进市场占有率。职能部门的管理权力会略强于项目管理。 为了达到最好的平衡，需要在项目和职能部门之间做好平衡。而我更偏向于项目略大于职能的管理模式。一切都是项目，一切都是目标管理。只是团队中来自于不同的专业部门临时组合在一起，完成一个共同的目标。职能部门的作用就是培训，规范本部门的工作，做到更专业化，提高效率。项目经理的责任，就是如何挑选适合项目的资源，并如何更好的整合在一起。 对于每个人所在的行业都会认为自己现阶段所处的这个行业需要学习的太多，要创新的却更多，就像现代社会的网络、电脑、软件，和这些有关的我们统称为“IT人士”，他们需要更快的学习创新速度因为这个行业新成代谢太快，而我也是其中一员，但在这些行业里有共同的一句话：“做好每件事之前先考虑做好一个人”，一个软件项目经理人也不例外。

　　一个项目的成功百分百归功于这个项目团队，而失败则百分百责任于项目经理人一人，可能失败的责任归于一人用之过大，但其实不然，如：1、项目的失败可能来源于一些外在的因素，这就表示项目经理人对项目的风险评估不够彻底；2、项目中因团队关键人员被调或流动，导致项目延期或无法进行所带来的损失，这就表明人力资源储备有限，更重要的是项目经理人是否有考虑过项目进行中团队某位或很多人员流动该怎样让项目能如期完成；3、项目大部分功能完成后需要客户的初验，这时就需要很多功能上的完善与增加，这可能无法避免但有些更荒唐的是客户看了之后可能对您说：“这和我想要的是两码事”这个时候您只能有权利做一件事，那就是尽情的晕吧！因为有些项目经理人根本就没有和客户说过一句话甚至更惨，没见过一次面，项目的初定和需求直接来源于业务人员，我们的大部分客户都不知道怎样把现实中的实物用程序的方式来展示去实现，所以项目经理人最起码也要用喝一个下午茶的工夫去告诉我们的客户：“您的这个想法我们需要进一步细化，我们将会通过****样的方式帮您实现，您看可以吗？”必须让他回答。 本文转自项目管理者联盟

　　以上总结于项目成败的三点：1、项目经理人对项目的风险评估是否彻底；2、项目经理人是否在团队人员缺失的情况下，能极力挽回项目进度，并能按期完成任务；3、项目经理人是否和客户有更为深入的交谈，项目经理人必须考虑是否真正为客户解决了实际问题。

　　做好一个项目经理（先从自己做起）：

　　第一：项目前的资源整合；尽量为项目开发提供一个好的环境，一个舒适的工作空间和项目预计所需要的工作工具（尽量提供最好的），就像一个开发人员有一台好的机器，你想想他有多带劲！还有就是召集这个项目需要切实用到的一切人力资源；

　　第二：能力测试；针对软件行业流动性很大的特点，并不排除您的项目团队中有陌生的面孔，也有可能是其他项目团队的派调过来的人手，或是其他合作公司的开发人员，这时您可能需要能力测试这一环节，测试并不是对团员能力的质疑,而是测试该把某个队员放在某个位置，或扮演项目开发中的什么角色比较合适。这种测试有很多方法，可以是做一些游戏或让你的团队一起去完成一个与项目无关的事情，来观察团队每个人员的特性与习性，然后就是针对项目中的每个技术环节做一个特定的测试，目的是为更好的跳过技术陷阱，测试的方法可以自订，但对于团队人员不能让他们感受到这是种测试，这样你就可以让每个团队人员在自己的适合的岗位上发挥自己最大的潜力！项目管理者联盟文章，深入探讨。

　　第三：个人执行力；怎样让自己具备有一个很好的执行力，首先，要端正所有项目经理人的观点（自己不光是该项目的领导人更是该团队中的普通一员），请把您对您的上级，公司领导的热情与尊敬复制到您对团队人员的身上，现代社会注重人文与个人魅力，以前的命令式做法已行不通，一个出色的领导人注重的是亲和力，要让你的团队人员感觉到“做好这个项目需要得到他们的帮助！”。

　　第四：团队精神与士气；如果在一个项目中您要是感觉到您正在扮演一个传递员的工作而每件队员与队员之间能解决的事情都需要经过您这台“服务器”的话，就说明您的这个团队中“神经系统”出了问题，人员的情绪千变万化，队员在生活中或工作中遇到了困难，这时项目经理人需要有迅速的洞察力“发现它就要解决掉它”，怎样让一个团队有一个更好的机动性和更强劲的动力，个人认为最简单快捷的方式就是在项目中抽出活动资金带着您的团队去”happy”！(对团队人员而言，一次活动互相接触的次数，大于在上班时间1个月所接触的次数。) 最好是制定活动计划和活动内容（最好是能让所有人都喜欢的），并严格规定不能缺席。

　　第五：分配任务的重要性；在分配任务时所有项目经理人都会发生的错误，就是在会议上当着整个团队强调某个队员任务的重要性，您提高了一个队员的积极性却降低了其他队员的士气，在分配任务到个人时还要注意把这个任务分配给某个人是否有想好还有更好的人选，不要主观地认为某个队员手头上的工作不太紧而分配给他，这样将会带来不可估计的后果，对项目本身而言，任务分配到个人有多有少有复杂有简单，这不能用天枰衡量，但怎样让每个队员心中平衡这可能就需要一个好的考核办法与项目奖金的分配制度，最好是公开透明的。

　　总的来说，做好一个项目经理人难，需要不断的努力、思考和完善！ 项目管理知识体系，是一个较大的知识系统，这也就让很多初学者摸不到头脑，感觉入门很难。 学习都是一个循序渐进的过程。 要把项目保证完成，首先要做的就是风险管理。只要做好了风险管理，基本能够保证你的项目在可控的范围之内，并能够按照范围内的指标完成。 第二步，要想把项目做好，就必须做好沟通管理。项目经理必须起到一个有效传达信息，平衡投资者，项目团队和客户之间的交流。

说到项目管理，大家都会想到铁三角 时间-质量-成本 中间覆盖的就是项目范围。这是一个经典的模型，项目经理必须深悟此道，融会贯通。 投资者，项目团队，客户也是一个三角，项目经理就在其中，重要性显而易见 人，工具，制度 这个是通用的管理模型，同样适合于项目管理。要把项目做得漂亮，提高项目的效率，项目经理就必须在三者之间结合内外环境状况，得到最佳的平衡。

项目管理虽然兴起在西方，但中国的项目管理实践历史已经非常悠久。好的项目经理，并不一定要考证。管理关键在于行，而不在于知。

　　其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生!”所以放在每一条，让刚刚毕业的朋友们早点看到哈!

　　2、一定要确定自己的发展方向，并为此目的制定可行的计划。

　　不要说什么，“我刚毕业，还不知道将来可能做什么?”，“跟着感觉走，先做做看”。因为，这样的观点会通过 你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物?向管理方向走，成为职业经理人?先熟悉行业和领域，将来自立门户?还是先 在行业里面混混，过几年转行做点别的?这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情!”。

　　3、软件开发团队中，技术不是万能的，但没有技术是万万不能的!

　　在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队 中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤 陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非 技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦!”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

　　4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。

　　请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用 将决定你的人生成败!本人自毕业以来，平均每天实际学习时间超过2小时。

　　5、书籍是人类进步的阶梯，对软件开发人员尤其如此。

　　书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书!我买的那些 家伙出的书，100%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识;拥有知识并不表示拥有技 能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。

　　6、不要仅局限于对某项 技术的表面使用上，哪怕你只是偶尔用一、二次。

　　“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看 Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序;用VC++、

　　Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码;除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。 试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”!

　　7、在一种语言上编程，但别为其束缚了思想。

　　“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由， 所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。

　　我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有VC++、Delphi) 进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀 的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式?为什么一切都必须 以个人、团队在当然开发语言上的传统或者经验来解决问题???“他山之石、可以攻玉”。

　　8、养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。

　　众所周知，对软件开发人员而言，有、无经验的一个显著区别是：无经验 者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结论不应该被局限在软件开发领域、可以延伸到很多方 面)。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是，最好还是自己实现，这样没 有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。

　　9、理论与实践并重，内外双修。

　　工程师的内涵是：以工 程师的眼光观察、分析事物和世界。一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发 语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个角度来看，这只是外在的东西，并非重要的、本质的工 作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题，才是真正的软 件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些思想与方式，最终形成自己的理论体系和实用方法论。

　　10、心态有多开放，视野就有多开阔。

　　不要抱着自己的技术和成果，等到它们都已经过时变成垃圾了，才拿出来丢人现眼。请及时发布自己的研究成果：开发的 产品、有创意的设计或代码，公布出来让大家交流或者使用，你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具，5、6 年之后的今天，还是那个样子，今天流行的好多Windows系统工具都比自己的晚，但进化得很好，且有那么多用户在使用。并且，不要保守自己的技术和思 想，尽可能地与人交流与分享，或者传授给开发团队的成员。“与人交换苹果之后，每个人还是只有一个苹果;但交换思想之后，每个人都拥有两种思想”，道理大 家都懂，但有多少人真正能做到呢?

　　11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。

　　网络早已不再只是“虚拟世界”，网上有很多的开源项目、合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工 作是做ERP，就不去学习和了解嵌入式、实时、通信、网络等方面的技术，反过来也是一样。如果当别人拿着合同找你合作，你却这也不会，那也不熟时，你将后 悔莫及。

　　12、书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。

　　诺贝尔经济学奖得主西蒙教授的研究结果表明：“对于一个有一定基础的人来说，他只要真正肯下功夫，在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果，故命名为西蒙学习法。

　　可见，掌握一门陌生的学问远远没有想象的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识，有空花时间看看，韬光养晦、未雨绸缪。

　　13、本文的总结与反思：

　　A：不要去做技术上的高手，除非你的目标如此。虽然本文是关于提高软件开发知识的建议，做技术的高手是我一向都不赞同的。你可以提高自己的专业知识，但能胜任工作即止。

　　B：提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理，可以很容易地延伸、应用到生活的其它方面。

　　C：在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质，尤其是那些目标不在技术方面的朋友。

JAVA系统架构师应该看的几本书 Thinking in Java Effective Java UML基础、案例与应用 UML入门提高 软件工匠 设计模式——可复用面向对象软件的基础 重构-改善既有代码的设计 敏捷软件开发-原则、模式、实践 企业应用架构模式 Expert One-on-One J2EE Development without EJB 软件工程——实践者的研究方法 软件领导－－成功开发软件的指导准则 后面的两本书，其实已经有点属于项目经理的范畴，不过还不是很深入，看看对做成功的系统架构师是很有好处。 企业应用的系统架构师应该关注的几个方面 数据持久层的设计 在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来。Rod的轮子太好用，基本上，大家只要套上去就行，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧 MVC架构的具体设计 MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构 大并发性访问 使用缓存，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能 超大数据量返回结果 尽量使用分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用 超大文件的读取和生成 尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。

多线程的应用和管理 线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放

用户界面可用性设计 平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点 分布式的数据交流和集成 选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享 群集系统的管理 如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？ 是否采用EJB?如何利用J2EE的特性（例如JNDI) 复杂的业务规则 规则引擎和工作流引擎场景和应用

其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看其它人的系统和代码，就能够给出有效的设计指导。 例如对于一个下载软件，可以有如下考虑： 1. 未明和非法url的检验，已经下载失败的容许，信息记录 2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性 3. 下载线程管理 4. 服务器或者P2P的机器之间的通讯协议 5. 速度监控和限制 6. 下载进度的监控和显示 作为一个在线播放软件,可以做如下考虑 1. 播放速度的保证 机器的问题基本不存在，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。 2. 播放质量的保证 如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API 由于没做过类似的项目，可以写的东西还是少很多。 系统架构师应该有的素质： 1、 实际的编程经验 最少2年吧，多就不说，其实从大学就开始钻研的话， 2、 书面表达能力和口头交流能力 [...]]]> 最近应聘系统架构师，面试回答一些问题，加上之前做的一些功课，搜索到一些文章，感觉有必要总结一下，到底如何做一个成功的系统架构师呢？
首先，何谓系统架构师？
IBM工程师的说明是：
架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功
中文Wiki上的说明是：
系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单
这两个解释，加起来基本说明系统架构师的定义。

JAVA系统架构师应该看的几本书
Thinking in Java
Effective Java
UML基础、案例与应用
UML入门提高
软件工匠
设计模式——可复用面向对象软件的基础
重构-改善既有代码的设计
敏捷软件开发-原则、模式、实践
企业应用架构模式
Expert One-on-One J2EE Development without EJB

软件工程——实践者的研究方法
软件领导－－成功开发软件的指导准则
后面的两本书，其实已经有点属于项目经理的范畴，不过还不是很深入，看看对做成功的系统架构师是很有好处。
企业应用的系统架构师应该关注的几个方面
数据持久层的设计
在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来。Rod的轮子太好用，基本上，大家只要套上去就行，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧
MVC架构的具体设计
MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构
大并发性访问
使用缓存，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能
超大数据量返回结果
尽量使用分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用
超大文件的读取和生成
尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。

多线程的应用和管理
线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放

用户界面可用性设计
平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点
分布式的数据交流和集成
选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享
群集系统的管理
如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？
是否采用EJB?如何利用J2EE的特性（例如JNDI)
复杂的业务规则
规则引擎和工作流引擎场景和应用

其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看其它人的系统和代码，就能够给出有效的设计指导。
例如对于一个下载软件，可以有如下考虑：
1. 未明和非法url的检验，已经下载失败的容许，信息记录
2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性
3. 下载线程管理
4. 服务器或者P2P的机器之间的通讯协议
5. 速度监控和限制
6. 下载进度的监控和显示
作为一个在线播放软件,可以做如下考虑
1. 播放速度的保证
机器的问题基本不存在，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。
2. 播放质量的保证
如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API
由于没做过类似的项目，可以写的东西还是少很多。
系统架构师应该有的素质：
1、 实际的编程经验
最少2年吧，多就不说，其实从大学就开始钻研的话，
2、 书面表达能力和口头交流能力
综合利用架构图，UML图，文字和代码片断，表达自己设计思想，至于是Word还是ppt，应该通吃
在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。
3、 自觉主动;积极解决设计问题
架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。
4、 抽象思维能力和总结能力
架构师，顾名思义，在系统未搭建好之前，就要能够有一个草图在心。而如果是对现有系统的改造，那么能在看过系统的文档（如果有的话）和代码后，就能总结出系统的架构特点。
架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。
开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。
5、 全面的技术资讯吸收能力和选择鉴别能力
作为开发人员出身，对于某一个具体问题的研究能力（虽然很多人总结为google能力），已经相当具备。但是对技术资讯的全面接受和选择性深入解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。

本文分析了软件项目管理常见问题：缺乏项目管理系统培训、项目计划意识问题、管理意识问题、沟通意识问题、风险管理意识问题、不重视项目经验的总结、项目干系人相关问题、项目团队内分工协作问题，抛砖引玉地提出了部分解决方案，提出了项目约束绳与多重目标模型。

关键字：

软件项目管理、问题、分析

正文：

目前许多软件开发公司实行了ISO质量管理体系，也有越来越多的公司通过了CMM软件成熟度相应级别认证。各软件在制定ISO质量管理体系时结合了部分项目管理的思想和技术，因此这些经过认证的公司的项目管理工作在ISO质量管理体系或CMM的帮助或约束下已有一定的规范，项目可以按照规定的过程一步一步做下去。但ISO体系注重的是质量管理（即用过程保证质量），早期更多的是针对制造业，而CMM主要是针对软件开发过程的关键过程域，都没有针对项目管理的全部范畴，如对于整体、范围、进度、人力资源、成本、沟通、风险、采购等的管理，即使有涉及到也是在专业范围内通过对过程的把握来保证各种质量要求，而在过程规定之外还需要依靠项目相关各方运用项目管理知识、工具、集体与个人的智慧来使项目管理做得更好，以保证项目在使用最少的时间、资源情况下按时保质地完成。

最近通过几次 “项目管理知识培训”，本人系统地学习了项目管理基础和项目管理实践等课程，掌握了项目管理在系统集成方面应用所必备的知识。结合所学的项目管理知识，我们可以对照我们原来的项目管理工作中存在的常见问题，利用项目管理知识进行分析，并提出解决的方案，希望有利于大家逐步改进我们的项目管理工作。这些方案因受到本人知识和工作经验的局限，只能起到一个抛砖引玉或参考的作用。

分析目前项目管理需要改进的问题可以从几种相关角色的角度去考虑：项目经理、项目组成员、公司管理人员、市场人员、客户等。

问题一：缺乏项目管理系统培训

相关对象：项目经理、管理人员

问题说明：项目经理在项目管理方面的培训较少或不够系统。项目经理或管理人员不了解项目管理的知识体系和一些常用工具和方法，所以在实际工作中没有项目管理知识的指导，完全依靠个人现有的知识技能，管理工作的随意性、盲目性比较大。有些学员说：“听了这些课才知道项目管理原来还有这么多的学问。”例如对于如何利用工作分解结构使项目的工作范围更加明确，如何用前导图法对活动进行排序并估算项目进度、制定项目进度计划，如何利用挣值法跟踪项目进度，项目经理的职责与必备素质、应具备的能力、工作方法，如何根据各种组织结构及其优缺点进行选择，如何对于风险进行定性定量分析等等，通过这次培训有了初步的掌握，将能够很快地应用到实际工作中。

问题点评：在软件企业中，以前几乎没有专门招收项目管理专业的人员来担任项目经理（甚至很少是管理专业的），被任命的项目经理主要是因为他们能够在技术上独当一面，而管理方面特别是项目管理方面的知识比较缺乏。因此项目经理接受系统的项目管理知识培训是非常必要的，有了专业领域的知识与实践，再加上项目管理知识与实践和一般管理的知识和经验的有机结合，必能大大提高项目经理的项目管理水平。

解决方案：实行项目经理知识技能资格考核制度，让项目经理自觉补充学习项目管理的知识和一些常用工具和方法。

问题二：项目计划意识问题

相关对象：项目经理

问题说明：项目经理对总体计划、阶段计划的作用认识不足。项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，不少事情没有仔细考虑；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。 问题点评：渐近明细是项目的特点，但这并不意味着不需要计划。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法。即根据总体阶段划分的总体WBS和专门针对详细设计或编码阶段的二次WBS。这其中部分的原因是需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS，根据代码模块的合理划分而得出的二次WBS才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细，无法对工作任务的分解、均衡分配和进度管理起参考作用，对此应当及时改善。

制定计划的过程就是一个对项目逐渐了解掌握的过程，通过认真地制定计划，项目经理可以知道哪些要素是明确的，哪些要素是要逐渐明确的，通过渐近明细不断完善项目计划。阶段计划中包含的工作汇报和下一阶段工作安排是掌握项目进度的依据，从阶段计划对照总体计划，才能一目了然地看出工作的进展情况。制定计划的过程，也是在进度、资源、范围之间寻求一种平衡的过程。制定计划的精髓不在于写出一份好看的文档，而在于运用您的智慧去应对各种问题和面临风险并尽可能做出前瞻性的思考。一旦计划被负责任地完成，他就可以给自己一个和管理层或客户交流与协商的基础，帮助你在项目过程中防范各种问题的出现，帮助你保证项目按时完成。

解决方案：提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。

问题三、管理意识问题

相关对象：项目经理

问题说明：部分项目经理没有意识到自己项目经理的角色，从总体上去把握管理整个项目，而是埋头于具体的技术工作，造成项目组成员之间忙的忙、闲的闲，计划不周、任务不均、资源浪费。

问题点评：在软件企业中，项目经理大多是技术骨干，技术方面的知识比较深厚，但无论是项目管理知识，还是项目管理必备的技能、项目管理必备的素质都有待补充和提高，项目管理经验也有待丰富。有些项目经理对于一些不服管理的技术人员，没有较好的管理方法，工作不好安排的工作只好自己做。另外由于工作分解结构设计的合理性，项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。因此技术骨干在担任项目经理之前，最好能经过系统的项目管理知识，特别是其中的人力资源管理、沟通管理的学习，并且在实际工作中不断提高自己的管理素质，丰富项目管理经验，提高项目管理意识。

解决方案：加强项目管理方面的培训，并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。

问题四：沟通意识问题

相关人员：项目经理、项目组成员

问题说明：在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失；有些人没有每天定时收邮件的习惯，以至于无法及时接收最新的信息。

问题点评：项目沟通管理指出：“管理者要用70％的时间用于与人沟通，而项目经理需要花费90％或更多的时间来沟通”。和问题三的情况类似，在软件企业中，项目经理大多是技术骨干，而项目组成员也都是“高科技人员”，都具有“从专业或学术出发、工作自主性大、自我欣赏、以自我为中心”等共同的特点。因此妨碍沟通的因素主要是“感觉和态度问题”，也就是沟通意识和习惯的问题。在系统的实施阶段或软件开发的试运行阶段，项目成员基本上是持续是在客户方进行工作，这种情况非常容易忽视沟通。项目组与组织之间、项目组与项目组成员之间，甚至同一个项目组的不同成员之间，都有可能在不同的地点，如果没有足够的沟通意识和沟通制度、沟通工具，就有可能造成信息不畅，从而加大项目失败的风险。即使都在公司内部也应做到及时沟通。所以项目经理不但自己要把工作重点放在沟通，善于沟通，还要引导、约定整个项目团队进行及时充分的沟通。

解决方案：制定有效的沟通制度和沟通机制，对由于缺乏沟通而造成的事件进行通报作为教训提醒，以提高沟通意识；沟通方式应根据内容而多样化，讲究有效率的沟通；通过制度规定对由于未及时收取邮件而造成损失的责任归属；对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位，例如除发送邮件外还要电话提醒、回执等，重要的内容还要通过举行各种会议进行传达。

问题五：风险管理意识问题

相关人员：项目经理

问题说明：项目经理没有充分分析可能的风险，对付风险的策略考虑比较简单。项目经理在做项目规划时常常没有做专门的风险管理计划文档，而是合并在项目计划书中。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。

问题点评：项目风险管理是对项目潜在的意外损失进行规划、识别、估计、评价、应对和监控的过程，是对项目目标的主动控制手段。采取主动行动，创造条件，尽量扩大风险的有利结果，以最少的成本保证安全、可靠地实现项目目标。因此项目风险管理对于保证项目目标的实现是非常重要的。

解决方案：通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。总结本行业项目中常见的风险及其对策作为风险管理计划中必要的风险内容，并切实评估相应对策的有效性和可行性。 问题六：不重视项目经验的总结

相关人员：项目经理、管理人员

问题说明：项目经理在项目结束时有些是因为自身对写文档工作的兴趣或意识，或者是因为紧接着要参加下一个项目，总体对项目总结的重视程度不够。有些是项目总结报告一再拖延，有些是交上来的报告质量较低，敷衍了事。

问题点评：项目经验总结非常重要，有利于组织内部或行业内部经验与数据的积累，项目过程的改进和技术与管理经验积累，对于今后的项目有非常重要的指导意义，因此应当引起项目经理及管理人员的足够重视。在项目管理的39个过程中，需要输入历史信息的就有9处之多。这些历史信息的来源从内部获得的主要来自以前项目的经验总结，可见项目经验总结是非常必要的。历史的数据使可以新的项目进行更为准确全面的规划，历史的教训可以使新的项目少走不必要的弯路，少花不必要的代价，减少项目失败的风险。

解决方案：在制度上鼓励和加强项目经验总结工作，使得项目总结及时并且具有指导意义而不是走过场。

问题七：项目干系人相关问题

相关人员：项目经理、项目成员、客户

问题说明：在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和要求责任心不强，提出的要求具有随意性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又要求项目尽早交付；项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。

问题点评：项目干系人STAKEHOLDER也有的翻译成利益关系人、利害关系人、利益干系人、利益共享者、涉众等等，即所有可能受到项目结果重大影响的人（不知道是因为中国的词汇过于贫乏，以至于你用来翻译的词我不满意，非要找另一个，结果没有一个词可以真正表达STAKEHOLDER的原意；还是因为中国的词汇过于丰富，爱怎么选就怎么选。看来中国要统一真是任重道远啊。）。项目干系人即可能是项目的受益者，也是项目的风险承担者，甚至有可能是项目的受害者。项目干系人的要求包含明确的和隐含的，也可以分为NEED、WANT、WISH等不同层次。不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。例如政府部门的不少对群众办公的信息系统，上层管理机关往往希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，并对信息进行有效控制而增加一些审批流程；基层对外办公的窗口则因为办公速度的压力希望减少信息的输入；而客户的客户（办事群众）则希望相关政府机构能够简化工作流程，加快办事速度。如果对项目所有干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体要求不够完整清晰，也可能因为某个项目干系人后期因为认识的变化而提出新的要求，造成工期的延长，成本的增加，甚至项目的完全失败。

解决方案：项目的目的就是实现项目干系人的需求和愿望。项目干系人管理应当从项目的启动开始，项目经理及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。

问题八：项目团队内分工协作问题

相关人员：项目经理、项目成员

问题说明：项目团队内部有时由于各阶段不同角色或同阶段不同角色之间的责任分工不够清晰而造成工作互相推诿、责任互相推卸的现象，有时各阶段不同角色或同阶段不同角色之间的责任分工比较清晰但是各项目成员只顾完成自己那部分任务、不愿意与他人协作。这些现象或多或少地造成了项目团队内部资源的损耗，从而影响了项目的进展。

问题点评：出现这种情况主要是项目经理的责任，项目经理应当使用WBS尽快地将工作范围进行分解，并将分解的工作责任分配给团队成员，这样就可以按任务分清每个人的责任；虽然项目的进行有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整。在同一个阶段中，不同的分工之间也存在各种各样复杂的关系，相互之间通过接口，一个或几个项任务的输出是另一个或几个任务的输入。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成项目任务。

解决方案：项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。

以上对软件开发项目管理中出现的问题的分析可能还不够深入，也无法列举所有遇到或将遇到的问题，解决方案也要根据实际情况进行调整，只能作为个人的观点，希望引起大家对这些问题的思考、改进。

项目是在一定资源及环境的约束下为完成某一独特的产品或服务所作的一次性努力。项目应当具有明确的目标，而这个目标往往是多重的，需要考虑范围目标、质量目标、进度目标、成本目标和其他目标等等。在一定条件的约束下，要想使各种目标都达到完美是不可能的任务，必须对各种目标的重要性进行排序、取舍、平衡。就像图1所示，资源的约束就像一条绳子，牵制着各项目标的达成。例如，假设质量目标是最重要的，则一定要有足够的资源或时间作为保障，这就是牺牲成本目标或进度目标；假设没有足够的资源或时间，又要完成项目范围目标，则质量目标必然受到牺牲。有一种观点认为，为了保证某个目标的实现，就要把其他目标的标准降低，因此对其他目标达成的评价标准也要相应调整到较为宽松的程度。这种想法是不正确的。目标达成的评价标准应该是对所有项目都一视同仁的，对同类的不同项目应当采用相同的评价标准，这样才能在项目组织间取得平衡。例如对质量的要求，一般项目需要90分才算完成质量目标，而对某些进度、资源紧张的项目，80分就可以算完成质量目标。这样才能对项目的质量有个可横向比较的、实事求是的结论，而不是对此项目降低评估标准去够到90分的质量目标。同时这种情况下的考核结果不能作为相关项目成员水平的指标。

由于的资源约束性、多重目标性，需要项目经理努力学习项目管理相关知识、技能，在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。

残酷的事实就是：开发进度可能会因设计师而停滞不前。为了追求最佳效率，设计师不仅需要描描画画，还需要能把它做出来！本文中，我想与读者分享一些为什么设计师需要学习编写代码的理由。

做现实可行的设计 有了一个最终产品将如何实现的明确印象，设计师将拿出更多实际可行的概念。作为开发进程中不可或缺的一份子，设计师肩负着确保他们的设计能够顺利转移到网络介质上，同时还要考虑其可用性，网页易读性和可实现性。一个对用户友好的网站不仅有简洁清晰的浏览顺序逻辑，还向用户提供一切所需的信息而不会显得咄咄逼人或是杂乱无章。想要知道一种 Web 布局是否可行的唯一途径就是亲自去了解如何建立一个网页。

使沟通更轻松 在几乎所有的设计与实现各自独立的产品中，设计组和实现组从没有满足过对方的期望，尤其是那些无形的产品，比如网站，软件和游戏。这通常归结于产品的期望和产品可行性的相互妥协，目前看来，这是难以完美统一的。解决之道是：设计师应该亲身尝试设计作品的实现，以避免沟通中的混淆，误解和误传。

方便的迭代开发过程 一个实践中的设计不应是绝对的。我的意思是，设计应该是灵活友好的，能够在修改以迎合系统技术限制的同时不扭曲其原有内涵。这些重复但必要的改动只能由原设计师来实现。一个设计师/开发者能够比开发人员把设计重提到设计师手里进行改动更加高效。而且设计师和开发者之间——事实上经常如此——会产生摩擦。

更好更和谐的结果 我常常喜欢把软件，网络或是游戏开发想成是管弦乐，而设计师是作曲家，开发者是乐团的指挥家。想象一下二者是同一个人将会怎样？交响曲将会是令人惊叹的，迷人的，纯正的！不仅是大师的神作，而且还是其本人亲自指挥的！

缩短开发时间 设计师同时充当程序员的角色意味着设计和编码的进度即使不是同时的也是连续的。结果就是开发周期的缩短——谁会不关心效率呢？

设计师更加市场化 现代的设计师需要提升自身的能力以保持个人价值，有一套技能是远远不够的，我们往往需要戴着不同的头衔：设计师，前端开发者，文章作者和项目经理。

通过学习实现你自己的设计，而不是让设计成为开发者手中的孤儿——你提升了自身价值。毕竟，在简历中提到设计和编码技能不会有坏处。相反，在这个金融危机时代的企业重组（参见：大规模裁员）和缩减开支的环境下，还能够强调一个人的重要性而免遭解雇。

然而，即使有这么多的理由支持设计师学习编写代码，这里还是有反对的声音。

引用 Lukas Mathis 的一篇有争议性的文章“设计师不是程序员”（注1）

如果设计师实现自己的设计，他会受制于两个不同的目标：代码的整洁和良好的用户体验。这两个目标是相互矛盾的。如果你要实现你自己的设计，你必然会为了代码的质量而妥协，这是不利于交互设计的。

实现自己设计的设计师面临着两个问题：他们知道一个很棒的新思路会建立混乱的代码，他们也知道如果改进用户体验，现有的代码会被打乱。这两者相互矛盾，因为用户体验都在于小的细节，而这些小细节最终毁于他们的不忍心使代码变得混乱。

这恰如其分的总结了“Web 开发纯化者”们所采取的强硬立场。他们是守旧派，倡导在设计和开发之间划清界限。显然，设计师为人类创作，开发者为机器创作。因此，用户体验设计师们应该设计出最可行的用户界面并让开发者做出最可行的编程决策。虽然这有一定的道理，但当我研究一个用户界面的时候，我从代码中寻找灵感的努力却以失败而告终。总之，在头脑中有一个技术及可用性限制的正确观念还是更有好处。

写在最后 归根结底，所开发项目的规模可能最终决定着设计师和开发者的角色。一个小型的应用可以由一个项目经理（注2）一手掌控，而一个大型的系统必然需要不同的专业人才！

据IT招聘公司Robert Half Technology的部门主管Igor Abramovitch称，该公司发现近几年人们对软

技能的兴趣明显浓厚起来。他说，光有扎实的技术性能力再也不吃香。

他解释，许多企业尽量避免把IT部门看成只是成本中心。他说：“他们希望IT部门与业务部门密切相

关，共同帮助企业增加利润。企业在物色拥有敏锐商业头脑和沟通技能的员工，以便与其他部门打交

道，进行积极有效的沟通，确保满足业务目标。”

据信息技术研究集团公司的高级研究分析师Jennifer Perrier-Knox称，问题是，老资格的IT员工并不

习惯于掌握软技能。她说，对完全是IT出身的人来说，他们所学的课程不可能包括软技能培养这块内

容。

学习软技能未必很简单。Karico Performance Solutions为制造行业的员工提供激励性培训服务，该

公司的员工绩效专家Karin Lindner表示，所有软技能都需要员工真心实意地去学。她说：“如果我真

想努力提高倾听技能，就会变得更善于倾听。”

拒不承认软技能是大势所趋到头来只会害你。IBM加拿大有限公司的沟通专家Jonathan Wray说：“要

是你有这样的想法——自己根本不需要改善软技能，我认为那确实会影响你的职业生涯，并且降低你

自身的水准。”他在2002年为多伦多地区的IBM公司组建一个演讲俱乐部。

Wray表示，让你谋得工作的也许是技术性能力，但有助于提升职业生涯的却是软技能。他指出，步步

高升的人是发表文章、在会上积极发言以及关注客户的那些员工。

Wray补充说，连那些埋头苦干、认为只需要技术性能力的开发人员最终也会发现，自己确实需要软技

能。比方说，技术专家会被拉过去向客户作简要介绍。他说：“每个人终究是工作团队的一分子。”

IT人员必不可少的十大软技能如下：

1. 倾听

Lindner认为，倾听是其中最重要的一项软技能，但也是最难学会的一项软技能。

Wray表示，你很容易认为自己在倾听，但仅仅听某人说并不意味着你就明白对方的话所要传达的那层

意思。他说：“如果你在一个团队中工作，就要集中注意力。”

2. 沟通

Wray认为，顺畅的沟通绝对是必不可少的，这主要是因为现在的技术太复杂。他说：“我们很容易在

沟通时讲只有少数人听得懂的一大堆缩略语、专业术语和行话。如果你面对的客户并不拥有与你一样

扎实的技术知识，清楚地表达和书写就显得非常重要。”

在IBM等跨国公司，沟通尤为重要。他说：“英语不是每个人的母语，所以如果你与俄罗斯或中国员工

组成的团队打交道，清楚地表达和书写就显得至关重要。”

沟通技能在Abramovitch看来应放在第一位。他指出，这不但包括口头沟通，还包括远程及网上沟通的

能力。他说：“许多IT团队是分布式的，未必坐在同一间房子或办公室。”

Perrier-Knox声称，交际和客户服务技能与沟通密切关联。她说：“IT是提供给企业其他部门的一项

服务，许多IT部门在围绕面向服务的交付模式对自己进行重新定位，所以拥有沟通和客户服务技能以

及外向型思维是一项很重要的软技能。”

3. 自信

Wray认为，自信和自我肯定非常宝贵。它们让你能够融入团体、与别人交流想法，并且敢作敢当。

4. 项目与时间管理

Perrier-Knox说：“大多数IT任务是根据项目来划分的。业务部门密切关注IT部门，以保证项目按时

、按预算交付。”能够合理确认项目里程碑，并且提供表明在整个项目过程中何时完成里程碑的状况

报告，这种能力成为一项“很重要的技能”。

Abramovitch认为，时间管理以及确定优先项目的能力是关键的技能。许多企业如今在物色这样的IT人

员：既能管理自己的时间，又能处理各办公室间的关系，确保项目按时完成，支持业务部门。他说：

“如今IT部门在做更多的事。上头要求他们懂业务。”

5. 团队合作

Abramovitch解释，由于IT部门在同时处理多个项目，接手的工作多许多，而专职员工比较少，所以团

队合作技能增强与公司忙不过来时从外面请来的临时合同工进行合作的能力。

6. 体谅他人

Lindner表示，体谅别人来自什么样的环境也很重要。

7. 表示感激

Lindner表示，学会感激和尊重是许多企业最缺乏的两项软技能，但它们在工作场所又非常需要。她指

出，表示感激很容易做到。她说：“要是你在处理任务时有人帮你一把，就向对方表示感谢，就这么

简单。”

8. 领导能力

由于工作团队规模缩小，中层管理人员被削减，现在经理人手少，要管理的员工却更多。Perrier-

Knox说：“领导人的责任变得非常大，所以这些领导人需要下放职权。”

9. 演说技巧

Wray认为，演说是每个人都想拥有的软技能，但也往往是每个人最为害怕的。他指出，人们对演说的

害怕甚至超过对死亡的害怕。

不过在他看来，演说也是最容易学会的软技能。他说：“许多人往往讲‘我不善于演说’，但让人意

外的是，其实稍加努力和练习，演说能力就能大幅提高。”

10. 业务知识

Perrier-Knox认为，解业务运营和流程“无疑”是最重要的。她说：“如果IT人员解业务问题、财务

问题，很有可能会升到高位。过去几年来，一直是这样子，原因是IT人员不解业务可是出名的。”

链接：获得软技能的五个途径

Federman认为，要学会软技能，最有效的手段还是以他人为榜样。这可能包括平时模仿领导人的行为;

要是你很尊敬部门里面的某个关键人物，他展现你所需要的软技能，那也可以模仿他的行为。

1. 内部指导

Perrier-Knox声称，学习软技能需要通过互动来进行练习;有一种很省钱的方法可以学习软技能，那就

是在所在部门找一个人正式作为你的辅导老师。

2.. 个别辅导

Perrier-Knox表示，个别辅导通常被认为是在管理层中很常见的做法。她说：“对普通的IT专业人员

来说，费用可能很高昂。这种事通常需要个人自己搞定，因为企业未必会为你安排这样的辅导老师。

”

3. 教室或网上课程

软技能的关键是要实际运用。Perrier-Knox说：“你可以去上课学习，但要是你还没有显示出掌握这

些技能的天赋，那么你在教室里学习也只是走过场而已，课程学完后并没有真正学到什么技能。”

4. 看书

Perrier-Knox表示，书籍通常过于简单化或过于理想化。她说：“如果你希望付出能获得相应的回报

，最好还是一对一地向辅导老师学习，或者在分成团队的环境，那样你可以练习学到的技能。当然，

少不看一些相关的书。但如果你光学不练，肯定不会有什么效果。”

5. 课外小组

特殊兴趣小组或专业组织(如国际演讲会)可以帮助你不必依赖贵公司，就能获得相应技能和培训机会

。然后，你可以把学到的技能带回到贵公司，开始为同事们树立榜样。

俺真的想不到，最终的问题是出在php的版本过高问题，就是这个版本过高。累俺花了五个晚上时间去搞迁移与恢复！而且，俺的php5.3.0是俺访问www.php.net时，并在中国的verycd network像像下载的！

虽然。俺平时不多说粗口，但是针对这个问题。累俺浪费这么多时间。俺真的禁不住说一句：操！是谁放出php.5.3.0这个版本的！

（一）

小满所在的公司，有一天，突然同时有好几个项目经理离职。最近一段时间，自从空降来的新的技术总监到了后，公司里的气氛怪怪的。

年初的时候，公司的新目标就指出：经过了三年的打拼，公司已经基本上站稳了脚跟。正面临着大发展的好时机。为了新的更大更快的发展，所以，公司在制度建设上，要趋于更加规范、严谨。

为了给广大员工贯彻这一基本指导思想，公司把每周的例会，从一次，扩展到三次。大家都听到耳朵起了茧。大家私下都在低估：这洗脑的架势，快赶上保险公司的培训了。

新政的宣传攻势才执行了三个月，资格最老的技术总监先辞职走了。

小满听大家私下里在说：技术总监之所以走，是因为老大对他很不满意。老大觉得技术总监太过为客户考虑，有那么多的单子不去做，差不多就行了。那么认真干嘛？

技术总监是个很能干的老实人，做事情，实打实的。小满一直以他为榜样。

技术总监离职后，老大满脸的不在乎。找猎头公司去挖了一个人过来。新总监以前在某著名的IT公司做项目经理。

新官上任三把火，小满就记得第一周，每天都在开会。新总监给大家重新阐述了老大的宏伟目标，给大家开始规范新的工作方法。

他要求：

【1】每天，每个项目经理，都要email给他Dialy Report（他以前在外资工作，假洋鬼子的说话，就是中、英夹杂）；

【2】每天，每个开发人员，要写Report给leader；

【3】严格考勤制度，迟到、早退要扣钱惩罚；

新总监抱怨说：他经常看到大家三三两两拉帮结派的上厕所。简直不象话，太耽误时间了，没有一点敬业的精神！

【4】以后做每件事，最好都要有文档备案，这是规范的基本要求；

小满觉得新总监不愧在外资干过，一看做事行头，有模有样的，心里好是佩服。他以前也是觉得虽然公司小，但是的确应该严格要求，做事情要严谨，这样才能长足发展。

小满觉得公司里面的开发的确存在一些问题，比如：文档不规范、不完整。如果人员流动，给后续工作带来很大的麻烦。

新人必有新气象，小满满心希望自己能学到点新东西，希望以前的情况能有所改变。

又过了二个月，小满发现了一些问题：

【1】开发人员开始不习惯写报告，后来渐渐适应了。有几个报告写得好的人，小满看测试那边反馈的结果来看，代码的质量却不好；

【2】会议开得太多，理念讲了一箩筐，但是，很多具体的问题却耽误下来了，最直接的表现就是：项目经理开会就一直抱怨，扯皮。大家都变得很不耐烦。事情做不完，还得加班，心里憋屈！ 【3】迟到的少了，但是，有人一来工作就打瞌睡，还有人就磨洋工。有人抱怨考勤制度不合理等等；

新总监来了半年，技术团队的人流失的很快。有些资格老一点的，直接找老大沟通。老大毫不犹豫地坚持自己的新政：为了未来的发展大计，牺牲一点算什么。

直到有一天，好几个项目经理同时辞职。老大才觉得大事不妙，找几个骨干推心置腹，还是没有挽留成功。老大一怒之下，新总监下课了。

公司从成立以来，一路高歌猛进，摧城拔寨，从未象现在一样风雨飘摇。整个公司，人心惶惶，大家都各怀心事。

出去的项目经理也在劝小满离开公司，另谋发展。

小满心里七上八下的，内心充满了不安和莫名的惶恐。

（二）

小满见到老鸟的时候，老鸟正在摆弄他的新笔记本电脑，一台IBM thinkpad-从淘宝购买的水货，比行货便宜很多。

小满打趣说：你也太守旧了，怎么老是买thinkpad啊，也不换一个其他牌子的。

老鸟买了好几台本本，都是thinkpad的。一般给朋友推荐，也是thinkpad。

老鸟说：“习惯了。这本本非常结实，扔在车子的后背箱，随便放，不会有问题。哪象你的本本，才用2年，表面的漆都不成样子了。”

小满的本本去年才换了新的，虽然便宜，但是每次去维修都耽误很多时间。小满一直懊悔不已。老鸟一直在跟他说：买thinkpad吧。

老鸟问小满最近在忙啥，小满把公司的情况一说。老鸟叹了口气。

老鸟说：很正常。很多创业公司在长大的过程中，都会出这种情况。而且有可能是反复出现。

（三）

在中国这些年，成长起来的创业小企业，一般都是这样的：

几个朋友、同学，或者就是家族里面的几个人，找到一个机会，销售或关系驱动，发家。

这样的公司，启动很快，而且前期增长也很快。有些执行力好的，1-2年就能做到很好。

增长期给人信心，也给人幻觉，觉得：没有想不到，只有做不到。创业者，或老大们，信心爆棚，然后开始希望业绩急速地增长，拼命追求快速成长。

从小公司迈向中大型公司，面临的第一道坎就是组织的管理方式改变了：以前几个人凑在一起，聊着说完了就开始干。现在公司大了，人多，事多。很多事情被分解得很细，控制的环节上，就冒出很多问题。

老大们一想：以前的老办法不行了。这得管理啊！

可啥是管理，老大们也不清楚。看书、听培训讲座。总算想明白了：管理就是要规范，就是要按规矩办事。

怎么办呢？

去其他的知名企业里挖人！挖一个著名公司的部门经理，过来做总监。

（四）

小满说：“我们老大也是这样想的。有什么问题吗？”

老鸟说：“规范企业管理，本身没有错。但是，如果一说到管理就认为只是那种形式上的规范，那就大错特错了。”

“很多自认管理很好的企业，其实，你问他的中层，反而会听到一些抱怨的声音。有人干脆直接说：搞管理的人，都是只会耍嘴皮的人！”

小满点头。

老鸟说：“十多年前，我曾经参观过一家IT的OEM工厂。里面的工人穿两种颜色的衣服。穿粉红色衣服的人是流水线上的工人，她们的任务就是完成整个流程上的规定步骤。穿蓝色衣服的是拉线上的检测人员。而真正的管理人员则穿便装。”

“你在现场，会有一种震撼：制造行业的流程设计，已经把人和机器做到了人机合一的境界，每个人都是一个螺丝钉一样。让人感叹不已。”

“我突然理解了：为何很多管理的理念，对精密的制度化的膜拜和追捧。因为很多所谓的现代管理理念，建筑在20世纪的机器自动化的现实上。”

“但是，相应的质疑也随之而来：如果我们不是某个流程上的螺丝钉，如果我们的企业或组织在从事创意产业的话，我们对基于工厂管理的制度化追求，是否还有其他更加合理和人性的方式。”

小满说：“建立规范，统一起来，不好吗？”

[...]]]> 管理的极限

（一）

小满所在的公司，有一天，突然同时有好几个项目经理离职。最近一段时间，自从空降来的新的技术总监到了后，公司里的气氛怪怪的。

年初的时候，公司的新目标就指出：经过了三年的打拼，公司已经基本上站稳了脚跟。正面临着大发展的好时机。为了新的更大更快的发展，所以，公司在制度建设上，要趋于更加规范、严谨。

为了给广大员工贯彻这一基本指导思想，公司把每周的例会，从一次，扩展到三次。大家都听到耳朵起了茧。大家私下都在低估：这洗脑的架势，快赶上保险公司的培训了。

新政的宣传攻势才执行了三个月，资格最老的技术总监先辞职走了。

小满听大家私下里在说：技术总监之所以走，是因为老大对他很不满意。老大觉得技术总监太过为客户考虑，有那么多的单子不去做，差不多就行了。那么认真干嘛？

技术总监是个很能干的老实人，做事情，实打实的。小满一直以他为榜样。

技术总监离职后，老大满脸的不在乎。找猎头公司去挖了一个人过来。新总监以前在某著名的IT公司做项目经理。

新官上任三把火，小满就记得第一周，每天都在开会。新总监给大家重新阐述了老大的宏伟目标，给大家开始规范新的工作方法。

他要求：

【1】每天，每个项目经理，都要email给他Dialy Report（他以前在外资工作，假洋鬼子的说话，就是中、英夹杂）；

【2】每天，每个开发人员，要写Report给leader；

【3】严格考勤制度，迟到、早退要扣钱惩罚；

新总监抱怨说：他经常看到大家三三两两拉帮结派的上厕所。简直不象话，太耽误时间了，没有一点敬业的精神！

【4】以后做每件事，最好都要有文档备案，这是规范的基本要求；

小满觉得新总监不愧在外资干过，一看做事行头，有模有样的，心里好是佩服。他以前也是觉得虽然公司小，但是的确应该严格要求，做事情要严谨，这样才能长足发展。

小满觉得公司里面的开发的确存在一些问题，比如：文档不规范、不完整。如果人员流动，给后续工作带来很大的麻烦。

新人必有新气象，小满满心希望自己能学到点新东西，希望以前的情况能有所改变。

又过了二个月，小满发现了一些问题：

【1】开发人员开始不习惯写报告，后来渐渐适应了。有几个报告写得好的人，小满看测试那边反馈的结果来看，代码的质量却不好；

【2】会议开得太多，理念讲了一箩筐，但是，很多具体的问题却耽误下来了，最直接的表现就是：项目经理开会就一直抱怨，扯皮。大家都变得很不耐烦。事情做不完，还得加班，心里憋屈！

【3】迟到的少了，但是，有人一来工作就打瞌睡，还有人就磨洋工。有人抱怨考勤制度不合理等等；

新总监来了半年，技术团队的人流失的很快。有些资格老一点的，直接找老大沟通。老大毫不犹豫地坚持自己的新政：为了未来的发展大计，牺牲一点算什么。

直到有一天，好几个项目经理同时辞职。老大才觉得大事不妙，找几个骨干推心置腹，还是没有挽留成功。老大一怒之下，新总监下课了。

公司从成立以来，一路高歌猛进，摧城拔寨，从未象现在一样风雨飘摇。整个公司，人心惶惶，大家都各怀心事。

出去的项目经理也在劝小满离开公司，另谋发展。

小满心里七上八下的，内心充满了不安和莫名的惶恐。

（二）

小满见到老鸟的时候，老鸟正在摆弄他的新笔记本电脑，一台IBM thinkpad-从淘宝购买的水货，比行货便宜很多。

小满打趣说：你也太守旧了，怎么老是买thinkpad啊，也不换一个其他牌子的。

老鸟买了好几台本本，都是thinkpad的。一般给朋友推荐，也是thinkpad。

老鸟说：“习惯了。这本本非常结实，扔在车子的后背箱，随便放，不会有问题。哪象你的本本，才用2年，表面的漆都不成样子了。”

小满的本本去年才换了新的，虽然便宜，但是每次去维修都耽误很多时间。小满一直懊悔不已。老鸟一直在跟他说：买thinkpad吧。

老鸟问小满最近在忙啥，小满把公司的情况一说。老鸟叹了口气。

老鸟说：很正常。很多创业公司在长大的过程中，都会出这种情况。而且有可能是反复出现。

（三）

在中国这些年，成长起来的创业小企业，一般都是这样的：

几个朋友、同学，或者就是家族里面的几个人，找到一个机会，销售或关系驱动，发家。

这样的公司，启动很快，而且前期增长也很快。有些执行力好的，1-2年就能做到很好。

增长期给人信心，也给人幻觉，觉得：没有想不到，只有做不到。创业者，或老大们，信心爆棚，然后开始希望业绩急速地增长，拼命追求快速成长。

从小公司迈向中大型公司，面临的第一道坎就是组织的管理方式改变了：以前几个人凑在一起，聊着说完了就开始干。现在公司大了，人多，事多。很多事情被分解得很细，控制的环节上，就冒出很多问题。

老大们一想：以前的老办法不行了。这得管理啊！

可啥是管理，老大们也不清楚。看书、听培训讲座。总算想明白了：管理就是要规范，就是要按规矩办事。

怎么办呢？

去其他的知名企业里挖人！挖一个著名公司的部门经理，过来做总监。

（四）

小满说：“我们老大也是这样想的。有什么问题吗？”

老鸟说：“规范企业管理，本身没有错。但是，如果一说到管理就认为只是那种形式上的规范，那就大错特错了。”

“很多自认管理很好的企业，其实，你问他的中层，反而会听到一些抱怨的声音。有人干脆直接说：搞管理的人，都是只会耍嘴皮的人！”

小满点头。

老鸟说：“十多年前，我曾经参观过一家IT的OEM工厂。里面的工人穿两种颜色的衣服。穿粉红色衣服的人是流水线上的工人，她们的任务就是完成整个流程上的规定步骤。穿蓝色衣服的是拉线上的检测人员。而真正的管理人员则穿便装。”

“你在现场，会有一种震撼：制造行业的流程设计，已经把人和机器做到了人机合一的境界，每个人都是一个螺丝钉一样。让人感叹不已。”

“我突然理解了：为何很多管理的理念，对精密的制度化的膜拜和追捧。因为很多所谓的现代管理理念，建筑在20世纪的机器自动化的现实上。”

“但是，相应的质疑也随之而来：如果我们不是某个流程上的螺丝钉，如果我们的企业或组织在从事创意产业的话，我们对基于工厂管理的制度化追求，是否还有其他更加合理和人性的方式。”

小满说：“建立规范，统一起来，不好吗？”

老鸟说：“看你指向什么。更要看结果。很多事情都是意愿是好的，但是，付诸行动的时候，却显得很粗糙。”

“比如说，印度做外包，做的就是代码编制的过程，而且人家就是人多。外包这种方式，就适合用工程的方式来控制质量：充分的文档、严格的测试等等。跟工厂制造差不多。这种方式下，通过CMM认证，或许真正对团队有利。”

“但是，如果你只有20-30个人，你的人手有问题。你的项目小组，可能只有5个人。那么你的管理方式就应该有所不同。在某些情况下，就要想：什么样的文档是必要的。或者说哪些环节才是真正重要的。应该关注结果，而不是强调某种手段。”

“如果你认为文档多，详细就代表规范的话，就会有人成天忙着写文档，不好好干活。你用什么目标去衡量人们，人们就用什么目标来满足你。但是，盲目的规范，代表的是教条，而不是真正的管理。”

“我们做技术的人也是这样：以为学了UML，就可以把系统设计搞好了。这简直是扯淡。你都不去和客户谈话，不去了解真实的需求。你以为图画好了，系统自然就OK。想一想，都是一样的道理：形式只是一种安慰，跟实质是不一样的。”

“德鲁克在《管理的实践》中说，管理的职能就是两个：创造顾客和创新。他提出了一个做法：就是绩效考核，末位淘汰。后来，有很多人说，该做法如何没有人性，都是源于他的结论。”

“其实，这怪不得德鲁克。人家提出了核心的目标。至于具体如何做，还得理论联系实际。很多企业把追求规范当成了目标，却忘了问规范的目标又是什么呢？”

“所以，那些成天跳晨操、唱口号，象宗教仪式一样控制员工的公司。往往是别有用心。”

（五）

小满说：“你觉得公司里面要怎么管理，才能有一个好结果呢？”

老鸟指了指自己的本本说：“这跟我买thinkpad的道理是一样的。你知道我为什么总是买这个品牌吗？”

小满说：“为什么呢？”

老鸟说：“是因为信任。我用这个本本，从来没有出什么问题。”

小满说：“我能理解。”

老鸟说：“商业的本质其实，就是这两个字：信任。我认为，也是品牌的内涵。顾客跟商家的连接在产品上，如果你的产品老是问题，你认为，你会再次相信这个商家吗？”

小满说；“当然不会。”

老鸟说：“对！其实，在企业内部的管理也是一样的道理。”

“孙子兵法说：上下同欲者胜。公司创业的时候，大家多齐心啊。大家都想：公司做好了，这下都有依靠了。大家一股劲，也不太计较什么，一下就做起来了，就是靠自觉。大家觉得公司的发展跟自己有关系。”

“公司做起来了。大家一看，真正发起来的只有老大。大家觉得还行，毕竟自己是元老，在公司资历深厚，老大当初的承诺，总不至于不认帐吧？”

“其实，很多老大不是这么想的。公司要发展，要做大。还要艰苦奋斗。站在老大的立场，对管理的追求，无可厚非。站在员工的立场看，曾经的奋斗，还是寄托在那个渐行渐远的风中的承诺。彼此的信任开始动摇了。”

“为什么不给老员工同等的机会呢？为什么不在替换之前，做一些合理的沟通呢？战略是冰冷的，而人心是温暖的。”

“很多企业和组织抱怨员工不够忠诚。我听过很多老大说：现在的人怎么都这样啊，想来就来，想走就走。我们做企业的才是真正的弱势群体。”

“老大们都认为自己是对的。从组织的游戏规则来看，也是没有错的：最先付出资本的人，收获果子也越多、越大。现代人已经墨守并相信这一规则的魔力，几乎没有人敢怀疑其正当性。”

“问题是：现代企业，很多是靠一群人。没有人认为自己就该呆在一个地方默默奉献，象叫花子一样讨口饭吃。越是知识型企业的员工，越是自觉的人，这种落差就越大。”

“其实，这就是人之常情：人都需要得到稳定，但更需要尊重和成就。如果他没有从组织里分享到应得的成果。你就是让全世界最口若悬河的成功大师对他励志也没有用。”

“真正有能力的人，只需要领导，而非管理。或者说管理变成了一种博弈的游戏：你给我空间，给我信任，我会自发做的很好的。因为你需要的才能和激情不是问题。”

“只要公司被视为单纯的私产，并漠视分享，那么，对于真正的人才来说，什么样的管理手段都无济于事。”

“管理的极限就是人性的极限，什么样的控制都改变不了人性。”

（六）

小满说：“那我该怎么办呢？是该留，还是该走呢？”

老鸟说：“虽然公司这么些情况，但很多问题出在中、高层。对你影响不大。”

“你们这个公司，对新人来说，还是不错的机会。这些年也算小有名气。你们做的项目，接触到的客户，对你的成长都非常有利。你刚做项目经理，很多经验上的细节，还需要磨砺。”

“你的这份工作，焦点在工作经验的积累上，待遇不是最重要的。”

小满说：“人一走，公司里面的人心里都有点发慌。心里不好受。”

老鸟说：“好好的公司搞成这样，是让人心疼的。不过，你要习惯这种方式。熟悉组织这种规则，让你对企业有更清楚的认识。”

“在这种时候，你反而要想：我自己在什么阶段，(世界经理人博客http://blog.icxo.com)我在这个公司是否可以学习到有用的经验，或者是否有成长的空间。我该如何投资自己，该如何视公司为一种投资的管道。”

“要求公司照顾你，如果事与愿违后，则大骂其背信弃义，都是没有什么用的。理性一些，更加理智一些。首先信任自己，评估自己的能力和潜力，不要让自己轻易落在井里。”

“有一天，你们老大或许会改变，或许永远不会改变。如果你改变不了别人，改变自己好了。”

小满说：“那我以后怎么办？如果在公司呆不下去了，我还是要去找工作？”

老鸟说：“最好是不要去找工作，而是尽可能让工作来找你。若干年后，你拥有的经验和人脉，可以支持你走很远。永远记住：没有任何人，没有任何公司可以给你百分百的保障。只有你自己才能保障你自己，只有对自己负责才能选择并兑现未来。”

对大多数的程序员来说，撰写程序代码或许是令人开心的一件事情，但我相信，有更多人视阅读他人所写成的程序代码为畏途。许多人宁可自己重新写过一遍程序代码，也不愿意接收别人的程序代码，进而修正错误、维护它们、甚至加强功能。

这其中的关键究竟在何处呢？若是一语道破，其实也很简单，程序代码是别人写的，只有原作者才真的了解程序代码的用途及涵义。许多程序员心里都有一种不自觉的恐惧感，深怕被迫去碰触其它人所写的程序代码。这是来自于人类内心深处对于陌生事物的原始恐惧。

读懂别人写的程序代码，让你收获满满

不过，基于许多现实的原因，程序员时常受迫要去接收别人的程序代码。例如，同事离职了，必须接手他遗留下来的工作；也有可能你是刚进部门的菜鸟，而同事经验值够了、升级了，风水轮流转，一代菜鸟换菜鸟。甚至，你的公司所承接的项目，必须接手或是整合客户前一个厂商所遗留下来的系统，你们手上只有那套系统的原始码（运气好时，还有数量不等的文件）。

诸如此类的故事，其实时常在程序员身边或身上持续上演着。许多程序员都将接手他人的程序代码，当做一件悲惨的事情。每个人都不想接手别人所撰写的程序代码，因为不想花时间去探索，宁可将生产力花在产生新的程序代码，而不是耗费在了解这些程序代码上。

很遗憾的是，上述的情况对程序员来说很难避免。我们总是必须碰触到其它人所写成的程序代码，甚至必须了解它、加以修改。对于这项需求，在现今开放源代码的风气如此盛行的今日，正如之前的《程序设计2.0》文中所提到的，你可以透过开放源代码学习到新的技术、学习到高手的架构设计，大幅提高学习的效率及效果。你甚至可以直接从开放源代码项目中抽取、提炼出自己所需的程序代码，站在巨人的肩膀上，直接由彼端获得所需的生产力。从这个观点来看，读懂别人所写的程序代码，就不再只是从负面观点的“被迫接收”，而是极具正面价值的“汲取养份”。

先了解系统架构与行为模式，再细读

倘若撰写程序代码是程序员的重要技能之一，那么读懂别人的程序代码、接着加以修改，也势必是另一个重要的技能。

如果你不能熟悉这项工作，不仅在遇到你所不愿面对的局面时，无法解决眼前接手他人程序代码的难题，更重要的是，当你看着眼前现成的程序代码，却不知如何从中撷取自己所需，导致最后只能入宝山空手回，望之兴叹。

阅读他人的程序代码，大致上可以分为三种程度：一、了解，二、修改、扩充，三、抽取、提炼。

了解别人的程序代码是最基础的工作，倘若不能了解自己要处理的程序代码，就甭论修改或扩充，更不可能去芜存菁，从中萃取出自己所需，回收再利用别人所撰写的程序代码。

虽说是“阅读”，但程序代码并不像文章或小说一样，通过这种做法，便能够获得一定程度的了解。阅读文章或小说时，几乎都是循序地阅读，你只消翻开第一页，一行行阅读下去即可。但是，有许多程序员在试着阅读其它人的程序代码时，却往往有不知从何读起的困难。

或许找到系统的第一页（也就是程序代码执行的启始点）并不难，但是复杂度高的系统，有时十分庞大，有时千头万绪。

从程序代码的起始点开始读起，一来要循序读完所有的程序代码旷日费时，二来通过这种方式来了解系统，很难在脑中构建出系统的面貌，进而了解到系统真正的行为。所以，阅读程序代码的重点，不在于读完每一行程序代码，而是在于有效率地通过探索及阅读，从而了解系统的架构及行为模式。以便在你需要了解任何片段的细节实作时，能够很快在脑上对应到具体的程序代码位置，直到那一刻，才是细读的时机。

熟悉沟通语言与惯例用语

不论如何，有些基本的准备，是阅读他人程序代码时必须要有的。

首先，你最好得了解程序代码写成的程序语言。想要读懂法文写成的小说，总不能连法文都不懂吧。有些情况则很特殊。我们虽然不懂该程序代码撰写所用的语言，但是因为现代语言的高阶化，而且流行的程序语言多半都是血统相近，所以即使不那么熟悉，有时也可勉力为之。

除了认识所用语言之外，再来就是要先确认程序代码所用的命名惯例（naming convention）。了解命名惯例很重要，不同的程序员或开发团队，差异可能很大。

这命名惯例涵盖的范围通常包括了变量的名称、函式的名称、类别（如果是对象导向的话）的名称、代码档案、甚至是项目建构目录的名称。倘若使用了像设计模式之类的方法，这些名称更有一些具体的表述方式。

命名惯例有点像是程序员在程序语言之上，另行建构的一组沟通行话。程序员会通过共同约束、遵守的命名惯例，来表达一些较高阶的概念。例如，有名的匈牙利式命名法，便将变量名称以属性、型别、说明合并在一起描述。对程序员来说，这种方式能够提供更丰富的信息，以了解该变量的作用及性质。

对程序代码阅读来说，熟悉这个做法之所以重要，是因为当你了解整个系统所采用的惯例时，你便能试着以他们所共同操用的语汇来进行理解。倘若，不能了解其所用的惯例，那么这些额外提供的信息，就无法为你所用。像以设计模式写成的程序代码，同样处处充满着模式的名称，诸如：Factory、 Facade、Proxy等等。以这些名称指涉的类别，也直接通过名称，表达了它们自身的作用。对于懂得这命名惯例的读者来说，不需要深入探索，也能很快捕捉到这些类别的意义。

当你拿到一套必须阅读的程序代码时，最好先取得命名惯例的说明文件。然而，并不是每套程序代码都附有此类的说明文件。另一个方式，就是自己到程序代码中，大略浏览一遍，有经验的程序员可以轻易发掘出该系统所用的命名惯例。

常见的命名方式不脱那几类，这时候经验就很重要，倘若你知道的惯例越多，就越能轻易识别他人所用的惯例。如果运气很糟，程序代码所用的惯例是前所未见的，那么你也得花点时间归纳，凭自己的力量找出这程序代码命名上的规则。

掌握程序代码撰写者的心态与习惯

大多数的程序代码，基本上都依循一致的命名惯例。不过运气更差的时候，一套系统中可能会充斥着多套命名惯例。这有可能是因为开发团队由多组人马所构成，每组人马都有不同的文化，而在项目开发管理又没有管控得宜所造成。最糟的情况，程序代码完全没有明显的惯例可言，这时候阅读的难度就更高了。

想要阅读程序代码，得先试着体会程序代码作者的“心”。想要这么做，就得多了解对方所使用的语言，以及惯常运用的语汇。在下一回中，我们将继续探讨阅读程序代码的相关议题。

　　比较三个境界，其实第一个境界最难。业内现在不乏衣带渐宽的憔悴之士，百度千度地摸索前行的公司也很多。如今大环境绝对称得上“西风凋碧树”了，但有谁“独上高楼，望断天涯路”了呢?既没有登高望远，没有创新，那么衣带渐宽，百度千度是没用的，最多是帮人烧钱，锻炼意志罢了。核心问题还在能否创新思维，创新策划，创新创造。业内智力很好的人不少，但有创造力的的人不多，所以大家才看到，我们抄的很快，但创新很少。 　　最近看了本书，是德国一个叫施万尼茨的教授写的通俗欧洲人文史，估计是给本科生的讲稿，书名叫“欧洲：一堂丰富的人文课”。这书和过去读的其他类似书籍不同，它分上下两篇，上篇讲知识，也就是我们所熟知的历史事实;下篇讲能力，讲为什么有人能创造知识。有段话很有意思，虽然不是他的独创：“智力并不代表一切，人还要有创造力”。“为区分创造力和智力，人们把思维方式分为收敛型和发散型。收敛型思维指的是直接建立在已有知识基础之上的新信息;而发散型思维则是思维向纵深发展，并产生独立于已有知识之外的新信息。IQ所测试的是收敛型思维，而发散型思维则是创造力的基础。前者所提出的问题只有一个正确答案，而后者的问题而可以有许多富有独创性的灵活的答案。但是，只有独创性还是不够的，发散型思维还要求人们具有批判的能力，把没有意义的突发奇想滤除掉，迅速地判别一个念头可行或不可行。”(P. 456) 　　创造性思维方式分为双向连接式思维，逆向思维，极端式思维和偷换命题四种。双向连接式思维是说“基于一个棘手的任务，两个领域被闪电般地联系在一起，从而使一个领域的问题从另一个领域中找到了答案”。这类创新在网络界最常见，例如GOOGLE把搜索和广告联系在一起，腾讯把即时通讯和动画形象联系在一起，百度帖吧把搜索和BBS联系在一起，雅虎把邮箱和新闻联系在一起，FACEBOOK把开放平台和第三方应用联系在一起，等等。逆向思维是把逻辑反过来想，不管结果，挑战前提。淘宝模式是逆向思维最成功的范例。EBAY模式是提供网上开店的环境，然后收取店租和交易费;而淘宝是免除店租和交易费，通过广告和其他服务收费。极端式思维是按一种逻辑设想一种最极端的甚至是荒谬的情况，然后挑战它，找到新思路。WEB2.0就是极端式思维的产物。我在以前的博客中曾经模拟过2.0的产生过程。既然过去的网络服务都是以网络公司自营服务的逻辑展开的，那么理论上最伟大的公司就可以把人类所有需要的服务都罗列在网站上，让全世界的所有用户都来用。但这样的结果就是网站结构臃肿复杂到用户无法找到和使用自己需要的服务，公司庞大到无法管理的程度。所以，干脆把原有的开店模式推翻了，从用户个人出发重构网站逻辑，通过开放，定制和智能匹配推荐等方式把每个人需要的服务送到用户家里去。偷换命题式思维“指变换一个命题，并找出新老命题在结构和内涵上的相似性，接着通过“自我”的检验，把二者归一”。(P.457)这方面我知道的最好案例是盛大模式。02-03年的时候，网络游戏最大的瓶颈在于没有方便，普及，成本低而可靠性高的网络支付体系，游戏好而收钱难。盛大的方式是不消极等待网络支付体系的成熟，也不是完全依赖游戏卡这类完全的线下体系，而是构建一个网上网下相结合的支付体系，充分发动网吧的积极性，一举解决了用户支付问题，连带构建了产品推广系统。 　　中国的社会环境和教育体制是不鼓励不培养学生创造性思维的，讲究的是权威崇拜和随大流，所以网络界创新难并不奇怪。所以，多数公司主要靠的是下死力气，市场公关和资金充裕。但是，从结果看，这些都难以弥补创新力不足的缺憾。也许在一个时期可以糊弄过去，但长期看是不解决问题的。

　　总之，在我看来，网络业的游戏规则第六条就是：创新力是网络公司成功的发动机。

　　什么是一个好的互联网战略?借用马行长的说法，略作发挥。

　　一.看的早一点

　　互联网历史已经证明，先发优势是公司成功的关键因素之一。无论美国最早做门户的雅虎，做商务的亚马逊，做C2C的EBAY, 还是中国最早做门户的新浪，做搜索的百度，做B2B商务服务的阿里，都在其后的竞争中在各自领域保持着第一品牌的先发优势。

　　看的早一点是件很困难的事，看的早首先要看的远，看的清市场发展趋势，然后才能提早动手。凭什么你比别人看的早?世界上没人做过的事情很多，其中绝大多数都是不能做的，做了一定死。但的确有些事符合市场的未来需求，技术和资源条件也具备，但大多数人就是不能提前三五年看到，只有极少数人看到了，更极少数人动手做了，更更极少数人做成了。成功的预测能力来自三方面：一是获取信息能力很强，综合分析能力很强，理性判断能力很强，简单说就是聪明。二是不信邪，不被现实所拘束，喜欢做别人没做过的事，或者别人做过但失败的事。网络业成功的年轻人居多，简单说就是敢干。三是脚踏实地，具备将前瞻性转化为现实可能性的能力。在网络业，看早三五年是优点，看早三五十年就是缺点了，前瞻不是妄想，简单说就是实际。所以，聪明，敢干，讲求实际的人一般都能比其他人看的远一点，看的早一点。

　　二.看的大一点

　　网络是新兴产业，空白点很多，想出个把新主意不是什么难事，难的是绝大多数新主意都不够大，不值得做，因为即使做成了也没什么前途，混口饭吃而已。现在已经成功的大公司在创业时起都有了各自的大目标，大追求，大野心。微软起家的口号就是让家家户户都有一台PC，安的都是微软的软件;雅虎刚开始做的就是想让人人都用的门户;GOOGLE在只有2个人的时候就想搜尽天下信息，为全世界人提供免费的信息检索。。。我们再谦虚，怎么也得把理想目标定在让中国大部分网民来用自己的服务吧?这就要求我们在开始设计战略，规划平台和产品的时候就要有雄心让自己的服务具有通用性，普适性，可扩展性和开放性。 　　很多人说，看大点容易做大难，还不如从小做起，等做的有点眉目了再想大的事。这话也对也不对。如果把大看作是说空话，不切实际，那当然是大而无当。但任何大事开始的时候都不大，都是从小做起的，关键在于小中有大。只要是在做大的正确方向上，起点多低都不怕，怕的是做的小巧精致，钱也挣了一点，名也有了一点，但走在一条死胡同里，没有成长空间。业内有很多公司，很难说在操作层面上做错了什么，但始终病歪歪的长不大，其原因就在于开局的时候格局太小，潜在市场有限，目标太具体了就没有想象空间，没有可持续成长性。

　　要想看的大还有个站位问题。一种是从互联网，从网民的角度看外面的世界，另一种是从外面的世界看互联网和网民。前面的角度我叫做网络的，想的是如何把花花世界上千奇百怪的东西弄到网络上来为网民服务;后面的角度我叫用网络的，想的是如何把网络的某些功能切割出来为自己的传统业务服务。两个角度各有各的道理，无所谓对错，但有所谓大小。做网络可以做大，因为打破了时间和空间的限制，不受传统产业原有条件的局限;用网络只能做小，因为它只是原有业务的改进和补充。 　　三.看的透一点

　　我读过看过不少网络公司的战略规划，通过观察网站也揣摩过很多公司的妙处何在。但细究起来，发现很难找出他们的核心竞争力在哪里。一个好的企业战略一定能看出其核心竞争力所在。例如招商银行的早快好战略，说到底就是一个先发战略，同样的服务比别人早做三五年。这和银行业的状况和自身的条件紧密相关。中国银行业的服务水平比发达国家差个一二十年，任何所谓创新也就是在国内比同行早做一段时间，没有什么新东西，都是外国早就做了的。所以，与同行打时间差就成了至关重要的战略要点，快和好只不过是为了进一步巩固早的成效。你快别人也可以快，你好别人可以比你更好，唯有早是别人不可能逾越的障碍，除非时光倒流。所以招商银行的核心竞争力就在一个早字上，永远比对手快两步。

　　和银行业这样的传统成熟产业相比，网络业公司的核心竞争力可以来自很多地方，例如创新，知识产权，规模，技术等等，一样不行就几样结合，总之要证明这事非我做不可，也只有我才能做好。如果做的是别人没做过的，需要证明自己能做;如果做的是别人已经做过的，需要证明自己做的和别人不一样。GOOGLE不是第一个做搜索的，事实上在它之前已经有许多公司做了。结果GOOGLE用它的PAGE RANK证明了自己和别人不一样。腾讯不是第一个做IM的，结果它用增值服务模式重新定义的IM。淘宝不是第一个做C2C的，但它用免费战略打败了EBAY的收费战略。所以，能看的早固然好，有先发优势，如果看的晚了，也要寻找后发优势，重新定义服务，变后发为先发。 　　总之，在我看来，互联网的游戏规则第5条是：一个先发的，格局比较大的，具有核心竞争力的战略是网络公司成功的必要条件

　　但是，有了钱就一定能成功吗?不一定，很不一定。从网络风险投资的成功率看，大致在10-20%之间，也就是说，投资10家公司成功(高回报退出)的也就一到两家。剩下那80-90%拿到钱却没有成功的公司出什么问题了?从十几年网络发展历程看，大概问题出在这样几个方面：

　　赶时髦，赶热潮

　　这十几年来，风险投资基本是按主题赶浪潮投资的。从早期的门户，电子商务，到中期的无线增值，游戏，再到这几年的视频，SNS。总之是美国什么火了，中国就投什么;一个公司火了，马上就投一堆。这也很难怪VC们，他们不是做网络的，很难判断网络业发展的内在规律，只好找参照物。而所谓参照物无非两类，一类是当红的公司，一类是其他VC投资的走向。按说做网络的应该有想法，有创新，但事实证明绝大多数做网络的也不比投资家们更内行些，也是傻子过年看隔壁，什么火跟什么，什么容易拿到钱抄什么。结果当然是成功率的大幅降低。

　　喧宾夺主，资本家成了企业家

　　尤有甚者，一些投资者不甘于位，主动甚至强行充当公司决策者和操作者的角色，这也算中国互联网业一大特色。经常见到一些投资人，张口就说：“我不懂网络”, 没等你夸他谦虚，他就会接着说：“但是，。。。”。然后预算要他说了算，招人要他说了算，产品要他说了算，管理要他说了算，进度要他说了算。这哪里是不懂网络，分明是全才啊。于是，资本的逻辑取代了网络业的规律，损益表的算法取代了企业经营的道理，一方股东的利益取代了全体股东的权益。都说中国企业界一大特色是大股东侵犯小股东利益，在我们网络界，投资方即使是小股东也常侵犯大股东或其他股东的权利。这样的公司能做成才是怪事。现代企业机制一大特征就是所有权与经营权分离，而以硅谷为代表的高科技企业机制更是弱化了传统董事会的角色。西方的真经被东来的和尚念歪了，不管这些和尚是说中文的还是说洋文的。 　　话又说回来，很多VC不得不介入公司运营也有其苦衷。中国的市场经济环境不成熟，大部分网络业创业者没有市场经济的基本概念和经营管理经验，又不肯放权给职业经理人(或者职业经理人也不够职业)，为了避免投资失败，只好放下身段弄脏手。但是，虽然是不得已而为之，那也不能证明角色错乱可以成功，只能证明投资的轻率。财大者难免气粗，但要粗的有章法，粗对地方。

　　市场大于产品，后继乏力

　　正是由于投资赶浪潮，追热点，所以同一拨同一类被投资的公司竞争起来异常艰苦激烈。正是由于外行领导内行(或者就没有内行)，所以网络业现在市场派的声音远大过产品派。我曾多次被人审问过是那一派的，我只能老老实实地说是产品派。纵观网络历史，凡是成功的公司都有好产品，无论在做好产品的磨难中道路多么曲折，压力多么巨大;凡是不成功的公司产品都不够好，无论其市场投入多大，招数多多。我当然同意在做好产品的基础上大做市场，但前提是必须有了好产品。大约是在03-04年开始，互联网业开始由卖方市场向买方市场转变，但我们一些同仁的思路还是停留在幸福的90年代，东西做的好坏不重要，因为市场贫乏，没有好东西，只要争了第一，总能找到出路。所以，做不出好东西(甚至就没想做出好东西)，就想吹出个好东西，以为中国还是过去那个钱多人傻的社会。结果，大量资金和力气都浪费在所谓市场推广上，最后也做不成个局面。任何公司做不出好东西，却寄希望于单纯的市场伎俩，无异于把投资当伟哥吃了。其实一个不好的东西放大一万倍还是成不了好东西，与其把宝贵的资本浪费在不切实际的幻想上，还不如老老实实地走创新之路，做出好产品。否则，最后落个举而不坚，坚而不久，久而不射的尴尬局面对谁都无法交代。 　　武大郎开店，后继无人

　　记得是80年代初，著名漫画家方成画了幅漫画，登在人民日报出的“讽刺与幽默”周刊上。作品的标题叫武大郎开店，引起强烈的社会共鸣。这幅漫画今天已被中国美术馆收藏，武大郎开店甚至今天已成了新成语。画里是一家武大郎(水浒里武松的哥哥，五短身材)开的餐馆，一个个子矮矮的伙计对前来应聘的大个小伙说：“我们掌柜的有个脾气，比我高的都不用”。作者还用挂在店里的一副对联进一步点明主题。上联是“人不在高有权则灵”，下联是“店虽不大唯我独尊”，横批是“王伦遗风”。

　　这幅漫画之所以成为经典，恐怕不在于画技有多高明，而在于辛辣地讽刺了中国几千年农业社会和专制制度带来的反向淘汰遗风。即使先进如我互联网业也未能免俗，凡是熟悉一点业内情况的人都不难发现，武大郎式的餐馆比比皆是，而且大有连锁化的趋势。已经成为业内一道风景的是，有一大批网络公司，创业短则五六年，长则十余年，就在那里不死不活地吊着。融资一轮又一轮，既没破产，也不见进步，而决策者却从不见换人，团队却是一茬不如一茬。外界都说互联网业变化快，几天一个新故事。但这些公司的共同特点是网站不是五年一贯制就是十年一贯制，从不见重大创新和模式改变。究其原因，武大郎哲学应该是其中重要一条。业内曾流传过一句话：“宁可公司在我手里做死，也不能让别人染指”。这和李嘉诚的名言“绝不和自己的公司谈恋爱”成了鲜明的对照。我很钦佩那些陪着这些公司玩了这么久而痴情不改的风投的忍耐力，但无法理解那些对投资者如此不尊重的掌舵人。 　　总之，货币资本投入早晚，数量大小，并不能决定一个网络公司的成败。只有货币资本同公司的制度资本，人力资本和社会资本良好结合才能提高公司的成功机会。所以，在我看来，互联网业的第四条游戏规则是：资金是网络公司这辆车前进所必须的燃料，但它不是发动机，更不是方向盘。

　　第一，在什么地方创业

　　到目前为止，绝大多数比较知名的网络公司都在北京，上海和广东(50%，20%，20%?)，上市的公司除阿里以外也都在这三个地方。道理显而易见，开放程度高，人才聚集多，资本，信息，资源多，基础设施和管理各方面上轨道。这种共享的公共的社会资本减少了公司创业期的痛苦和成本，增加了公司的成功率。三地的文化特点也潜移默化地影响着网络公司的风格，例如北京的大视野，上海的执行力，广东的实干精神。三地之外不是不能干网络(例如阿里)，但成功率低的多，而且主要的机会在地区性的，和传统产业结合的，产业链低端的网络简单应用。

　　这不仅在中国如此，硅谷之所以能够成为世界IT业和网络业之都，是和那块地方多年积累的雄厚社会资本分不开的。它占据了产业上游，其他地方只好屈居中下游。这不是哪个公司或哪个个人的问题，是社会资本积累历史的必然结果。同样道理，如果谁想在中国互联网上游和主流中找机会，闯天下，那最好扎根在北京或者上海广东，在其他地方尝试，用人力资本或货币资本去弥补社会资本的不足，那绝对是得不偿失的。

　　其实就是在北京，社会资本也不是平均分布的。北京的网络公司主要集中在西北角的北四环一带，东三环一带也有一些公司，其他地方就是散兵游勇了。以我个人的体会，西北角的公司更像是做网络的，东边的更像是做公司的。无论是招聘人才(特别是技术人才)，参加聚会，还是同业交流，资源交易，西边的成本远低于东边。这也不是哪个公司聪明或笨拙造成的，是环境使然。北京西北角的大学区加高科技创新区的大氛围决定了这里的网络公司更像网络公司，在一定的社会资本支持下，成功的成本更小些，机会更大些。 　　2. 选择什么方面创业

　　从尽可能充分利用社会资本的角度观察，成功的公司创业的切入角度有三个共同点：1)做社会能够接受至少能够容忍的主流应用和服务，理论上是全体或大多数用户会经常用到的东西，例如新闻，搜索，邮箱，即时通讯，商务等等;2)敢为天下先，集万般宠爱于一身。这些公司在既定领域出发比较早，不是独发或先发，也是先发之一，留下充分的时间去犯错误，积累经验，创出品牌，完善产品和服务; 3)做别人不想做，不会做，不能做的东西，不和既得利益者打擂台，争生死。最多局部竞争，绝不和垄断寡头全面竞争。

　　例如游戏，相对成功的网络企业比较多，这是因为游戏间的差异性比较大，每款游戏都和其他游戏不一样，所以先发后发无所谓，只要是好东西就有市场。而且过去并不存在一个规模比较大，垄断性比较强的游戏市场，游戏公司是在创造市场，而不是在成熟市场上抢别人的地盘。例如新闻，在现有社会条件下空间有限，大家做的东西同质性很高，所以只能靠其他服务号召群众。再例如视频，是一个高度垄断，高度敏感的市场，根本不可能公平竞争。加上现有体制下出不了什么好东西，社会对知识产权的保护日益加强，选择干这行真是累人啊。我始终弄不懂为什么有人有钱投入专干网络视频，无论YOUTUBE模式还是HULU模式在中国完全没有现实可行性，又没有什么技术含量，何必去送死?整天琢磨如何在灰色地带找出路，担惊受怕。一旦没人管，大家就蜂拥而上，一旦雷来了，大家又去陪笑脸，跑关系。这是做网络吗? 　　3. 定位在产业链的什么地方

　　有人说我好大喜功，一味鼓吹做平台，做创新，做大产品。其实这是误解。东西无论大小，关键在处于产业链，价值链的位置。谁都知道创业初期，经验，能力，资源都不足，肯定不可能一上手就做出什么惊世骇俗的东西出来。但是，以此为借口，什么简单做什么，什么热门抄什么，肯定也不会有前途。如果定位在产业链上游，东西开始可以做的很小，做的很不好，但随着时间和经验的积累，东西会逐渐好起来。因为处于上游，用的人多，带动中下游的应用和服务多，在虚拟世界里的社会资本大，先慢后快，先苦后甜的机会是有的。相反，如果定位在产业下游，东西可能做的很精致，很漂亮，但张力有限，给人家拾遗补缺，在虚拟世界里没什么社会资本，先快后慢，先甜后苦的机会很大。君不见，淘宝自己什么都不卖，却撑起来中国第一电子商务平台;腾讯一个小QQ，却撑起来年产值10亿美元的中国第一网络帝国;GOOGLE只做搜索，却让全球的网络公司给它打工;FACEBOOK自己没什么应用，却有十几万人在拼命给它提供应用，成为应用最丰富的世界第一网络生活平台。 　　当然，不是认识到定位重要性就可以定位在产业链上游。除了认识以外，还需要人力资本和货币资本的支持。如果是新手，也没什么资源，随便做点什么都好，现在可以给开发平台做应用，或者和传统产业结合做服务。但一定要有自知之明，别把梦做大了，做野了。这样做不会成为网络业的主流，最多是个过得去的生意而已。

　　所以，在我看来，互联网的游戏规则第三条就是：上游定位，创新定位，前瞻定位，最大限度地利用社会资本。

　　人力资本一般指的是人们所具有的智力，体力，知识，能力，经验和业绩。这个概念已经流行40多年了，在美国资本市场和高科技行业被普遍接受，但在中国无论是在理论层面还是实践层面都还是近年才逐渐开始被重视。北大经济学教授周其仁写过一篇很精彩的文章，叫做“人力资本的产权特征”。在他看来，人力资本从产权的角度看具有三大特征：“第一，人力资本天然归属个人;第二，人力资本的产权权利一旦受损，其资产可以立刻贬值或荡然无存;第三，人力资本总是自发地寻求实现自我的市场。”周教授进一步说明道：“人力资本是“主动资产”，天然属于个人，并且只能由其天然的所有人控制着这种资产的启动、开发和利用。因此，当人力资本产权束的一部分(或全部)被限制或删除时，产权的主人可以将相应的人力资本“关闭”起来，以至于这种资产似乎从来就不存在。”“ 更特别的是，这部分被限制和删除的人力资本的产权，根本无法被集中到其他主体的手里而作同样的开发利用。一块被没收的土地，可以立即转移到新主人手里而保持同样的面积和土壤肥力。一座厂房和一堆设备，也可以没收后投入另一个生产过程而保持同样的价值和效率。一堆“没有臭味”的货币，谁用都值那么多钱。但是一个被“没收”的人，即便交到奴隶主手里，他还是可能不听使唤、“又懒又笨”，甚至如张五常教授所说，宁死不从。换言之，人力资本是一种可能因为“产权残缺”而立即自动贬值的特别资产。人力资本及其所有者用来反制产权残缺和残缺产权的转移的基本机制，就是“主动”使这种资产的经济利用价值一落千丈，甚至瞬时为零。” “人力资本这个东西还有一个特性，就是千方百计会找机会实现自身的价值。我们不是看到过，寒冬腊月在公家地里睡觉的“懒虫”，一回到他的自留地里，居然会干得满头大汗吗?”

　　既然人力资本这么重要，又这么难缠，应该用什么办法最大限度地把它的潜力发挥出来，使企业走向成功呢?周其仁在他另一篇文章“刮目相看人力资本”中，讨论了可能的三种方法。“一种就是强迫。这通常对简单劳动起作用，但对复杂劳动不能够持久。因为谁来强迫强迫者呢?”“ 第二种是靠热情，类似于宗教的、意识形态的、信仰的东西。它的作用有，但不够普遍。因为不是所有人都相信这套东西，也不能持久。”“调动人力资本更重要、更普遍、更持久的办法应该是交换。要让人的资源充分调动起来。企业也好，社会也好，国家也好，你总要跟他换东西，而这种交换跟任何交换一样，都要遵循市场的法则。” 　　网络业普遍实行的现代高科技企业制度是我们目前所能看到的最能调动人力资本的交换制度。既然人力资本是主动资本，人是人力资本的载体，那就让具有人力资本的人当公司创始人，当大股东好了。公司成了，大家都发财;公司死了，大家玉石俱焚。既然除创始人以外的员工也都具有数量不等的人力资本，那就让他们也拿上数量不等的期权。公司成了，大家都高兴，公司死了，大家都白干。所以，和其他产业相比，网络业从业人士的工作热情最高，干劲最大，创新最多，持续性最长，成功的故事最动听，成功的创业者和投资者的金钱回报也最可观。

　　当然，这套制度也有它的挑战性：

　　人力资本的价值如何确定?谁知道哪个人，哪个团队，哪个公司的人力资本最雄厚，成功的可能性最大?人力资本是无形的，是弹性的，和有形的物质资产比，很难把握，很难捉摸，很难定价。谁都知道投资以人力资本为主的创业公司风险大，这风险就在于人力资本与货币资本的对价和博弈。所以，干这行的叫风险基金和风险投资家，越有风险越投资，赌的就是成功率。 　　第二，人力资本的风险如何控制?投资虽然投的是能够创造财富的人力资本，但人力资本都具体体现在个人身上，而一个人身上不是所有品质，能力和经验都能创造财富，也会有些不好的品质，不足的能力和不多的经验是负人力资本。如何建立和有效实施一整套决策，管理和监督机制，搭配一个优良团队，激励好的人力资本的发挥，抑制坏的人力资本的破坏，也是一个公司成功与否的重大挑战。

　　第三，人力资本的周期性如何调配?一个公司经过长时间奋斗，如果成功了，上市了，那是一个皆大欢喜的局面，风险投资可以拿着丰厚回报退出，创始人成了亿万富翁，创业团队也可以兑现期权股权，然后呢?公司接下去怎么办?再来一轮人力资本投资?公司市价已经很高了，新的股权期权给便宜了公司受不了，给贵了员工受不了，这成了上一轮靠自身人力资本起家的创业者的难题。对这个难题解答的好坏，往往决定着一个初步成功的网络公司能否走向成熟期的关键。我们已经看到一些曾经成功的公司或者现状平平，或者正在走向衰落。很大的一个原因就是人力资本消耗了，散失了，匮乏了。人心散了，队伍不好带了。所以，我们近年看到一些新的尝试，目的都是为了人力资本的保值增值。例如，一些上市网络公司不再给新员工期权而是有限制条件的股权;例如，GOOGLE最近花4个多亿美元给期权未到期，但期权价格已经与股票价格倒挂的员工补偿;再例如，搜狐最近分拆上市。也许别人对搜狐分拆有不同的解释，但在我看来，解决那些没赶上上一拨发财机会，但对目前搜狐经营贡献巨大的做网络游戏的核心团队的人力资本兑现问题是最能说服人的理由。 　　总之，尽管对网络业实行的这一套制度批评不少，其中的挑战和风险也很多。但是，两利相衡取其重，两害相衡取其轻。用这套的有成功机会，不用这套的没有成功机会，这是网络业历史已经证明的了。

　　所以，在我心目中，网络业游戏规则的第二条就是：人力资本是网络公司的核心资产，最大限度地调动和利用人力资本是网络公司成功的关键。

　　我不敢妄称懂得制度经济学，但一般的概念和逻辑还是读过些东西的。陈教授是从宏观角度看一个国家，我想也可以从微观角度用同样的道理去看一个产业和一个企业。互联网产业和国内其他产业相比，在制度层面上有什么性质上的差别?如果有，这些差别在增加网络业的制度资本，减少制度成本上起了什么作用?更具体地问，那些比较成功的互联网企业和那些不怎么成功甚至失败的企业相比，在基本公司制度上的根本差别在哪里?就我十几年的观察和实践，至少以下几点是值得思考的。 　　一. 互联网企业普遍实行了与国内其他行业不同的现代高科技企业制度

　　说来好像是因祸得福。因为国内的公司法和证券法没有设计外资进入后的退出机制，而新创业的网络公司无法得到国内的风险投资和银行贷款(至少早期如此)，所以，所有得到外国风险投资的网络公司不得不采用国际通行的公司制度，在海外注册，再通过错综复杂的合法机制安排，从而可以既在国内经营，又可海外上市，风险投资在理论上有了退出机制。多数创业者对这套外来货并不熟悉(其实对国内那套东西和东西以外的东西也未必熟悉)，又是洋文，又是律师审计师，过程漫长，昂贵而麻烦。但看在钱的份上，大家咬牙接受了。十几年的摸爬滚打下来，网络业竟形成了国内其他行业所没有的行规，积累了别人所没有的制度资本。很多其他行业不好办或办不了的事情，网络业七混八混地也就办了。现在想起来，国内大众知道风险投资，海外上市，期权等概念，这个O那个O的称呼，还都是拜互联网所赐呢。

　　二. 这种制度突出承认和保护了无形资产的价值和作用

　　网络业采用这套制度，当然不全是为风险投资推出着想，随之而来的还有一系列的理念，方法和机制。国内公司法在相当长时期不承认或限制承认无形资产作为创业投入(现在好像限制在注册资本的30%吧)。而国际流行的制度普遍承认知识产权，创意，技术，KNOWHOW，经验，业绩等无形资产可以折算为创业投入。至于值多少钱，占多少股，那是公司股东之间谈判的事，没有上限。通常第一轮投资占公司的15-30%之间，你想让风险投资商当大股东人家还不干呢。如果节奏掌握的好，少融几轮资，就是公司上市了，创业者还可能是公司的绝对大股东或相对大股东呢。看看网易和盛大，就是网络创业成功，而创业者股权稀释不多的范例。

　　三. 这种制度突出承认和保护了企业未来成长和获利的能力的价值

　　投资者给网络公司的估值，无论是按PE还是按PR，或者按其他什么专门的计算方法，一般都远高于对传统产业的估值。其中的道理无非是因为网络是新兴行业，门槛比较高，空白领域比较多，发展比较快，变化比较多，使得人们的想象空间比较大。否则按传统办法估，一个PPT，几万行代码，几台电脑服务器，若干办公家具，加上看不见摸不着的用户数，能给多少钱呢?

　　四. 这种制度突出承认和保护了员工在企业未来成长中的价值和作用 　　在外人看来，最刺激最富有诱惑力的莫过于网络业普遍实行的员工股权期权激励制度了。挣不挣得到真金白银另说，至少给人一个梦总是好的。既然投资者承认创业者的无形资产的价值，那么他们也就应该共同承认其他员工的无形资产在公司成长中的价值。创业者，投资者和员工理论上利益数量不同，但利益方向和实现方式一致，这就极大地调动了员工的工作主动性和创新精神。比起传统的奖金制度，期权制既节省了公司的资金，又给了大家一个无限的发财梦，真是个好主意。

　　五. 这种制度确认了创始人，投资者和经营者在企业中的地位和作用，确认了董事会，经营团队和员工的责任和分工，也就确认了企业的决策机制，执行机制和监督机制。与传统制度下大股东，资本方强势垄断一切相比，这种制度加强了CEO和经营团队在公司战略制定和执行中的角色和地位，使利益各方的作用相对平衡，能够各自发挥其所长。

　　这种制度的特色还有一些，但我印象深刻的主要就是以上5条。总起来看，它回避和克服了国内现有企业制度的部分弊病，突出了无形资产在网络企业中的核心地位和作用，将企业参与者各方的利益，权利，权力，责任和相互监督机制都以法律的形式明确固定下来，这就使得公司内部各方利益的交易成本大大下降，不必先是语焉不详，然后是无休止地博弈内斗，提高了合约权益的实现可能性。大家都有各自明确有限可靠的权益和实现机制，剩下的就是如何通过长期艰苦的劳动去把他们实现的过程了。

　　虽然业内大家都承认和采用了这种制度，但在公司成长过程中对待它的态度，执行程度和坚持性是不一样的。真正优秀的公司通过十年左右的努力，已经把公司制度和公司文化紧密联系在一起，成为血肉相连的公司基石，并在成长中不断加以完善。曾经优秀过但近年表现一般成长不佳的公司，故事可以不同，但说到底都是违背了公司基本制度，回归传统了。还有大量的未能起飞或者起飞了却飞得歪歪斜斜，弄不好又坠落了的公司，相当一部分都是在执行公司基本制度上阳奉阴违，缩水掺假，似做非做，形似而神不似，因此导致人才流失，士气不振，外战外行，内战内行，缺乏创新和执行力不强。至于那些其他产业中试图转战网络而来的资本和人物，十个有九个对网络业的基本制度不熟悉，不承认，不接受，或者只是接过旗帜，实际上还是搞传统的那一套。本来就不懂网络，又是后来者，再缺乏制度资本，无法吸引一流人才，无论资本如何雄厚，其他资源如何丰富，来头如何显赫，实战结果无一例外的只有失败。 　　所以，在我心目中，网络业游戏规则的第一条就是：接受并坚定不移持之以恒地实行现代高科技企业制度。

　　附记—-行文至此，看到创业板5.1开张的消息。现代高科技企业制度之所以得以实现，是因为NASDAQ的存在，否则资本市场不认可，再好的企业制度也无从发挥。仅从现在发布的创业板上市管理办法看，还不清楚除了业绩指标下调外，和A股市场与中小企业板的实质性区别在哪里。也许要等到管理细则出来才能看到业内最关心的退出机制是什么。如果是按现行的企业法和证券法而没有变通，那这个创业板还是距离NASDAQ很远，也许对其他传统行业有帮助，但对网络业这样的高科技行业吸引力不够啊。

　　“睡觉。”

　　“睡过了呢?已经睡得不能再睡了?”

　　“他有没有别的本事?譬如治理国家、弹棉花、腌制猪头等等。”

　　“没有，一概没有，四体不勤，五谷不分。”

　　“他是不是很有追求?”

　　“追求得一塌糊涂。”

　　“他认多少字?”

　　“加上错别字有那么三五千吧。”

　　“那就当作家吧。”安佳平静地望着我，“既然他什么也干不了又不甘混同于一般老百姓。”

　　“也只好这样了。”我赞同道，“看来确实别无选择。”

　　“那就当吧。”

　　“当吧。”我站起来，走到大衣柜的镜子前怜惜地看着自己，“瞧瞧你都成了什么样子。”

　　“我问你。”安佳也站起来，走到镜子前仔细地瞅瞅镜子里的我，问道，“如果一个人两手攥空拳，无财无势无德无貌，他怎么才能一夜之间小家乍富平步青云摇身一变什么的……”

　　“去偷去抢去倒腾国宝嫁大款什么的。”

　　“既没偷抢的胆儿又没做生意的手腕还阳萎。”

　　“脸厚不厚?心黑不黑?”

　　“厚而无形，黑而无色。”

　　“那就当作家，他这条件简直就是个天生的作家坯子。”

　　“那你还犹豫什么?”

　　“不犹豫了，下决心了，干!蒙谁不是蒙?”

　　“对，就得有这种一条道走到黑的勇气。”…… 　　这是王朔在他早期小说“一点正经没有”的开头，描绘的是80年代后期北京城里一男一女两个无业小青年的对话。20年前，中国改革开放还没大见成效，如果不愿意过父辈们几十年一贯制的传统日子，跻身于文艺界是个看上去比较刺激，富有想象空间的路子。之所以以王朔的成就却始终被排斥于主流文学界之外，被很多自命为人类心灵工程师，以正统道德文化传教士为己任，整天忙于正确舆论导向的作家文人所不齿，和他对写字这职业的调侃态度很有关系。

　　如果把这段对话中“当作家”改成“干网络”,用来形容这些年来网络业的红火和加盟此行的相当一批人的心态，恐怕也相去不远吧?我虽疏于在业内走动，但也时不常地被一拨拨热血青年找上门来，探讨如何打入网络业，创出一番天地的奥秘。这些人大致可分成四类：一是自认为对网络有心得，有独到之见，或者有独特资源;二是已经在网络业干了若干年，但不甘心为别人打工，想自立门户;三是为网络业一个又一个的传奇故事所激动，但也没觉得那些成功人士有什么了不起，觉得自己也行;四是在其他传统行业干够了，认为网络是个新兴行业，钱多人傻机会多。最近来谈投资网络的人也不少，我猜大概是金融风暴，百业萧条，惟独网络业仍然高歌猛进，什么搜索，视频，2.0，新故事一个接一个，觉得可以摸一把。大家都把注意力放在结果上，对过程，对原因或者不重视，或者不真的了解。网络自有它的吸引力，但如果弄不清楚这吸引力的来源，那它往往对大多数人来说是致命的。

　　我这人虽然嘴上不甚厚道，但自以为还是个老实人，不愿意看见许多人许多钱许多心血许多时间在不明就里的情况下，贸然投进网络这个风险极大，成功率极低的行业里。所以每逢这种场合，我一般都会泼冷水，讲此行此业的特殊性。话多了且重复，别人不烦我也烦了，就想不如一次写出来。大家先看了，如果还没被我吓跑，再谈就比较容易了。所想所说的比较杂，姑且叫做网络业的游戏规则，全称应该是网络业主流成功的游戏规则，想利用网络搞活传统产业的不在讨论范围之内。话比较多，估计得写个十篇八篇的。话不一定对，但至少是我认为有道理。话是概率性的，谁找个反例批判，我也无话可说，谁让世界复杂呢。对这些游戏规则的发现和认识，肯定和我的从业经历有关，但主要来自对产业历史的观察分析，尽可能从事实出发，在事实基础上找规律。

　　先来看些基本事实。这些事实归纳于美国主要网络公司(GOOGLE, YAHOO, EBAY, AMAZON, …)和中国主要网络公司(腾讯，百度，新浪，搜狐，网易，盛大，阿里。。。)。这些公司的共同特点是比较大，比较知名，比较成功，透明度也比较高。

　　事实1.成功的网络公司都是由一两个创始人发起，这些人除了热爱网络外，在其他产业都没有多少成功经验，甚至不少人连一般的工作经验都没有。

　　事实2.成功的网络公司都一定在某个网络服务方向上是首创者，或者是已有方向上的重大创新者。这些公司的服务都是面向大多数网络用户的普遍需求，而不是少数用户的专门需求。 　　事实3. 成功的网络公司都在早期只有一个构想或者只有一个粗糙原型，或者网站即使上线用户也不多，但成长趋势明显的时候，就已经获得了多少不等的风险投资，这笔投资可以使公司在一两年内专心发展，免受盈利的压力(事实上，很少有在前3年盈利的)。

　　事实4. 成功的网络公司都在获得1-3轮投资后，经过3-5年努力在美国或香港上市，上市前就已经持续规模化盈利的公司一般市盈率比较高，融资比较多。

　　事实5. 成功的网络公司都不是被投资方控制的，而是仍然由创始人或创始人+职业管理团队主导，无论这些创始人是大股东，还是相对控股，甚至是小股东。风险投资方都是以获利而不是以控制经营为投资目的，一般都在公司上市后全部或大部分退出。

　　事实6. 成功的网络公司都实行由美国硅谷发明和完善的期权和股权制度，以此作为吸引人才，鼓励创新的主要手段。这些公司都实行现代企业制度，管理比较规范，分工比较明确，财务比较透明，文化比较开放。

　　事实7. 成功的网络公司都在持续不断地创新或者紧跟产业潮流，做的好一些的公司成长就快一些，做的差一些的公司成长就慢一些。这种差别在公司生存7-8年后显得尤其突出，创始人在经验和能力上的缺陷和不足也在这个时期体现出来。

　　还可以罗列其他一些事实，但最重要，最能说明问题的好像就这些了，其他都是次要的，派生的。作为对比，我们还可以看到其他一些不成功的互联网实践所共有的事实。

　　事实8.凡是由其他领域的成功者所代表的实业资本投资控股的网络公司或者子公司都没有很成功的，著名的例子包括IBM,AT&T,西班牙电信，联想，TOM,CHINA.COM，等等。

　　事实9.凡是由其他领域的成功者但本身不是网虫，对网络没什么特别感觉的人投资，控制和经营的网络公司或者子公司都没有很成功的，著名的例子包括。。。(以下删去20字)。 　　事实10.凡是试图将其他领域的传统资源与网络嫁接的，都没有很成功的，无论这些资源是权力，垄断地位，技术，产品，品牌，金钱还是市场。著名的例子包括微软(软件)，BROWN&NOBLE(图书)，迪斯尼(儿童游乐)，等等。

　　这些事实大概比较关注网络业的人都知道，但如何解释这些事实背后的道理，也就是我说的游戏规则恐怕就没有大家都服气的说法了。我接下去写的系列博客就是想把我的看法简单罗列出来，和关心网络发展的人士探讨。

　　附记—-刚写完这篇东西，就看到今天送来的“南方周末”。第6版有篇报道，题目是“网络舆论操控食物链”，很值得业内人士读一下。不过，那上面描述的东西不是我想讨论的。事情都知道，但没兴趣。也许有哪位有心人针锋相对，写一组“互联网的游戏潜规则”的博客出来，那就相得益彰了。呵呵。