软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有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个月所接触的次数。) 最好是制定活动计划和活动内容（最好是能让所有人都喜欢的），并严格规定不能缺席。

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

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

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

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

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

关键字：

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

正文：

目前许多软件开发公司实行了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分的质量目标。同时这种情况下的考核结果不能作为相关项目成员水平的指标。

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

据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. 课外小组

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

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

（一）

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

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

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

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

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

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

技术总监离职后，老大满脸的不在乎。找猎头公司去挖了一个人过来。新总监以前在某著名的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)我在这个公司是否可以学习到有用的经验，或者是否有成长的空间。我该如何投资自己，该如何视公司为一种投资的管道。”

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

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

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

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

　　项目经理的责任是产品的成功交付——在确定目标、划定范围、固定时限、给定预算等限制条件下的一次性努力。项目经理的工作内容包括资源配置、问题与风险管理、以及协调几乎所有完成项目所必需的元素。至于项目与产品的关系，项目的任务可能是开发新产品、增加产品功能、以及产品的新版本或扩展包的开发。项目完成后，项目经理通常会转向新的项目，而这新项目通常和不同的产品有关。

　　产品经理的责任则是保证产品全方位、各阶段的成功。在新产品开发项目结束、项目经理奔赴新的任务后，产品经理仍要管理产品，贯穿产品的整个生命周期。这时其他与该产品相关的项目可能启动，产品经理将自始至终参与其中，制定项目目标、引导团队完成既定商业目标。

　　两种角色间的一个挑战是：二者的关系可能表现为一种冲突。产品经理为了满足目标客户需求可能想加进去很多功能，而项目经理为了保证项目按时不超预算地交付可能想把范围控制得尽可能小。传统定义(可能本文前述定义也是如此)通常把项目经理错误的描述为仅仅关心按时、不超预算的完成项目，对产品是否符合市场或用户的需求漠不关心。 　　好的产品经理和好的项目经理能够在这些冲突中建立一种平衡。好的项目经理清楚，项目的真正成功不是根据其是否按时完成或是否超出预算判断的，而是根据它是否满足了预定的整体目的和具体目标来判断的。好的产品经理也清楚，如果项目不断延期无法上市，或花费超出预算过多导致无法完成，那再多的功能也失去了意义。

　　特别地，对于基于网络和技术的产品，项目管理和产品管理之间的混淆特别常见，这种混淆对于不了解二者区别的组织来说还有潜在的危害。Rob Grady在《你是网站项目经理还是网站产品经理(第一部分)》中写道：

　　在网站对业务的重要性日益提高的今天，它们——不幸的是——仍被作为项目来对待。这种现状成了一个问题，对达成业务目标、确立优先级、掌握管理一项新生的核心业务功能的正确技术都是障碍。如果网站已经成为或始终是一项核心的业务功能，其需求就会比项目管理需要的更多。当网站成了一个产品，它需要一系列的项目驱动来达成业务目标。

　　以下是一些关于项目管理和产品管理的要点，值得牢记在心：

　　正如每个产品都需要产品经理，每个项目也需要项目经理。

　　产品经理以为他们可以管理自己的项目，但仅凭这一点不能得出他们该这么做。 　　项目管理涉及的手段、才能和品质与产品管理所涉及的差别很大。

　　正如一个人难以身兼产品管理和产品营销二职，想找到一个同时胜任产品管理和项目管理两个角色的人也很难。

　　项目管理不是产品管理的垫脚石，产品管理也不是项目管理的爬墙梯。

　　好的项目经理和好的产品经理同样可贵。

　　找一个好的项目经理管理你的项目，这样你能成为一个更好的产品经理。

　　产品经理花在项目管理上的时间越少，可以花在产品管理上的时间就越多。 　　为了避免产品经理和项目经理之间的冲突，产品经理、项目经理和项目团队应该就共享的整体目的和具体目标达成尽可能多的一致。

我想讲一些关于程序员对自身认识的故事，这些故事都和灯下黑有关。只要正确认识自己，道理非常简单，但是，到处都可以看到灯下黑的故事。

某程序员，有一天接到一个任务：公司的有一个产品的文件太大，要求采用压缩算法，减少尺寸，最好能压缩20%。

程序员兴高采烈地接受任务：以前没玩过压缩算法，这下可以学习新东西！研究几个月后，他觉得差不多，就交给项目经理。项目经理正等着呢，高兴坏，拿着演示文件就去找产品经理。产品经理开始挺高兴，看完脸就拉下来。打开文件，把所有的文件尺寸一算，很淡淡的说：“才压缩10%，有什么用啊！”

程序员愣住，“不会吧！我看过的，压缩 20%！”

产品经理指着文件列表说：“你看，某文件是压缩20%，可你的压缩算法增加一个动态库文件，尺寸还不小，总共加起来，不就只减少10%吗？”

各位看官，这是不是软件公司里经常发生的情形？

这种失败的成因当然是复杂的，有沟通管理方面的问题，也有程序员能力的问题。我今天想要说的是程序员认识方面的问题。

继续故事：

项目经理很没面子，回去就和程序员找原因。项目经理是老程序员，直话直说；终于弄清楚的事情的本质：

第一，这位程序员一个的时间读很多关于压缩算法的书，会不少算法。可是从来没比较过算法的优劣。这老兄觉得研究算法很有趣，乐此不彼，写好几个实现。

第二，这位老兄在最后几天才想起来20%的目标，也没太放在心上，看看差不多就拿出来。

这是典型的程序员的认识问题，重知识而轻技术。

先从是么是知识，什么是技术说起。

知识就是知道，你知道某件事是怎么回事，就是有知识。

技术就是你能做出来，做得好叫技术好，做的不好叫技术差。

怎么写操作系统？看完操作系统原理，再苦读完源代码，这叫有知识。如果有本事把任务调度、内存管理、IO什么的都写出来，还能写得稳定，快速，可扩展，那是有技术。有知识和有技术可差远。早年我在工厂实习，要挫一个圆孔，拿着内锉刀干一天，只挫一个椭圆；师父来，三分钟，比冲床冲出来还圆！我是个好学徒，使用锉刀的知识全记住的，可以写一篇内圆挫使用大全。知识是有，可没这个技术。

程序员也一样。什么C++，Java，.net，什么STL，Struts，Spring，就是门门都满分，这也就是有知识。算不算技术好呢？差远。软件工程师界就专门出这种不会写程序的“高手”。我遇到一位老兄，精通Java知识，从虚拟机到各类框架，概念，无所不同，谈起Java来，没人说的过他。可是他的代码永远Bug最多，而且都是最简单的Bug，什么逻辑不对啊，功能没实现啊，UI不对啊。他的领导只有又好气又好笑。问下去，发现这老兄写几个程序文件以后，就不感兴趣，因为所用的技术没什么不知道的。所以马马虎虎交差。

说到底，写程序是个手艺活，就和古代的匠人一样，是要讲工艺的。比如一个玉匠，能打造栩栩如生的玉孔雀，那得打的好！要是一个玉匠说，这些手艺我都知道，重复做东西没劲，将就着给客人做出来吧！那他还不吃西北风！

可是，十几年来，程序员界有的是这样的人，还引发大规模争论。象什么C++和Java之争啦，J2EE和.Net之争啦。你看里边的帖子，不停有人赌这个阵营那个阵营，有发誓一辈子做C++的，有发誓打倒.Net。我还奇怪，专门没人效忠机器码的，那不是最难最有“学问”吗？这都是在争论什么知识最重要。可是啊，很少有人谈谈怎么做好产品的。

现在程序员最大的问题就是太看重知识，拼命追逐新玩意，而忽略身边的够得着东西。好，什么C++，Window API都知道，东西也弄出来，可是三天两头崩溃，还找不到原因？为什么？有没有看看代码，看看是不是某函数写2000行，自己都看不懂？是不是全局变量乱用？是不是没考虑前后兼容性？没考虑冗余和故障恢复？

末再回到开头的故事：

项目经理回去和程序员再重新设计，又多花一个月，终于达到目标。但因为这个部分是一个大项目的一部分，整个项目不得不延迟一个月。

年底考评的时候，项目经理给程序员打一个及格；程序员不服，告到总经理那里。总经理说：“你知足吧，给你打及格已经看在你干的很辛苦的份上，因为你没有按时完成，整个项目延迟一个月，这帐都没找你算呢。”程序员颓然。

无疑，不在上级面前过多地谈自己的下属，不拿客观事实当挡箭牌，尽可能地“努力表现”是一个成功的职业经理人必备的职业操守。

其中，“不停地辩解”是拒绝承担个人责任的一种表现，“我以为”。 “我以为”也是一个辩解口头语，很多人犯错误以后经常会用这3个字为自己辩解。少讲“我以为”，努力地表现。当错误出现时，及时承认错误，少相互推卸责任，少追究是谁的错，努力解决问题，会大大提高企业的工作效率。 2）吃亏是福 身边一个研发同事在公司中总是在忙，请他帮忙的人多，他又是来者不拒。不论是研发中还是生产线上发生的技术问题，他都会帮着做，他跟大家交流时说，看起来是吃亏了，别人在休息，自己还在做事，但是正是因为做了很多Debug，才积累了很多经验，否则仅知道原理，没有实际经验，设计的产品还是会又很多不符合生产制程的问题。 我在做六希格码项目时，开会我都要求会议的纪录要在会后半天内整理完毕发给相关同事。开始助理对有些技术的内容记不下来，我坚持要她做到。她是做生产工程质量的，这就逼着她要了解相关的软硬件研发质量管理，项目下来，她就成了可独当一面的质量管理工程师。 一般来说，员工总是追求高薪，但有时未见得是好事，因为你拿了高薪，工作的压力也一定更大，而且在其它同等条件下，你的市场竞争力会降低，而且那个高薪，如果是老板为了解决一时之需，那就更不好了。在公司状况不好时，裁员也是被先考虑的。 总的来说年青的时候，多做事，多经历一些磨砺，即使有些不公平，也不要去计较，不是没一次投入都有回报，但你总是在投入，终是有回报的，抱着这样的心态去面对工作，总会收回所有的投入的，这就是上天不负有心人。

3）开放心态 开放心态更多是大家在日常工作中，多与相关部门、领域的朋友交流，很多情况下也许是他人的一句话会让你事半功倍。这也是我提倡的他山之石可以攻玉的理念！

2、做一个合格的项目经理 如何入门：多学多看多交流 任何事情都有它的发展规律，急于求成往往弄巧成拙。项目管理也是这样！ 很多网友初入项目管理，甚至之前没有参与过项目，两眼一摸黑急于上手。于是，在网上或论坛要上来就拜求、跪求项目管理资料，心情可以理解但方式不可取。自己首先需要沉下心来，提问之前先问问自己：我是否仔细翻阅了前人的资料？互联网时代任何信息都可以通过网络来找到，只要你愿意学习，入门资料是很容易获得的。在初步掌握框架理论之后，结合自己的具体项目再去求助。其实，说问具体要远比泛泛要更容易获得帮助。这里举一个不太恰当的例子（批判一下现实社会），人们在遇到困难时通常会大喊“救命”，基本没什么人反应，但试想如果他直接跑向某些具体人抓住他喊“请你救救我”，相信获得帮助机会要大很多，哪怕是碍于面子。最终结果是得到了帮助。 3、做一个优秀的项目经理 1）系统学习：pmp/cmm/iso 2）钻研T/Q/C T市场需要：如何提高开发进度，加大资源投入（自己做、外包）、并行开发、加班、封闭开发提升内部开发效率 项目经理如何争取资源？人力物力财力投入，外包 项目经理如何合理赶工：并行开发、加班、封闭开发 Q如何做 [...]]]> 理论的说，任何角色的转换都要要面临几方面的挑战。
1、能力差异。通常，能力划分为四个等级：初步了解/基本应用/熟练应用/专家应用
2、角色惯性与角色惰性。
3、成就感缺失与定位模糊。
4、不知道付出多大代价。
在中国，技术人员通常会落入技而优则仕的道路，这是现实带给技术人员制定的独木桥。那么对于大多数考拉类型的技术人员，在向项目经理或者部门经理转型时，面临的阵痛则是刻骨铭心的。
从技术人员专向项目经理，要经历自我认知、合格的项目经理、优秀的项目经理三个阶段。然后再向资源型职业经理人转换。
1、认识自我：
1）不要轻易说no。
拒绝承担责任是一个我们易犯的错误。大多数技术人员有一个难以提升的共性问题：习惯性说no，不愿意主动为事情结果负责。这里说的no是泛指，具体地讲就是习惯性“不停地辩解”。“不停地辩解”是一种恶习，但是有这种习惯的却大有人在。是否你也有这样的习惯？找一个人当替罪羊，拉一个人当挡箭牌。如果你经常这样做，试想一下会给人留下什么样的印象？
【举例】
总经理与董事长的对话片断
片断一
董事长：余总经理，你注意一下，我们的钢铁销量最近正在下滑。
总经理：对不起，董事长，这是我的错，我马上召集有关人员调整销售策略。
董事长：西班牙瓦布贝尔家具最近不太好卖，怎么回事儿？
总经理：这也是我失察，我尽快找出解决方案。
董事长：还有，余总经理，你注意一下，听说王厂长最近在闹情绪，想辞职。
总经理：……

片断二
董事长：余总经理，你注意一下，我们的钢铁销量最近正在下滑。
总经理：董事长，这是因为韩国釜山钢铁最近一直在美国不停地杀价，我也没有办法呀！
董事长：西班牙瓦布贝尔家具最近不太好卖，怎么回事儿？
总经理：我以前提醒过您不要进口西班牙大理石的家具。
董事长：还有，余总经理，你注意一下，听说王厂长最近在闹情绪，想辞职。
总经理：我听说那个家伙在外面“包二奶”……

无疑，不在上级面前过多地谈自己的下属，不拿客观事实当挡箭牌，尽可能地“努力表现”是一个成功的职业经理人必备的职业操守。

其中，“不停地辩解”是拒绝承担个人责任的一种表现，“我以为”。
“我以为”也是一个辩解口头语，很多人犯错误以后经常会用这3个字为自己辩解。少讲“我以为”，努力地表现。当错误出现时，及时承认错误，少相互推卸责任，少追究是谁的错，努力解决问题，会大大提高企业的工作效率。

2）吃亏是福
身边一个研发同事在公司中总是在忙，请他帮忙的人多，他又是来者不拒。不论是研发中还是生产线上发生的技术问题，他都会帮着做，他跟大家交流时说，看起来是吃亏了，别人在休息，自己还在做事，但是正是因为做了很多Debug，才积累了很多经验，否则仅知道原理，没有实际经验，设计的产品还是会又很多不符合生产制程的问题。
我在做六希格码项目时，开会我都要求会议的纪录要在会后半天内整理完毕发给相关同事。开始助理对有些技术的内容记不下来，我坚持要她做到。她是做生产工程质量的，这就逼着她要了解相关的软硬件研发质量管理，项目下来，她就成了可独当一面的质量管理工程师。
一般来说，员工总是追求高薪，但有时未见得是好事，因为你拿了高薪，工作的压力也一定更大，而且在其它同等条件下，你的市场竞争力会降低，而且那个高薪，如果是老板为了解决一时之需，那就更不好了。在公司状况不好时，裁员也是被先考虑的。
总的来说年青的时候，多做事，多经历一些磨砺，即使有些不公平，也不要去计较，不是没一次投入都有回报，但你总是在投入，终是有回报的，抱着这样的心态去面对工作，总会收回所有的投入的，这就是上天不负有心人。

3）开放心态
开放心态更多是大家在日常工作中，多与相关部门、领域的朋友交流，很多情况下也许是他人的一句话会让你事半功倍。这也是我提倡的他山之石可以攻玉的理念！

2、做一个合格的项目经理
如何入门：多学多看多交流
任何事情都有它的发展规律，急于求成往往弄巧成拙。项目管理也是这样！
很多网友初入项目管理，甚至之前没有参与过项目，两眼一摸黑急于上手。于是，在网上或论坛要上来就拜求、跪求项目管理资料，心情可以理解但方式不可取。自己首先需要沉下心来，提问之前先问问自己：我是否仔细翻阅了前人的资料？互联网时代任何信息都可以通过网络来找到，只要你愿意学习，入门资料是很容易获得的。在初步掌握框架理论之后，结合自己的具体项目再去求助。其实，说问具体要远比泛泛要更容易获得帮助。这里举一个不太恰当的例子（批判一下现实社会），人们在遇到困难时通常会大喊“救命”，基本没什么人反应，但试想如果他直接跑向某些具体人抓住他喊“请你救救我”，相信获得帮助机会要大很多，哪怕是碍于面子。最终结果是得到了帮助。

3、做一个优秀的项目经理
1）系统学习：pmp/cmm/iso
2）钻研T/Q/C
T市场需要：如何提高开发进度，加大资源投入（自己做、外包）、并行开发、加班、封闭开发提升内部开发效率
项目经理如何争取资源？人力物力财力投入，外包
项目经理如何合理赶工：并行开发、加班、封闭开发
Q如何做
质量是个系统工程，你越重视他，收益越大
C
成本是公司必定考虑的
优秀的项目经理应该有能力让由专家、成手、新人、外部人力组成的团队按时保质完成项目
3）项目流程管理
首先要把流程培训放到项目启动会后的第一个工作。个人经验：在中国，如果想要人重视某项工作或某个流程，那就把它正式化和妖魔化。所谓正式化，就是把它通过正式的会议、邮件、面谈等方式郑重的告知你的团队。人都是有惰性的，特别是技术人员，你不明确他的工作范围做出来的东西一定不是你所想要的。正式的会议等方式，会强化他认识到这件事是重要的。所谓妖魔化，就是充分宣贯它的好处和优势，明确达到和未达到得约束，使大家想到它就联想到好处、激励和惩罚。
这就是所谓中国风文化吧。也就是一开始就把“游戏准则”说清楚。虽然这会使项目经理做更多会前作业，今天的工作不留给明天么。

2. 作为项目组的核心角色指导和领导项目组成员，使他们能迅速的脱离困境

3. 给项目组成员提供更多资源、时间、激励上的支持

4. 和项目组成员，用户/客户，项目上级，其他团队，以及其他项目干系人保持清晰/及时的沟通

5. 及时有效的协调和解决项目的问题和项目组成员之间的矛盾/问题 6. 及时有效的调整计划（比如在范围变更，任务延时，或者资源紧缺等情况），这是节省成本的好途径

7. 在项目整个生命周期中给团队成员的任务提供建议和反馈支持。

8. 理解项目管理既是艺术也是科学，方法、技巧和培训对于运作一个项目是至关重要的；PM过程需要各种指南、标准、模版、规则，所以是科学，PM过程需要指导别人、管理变化、管理心态，甚至在关键时刻（不容许过多考虑，但是必须要下断言）的决策，所以也是艺术。 9. 正式的授权给项目组成员，好让他们能够有效的、无担忧的做一些关键的决定

10.走动式管理，卷起袖子马上干，每天激情投入……直到项目成功结束

　　一切都从“问题”开始

　　我认为一个人在一个职业方向上能走多远，不是取决于我们的宏伟抱负，也不是取决于我们渊博的理论知识，而是取决于你面对问题和解决问题的态度。

　　也许这只是我的个人体会，但自从我认识到这一点以后，我就放弃给自己做职业规划了。我不做职业规划，只会更多的考虑，在我工作的地方，在我工作的范围内，我们面临什么样的问题？我们还有哪些问题没有解决？我们还在哪些地方需要改进？我可以做出什么样的努力？ 　　中国人其实很善于去“发现问题”，过去，老同学坐在一起，就是在讨论我们的国家、我们的某某政府、我们的某某单位甚至某某领导人有这样那样的问题云云，总之，大家都很会“数落”，在“数落”的同时，我们也不会忘记发表自己的“高见”。每每遇到这样的情形，我都会观察，问题的提出者是否会去专心的研究和准备处理这些问题。如果大家只是高谈阔论，发发感慨，我总是选择一言不发，并对被议论的对象报着深刻的同情！这种“同情心”会被人怀疑我的立场！

　　其实，我认为自己并不是要去回避这些问题。只是自己也无法解决的问题，我们在抱怨和高谈阔论之前，更应该多学习和思考而不是飞短流长，包括站在当事者的立场去考虑这些问题。

　　IT也好，ERP也好，我们在一个企业可能遇到的问题其实是最多的。我并不认为所有的人都要抱着文绉绉的态度去研究和思考一番，而是作为一个学习者，问题本身就是最好的老师。与其对问题飞短流长，不如下来好好思考一番，并学习如何去解决。

　　作为IT项目经理，我们可能遇到的问题其实是非常多的。公司业务在不断变化，任何变化都会给IT带来一揽子令人头痛的问题。比如，过去的一个订货系统面向机构订货，你只需要应对几十家分支机构客户；现在公司的业务模式变了，马上要将所有代理商实现集中订货，你的系统一下子增加了上千家客户，系统如何承受这样的压力？公司的组织结构和业务流程的变动更是无时无刻不在考验IT人的智慧！

　　可以这样说，在一个公司里，需要广泛、深入接触各个业务部门的人非IT经理莫属。这是机遇也是挑战，你是只考虑自身的或本部门的利益，还是考虑客户和业务部门的问题将决定你在IT经理的岗位上可以走多远。现在，越来越多的IT经理会毫无疑问的选择后者，这无疑是一种明智的选择。 今天和大家一起讨论第二个主题：作为甲方学习 　　在讨论这个问题之前，先和大家讨论一个问题：IT项目经理属于甲方还是乙方？ 　　在金蝶IT部门，IT项目经理加上部门经理超过10人，每个人都会带一个小团队。IT项目经理有各种各样的背景，有的是从开发岗位提升上来的，有的是需求岗位提升上来的，有的是从实施岗位提升上来的，有的是从网络工程师岗位提升上来的，还有从市场和服务岗位转型而来的。我们发现，一些客户公司的IT部门比我们的项目管理体系甚至要更加完善，甚至整个IT部门都是由一些独当一面的IT项目经理构成的。我认为IT项目经理的能力成熟度可以代表一个公司IT部门的成熟度，所以IT项目经理的沟通能力和学习能力对一个企业的IT战略执行非常关键。 　　现实中，我们的IT项目经理都是非常善于学习的，对于项目任务也是非常负责。但是我发现了一个普遍存在的问题：我们很多项目经理把自己放在了乙方的位置上。 　　这里讲一个最近的故事：上周五，我们EAS协同平台因为一个补丁测试不充分，导致多个流程无法审批，前一天早上我已经发现了这个问题而且反馈给项目组加快重点跟踪。可是周五这个问题却再次重新而且是财务副总裁第一个发现。这个问题发生后，我们同时将问题反馈给了EAS事业部和本部门的项目组。EAS事业部在测试部经理的推动下，派出了支持人员到现场了解原因，测试部经理在问题处理前、处理中、处理后三次打电话给我反馈进展，消除我的担忧，处理完后发邮件给相关人员确认。而我们的项目经理却轻描淡写的说：他发现目前只有一两个核心的问题没有解决。他的答复让我怀疑我是不是用对了人！当然，我们的EAS项目经理也是一个非常有责任心的优秀员工，——一个小时以后，EAS项目经理主动找到我，让我给提出来究竟在哪里方面他还需要改进。为什么同一一个问题，两个团队的响应相差这么远？这不能不让我思考。 　　在这个事件中，我首先发现了IT项目经理和实施人员的不同。我们的实施人员在内心里有非常明确的甲方和乙方之分，即使在公司内部，我们的项目也分为甲方和乙方。EAS项目经理代表的是乙方，我是乙方的总负责人。但我心中的IT项目经理并不是乙方项目经理，我更多的是需要我们的项目经理站在公司业务发展和最终用户体验的角度去评估项目绩效，而不是简单做到让“甲方”业务负责人满意，业务部门和管理层也断然不会认为我是“乙方”代表，在任何时候，我都是“甲方”代表，我的使命就是要为公司的战略提供IT支持，而不是简单的把业务部门当成“乙方”。 　　站在甲方的角度学习，我们会发现，我们要关注的已经不是过去简单的“甲方”代表的满意度，而是甲方所有最终用户的满意度。我们的项目干系人发生了很深层次的变化。以金蝶为例，我们的项目赞助人或需求方往往是业务部门，但是如果仅仅考虑让某一个业务部门满意那就大大错误了！ 　　未从事过IT部门工作，在这方面可能难以体会深刻，但是在进一步讨论前，这是我特别强调的一点。这对我们学习和解决问题的心态有太大的影响，后续再慢慢道来. 　　所以，变化的业务、业务的变化带给IT经理最大的挑战就是：我们如何去学习？ 　　未完待续。 前两篇介绍了（一）一切从问题开始，（二）站在甲方的立场学习。我认为这是我们IT项目经理很重要的两个态度。本篇则从能力上介绍项目经理如何完成职业化转型。

　　项目实践与职业化学习

　　由于IT项目经理的奇缺，我们很多人可能还在没有做好专业知识准备的情况下就开始担任IT项目经理。无论你从事的项目大小，千万别小看了这个机会，这是一个学习和锻炼自己的很好的机会！

　　IT项目经理的职业化学习基本上可以分为专业学习和项目管理知识的学习两个部分。大部分IT项目经理的专业知识比较突出，但管理能力却有不足。在我们这里，有一个课程是绝大部分IT项目经理都一定会学习的，那就是《从专业人员转型为管理人员》，这个课程实际上就是把管理意识深深灌入项目经理的头脑。这门课程的重点不是掌握管理知识，而是通过团队培训和角色模拟，让我们深深发现自己身上的不足，并开始职业项目经理的个人转型。如果这个转型不成功，这样的项目经理的职业生涯是不可能长久的。很多专业人员对做管理没有信心，但是，只要你的悟性高，这门课程往往可以让我们起到茅塞顿开、豁然开朗、信心倍增的效果。

　　不过，这一切只是开始。由于IT项目的专业复杂性、组织复杂性、社会复杂性等等综合因素，你要应对自如，要学习的东西还非常多。知识方面，一个是从专业知识上，你要学习信息系统规划、设计、开发、测试等软件工程相关的知识，学习网络、通讯、安全、存储等相关的技术知识。如果你从事的是企业信息系统的项目管理，可能还需要学习ERP理论及系统实施的方法论知识；其次是从管理上，学习IT项目管理的特定知识。IT项目比建筑等其他专业项目更考验人的地方在于，IT项目是无形产品的交付，在项目目标、交付对象、项目干系人管理、项目范围管理、项目进度管理、项目沟通管理、项目质量管理等方面相对建筑等项目恐怕更加复杂。正是IT项目的特殊性，才使得IT项目管理成为一门独特的专业。在知识方面，目前国内有专业的培训和资格认证，如果我们希望在短时间内获得职业化能力，参加专业的培训应该也是比较好的方法。在部门内部，我们是通过外部培训和内部培训相结合的方式去培训IT项目经理，外部的培训主要以PMI的PMP培训为主，内部培训则是参加过相关外部培训的学员在内部做分享和交流。

　　专业知识和项目管理知识都只是IT项目经理的基础能力，拥有了这些知识，并不表明你就能成为一个好的IT项目经理。我认为，好的项目经理至少需要具有五个条件：

　　（一）、具备强烈的责任感和良好的管理意识； 　　（二）、熟悉综合性的信息系统软硬件知识； 　　（三）、精通IT项目管理知识； 　　（四）、具有３年左右的项目工作实践经验； 　　（五）、具备良好的协调和沟通能力； 　 　　我们在判断一个项目经理是否胜任的时候，并不是看表面的印象，而是以项目绩效和民主评议为前提来甄别的。所以这些条件不是指的你拿了多少国内或国际的证书。项目经理一定是在实践中经过千锤百炼打造出来的。

　　我们也有很多专业人员经历了很多项目，但并没有完成职业化的项目经理的转型，究其原因，我观察有以下几个方面：

　　（一）、对IT项目经理的角色认识不清晰。IT项目经理是要对项目目标负责，对项目干系人的需求实现和最终满意度负责，而且是要在规定的时间和预算的范围内完成这些工作。很多项目经理对这个角色的认识不清晰，往往会从专业人员的角度把项目当成一件事务性的工作去完成，很少考虑项目干系人的真实需求和项目的实际目标。最后项目完工了，发现并不是业务部门和甲方所需要的系统。IT项目经理的角色意识不强，会导致项目缺少起码的日常沟通和管理，大量的工作返工、时间和预算失去控制。试问有多少个企业敢用这样的项目经理呢？ 　　（二）、缺少向实践学习、向同行学习的积极性。在知识社会，绝大部分专业人员都知道学习的重要性。但每个人的学习和思考的习惯、学习和思考的方法却具有非常大的差异。在新知识的学习上，一直有所谓的学院派和实务派之分。解决同样一个问题，因为学院派会穷根究底、理性分析，一个问题解决起来往往费时费力，但问题解决的深度和知识积累的效果会比较好；实务派则更多的懂得借鉴具体的实践经验，快速行动，问题解决的效率高，但容易陷入头痛医头、脚痛医脚的困境。无论是实务派和学院派，如果能够不耻下问，多拜前人为师，我认为都会或多或少的克服自身学习能力方面的不足。否则，仍由个人发挥，很有可能陷入极端。如果自认为掌握了一定的窍门，就不能虚心的向同行和老师学习，个人的成长一定会受到影响。

　　（三）、学习和创新能力参差不齐，项目应变缺少灵活性。毫无疑问，IT项目的业务多样性和快速变化对IT项目经理的创新能力和灵活性是一个很大的考验。在企业的IT部门，没有一个项目经理只做财务或者只做物流，项目临时性决定了我们的项目任务总在不断的变动中，没有任何一个人可以为未来的项目准备好所有的专业知识和最佳实践。所以，在新的项目任务提出来以后，项目经理如何快速学习、如何快速做出创新，这是对项目经理的学习和创新能力的很大的考验。

　　（四）、缺少与个人和组织打交道的热情和能力。实行混合项目制的组织，对同一个项目，往往负责人既有项目经理，也有职能经理。这些组织的项目经理的权力可能会在一定的程度上被削弱，这影响了项目经理与个人和组织打交道的积极性和主动性。这必然给项目的沟通带来很大的风险，项目经理的沟通会更加困难。而从学习来看，沟通和协调能力实际上项目经理最重要的能力。项目经理一定要过好与人打交道的能力。否则，在复杂的项目中，项目的推进力度和推进效果会在很大程度上受到影响。

　　 下一篇会继续从资源的角度，谈IT项目经理学习资源的挖掘与利用。 空间管理 您的位置: ITPUB个人空间 » 王叶忠的IT管理故事 » 日志 IT项目经理如何学习（四）：IT项目经理的个人知识管理 上一篇 / 下一篇 2007-12-13 15:47:40 / 个人分类：IT管理 查看( 81 ) / 评论( 1 ) / 评分( 0 / 0 ) 前一篇文章还是在9月底写的，这一篇用一些零零碎碎的时间写，实在让大家久等。这篇想和大家分享的是作为IT项目经理，如何挖掘和利用IT项目经理所需要的学习资源。

　　IT项目的特点对我们的学习和反应速度提出了很高的要求，主要表现在

　　一、IT项目环境在不断变化，要求IT项目经理不断学习

　　IT项目面对的环境包括企业的组织架构、业务流程、企业组织文化、项目团队文化、信息技术、领导风格等等不同因素。你需要不断学习，因为这些因素都在不断变化，而学习的目的就是适应这些变化。

　　二、IT项目需求的复杂性，要求IT项目经理具有快速学习和创新能力

　　IT项目交付物是无形产品，无论是功能性需求还是技术性需求、易用性需求，影响的因素都非常复杂。你随时都会遇到自己从未思考或学习过的问题。所以，我们总是要考虑如何在最短的时间里，发现最有效的方法和方案。

　　三、IT项目经理的时间都非常紧张，学习必须是高效率的。 　　 　　所以，IT项目经理的学习一定是非常特殊的，否则，很难在有限的时间里完成大型的复杂的项目。 那么什么才是IT项目经理最有效的学习之道呢？ 　　这里给大家分享一些我自己的做法。个人知识管理理论认为，个人知识管理的过程分为四个方面,我们也不妨从这四个方面展开：

　　1、FIND:寻找资源

　　IT项目经理所需要的学习资源有很多分类,我这里以ERP项目为例，每一类里面我只推荐我比较多使用的网站管理学习资源：

　　通用管理理论：（使用频率：非常低）http://www.12manage.com，该网站支持八种语言。 　　阅读过波特、德鲁克、柯普兰等的主要代表作，其他管理理论以MBA教材为主，MBA管理类教材基本都是国外知名大学引进的教材，中文和英文各占一半。对通用管理理论的学习我自认为自己做的是不够的。

　　管理实务： 　　主要以搜索引擎搜索为主，无固定网站，如财务、投资、工厂管理、市场营销、信息管理、项目管理、需求管理、知识管理都是我从事过的具体业务和管理工作，需要的工具以专业书籍和搜索引擎搜索为主，推荐google和xunlei就够。还有一些国内外的数字图书馆，只要有价值我一般自费购买，每年投资在3000元左右；

　　中国管理实践： 　　http://cnc.gemag.com.cn/gemag/new/，中文

　　项目管理动态： 　　http://www.pmi.org，英文，加入PMI国际会员，以阅读pmi发来的一些刊物为主，网站上的比较少；

　　运营管理： 　　http://www.apics.org,英文，加入APICS国际会员，大量的学习资料和互动交流社区；

　　商业案例和管理评论： 　　http://www.businessweek.com（商业周刊，业界最前沿的观点发源地） 　　http://www.nytimes.com（纽约时报，报道非常及时） 　　http://hbswk.hbs.edu/（哈佛商学院的工作知识，每一篇文章的份量都很重）

　　IT学习资源，在IT项目中不同角色需要不同的学习资源

　　技术动态，以IT专家网为主，基本不买书；要买也是买如“世界是平的”，“长尾理论”。如果看书的话，一定会一字不漏全部看完；近期以学习SOA为主。

　　技术学习，以IBM开发者社区为主，关于数据库、编程语言、软件架构及相关技术、软件工程、网络、存储等相关的书都会看一些，尤其是前几年，但学习只求一般理解。技术方面只写过部分规划和分析文档，纸上谈兵罢。

　　产品学习，金蝶自身的产品学习自然具有先天的条件，其他以SAP、oracle开发者社区为主,买的SAP和ORALCE产品和光盘资料也比较多，国内可以买到的国外出版的ERP、工作流、供应链、门户等书籍基本都会买，是专业书籍中看得比较认真的部分

　　特殊的技术和产品学习：参考各厂商的网站为主，微软的网站访问比较多。

　　以上资源，不同的人会有不同的对待方式。重要的其实不在于搜集（collection),而在于发现(find)。同样的资源，不同的人会有不同的发现。我们要更好的发现“宝库”，还需要具备其他一些条件。通俗一点说，你要具备一双善于“发现”的眼睛。只要善于发现，互联网上到处都是金子。

　　2、connect：连接专家

　　connect这个词现在我们应该深有体会，你加入任何一个社会网络或社区，其实你都是在不断的和其他人建立连接。金蝶社区的各位同仁和版主都是我的连接对象，此外，早期，我还会与业内不同网站的创始人和主编经常保持联系。这两年主要是与国外的同行交流多一些。这方面我认为自己做的还很不够，需要多向大家学习。

　　在阅读文章和资料的时候，我有一个习惯，就是会特别留意文章的作者。熟悉这些作者，并尽量和他们保持联系。这两天见到蔡颖老师，蔡老师说他还记得04年我就与他联系过，我很感动他还记得我。国内确实有一大批优秀的专家，与专家交流，是人生的一大快事！不过，与专家交流，是如何让专家了解你，找到双方沟通的桥梁。如果我们不象专家一样思考，很难与专家保持真正的长久沟通。

　　现在已经有了一些网站专门帮助你建立与各类专家的联系，这些网站现在称为社会网络（Social Network）。现在建立社会网络有很多的选择，金蝶社区目前也在进行社会化改造；金蝶友商网甚至干脆将自己的社区称为商务和管理的社会化网络。金蝶以外，畅想网是一个不错的平台。

　　我也使用社会化网络，每天至少会有半小时与我的专家网络联系。国内的以金蝶网站为主，国外的以facebook等网站为主。关于社会化网络，后期我可能会有更多的日志和大家分享。我们自己的金蝶社区将在明年年初的时候初步完成社会化网络改造。 　　3、learn：系统学习

　　互联网的丰富资源可以扩充我们的视野，为学习提供一些参考资料。但我认为真正的学习还是要专下心来，对重点知识领域一个一个的去攻破。作为IT项目经理，特别需要啃下一些基本的IT技术和项目管理的基本专业知识，包括技术方面的管理信息系统（ERP理论）、决策支持系统（商业智能）、软件工程方法（需求管理、分析与设计、软件过程控制、软件测试）、服务器与网络、数据库、分布式计算、SOA、web2.0及其他相关的技术知识；业务方面的会计学、财务管理、供应链管理、运营管理、组织管理、流程管理、项目管理、质量管理、知识管理。现在很多计算机专业的学生可能在大学阶段都或多或少接触过一些这些知识，但是有了一定的实际工作经验后，你可以发现情况又会很不一样。

　　在个人知识管理的四个环节中，Learn这个环节无疑是最考验个人的智慧、学习能力和学习意志的。可能大家已经听过很多次，不过，我还是想重点强调一次：这些学习，宜直接选择国外的教材。这是我二十几年的学习和阅读经历证明了的。以上这些知识模块，我大概只有在ERP理论这一部分学习过陈启申教授的那两本书，其他都是选择国外教材。 　　在国外有一些电子书网站可以下载到上面提到的大多数的专业领域的教材，

　　4、explore:探石问路

　　会学习的人总是会带着问题去学习，勤问、勤记永远是学习的最佳法宝。很多人利用互联网都是从在网上发帖子、问问题开始的。当然，你能够得到什么样的解答，取决于你选择的交流平台。我很久没有在社区问过问题了。因为如果有问题的话，我会首先问公司内部的专家，其次是用搜索引擎再其次就是找专家社交圈（social network)的人。令我感动的是，在专家网络中，大多数专家在接到邮件和问题后都能给出非常满意的答复。我相信建立自己的专家网络对个人学习是非常重要的。

你被指派负责一项具高度挑战的项目，可能是负责一宗购并案、推出新产品，或执行新的绩效评估系统等。不论你负责的是哪一类项目，都得在有限的时间与预算下，扛起为企业节省成本、创造利润的目标。

然而，身为一名项目经理人，过去你可能没有任何类似的经验，而你的专业知识也与所负责的项目相去甚远。在这样的情况下，你如何成功推动项目？

在《项目管理ΜＢＡ》（The Project Managers MBA）一书中，作者科汉（Dennis J. Cohen）与葛拉汉（Robert J. Graham）指出，成功的项目经理人需要具备几项重要的知识与技能，其中包含了解企业策略、如何提升项目成效、了解顾客等；另外，项目经理应将项目视为一个新创事业，将自己的角色转换成一名创业家，了解企业如何为股东、顾客与企业本身创造价值。 首先，在推动项目之前，项目经理必须先了解企业策略，让项目和企业策略结合。

企业策略如同方向盘，让项目的推行有焦点，不致偏离轨道。举例来说，如果企业的策略着重在强化产品龙头地位，新产品研发的项目就不会把焦点集中于顾客服务，而会把目标放在产品的创新与速度上。如果项目经理人不了解企业策略，很容易就会将项目导入与企业策略相反的方向，最后徒劳无功。

企业策略大致有三类：建立顾客亲密关系、卓越营运，与产品领导。企业应特别强化其中一类，但是在其余两类也要达到产业一般水准。例如，以卓越营运为企业目标的企业，讲求的是效率与数量。麦当劳就是其中的范例。全球麦当劳几乎都一模一样，顾客不论走到哪里，都可以有相同的期待；着重于产品领导的企业，它的目标顾客则是创新的拥护者，因此他们会要求，产品要最好、最新的。当项目经理人清楚公司的策略，在推动项目的过程才不会偏离轨道，追求和公司不一样的方向，导致事倍功半。

其次，如何提升项目的成效？在回答这个问题之前，先要从评估的标准着手。一般而言，项目成效评估的重点有三：项目推行的速度、品质，以及它所产生的价值。

通常，一个项目从概念形成到项目结束，称为项目循环时间（project cycle time），这个时间愈短，企业就愈快享有项目产生的价值，投资也愈快得到回收。因此，缩短项目循环时间，可以为企业增加现金流量、减少项目投资，同时增加经济价值。然而，如何在控制成本的同时，又兼顾品质及缩短项目循环时间？以下有六个原则可供参考： 一、 选派训练有素的项目经理人。

[...]]]> 你受指派负责一个项目，过去你没有这样的经验，你的专业知识也和项目内容没有太大的关系。究竟如何才能确保这个项目成功推动？

你被指派负责一项具高度挑战的项目，可能是负责一宗购并案、推出新产品，或执行新的绩效评估系统等。不论你负责的是哪一类项目，都得在有限的时间与预算下，扛起为企业节省成本、创造利润的目标。

然而，身为一名项目经理人，过去你可能没有任何类似的经验，而你的专业知识也与所负责的项目相去甚远。在这样的情况下，你如何成功推动项目？

在《项目管理ΜＢＡ》（The Project Managers MBA）一书中，作者科汉（Dennis J. Cohen）与葛拉汉（Robert J. Graham）指出，成功的项目经理人需要具备几项重要的知识与技能，其中包含了解企业策略、如何提升项目成效、了解顾客等；另外，项目经理应将项目视为一个新创事业，将自己的角色转换成一名创业家，了解企业如何为股东、顾客与企业本身创造价值。

首先，在推动项目之前，项目经理必须先了解企业策略，让项目和企业策略结合。

企业策略如同方向盘，让项目的推行有焦点，不致偏离轨道。举例来说，如果企业的策略着重在强化产品龙头地位，新产品研发的项目就不会把焦点集中于顾客服务，而会把目标放在产品的创新与速度上。如果项目经理人不了解企业策略，很容易就会将项目导入与企业策略相反的方向，最后徒劳无功。

企业策略大致有三类：建立顾客亲密关系、卓越营运，与产品领导。企业应特别强化其中一类，但是在其余两类也要达到产业一般水准。例如，以卓越营运为企业目标的企业，讲求的是效率与数量。麦当劳就是其中的范例。全球麦当劳几乎都一模一样，顾客不论走到哪里，都可以有相同的期待；着重于产品领导的企业，它的目标顾客则是创新的拥护者，因此他们会要求，产品要最好、最新的。当项目经理人清楚公司的策略，在推动项目的过程才不会偏离轨道，追求和公司不一样的方向，导致事倍功半。

其次，如何提升项目的成效？在回答这个问题之前，先要从评估的标准着手。一般而言，项目成效评估的重点有三：项目推行的速度、品质，以及它所产生的价值。

通常，一个项目从概念形成到项目结束，称为项目循环时间（project cycle time），这个时间愈短，企业就愈快享有项目产生的价值，投资也愈快得到回收。因此，缩短项目循环时间，可以为企业增加现金流量、减少项目投资，同时增加经济价值。然而，如何在控制成本的同时，又兼顾品质及缩短项目循环时间？以下有六个原则可供参考：

一、 选派训练有素的项目经理人。

选择项目经理人时，不可以因为他是技术背景出身，就委派他为项目经理人。项目经理人必须充满热忱，受过训练，因为他要为项目成败负责。

二、 迅速建立标准程序。

建立项目标准程序的速度要快，但不需要完善。不完善的标准程序可以让问题凸显出来，进而加速形成解决问题的方案。

三、 组织核心团队。

项目团队应该由跨部门的人员组成。由于团队成员来自不同的部门，因此当问题发生时，可以获得不同部门的意见和奥援，有效解决问题。同时应该注意的是，项目成员还应该包含终端使用者或顾客。核心成员必须有始有终地参与。

四、 确保团队成员全职负责项目。

为了加速项目的完成，团队成员应该一次只负责一项项目，避免同时负责多项项目，削弱力量。

五、 团队成员最好避免分处各地。

团队成员应该在同一个区域工作，彼此的沟通协调较容易。

六、 高阶主管的支持。

项目失败通常是因为高阶主管没有参与。项目一旦开始推行，高阶主管负有全程参与的责任。

此外，在必要的时候，为了准时达成项目目标，企业应增加额外投资。麦肯锡顾问公司曾经分析，推出新产品时，如果项目时间拖延相当于产品生命周期百分之十，潜在利润的损失可能就高达三○％；但是，若项目超出百分之五十的预算，产品能准时上市，则潜在利润的损失可能只有三％。

另外，在推动项目的过程中，必须时时刻刻谨记顾客的需求。举例来说，新产品研发的项目是为了满足外在顾客的需求；但某些科技项目的推行，则是为了提升内部员工的工作效率。不论项目对内或对外，项目经理人都得先了解目标顾客是谁，他们有什么需求，才可能达成项目的成效。

然而在了解顾客之前，先得掌握市场趋势。很多项目经理人都有一个错误的认知，认为「新品一推出，就会有人买。」事实证明，这是错误的观念。摩托罗拉的铱计划就是典型的例子，这项透过卫星提供通讯的服务，最后证明没有市场。为了避免类似事件的发生，项目团队必需纳入行销人员，以便掌握市场。

此外，项目经理人必须区分顾客及使用者的个别需求。所谓顾客，是指实际付钱购物的人，使用者则是实际从商品受惠的人。举例来说，母亲为婴儿购买浓缩汤，则母亲是顾客，婴儿是使用者。因此，使用者会直接影响产品的销售.

二、人员配置 在整个项目的生命周期中，可能涉及到开发方的角色如下： 1、需求分析师 完成产品或项目的需求调研和开发，将客户的需求变成产品需求，参与需求的讨论和分析，完成需求规格说明书等的编写。 2、系统架构师 系统架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，他侧重于系统的质量属性设计，包括系统的可靠性、可测试性、可重用性、可维护性、可重用性、可扩展性、性能指标、组件框架设计、共用基础结构等。 3、系统分析员 该角色是系统设计中的一个主要角色，他参与需求分析、系统功能设计、系统质量属性设计等过程。 4、项目经理 项目经理是项目沟通的纽带，他执行项目的进度跟踪、质量管理、客户非技术人员业务交流、项目成员共同、非技术风险管理等职责。 5、配置管理员 该角色的职责是完成项目中各文档的管理等。 6、QA 重点关注软件过程的质量，在项目中，主要执行的是监督的作用，他参与需求评审、设计评审等过程。 7、开发人员 完成系统的编码，在有些公司，开发人员还需要进行部分功能模块的设计。 8、测试人员 进行系统的测试，例如功能测试、集成测试、系统测试和验收测试等，在测试前期，需要编写测试计划，并编写测试用例来辅助测试。 9、美工 负责美化系统界面。 10、项目实施人员 职责为进行项目的实施。 根据项目的大小等的不同，上面的人员配置可能有一些合并，例如在一些较小的项目中，可能会将系统架构师、系统分析师、项目经理的职责都统一到项目经理身上。在一些项目中，若具有系统架构师、系统分析师和项目经理三个角色，有一些人也很容易搞混，在网上有人进行了比较明确的区分，下面让我们来看看下面的表格： 三、项目管理中需要注意的问题 大家都知道，项目管理的四要素为：质量、进度、成本和资源。这四项如果有一项超出控制，项目就可能会失败。在笔者的实践过程中，总结了如下注意事项： 1、明确各人员的任务 明确各人员的任务并对其进行确认。例如，对各开发人员任务的详细分配后，有些开发人员并不一定清楚了自己所要做的事或理解有出入，做到后来，才发现所做的和项目所需要的南辕北辙，到了这个时候才发现问题，补救不及时的话很可能引起进度的拖延和成本的增加，所以项目经理需要进行确认。 2、跟踪项目情况 很多开发人员都有这样的情况，前期开发比较轻松，一到要验收的时候，才发现很多功能还不完善，存在很多bug，于是为了在指定时间内完成任务，只得加班加点。其实这也是管理不善引起的，因为没有定期的跟踪项目，对项目所处的状态不太清楚，所以导致了这种情况。 3、进行风险分析和管理 在项目管理过程中，风险分析也是一个很重要的方面，风险包括很多方面，例如技术风险、人员风险等。若在项目管理不注意风险的管理，那么当项目中的风险发生时，很可能引起项目管理的四要素的问题出现。例如若项目组盲目引入新技术，在中后期才发现该新技术在该系统中不合适。再例如，若在项目后期主要设计或开发人员跳槽，若没有风险管理，没有采取规避或减弱措施，那么当这些风险产生时，将会带来很大的影响。 4、重视需求开发 有些项目组对需求开发不太重视，做需求开发时没有深度挖掘客户的需求，在中后期还在进行需求的大幅调整，在进度等方面当然也会受到很大的影响。需求是后续开发的根本，后续的设计、开发、测试等都是基于它的，因而也是重中之重，需要引起大家的重视。 [...]]]> 笔者涉足项目管理已有一段时间，而且通过CMMI培训和实践，笔者对项目管理中的需求获取、人员配置以及项目管理中需要注意的问题有一些想法，在此与大家共享之。
一． 需求获取
需求开发在CMMI中有一个专门的过程域来描述，它在项目管理过程中也是很重要的一块，因为后续的设计、开发等都是基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来的话，那么在后期选择弥补时，将会造成项目延期以及成本的大幅度增加。
需求开发的目的是产生和分析客户、产品和产品组件需求。需求是客户在项目立项时就有的一个远景，在项目管理过程中它得到不断的变更和细化。客户根据需求会决定在整个项目的需求中，要承办方具体要做些什么，即承办方的任务， 承办方具体要实现哪些需求。 承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。
需求获取的目的是通过各种途径获取用户的需求信息，由于在实际工作中，大部分客户是无法完整地讲述其需求，因此需求获取是一件看似简单，做起来很难的一件事情。在需求获取过程中，主要需要弄清楚3个问题，即：明确需要获取的信息（What）、明确所获取信息的来源和渠道（Where）和怎样获取需求（How）。下面我们分别对这三点进行讲述。

1、明确需要获取的信息（What）
需求分析师应在需求获取前明确需要获取的信息，以确保在实施需求获取时有的放矢。
通常需求获取要获取的信息包括三大类：
1）与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；
2）与要求解决的问题直接相关的信息；
3）用户对系统的特别期望与施加的任何约束信息。
2、明确所获取信息的来源和渠道（Where）
接着需求分析师还应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。
需求信息的来源通常包括：
1）来自客户的需求：
a) 旧系统的用户或客户对系统安装、使用、维护、管理等方面的需求；
b) 系统的潜在用户或客户对系统的需求。
2）竞争对手的产品优势与不足；
3）国家政策、业务规则以及相关行业标准；
4）实施产品设计所需满足的需求；
5）执行测试验证工作所需满足的需求；
6）实施系统安装、维护所需满足的需求。
获取需求信息的渠道包括：
1）用户或客户；
2）公司研发管理部门；
3）公司技术管理部门
4）项目实施部门；
5）营销管理部门；
6）旧有系统的研发项目组；
7） 来自项目组内。
3、怎样获取需求（How）
接下来项目经理应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：
１） 用户访谈
用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。
用户访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难，例如客户经常很忙，难以获得充足的访谈时间；客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识。
２） 用户调查
用户调查是通过精心设计提问问题形成调查问卷，然后下发到相关人员手中，让他们填写答案，来获取用户需求。
用户调查的方法最大的缺点是缺乏灵活性，由于缺乏面多面的交流，所获取的信息量也比较有限。因此在实际工作中，我们建议可以先采用用户调查的方式获取一定量的信息，然后有针对性地开展用户访谈。
３） 现场观摩用户的工作流程，观察用户的实际操作
俗话说，“百闻不如一见”，对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。
４） 从行业标准、规则中提取需求
如果用户要求所开发的软件产品必须满足一定的行业标准和业务规则，需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。
这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向，这对从技术出生的需求分析师来说是一个巨大的考验。

５） 文档考古
对于一些数据流比较复杂的、工作表单较多的项目，有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究，考古一词非常形象地说明了其主要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告，获得所需的信息。
６） 需求讨论会
这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表，分析人员，开发人员，通过有组织的会议来讨论需求。
在会议之前，应该将与讨论主体相关的材料提前分发给所有将要参加会议的人。在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。
７） 原型法
原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
原型法的优点是：
i）鼓励业务管理者的积极参与；
ii）有助于解决业务管理者之间的差异；
iii）能给业务管理者一个对最终系统的直观感受；４）周期短；５）成本低；６）用户较满意。
但原型法也有缺点，主要为：
i）导致人们认为最终系统将很快产生；
ii）对系统操作权限的说明较弱；
iii）不适合于开发大系统；
iv）开发过程管理困难。
在实际开发过程中，笔者所在公司一般比较常用的需求获取方法是用户访谈、需求讨论会和原型法。对于相对较小的项目，笔者极力推荐原型法，因为通过可视化的界面，可更容易的、更快的挖掘客户的需求。

二、人员配置
在整个项目的生命周期中，可能涉及到开发方的角色如下：
1、需求分析师
完成产品或项目的需求调研和开发，将客户的需求变成产品需求，参与需求的讨论和分析，完成需求规格说明书等的编写。
2、系统架构师
系统架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。这典型的包括识别和文档化系统的重要架构方面，他侧重于系统的质量属性设计，包括系统的可靠性、可测试性、可重用性、可维护性、可重用性、可扩展性、性能指标、组件框架设计、共用基础结构等。
3、系统分析员
该角色是系统设计中的一个主要角色，他参与需求分析、系统功能设计、系统质量属性设计等过程。
4、项目经理
项目经理是项目沟通的纽带，他执行项目的进度跟踪、质量管理、客户非技术人员业务交流、项目成员共同、非技术风险管理等职责。
5、配置管理员
该角色的职责是完成项目中各文档的管理等。
6、QA
重点关注软件过程的质量，在项目中，主要执行的是监督的作用，他参与需求评审、设计评审等过程。
7、开发人员
完成系统的编码，在有些公司，开发人员还需要进行部分功能模块的设计。
8、测试人员
进行系统的测试，例如功能测试、集成测试、系统测试和验收测试等，在测试前期，需要编写测试计划，并编写测试用例来辅助测试。
9、美工
负责美化系统界面。
10、项目实施人员
职责为进行项目的实施。
根据项目的大小等的不同，上面的人员配置可能有一些合并，例如在一些较小的项目中，可能会将系统架构师、系统分析师、项目经理的职责都统一到项目经理身上。在一些项目中，若具有系统架构师、系统分析师和项目经理三个角色，有一些人也很容易搞混，在网上有人进行了比较明确的区分，下面让我们来看看下面的表格：

三、项目管理中需要注意的问题
大家都知道，项目管理的四要素为：质量、进度、成本和资源。这四项如果有一项超出控制，项目就可能会失败。在笔者的实践过程中，总结了如下注意事项：
1、明确各人员的任务
明确各人员的任务并对其进行确认。例如，对各开发人员任务的详细分配后，有些开发人员并不一定清楚了自己所要做的事或理解有出入，做到后来，才发现所做的和项目所需要的南辕北辙，到了这个时候才发现问题，补救不及时的话很可能引起进度的拖延和成本的增加，所以项目经理需要进行确认。
2、跟踪项目情况
很多开发人员都有这样的情况，前期开发比较轻松，一到要验收的时候，才发现很多功能还不完善，存在很多bug，于是为了在指定时间内完成任务，只得加班加点。其实这也是管理不善引起的，因为没有定期的跟踪项目，对项目所处的状态不太清楚，所以导致了这种情况。
3、进行风险分析和管理
在项目管理过程中，风险分析也是一个很重要的方面，风险包括很多方面，例如技术风险、人员风险等。若在项目管理不注意风险的管理，那么当项目中的风险发生时，很可能引起项目管理的四要素的问题出现。例如若项目组盲目引入新技术，在中后期才发现该新技术在该系统中不合适。再例如，若在项目后期主要设计或开发人员跳槽，若没有风险管理，没有采取规避或减弱措施，那么当这些风险产生时，将会带来很大的影响。
4、重视需求开发
有些项目组对需求开发不太重视，做需求开发时没有深度挖掘客户的需求，在中后期还在进行需求的大幅调整，在进度等方面当然也会受到很大的影响。需求是后续开发的根本，后续的设计、开发、测试等都是基于它的，因而也是重中之重，需要引起大家的重视。
本文浅析了项目管理过程中需求开发、人员配置以及项目中需要注意的问题，项目管理是一个很复杂的过程，需要项目组各成员的努力。

　　本文对上表的数字作了部分调整。主在维护阶段剔除了完善性维护成本。这一项成本不应列入委托评估系 统软件的本次价值评估。这样，开发、维护成本在整个生命周期中的份额也相应发生了变化。

　　一、系统软件的成本构成

　　系统软件的成本作为一个经济学范畴，应反映软件产品在其生产过程中所耗费的各项费用，为原材料、燃料、动力、折旧、人工费、管理费用、财务费用待项开支的总和。

　　从财务角度来看，列入系统软件的成本有如下的项目：

　　（1）硬件购置费如计算机及相关设备的购置，不 间断电源、空调器等的购置费。

　　（2）软件购置费，如操作系统软件、数据库系统软件和其它应用软件的购 置费。

　　（3）人工费，主要是开发人员、操作人员、管理人员、的工资福利费等。

　　（4）培训费。

　　（5）通讯费，如 购置计算机网络设备、通讯线路器材、租用公用通讯线路等的费用。

　　（6）基本建设费，如新建、扩建机房、购置计算机机台、机柜等的费用。 　　（7）财务费用。

　　（8）管理费用，如办公费、差旅费、会议费、交通费。

　　（9）材料费，如打印纸、包带、磁盘等的购置费。

　　（10）水、电、汽、气费。

　　（11）专有技术购置费。

　　（12）其它费用，如资料费、固定资产折旧费及咨询费。

　　从系统软件生命周期构成的两阶段即开发阶段和维护阶段看，系统软件的成本由开发成本和维护成本构成。其中开发成本由软件开发成本、硬件成本和其他成本组成，包括了系统软件的分析/设计费用（含系统调研、需求分析、系统分析）、实施费用（含编程/测试、硬件购买与安装、系统软件购置、数据收集、人员培训）及系统切换等方面的费用；维护成本由运行费用（含人工费、材料费、固定资产折旧费、专有技术及技术资料购置费）、管理费（含审计费、系统服务费、行政管理费）及维护费（含纠错性维护费用及适应性维护费用）。

　　二、系统软件的成本测算程序

　　1、根据待开发软件的特征、所选用硬件的特征、用户环境特征及以往同类或相近项目的基础数据，进行软件规模测算。

　　2、由系统软件的成本构成，结合成本影响因素、环境因素以及以往同类或相近项目数据分析，进行软件 成本测算。其中包括了安装、调试的人力和时间表、培训阶段的人力和时间表。

　　3、系统软件成本测算的风险分析。这是基于系统软件成本测算的不确定性、成本测算的理论和测算技术 的不成熟性而提出的工作程序。系统软件成本测算的风险因素应包括： 　　（1）对目标系统的功能需要、开 发队伍、开发环境等情况的了解的正确性；

　　（2）所运用历史数据及模型参数的可靠性；

　　（3）系统分析 中的逻辑模型的抽象程度、业务处理流程的复杂程度及软件的可度量程度；

　　（4）软件新技术、替代技术的出现和应用对成本测算方法的冲击的影响；（5）用户在系统软件开发中的参 与程度，开发队伍的素质及所采用开发模式对开发成本的影响；

　　（6）对系统软件开发队伍复杂因素认识程度；

　　（7）系统软件开发人员及其组成比便的稳定性；

　　（8）系统软件开发和维护经费，时间要求等方面的变更等非技术性因素所带来的风险等。

　　在系统软件价值评估中实施上述程序进行成本测算时，除了应坚持持资产评估操作程序中规定的各项原 则外，还应遵循真实性与预见性原则、透明性与适应性原则和可操作性与规定性原则。 　三、系统软件成测算

　　综上所述，系统软件的成本由软件的开发和维护成本所构成，即： C=C1+C2 （1）

式中：C为系统软件的开发成本；C1为系统软件的开发成本所构成；C2为系统软件的维护成本。

　　1、系统软件的开发成本C1的测算。

　　我们认为系统软件的开发成本按其工作量及单位工作量成本来测算是可行的，具体测算方法为按系统软 件的软件规模（一般为软件源程序的指令行数，不包括注释行）、社会平均规模指数以及工作量修正因素来 进行。尤其是CAD系统软件的实际测算，结合国内外研究成果的综合分析和专家咨询，软件社会平均生产率 参数和软件社会平均规模指数可分别确定为3.5和1.3左右；软件工作量订由八个因子、五个等级组成。

　　2、系统软件维护成本C2的测算。

　　系统软件的维护为修正现有可运行软件并维护欺其主要功能不变的过程。系统软件在其交付使用后，其维护阶段在软件生命周期或生存期中占较大比重，有的可达软件生存周期的50-70%。因此，系统软件的维护成本是软件成本测算中不可忽略的一部分。

　　系统软件的维护包括三类：A、改正、纠正性维护；B、适应性维护；C、完美性维护。其中C类是为扩充 功能、提高性能而进行的维护，在软件资产价值评估中一般不计入该系统软件成本，而A、B两类，则与软 件的开发过程有着紧密的联系，应计入软件成本。

　　在系统软件维护阶段，对软件工作量的影响因素与开发阶段的影响因素基本相同，是开发阶段影响因素 的后的影响。因此，系统维护的可靠性越大，规模越复杂，隐错越难发现，纠错越难。系统软件越复杂， 要使其适应软、硬环境变化，进行适应性维护也越困难。当然，可靠性大、复杂度高的系统软件，其可维 护性要求也越高，软件在运行中出错的可能性也会少些。基于上述分析，系统软件维护成本的测算，可按 系统软件开发成本乘以一个该系统软件的维护参数来求取。这一维护参数，可按系统软件的复杂度从简单 到一般、到复杂的顺序，分别取0.15、0.20、0.25及0.30、0.35、0.40等。

　　计算机系统软件作为计算机系统的组成部分，是信息社会的重要商品，也是知识经济社会中的重要资产。 系统软件同其他计算机软件一样，具有如下的特点： 　　1、系统软件是由许多人共同完成的高强度智力劳动的结晶，是建立在知识、经验和智慧基础上的具有独 创性的产物。系统软件的开发可以工程化，软件生产可以工厂化，因此，系统软件具有价值和使用价值。 同时，系统软件具有独创性（即原始性），所以软件著作权人对系统软件产品依法享有发表权、开发者身份权、使用权、许可权、获取报酬权及转让权。

　　2、系统软件产品是无形的，存在于磁盘等介质的有形载体中，通过载体进行交易。因此，带有系统 软件的磁盘交换价值，是磁盘自声价值与系统软件之和，而且主要是系统软件的价值。

　　3、系统软件产品的复制（批量生产）相应简单，其复制成本同其开发成本比较，几乎可以忽略不 计。因此，系统软件产品易被复制乃至剽窃。为保护系统软件产品的著作权，必须依法登记。

　　4、系统软件产品一般没有有形损耗，仅有无形损耗。系统软件产品的维护，一是由于系统软件自身 的复杂性，特别是为了对运行中新发现的隐错进行改正性维护；二是由于系统软件对其硬、软件环境有依赖性。硬、软环境改变时，系统软件要进行适应性维护；三是由于需求的变化，要求增强系统软件功能和提高系统软件性能，系统软件要进行完美性维护。因此，系统软件的维护在其生命周期中占有重要地位。同时，系统软件的维护过程是一个软件价值的增值过程。由上述测算方法可知，系统软件的维护费用，即使不计入完善性维护费用也已相当昂贵。不断的升级的新版本代替旧版本软件也是系统软件价值评估中应予考虑的一个特点。

为什么要对项目进行估算

对于庞大的、多变的软件项目来说有着太多的不确定性。之所以要先制定项目计划，目的就是为了让项目更加可控。如果项目的计划缺乏数据进行支持，或者根本不进行估算，只凭项目管理人员的经验进行管理，那么项目最终就会变成软件项目常见的“三拍”现象：“首先公司领导拍拍某个项目经理的脑袋，说你来负责这个项目；项目经理拍拍胸脯说没问题；最后项目失败的时候项目经理就只能拍拍屁股走人”。

当然，这只是个玩笑。不过由此可见项目估算是项目管理人员深入了解项目的第一步，做到“知己知彼，才能百战不殆”。

常用的软件估算方法

软件可以通过主观和客观两种方法对其进行估算。 主观的估算方法可以通过召集项目团队成员，或者邀请各方面的专家，共同对某个项目的属性进行评估。参与评估的每个人都要单独进行估算，如果发现大家对某个项目属性估算的结果存在较大偏差，那么就需要做进一步的讨论，直到取得共识为止。对个别特殊属性进行主观估算时，一定要有直接干系人的参与，例如：对某个文档工作量进行估算时，最好该文档的负责人参与估算，因为他才是最终的执行人。

客观的估算方法是利用公司提供的各种度量数据进行估算，例如：组织级的生产率，或者其他项目的度量数据。本文主要讲解项目管理人员如何通过客观的方法对项目进行估算。

项目的哪些属性可以进行估算

软件项目的属性有很多，建议至少以下属性要在项目计划时对其进行估算：

1、 项目规模 2、 项目工作量 3、 项目所需资源 4、 项目各阶段工作量 5、 项目成本

> 如何对项目规模进行估算

对项目规模进行估算是为了将项目的范围进行量化，项目规模的估算是整个软件估算中最核心、最基础的环节，也是整个估算的第一步。

软件项目的规模可以使用功能点估算法和代码行估算法两种方式，但是作为项目初期阶段，建议使用功能点法进行估算会比较合理。具体的功能点估算方法可以参考我之前在ITPUB上发表的相关文章。

> 如何对项目工作量进行估算

在项目规模的基础上，可以利用组织级生产率得到项目总的工作量。例如：一个公司组织级生产率如下图所示，在2008年中期时，该组织每开发一个功能点需要花费1.5个人/天的工作量。假如该公司某项目有200个功能点，那么该项目的工作量就可以通过以下公式计算出来： 项目工作量= 200 * 1.5 = 300 人/天

> 如何对项目所需资源、各阶段工作量进行估算

对这些项目属性进行估算的主要方法是通过与组织级度量库中的历史数据进行对比，找到相同规模的历史项目，参考其数据，根据本项目的特点对相关属性进行估算。假如本项目与公司之前的某项目A规模大体相当，项目A历史数据如表1和表2所示：

表1-项目A使用资源数人力资源估算 设计人员 2人 需求人员 1人 开发人员 4人 测试人员 3人

表2-项目A生命周期各阶段工作量分布瀑布模型生命周期各阶段 立项阶段 2.00% 需求阶段 5.00% 计划阶段 6.00% 设计阶段 22.00% 开发阶段 22.00% 系统测试阶段 25.00% 用户验收阶段 11.00% 结项阶段 7.00%

两个项目的规模相当，这是我们进行估算的依据，根据之前对项目总工作量的估算（300人/天），那么就可以得到本项目各个阶段的工作量分布，如表3所示：

表3-本项目各生命周期工作量分布瀑布模型生命周期各阶段 人/天 立项阶段 2.00% 6 需求阶段 5.00% 15 计划阶段 6.00% 18 设计阶段 22.00% 66 开发阶段 22.00% 66 系统测试阶段 25.00% 75 用户验收阶段 11.00% 33 结项阶段 7.00% 21

> 如何对项目工期进行估算

假设本项目采用瀑布式的开发模型，并且所需资源与组织级度量库中的历史项目A相同，根据表3对各个生命周期阶段工作量的估算，以及表1对各种资源的估算，那么通过表4的计算就可以得到完成本项目所需要的时间。

假如每月按照21个工作日进行计算，那么本项目估计5.82个月后可以结束。

表4-对项目周期的估算生命周期各阶段生命周期各阶段 工时数人/天 参与角色 参与人数 天数 立项阶段 6 PM 1 6 需求阶段 15 需求人员 1 15 计划阶段 18 PM 1 18 设计阶段 66 设计人员 2 33 开发阶段 66 开发人员 4 16.5 系统测试阶段 75 测试人员 3 25 用户验收阶段 33 测试人员、需求人员、PM 5 6.6 结项阶段 21 全体成员 10 2.1 项目周期（天） 122.2

如何估算项目的成本

假如本项目所使用的资源与项目A相同，那么就可以参考组织度量库中2008年各种资源的平均成本，如下图所示：

经过对项目周期的估算，可以得知本项目大概需要5.82个月的时间。基于以上数据就可以通过表5来对项目的成本进行估算，其结果如下所示：

表5-本项目成本估算工种 人数 参考数据（元/月） 估算成本 设计人员 2 8000 16000 需求人员 1 5000 5000 开发人员 4 6000 24000 测试人员 3 4500 13500 项目经理 1 9000 9000 每月成本（元） 67500 项目为期5.82个月，总成本（元） 39，2850

至此，对项目的规模、成本、工作量、资源和工期的估算方法和顺序就介绍完了，通过本文的介绍，希望广大项目管理人员可以掌握项目估算的技巧。对于使用客观方法进行估算时，组织级的度量数据是关键核心点。另外，软件项目始终伴随着各种各样的变更，这正所谓“变化是永恒的，不变是短暂的”。 作为一个成熟的项目管理者应该勇于面对变化，在每次重大变化后对项目进行重新估算是十分必要的。

    1． 在正常的时间里完成自己的工作 

    加班预示着你无法合理的安排自己的工作，造成上班的时候都比较散漫，效率很低；工作中处理的都是一些小事。把大部分工作都安排在自己手中，也不利于自己良好的分配权利。很好的工作习惯将会使你的工作变得十分顺利，并能很好的将它们完成。工作习惯将决定了你在各种事情面前都将有一个先后顺序。你将一定会关注你的家庭生活，社会生活和个人生活，那么你将一个快乐的人，而你的快乐势必将带动你的同事将一起快乐，工作便将完好的完成。请记住：“如果希特勒不是成天想着我要征服世界，那么他早就征服世界了”。也就是说一个人一生不能只在一件事情上有专长，那样将太少了。 

    2． 构建自己理想的工作环境 

    对于“什么是一个理想的环境”有许多观点，最重要的是它能使你的工作变得轻松。  

    3． 适当得给予荣誉 

    ① 在一个产品中让每个成员都有荣誉感，要将他们得名字公布于众。 

    ② 学会在公共场合适时的表扬； 

    ③ 在私下里对你的职员提出批评；(千万不要将批评储存起来，要温和而果断及时的批评你的职员，最糟的一种情况是在当众批评后，再私下里道歉) 

    ④ 在失败中寻找成功； 

    4． 职员不是模块 

    如果没有十分的必要，请不要随意的交换你的职员的位置。 

    5． 信任你的职员 

    ① 努力了解你的职员――他们的潜力和才干，这样在工作中你可以完全放手让他们去干自己的工作，并相信他们能做得更好； 

    ② 一个简单也是最好得为你工作的人表示信任的方法是鼓励他们去管理自己的时间，鼓励他们使用他们认为自己效率最高的工作方法； 

    6． 保持自己的技术水平 

    ① 第一层经理而言，走在技术的前端，并完全参与到其他职员的工作中是相当重要的，他们必须擅长设计，编程，编制测试说明书和任何职员所进行的工作。可以完全理解其职员的产品，能判断产品的质量，并指导缺乏经验的职员。经理必须学会评估产品，安排计划和估算费用；      ② 想成为一名优秀的管理者的障碍是把做一名经理看成是自己在公司提升的捷径。做为一名一线经理，你要用心工作，赢得声望和你的职员一起开发出让其他人羡慕的产品。 

    ③ 如果你的团队的人数过大，你就不可能完全参与到所有人的工作中去，最好将你控制的人数定在6人之内。 

    ④ 当你变得有经验的时，你会发现管理者最需要的具备的能力是发现有潜力的职员，然后合理的安排工作，使你的职员能充分的发挥他们的潜能。 

    7． 欢迎批评和建议 

    ① 你的任务之一是做决策，不要只依靠你自己一个人的头脑来做决定； 

    ② 应该将一些无关紧要的小事分派给其他人，即使做错了，也应该原谅。 

    ③ 管理是一门道德学，你应该尽力指导你的职员在工作质量，不断学习，处理人际关系，敬业等关键问题上树立一系列的正确价值观。 

    8． 尽快的纠正错误 

    对于自己做的一些愚蠢的事情，解决方法只有一个，不要让这个作物任意的发展下去，不要视而不见，或把责任推卸到别人身上。要敢于承认错误，然后纠正它，并继续开展工作。 

    9． 给技术人员相当管理人员的酬劳 

    你需要依赖技术顾问来了解信息，进行决策。      10． 逐步灌输服务的思想 

    你和你的项目都是服务于客户的，并因此而热爱你的工作。

2、制定前景规划的能力 　　想要成为一名优秀的IT经理，你必须要能够确定自己的目标，并且制定出前景规划，让你手下的员工了解你希望大家通过努力能够取得的成绩。想要成为一名优秀的IT经理，你要担负起自己的职责，领导整个小组向着目标前进。能够制定出计划并且清楚的向自己手下的员工说明的IT经理能够在工作中取得巨大的成功，因为你手下的员工会按照你的要求去做。清楚的向自己手下的员工说明自己的前景规划会让他们了解工作的中心，让他们了解你会带领他们向明确的目标前进。

3、制定计划的能力 [...]]]> 1、了解公司需求的能力
　　所有的IT经理都需要知道如何才能够了解公司的需求，因为这同自己的技术职责密切相关。不管自己在公司当中的位置如何，作为一名IT经理，你都有必要了解公司的真正需求，只有在此基础上才能做出“正确的事情”。太多的IT经理在制定“IT议程”之前都没有真正了解公司的目标和需求。迅速掌握了解公司技术需求的能力会让你了解自己更多的职责。如果IT经理在制定计划时由于缺乏了解公司需求的技能而“错过了公司的目标”，公司可能会蒙受数万美元的损失。了解公司的技术需求是IT经理职业生涯发展的一个重要组成部分。

2、制定前景规划的能力
　　想要成为一名优秀的IT经理，你必须要能够确定自己的目标，并且制定出前景规划，让你手下的员工了解你希望大家通过努力能够取得的成绩。想要成为一名优秀的IT经理，你要担负起自己的职责，领导整个小组向着目标前进。能够制定出计划并且清楚的向自己手下的员工说明的IT经理能够在工作中取得巨大的成功，因为你手下的员工会按照你的要求去做。清楚的向自己手下的员工说明自己的前景规划会让他们了解工作的中心，让他们了解你会带领他们向明确的目标前进。

3、制定计划的能力
　　一旦知道了自己想要实现的目标，成功的IT经理会知道如何去制定计划，以实现自己的目标。这意味着要正确估计眼前的形势，知道哪些事应该摆在优先的位置，制定出大胆而又切实可行的计划。对于一名想要取得“高度成功”的IT经理来说，制定计划是一个非常基础的步骤。但可惜有太多的IT经理没有能够做到这一点。在这种情况下，他们所取得的工作成绩要比公司有能力取得的成绩小的多。拥有制定计划的能力，通过计划的实行来实现公司的目标会让你承担更多的工作职责。事先制定计划表明你是一个积极主动而不是一个消极被动的人。

4、组建小组的能力
　　成功的IT经理知道组建一个有深度而又有技能的IT小组的重要性。既要知道如何改进现有的IT小组，又要知道如何白手起家，建立一个新的IT小组。我所见过的所有优秀的IT经理都有根据手头的工作任务建立一个有力的工作小组的能力，有正确预计未来工作需求以使整个小组做好应对新挑战的准备的能力。强有力的职业IT经理能够有效的组建自己手下的员工队伍。他们了解职业生涯的重要性，并且愿意把职业生涯的构建作为一种工具，来组建强有力的工作小组，更加独立的开展工作。

5、集中使用资源的能力
　　如果想要取得成功，IT经理要集中公司所有的IT工作人员、资金和技术资源，处理最关键最重要的事情。公司技术资源的使用要同公司的需求和目标保持同步，并且要通过多产有效的方式。任何有清楚的职业发展目标的IT经理都知道集中使用资源的重要性。

6、贯彻“客户服务”理念的能力
　　对于任何IT公司来说，高水平的客户服务都是非常重要的。成功的IT经理会在员工的心目中贯彻一种客户优先的文化理念——不管是内部用户还是外部客户。优秀的IT经理知道自己职业生涯的存在和发展是由于客户需要他们提供的技术，支持他们提供的服务。这也正是成功的IT经理要同客户建立出色的关系的原因。

7、管理项目的能力
　　公司能够以可以预见的有效方式制定出项目计划是所有IT经理开展工作的基础。任何IT经理想要取得成功，都要对项目进行有效的管理。不管你的职业生涯发展方向如何，强有力的项目管理技能都能够增加你获得成功的机会。

8、应对变化、进行管理的能力
　　迅速的发展变化是技术的本质特征。每一个IT经理都要了解如何有效的应对变化、进行管理。不能有效的应对变化会影响IT经理职业生涯的发展。

9、领导员工并激发其工作热情的能力
　　如果工作热情得不到有效的激发，IT工作人员就无法在工作中发挥出自己最大的能量。成功的IT经理总是能够对员工进行强有力的领导并激发他们的工作热情。成功的管理人员知道如何发挥他人的潜质，这是一项非常重要的技能。

10、有效沟通的能力
　　成功的IT经理能够通过多种不同的方式同不同的员工进行沟通。通常，职业生涯的成功在很大的程度上依赖于有效的沟通技能。想要成为成功的IT经理，必须能够同各种人进行有效的沟通，既包括技术人员也包括非技术人员，要同高级经理交换对项目进展状况的看法。很多IT经理就是因为做不到这一点而极大的影响了自己的工作成绩。能够在自己的职业生涯中取得最大的成功的IT经理能够同所有人进行有效的沟通：员工、同行、外部客户、销售商和高层管理人员。

11、追踪并衡量工作表现的能力
　　确定目标并以此来衡量工作表现是非常重要的。成功的IT经理能够通过明确的方式来衡量小组的工作表现，并且通过反馈信息来改进工作表现。

　　一切都从“问题”开始

　　我认为一个人在一个职业方向上能走多远，不是取决于我们的宏伟抱负，也不是取决于我们渊博的理论知识，而是取决于你面对问题和解决问题的态度。

　　也许这只是我的个人体会，但自从我认识到这一点以后，我就放弃给自己做职业规划了。我不做职业规划，只会更多的考虑，在我工作的地方，在我工作的范围内，我们面临什么样的问题？我们还有哪些问题没有解决？我们还在哪些地方需要改进？我可以做出什么样的努力？

　　中国人其实很善于去“发现问题”，过去，老同学坐在一起，就是在讨论我们的国家、我们的某某政府、我们的某某单位甚至某某领导人有这样那样的问题云云，总之，大家都很会“数落”，在“数落”的同时，我们也不会忘记发表自己的“高见”。每每遇到这样的情形，我都会观察，问题的提出者是否会去专心的研究和准备处理这些问题。如果大家只是高谈阔论，发发感慨，我总是选择一言不发，并对被议论的对象报着深刻的同情！这种“同情心”会被人怀疑我的立场！ 　　其实，我认为自己并不是要去回避这些问题。只是自己也无法解决的问题，我们在抱怨和高谈阔论之前，更应该多学习和思考而不是飞短流长，包括站在当事者的立场去考虑这些问题。

　　IT也好，ERP也好，我们在一个企业可能遇到的问题其实是最多的。我并不认为所有的人都要抱着文绉绉的态度去研究和思考一番，而是作为一个学习者，问题本身就是最好的老师。与其对问题飞短流长，不如下来好好思考一番，并学习如何去解决。

　　作为IT项目经理，我们可能遇到的问题其实是非常多的。公司业务在不断变化，任何变化都会给IT带来一揽子令人头痛的问题。比如，过去的一个订货系统面向机构订货，你只需要应对几十家分支机构客户；现在公司的业务模式变了，马上要将所有代理商实现集中订货，你的系统一下子增加了上千家客户，系统如何承受这样的压力？公司的组织结构和业务流程的变动更是无时无刻不在考验IT人的智慧！

　　可以这样说，在一个公司里，需要广泛、深入接触各个业务部门的人非IT经理莫属。这是机遇也是挑战，你是只考虑自身的或本部门的利益，还是考虑客户和业务部门的问题将决定你在IT经理的岗位上可以走多远。现在，越来越多的IT经理会毫无疑问的选择后者，这无疑是一种明智的选择。 今天和大家一起讨论第二个主题：作为甲方学习 　　在讨论这个问题之前，先和大家讨论一个问题：IT项目经理属于甲方还是乙方？ 　　在金蝶IT部门，IT项目经理加上部门经理超过10人，每个人都会带一个小团队。IT项目经理有各种各样的背景，有的是从开发岗位提升上来的，有的是需求岗位提升上来的，有的是从实施岗位提升上来的，有的是从网络工程师岗位提升上来的，还有从市场和服务岗位转型而来的。我们发现，一些客户公司的IT部门比我们的项目管理体系甚至要更加完善，甚至整个IT部门都是由一些独当一面的IT项目经理构成的。我认为IT项目经理的能力成熟度可以代表一个公司IT部门的成熟度，所以IT项目经理的沟通能力和学习能力对一个企业的IT战略执行非常关键。 　　现实中，我们的IT项目经理都是非常善于学习的，对于项目任务也是非常负责。但是我发现了一个普遍存在的问题：我们很多项目经理把自己放在了乙方的位置上。 　　这里讲一个最近的故事：上周五，我们EAS协同平台因为一个补丁测试不充分，导致多个流程无法审批，前一天早上我已经发现了这个问题而且反馈给项目组加快重点跟踪。可是周五这个问题却再次重新而且是财务副总裁第一个发现。这个问题发生后，我们同时将问题反馈给了EAS事业部和本部门的项目组。EAS事业部在测试部经理的推动下，派出了支持人员到现场了解原因，测试部经理在问题处理前、处理中、处理后三次打电话给我反馈进展，消除我的担忧，处理完后发邮件给相关人员确认。而我们的项目经理却轻描淡写的说：他发现目前只有一两个核心的问题没有解决。他的答复让我怀疑我是不是用对了人！当然，我们的EAS项目经理也是一个非常有责任心的优秀员工，——一个小时以后，EAS项目经理主动找到我，让我给提出来究竟在哪里方面他还需要改进。为什么同一一个问题，两个团队的响应相差这么远？这不能不让我思考。 　　在这个事件中，我首先发现了IT项目经理和实施人员的不同。我们的实施人员在内心里有非常明确的甲方和乙方之分，即使在公司内部，我们的项目也分为甲方和乙方。EAS项目经理代表的是乙方，我是乙方的总负责人。但我心中的IT项目经理并不是乙方项目经理，我更多的是需要我们的项目经理站在公司业务发展和最终用户体验的角度去评估项目绩效，而不是简单做到让“甲方”业务负责人满意，业务部门和管理层也断然不会认为我是“乙方”代表，在任何时候，我都是“甲方”代表，我的使命就是要为公司的战略提供IT支持，而不是简单的把业务部门当成“乙方”。 　　站在甲方的角度学习，我们会发现，我们要关注的已经不是过去简单的“甲方”代表的满意度，而是甲方所有最终用户的满意度。我们的项目干系人发生了很深层次的变化。以金蝶为例，我们的项目赞助人或需求方往往是业务部门，但是如果仅仅考虑让某一个业务部门满意那就大大错误了！ 　　未从事过IT部门工作，在这方面可能难以体会深刻，但是在进一步讨论前，这是我特别强调的一点。这对我们学习和解决问题的心态有太大的影响，后续再慢慢道来. 　　所以，变化的业务、业务的变化带给IT经理最大的挑战就是：我们如何去学习？ 　　未完待续。 前两篇介绍了（一）一切从问题开始，（二）站在甲方的立场学习。我认为这是我们IT项目经理很重要的两个态度。本篇则从能力上介绍项目经理如何完成职业化转型。

　　项目实践与职业化学习

　　由于IT项目经理的奇缺，我们很多人可能还在没有做好专业知识准备的情况下就开始担任IT项目经理。无论你从事的项目大小，千万别小看了这个机会，这是一个学习和锻炼自己的很好的机会！

　　IT项目经理的职业化学习基本上可以分为专业学习和项目管理知识的学习两个部分。大部分IT项目经理的专业知识比较突出，但管理能力却有不足。在我们这里，有一个课程是绝大部分IT项目经理都一定会学习的，那就是《从专业人员转型为管理人员》，这个课程实际上就是把管理意识深深灌入项目经理的头脑。这门课程的重点不是掌握管理知识，而是通过团队培训和角色模拟，让我们深深发现自己身上的不足，并开始职业项目经理的个人转型。如果这个转型不成功，这样的项目经理的职业生涯是不可能长久的。很多专业人员对做管理没有信心，但是，只要你的悟性高，这门课程往往可以让我们起到茅塞顿开、豁然开朗、信心倍增的效果。

　　不过，这一切只是开始。由于IT项目的专业复杂性、组织复杂性、社会复杂性等等综合因素，你要应对自如，要学习的东西还非常多。知识方面，一个是从专业知识上，你要学习信息系统规划、设计、开发、测试等软件工程相关的知识，学习网络、通讯、安全、存储等相关的技术知识。如果你从事的是企业信息系统的项目管理，可能还需要学习ERP理论及系统实施的方法论知识；其次是从管理上，学习IT项目管理的特定知识。IT项目比建筑等其他专业项目更考验人的地方在于，IT项目是无形产品的交付，在项目目标、交付对象、项目干系人管理、项目范围管理、项目进度管理、项目沟通管理、项目质量管理等方面相对建筑等项目恐怕更加复杂。正是IT项目的特殊性，才使得IT项目管理成为一门独特的专业。在知识方面，目前国内有专业的培训和资格认证，如果我们希望在短时间内获得职业化能力，参加专业的培训应该也是比较好的方法。在部门内部，我们是通过外部培训和内部培训相结合的方式去培训IT项目经理，外部的培训主要以PMI的PMP培训为主，内部培训则是参加过相关外部培训的学员在内部做分享和交流。

　　专业知识和项目管理知识都只是IT项目经理的基础能力，拥有了这些知识，并不表明你就能成为一个好的IT项目经理。我认为，好的项目经理至少需要具有五个条件：

　　（一）、具备强烈的责任感和良好的管理意识； 　　（二）、熟悉综合性的信息系统软硬件知识； 　　（三）、精通IT项目管理知识； 　　（四）、具有３年左右的项目工作实践经验； 　　（五）、具备良好的协调和沟通能力； 　 　　我们在判断一个项目经理是否胜任的时候，并不是看表面的印象，而是以项目绩效和民主评议为前提来甄别的。所以这些条件不是指的你拿了多少国内或国际的证书。项目经理一定是在实践中经过千锤百炼打造出来的。

　　我们也有很多专业人员经历了很多项目，但并没有完成职业化的项目经理的转型，究其原因，我观察有以下几个方面：

　　（一）、对IT项目经理的角色认识不清晰。IT项目经理是要对项目目标负责，对项目干系人的需求实现和最终满意度负责，而且是要在规定的时间和预算的范围内完成这些工作。很多项目经理对这个角色的认识不清晰，往往会从专业人员的角度把项目当成一件事务性的工作去完成，很少考虑项目干系人的真实需求和项目的实际目标。最后项目完工了，发现并不是业务部门和甲方所需要的系统。IT项目经理的角色意识不强，会导致项目缺少起码的日常沟通和管理，大量的工作返工、时间和预算失去控制。试问有多少个企业敢用这样的项目经理呢？

　　（二）、缺少向实践学习、向同行学习的积极性。在知识社会，绝大部分专业人员都知道学习的重要性。但每个人的学习和思考的习惯、学习和思考的方法却具有非常大的差异。在新知识的学习上，一直有所谓的学院派和实务派之分。解决同样一个问题，因为学院派会穷根究底、理性分析，一个问题解决起来往往费时费力，但问题解决的深度和知识积累的效果会比较好；实务派则更多的懂得借鉴具体的实践经验，快速行动，问题解决的效率高，但容易陷入头痛医头、脚痛医脚的困境。无论是实务派和学院派，如果能够不耻下问，多拜前人为师，我认为都会或多或少的克服自身学习能力方面的不足。否则，仍由个人发挥，很有可能陷入极端。如果自认为掌握了一定的窍门，就不能虚心的向同行和老师学习，个人的成长一定会受到影响。

　　（三）、学习和创新能力参差不齐，项目应变缺少灵活性。毫无疑问，IT项目的业务多样性和快速变化对IT项目经理的创新能力和灵活性是一个很大的考验。在企业的IT部门，没有一个项目经理只做财务或者只做物流，项目临时性决定了我们的项目任务总在不断的变动中，没有任何一个人可以为未来的项目准备好所有的专业知识和最佳实践。所以，在新的项目任务提出来以后，项目经理如何快速学习、如何快速做出创新，这是对项目经理的学习和创新能力的很大的考验。

　　（四）、缺少与个人和组织打交道的热情和能力。实行混合项目制的组织，对同一个项目，往往负责人既有项目经理，也有职能经理。这些组织的项目经理的权力可能会在一定的程度上被削弱，这影响了项目经理与个人和组织打交道的积极性和主动性。这必然给项目的沟通带来很大的风险，项目经理的沟通会更加困难。而从学习来看，沟通和协调能力实际上项目经理最重要的能力。项目经理一定要过好与人打交道的能力。否则，在复杂的项目中，项目的推进力度和推进效果会在很大程度上受到影响。

　　 下一篇会继续从资源的角度，谈IT项目经理学习资源的挖掘与利用。 空间管理 您的位置: ITPUB个人空间 » 王叶忠的IT管理故事 » 日志 IT项目经理如何学习（四）：IT项目经理的个人知识管理 上一篇 / 下一篇 2007-12-13 15:47:40 / 个人分类：IT管理 查看( 81 ) / 评论( 1 ) / 评分( 0 / 0 ) 前一篇文章还是在9月底写的，这一篇用一些零零碎碎的时间写，实在让大家久等。这篇想和大家分享的是作为IT项目经理，如何挖掘和利用IT项目经理所需要的学习资源。

　　IT项目的特点对我们的学习和反应速度提出了很高的要求，主要表现在

　　一、IT项目环境在不断变化，要求IT项目经理不断学习

　　IT项目面对的环境包括企业的组织架构、业务流程、企业组织文化、项目团队文化、信息技术、领导风格等等不同因素。你需要不断学习，因为这些因素都在不断变化，而学习的目的就是适应这些变化。

　　二、IT项目需求的复杂性，要求IT项目经理具有快速学习和创新能力

　　IT项目交付物是无形产品，无论是功能性需求还是技术性需求、易用性需求，影响的因素都非常复杂。你随时都会遇到自己从未思考或学习过的问题。所以，我们总是要考虑如何在最短的时间里，发现最有效的方法和方案。

　　三、IT项目经理的时间都非常紧张，学习必须是高效率的。 　　 　　所以，IT项目经理的学习一定是非常特殊的，否则，很难在有限的时间里完成大型的复杂的项目。 那么什么才是IT项目经理最有效的学习之道呢？ 　　这里给大家分享一些我自己的做法。个人知识管理理论认为，个人知识管理的过程分为四个方面,我们也不妨从这四个方面展开：

　　1、FIND:寻找资源

　　IT项目经理所需要的学习资源有很多分类,我这里以ERP项目为例，每一类里面我只推荐我比较多使用的网站管理学习资源：

　　通用管理理论：（使用频率：非常低）http://www.12manage.com，该网站支持八种语言。 　　阅读过波特、德鲁克、柯普兰等的主要代表作，其他管理理论以MBA教材为主，MBA管理类教材基本都是国外知名大学引进的教材，中文和英文各占一半。对通用管理理论的学习我自认为自己做的是不够的。

　　管理实务： 　　主要以搜索引擎搜索为主，无固定网站，如财务、投资、工厂管理、市场营销、信息管理、项目管理、需求管理、知识管理都是我从事过的具体业务和管理工作，需要的工具以专业书籍和搜索引擎搜索为主，推荐google和xunlei就够。还有一些国内外的数字图书馆，只要有价值我一般自费购买，每年投资在3000元左右；

　　中国管理实践： 　　http://cnc.gemag.com.cn/gemag/new/，中文

　　项目管理动态： 　　http://www.pmi.org，英文，加入PMI国际会员，以阅读pmi发来的一些刊物为主，网站上的比较少；

　　运营管理： 　　http://www.apics.org,英文，加入APICS国际会员，大量的学习资料和互动交流社区；

　　商业案例和管理评论： 　　http://www.businessweek.com（商业周刊，业界最前沿的观点发源地） 　　http://www.nytimes.com（纽约时报，报道非常及时） 　　http://hbswk.hbs.edu/（哈佛商学院的工作知识，每一篇文章的份量都很重）

　　IT学习资源，在IT项目中不同角色需要不同的学习资源

　　技术动态，以IT专家网为主，基本不买书；要买也是买如“世界是平的”，“长尾理论”。如果看书的话，一定会一字不漏全部看完；近期以学习SOA为主。

　　技术学习，以IBM开发者社区为主，关于数据库、编程语言、软件架构及相关技术、软件工程、网络、存储等相关的书都会看一些，尤其是前几年，但学习只求一般理解。技术方面只写过部分规划和分析文档，纸上谈兵罢。

　　产品学习，金蝶自身的产品学习自然具有先天的条件，其他以SAP、oracle开发者社区为主,买的SAP和ORALCE产品和光盘资料也比较多，国内可以买到的国外出版的ERP、工作流、供应链、门户等书籍基本都会买，是专业书籍中看得比较认真的部分

　　特殊的技术和产品学习：参考各厂商的网站为主，微软的网站访问比较多。

　　以上资源，不同的人会有不同的对待方式。重要的其实不在于搜集（collection),而在于发现(find)。同样的资源，不同的人会有不同的发现。我们要更好的发现“宝库”，还需要具备其他一些条件。通俗一点说，你要具备一双善于“发现”的眼睛。只要善于发现，互联网上到处都是金子。

　　2、connect：连接专家

　　connect这个词现在我们应该深有体会，你加入任何一个社会网络或社区，其实你都是在不断的和其他人建立连接。金蝶社区的各位同仁和版主都是我的连接对象，此外，早期，我还会与业内不同网站的创始人和主编经常保持联系。这两年主要是与国外的同行交流多一些。这方面我认为自己做的还很不够，需要多向大家学习。

　　在阅读文章和资料的时候，我有一个习惯，就是会特别留意文章的作者。熟悉这些作者，并尽量和他们保持联系。这两天见到蔡颖老师，蔡老师说他还记得04年我就与他联系过，我很感动他还记得我。国内确实有一大批优秀的专家，与专家交流，是人生的一大快事！不过，与专家交流，是如何让专家了解你，找到双方沟通的桥梁。如果我们不象专家一样思考，很难与专家保持真正的长久沟通。

　　现在已经有了一些网站专门帮助你建立与各类专家的联系，这些网站现在称为社会网络（Social Network）。现在建立社会网络有很多的选择，金蝶社区目前也在进行社会化改造；金蝶友商网甚至干脆将自己的社区称为商务和管理的社会化网络。金蝶以外，畅想网是一个不错的平台。

　　我也使用社会化网络，每天至少会有半小时与我的专家网络联系。国内的以金蝶网站为主，国外的以facebook等网站为主。关于社会化网络，后期我可能会有更多的日志和大家分享。我们自己的金蝶社区将在明年年初的时候初步完成社会化网络改造。

　　3、learn：系统学习

　　互联网的丰富资源可以扩充我们的视野，为学习提供一些参考资料。但我认为真正的学习还是要专下心来，对重点知识领域一个一个的去攻破。作为IT项目经理，特别需要啃下一些基本的IT技术和项目管理的基本专业知识，包括技术方面的管理信息系统（ERP理论）、决策支持系统（商业智能）、软件工程方法（需求管理、分析与设计、软件过程控制、软件测试）、服务器与网络、数据库、分布式计算、SOA、web2.0及其他相关的技术知识；业务方面的会计学、财务管理、供应链管理、运营管理、组织管理、流程管理、项目管理、质量管理、知识管理。现在很多计算机专业的学生可能在大学阶段都或多或少接触过一些这些知识，但是有了一定的实际工作经验后，你可以发现情况又会很不一样。

　　在个人知识管理的四个环节中，Learn这个环节无疑是最考验个人的智慧、学习能力和学习意志的。可能大家已经听过很多次，不过，我还是想重点强调一次：这些学习，宜直接选择国外的教材。这是我二十几年的学习和阅读经历证明了的。以上这些知识模块，我大概只有在ERP理论这一部分学习过陈启申教授的那两本书，其他都是选择国外教材。 　　在国外有一些电子书网站可以下载到上面提到的大多数的专业领域的教材， 　　4、explore:探石问路

　　会学习的人总是会带着问题去学习，勤问、勤记永远是学习的最佳法宝。很多人利用互联网都是从在网上发帖子、问问题开始的。当然，你能够得到什么样的解答，取决于你选择的交流平台。我很久没有在社区问过问题。因为如果有问题的话，我会首先问公司内部的专家，其次是用搜索引擎再其次就是找专家社交圈（social network)的人。令我感动的是，在专家网络中，大多数专家在接到邮件和问题后都能给出非常满意的答复。我相信建立自己的专家网络对个人学习是非常重要的。

上周从开发部转来一个刚毕业的小伙子，要我面试一下看看是否适合质量部的相关工作。交谈中，小伙子说大学里已经考过了系统分析员，于是我便问他：“系统分析员主要做什么？” 小伙子想了一会说道：“系统分析员主要就是组织、管理和规划系统”。于是我接着问道：“如果负责组织、管理、规划的话，那和项目经理的区别是什么？”小伙子想了半天，终于摇着头说：“不知道。”问这个问题倒不是为了为难小伙子，主要是希望他能够明白，书本上学来的东西必须和实践联系起来，在开发也好在质量部也好，都离不开自己的主动学习和思考，没有思考的学习只是在收集知识而已，是不能够化为己用的。在离开学校的头两年里，大部分人是无法找到自己真正的兴趣所在，我也是一样，所以刚开始无论在哪个岗位都必须主动学习和思考，包括对自己现有岗位的知识的学习，以及由于不满而对岗位之外的知识的学习（当然这是在工作之外），而不满正是思考的起点。不过，正是因为无法找到真正的兴趣所在，就需要坚守岗位，一方面也许它就是自己的兴趣所在，一方面也为了寻找真正的爱好而积蓄力量。

　　额外的话说了不少，还是回来看看，到底“系统分析员、架构师、项目经理”之间有着什么样的差别？下面按自己的理解粗略的整理了一下，也许并不全面，绿色部分代表每一个角色主要需要参与考虑的活动（注：下面所说的系统分析员混合了设计的职责）： 

　　首先看一下架构师和系统分析员的区别： 　　1、系统分析员必须考虑自己所设计系统的方方面面，他是系统实现的原始作者，也对系统能否满足客户的技术要求以及产品成本是否可接受起着最直接的作用。

　　2、架构师一般在软件组织内仅仅是少数人，他们主要负责对产品的架构进行评估以及子系统之间的接口批准上，评估的主要方面集中在系统级的质量属性和成本上，包括：当前架构是否满足可靠性要求、系统架构的可扩展性、可重用性、性能以及基础的公共功能等等。他们必须对系统分析员设计出来的系统进行最初的把关，所以责任重大，也需要经验非常丰富的人来承担。在公司其他部门和Ivar Jacobson的交流中，Jacobson明确的指出，架构委员会不是常设组织，通常都来源于团队的系统分析员，唯一常设的职位通常只有一个主席，其他的成员必须临时来源于系统开发的一线，只有他们最了解系统开发的基本思想。

　　3、系统成本是架构师和系统分析员最容易忽略的事情，而这个也是他们最基本的职责之一

接下来看看系统分析员和项目经理的差别： 　　1、一个不合理的计划往往被归咎于项目经理，但这并不是事实。计划的制定严重依赖于系统分析员所设计系统的部件完成工序，而唯一能对这个作出准确判断的只有系统分析员。所以，计划的最初版本是来源于系统分析员而不是项目经理。项目经理在这方面的主要作用是协助系统分析员制定计划，帮助考虑人员、资源方面的投入情况，并在项目的执行过程中严格监控项目的进度情况。

　　2、质量目标的制定和计划一样，来源于系统分析员，尤其是性能、可靠性等关键技术指标，而这些�