这个问卷给你一个机会来告诉我们你对刚刚使用该产品的感受，你的回答可以帮助我们了解你对产品感到不满意和满意的方面，从而帮助我们改进设计，在回答每一个问题的时候，尽量回忆你完成的所有任务，圈划最能表达你感受的答案。如果某个问题对你不适用，请圈划不适用。

1.         总体来说，我对使用这个系统的容易程度感到满意。

2.         这个系统使用起来简单。

3.         我可以用这个系统有效地完成任务。

4.         我能够使用这个系统较快地完成任务。

5.         我可以高效地使用这个系统来完成任务。

6.         使用这个系统时我感到舒适。

7.         学会使用这个系统比较容易。

8.         我认为使用这个系统可以帮助我提高生产力。

9.         这个系统给出的错误信息清楚地告诉我该怎样改正错误。     

10.     当我使用这个系统犯错误的时候，我可以容易地迅速从错误中恢复过来。

11.     这个系统提供了清楚的信息(例如，联机帮助、屏幕上的信息和其它文件)。

12.     我可以很容易地找到我所需要的信息。

13.     这个系统提供的信息容易理解。

14.     这个系统的信息有效地帮助我完成任务。     

15.     这个系统的信息在屏幕上组织得比较清晰。

16.     这个系统的界面让人感到舒适。

17.     我喜欢使用系统的界面。

18.     这个系统提供了所有我期望的功能。   

19.     总体来说，我对这个系统感到满意。

 

分数的计算方法：

对每个问题，你如果觉得非常同意，得７分；

你如果觉得非常不同意，得1分；

你如果觉得不适用，得0分；

 

总体得分　　　　　问题1~19得分之和

系统可用性得分　　问题1~8得分之和

信息质量得分　　　问题9~15得分之和

用户界面质量得分　问题16~18得分之和

by Michael Feathers
September 9, 2005

Summary
Don't let slow tests bog you down.

Teams that adopt agile practices often adopt Test Driven Development (TDD), which means, of course, that they end up writing a lot of tests. In general, that’s great but there is a failure case for teams that attempt to get test infected; you can end up writing very slow tests that take so long to run that they essentially start to feel like baggage even though they help you catch errors.

This issue with unit tests isn’t a new issue, it’s been around for a while, and there are a couple of ways of handling it. In Extreme Programming, the typical way of handling it is to periodically go back and optimize your tests as they get too slow. In many cases this works well, but the amount of optimization that you have to do can be rather large if you haven’t been conscious of how long your tests run during development. In one case that stands out in my memory, I visited a team on the east coast about four years ago that wrote oodles of tests against their EJB environment. The tests hit a server and went through session beans, entity beans, down to the bowels of the database and then up again. Their refrain? “We don’t like writing unit tests any more; they take too long to run.” I didn’t blame them for feeling that way, but I also didn’t agree that they had written any unit tests.

The problem is rather common. I’ve spoken to other XPers about it over the years and I sort of figured that the way that I handled it was common, but I was surprised to discover (on the XP yahoo group this week) that it was also a bit contentious. Here’s what I typically say when I run into teams that have this problem.

A test is not a unit test if:

·  It talks to the database

·  It communicates across the network

·  It touches the file system

·  It can't run at the same time as any of your other unit tests

·  You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

That might sound a little severe, but it is medicine for a common problem. Generally, unit tests are supposed to be small, they test a method or the interaction of a couple of methods. When you pull the database, sockets, or file system access into your unit tests, they aren’t really about those methods any more; they are about the integration of your code with that other software. If you write code in a way which separates your logic from OS and vendor services, you not only get faster unit tests, you get a ‘binary chop’ that allows you to discover whether the problem is in your logic or in the things are you interfacing with. If all the unit tests pass but the other tests (the ones not using mocks) don’t, you are far closer to isolating the problem.

Frankly, we need both kinds of tests, but these "pure" unit tests are undervalued.

使用说明：本调查表共有100题，回答每一个问题时请按照如下三个步骤：

(a)        请评估每一个问题是否适用于所评审的系统，如果不适用，跳到下一题，如果适用，请继续回答下面两个问题。

(b)        对于所评估的系统，请评价该问题的重要性（１最不重要的，３是最重要的）。

(c)        评价系统该问题上的表现（１是非常糟糕，７是非常好），如果不存在，请选择不存在该项。

一.       兼容性

1.         光标的控制是否符合光标的移动？

2.         用户控制的结果是否符合用户的期望？

3.         所提供的控制是否符合用户的技能水平？

4.         界面的编码（例如，颜色、形状等）是否为用户所熟悉？

5.         用词是否为用户所熟悉？

二.       一致性

6.         界面颜色的编码是否符合常规？

7.         编码是否在不同的显示及菜单上都保持一致？

8.         光标的位置是否一致？

9.         显示的格式是否一致?

10.       反馈信息是否一致？

11.       数据字段的格式是否一致？

12.       标号的格式是否一致？

13.       标号的位置是否一致？

14.       标号本身是否一致？

15.       显示的方向是否一致？（漫游或卷动）

16.       系统要求的用户动作是否一致？

17.       在不同的显示中用词是否一致？

18.       数据显示和数据输入的要求是否一致？

19.       数据显示是否符合用户的常规？

20.       图形数据的符号是否符号标准？

21.       菜单的用词和命令语言是否一致？

22.       用词是否符合用户指导的原则？

三.       灵活性

23.       是否可疑使用命令语言而绕过菜单的选择？

24.       系统是否有直接操作的功能？

25.       数据输入的设计是否灵活？

26.       用户是否可以灵活地控制显示？

27.       系统是否提供了灵活地流程控制？

28.       系统是否提供了灵活地用户指导？

29.       菜单选项是否前后相关？

30.       用户是否可以根据他们的需要来命名显示和界面单元？

31.       系统是否为不同的用户提供了好的训练？

32.       系统是否可以自己改变视窗？

33.       用户是否可以自己命名系统命令？

34.       系统是否允许用户选择需要显示的数据？

35.       系统是否可以提供用户指定的视窗？

36.       为了扩展显示功能，系统是否提供了放大的功能？

四.       可学习性

37.       用词是否清晰？

38.       数据是否有合理的分类、易于学习？

39.       命令语言是否有层次？

40.       菜单的分组是否合理？

41.       菜单的顺序是否合理？

42.       命令的名字是否有意义？

43.       系统是否提供了无惩罚的学习？

五.       极少化的用户动作

44.       系统是否为相关的数据提供了组合输入的功能？

45.       必要的数据是否只需要输入一次？

46.       系统是否提供了默认值？

47.       视窗知觉的切换是否容易？

48.       系统是否为经常使用的控制提供了功能键？

49.       系统是否有全局搜索和替代的功能？

50.       菜单的选择是否可以使用点击的功能？（主要的流程控制方法）

51.       菜单的选择是否可以使用键入的功能？（辅助的控制方法）

52.       系统是否要求极少的光标定位？

53.       在选择菜单时，系统是否要求极少的步骤？

54.       系统是否要求极少的用户控制动作？

55.       为了退到更高一级菜单中，系统是否只需要一个简单的键入动作？

56.       为了退到一般的菜单中，系统是否只需要一个简单的键入动作？

六.       极小化的记忆负担

57.       系统是否使用了缩写？

58.       系统是否为输入分层次的数据提供了帮助？

59.       指导信息是否总是可以得到？

60.       系统是否为序列的选择提供了分层次的菜单？

61.       被选的数据是否有突出显示？

62.       系统是否为命令提供了索引？

63.       系统是否为数据提供了索引？

64.       系统是否提示在菜单结构中的当前位置？

65.       数据是否保持简短？

66.       为选择菜单使用的字母代码是否经过认真的设计？

67.       是否将长的数据分成不同的部分？

68.       先前的答案是否可以简便的再利用？

69.       字母大小写是否等同？

70.       系统是否使用短的代码而不使用长的代码？

71.       图符是否有辅助性的字符标号？

七.       知觉的有限性

72.       系统是否为不同的数据类别提供不同的编号？

73.       缩写是否清晰而互补相同？

74.       光标是否不同？

75.       界面单元是否清晰？

76.       用户指导的格式是否清晰？

77.       命令是否有清晰的定义？

78.       命令的拼写是否清晰？

79.       系统是否使用了易于分辨的颜色？

80.       目前活动的窗口是否有清楚的标识？

81.       为了直接比较，舒峰是否成对地摆在一起？

82.       是否限制语音信息使用的数量？

83.       系统是否提供了一系列相关信息？

84.       菜单是否和其它的显示信息有明显的区别？

85.       颜色的编码是否多余？

86.       系统是否提供了视觉上清晰可辨的数据字段？

87.       不同组的信息是否明显分开？

88.       屏幕的密度是否合理？

八.       用户指导

89.       系统反馈的错误信息是否有用？

90.       系统是否提供了“取消”的功能？

91.       错误的输入是否被显示出来？

92.       系统是否提供了明确的改正错误的方法？

93.       系统是否为控件输入提供了反馈？

94.       是否提供了“帮助”？

95.       一个过程的结束是否标志清楚？

96.       是否对重复的错误有提示？

97.       错误信息是否具有建设性并提供有用的信息？

98.       系统是否提供了“重新开始”的功能？

99.       系统是否提供了“撤销”的功能？

100.     用户是否启动流程控制？

 

可用性分数：

∑（wi * (Si-Pi)）  /   7*∑(wi*Ii)   *100

 

其中：i   第i个问题

Si　　该系统在第i个问题上所得的分数

Pi　　＝1，如果第i个问题适用但不存在

Pi　　＝0，如果第i个问题不适用

Ii　　　＝1，如果第i个问题适用

Ii　　　＝0，如果第i个问题不适用

wi　　第i个问题重要性的得分

 

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

系统设计/概要设计阶段

 详细设计/实现阶段

 

系统测试阶段

 

End

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

产品论证阶段

QA活动	活    动    描    述
咨询/指导/培训	无
QA计划	无
过程审核	无
工作产品评估	无
度量分析	度量该产品线其他商用版本的质量表现情况及研发过程数据（如研发周期）等供版本规划用。
沟通/汇报	1)参加事业部组织的各产品季度技术规划，了解产品的中长期技术规划 2)参加产品质量和经营例会，了解产品经营信息；

项目系统需求阶段

QA活动	活    动    描    述
咨询/指导/培训	组织需求工程相关培训[工具、方法、过程规范]及实施指导
QA计划	开始制定初始的QA计划，并且需求阶段的QA工作被细化
过程审核	1）至少执行一次需求过程的审核 2）可能执行项目管理、变更控制、评审、技术决策方面的过程审核
工作产品评估	1）敦促项目组初始化项目需求追踪矩阵，抓入用户需求和项目需求并建立追踪关系； 2）参加需求评审，并利用追踪矩阵抽查项目需求和用户需求的一致性； [需求和设计文档被规格化条目化、需求追踪关系的建立是开展前提，也是工作产品一致性审核的前提。]
度量分析	1) 度量需求评审速率、缺陷密度等，并运用9象限法敦促整改。 2) 度量需求变更次数，分析项目需求稳定度。
沟通/汇报	1)参加事业部组织的各产品季度技术规划，了解产品的中长期技术规划 2)参加产品质量和经营例会，了解产品经营信息； 3)参加项目例会，应邀参加业务部门例会； 4)参加CCB会议并监控CCB过程规范性；

项目项目计划阶段

QA活动	活    动    描    述
咨询/指导/培训	组织项目管理(估算、风险、过程定义、计划技术)相关培训[工具、方法、过程规范]及实施指导
QA计划	依据项目计划制定QA计划并组织评审
过程审核	1）见证估算活动和计划评审活动 2）参与过程定义、里程碑评审，执行项目计划和跟踪监控审核 2）可能执行风险管理、变更控制、评审、管理决策方面的过程审核
工作产品评估	1）敦促项目组定制项目过程，组织估算，排定计划并进行计划评审； 2）审核需求与计划的一致性；
度量分析	1）风险费效比（贯穿全生命周期，后续环节不再单独提及） 2）计划的里程碑进展（贯穿全生命周期，后不再提及） 3）周期内任务完成百分比，周期内任务延误分步 [对实际工时和计划工时的挣值分析做的比较弱。这些以及生产率都是最终项目复盘时候总结提供]
沟通/汇报	1)参加事业部组织的各产品季度技术规划，了解产品的中长期技术规划 2)参加产品质量和经营例会，了解产品经营信息； 3)抽样参加项目周会和CCB会议，但所有会议纪要都要求抄送QA

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

• 利用缺陷的阶段分布模型进行质量预测

    假设我们为bug管理系统建立了“一、利用缺陷引入-发现矩阵分析”中描述的缺陷引入-缺陷发现阶段信息，那么我们可以对相似的项目的缺陷阶段分布进行度量，形成该类型项目的缺陷分布的过程模型。它给予我们的信息是：只要是这种类型的项目，按照相似的过程方法进行研发，那么其质量表现也是相似的。

    我们之所以作这样的假设，是有一个前提，就是我们研发过程是高度一致的，并且过程的表现也是稳定的。这样，我们得出的过程能力模型才具有可信度。

    下面是一个如何运用测试分布模型进行质量预测的例子：

    如果需求阶段发现了10个缺陷，就可以预计到设计阶段我大概要清除70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约2个故障泄露到用户手中。

    这种分析预测模型的建立，要求组织的测试/评审过程比较稳定。即组织整体达到CMMI三级成熟度，同时在VAL和VER（验证和确认）过程域的达到CMMI四级的成熟度级别，即量化管理级别。

• 利用泄漏的下游缺陷回溯过程有效性

    经验告诉我们，越到后端发现的缺陷，用于问题复现、问题定位和bug修复的时间就越多。那么我们是不是可以在项目研发的更前端发现这些缺陷呢？有什么方式让我们识别项目研发前端哪些活动没有充分投入、或者没有运用合适的工程/技术方法导致这些问题被泄露到下游呢？

    其实，我们有很简便的方法可以达到这个目的。从团队的典型项目中运用一定的抽样原则抽样出某个阶段的若干个缺陷，从技术、流程、工程方法、费效比方面去分析其更适合、更经济的清除方法。然后把这些方法固化到我们日常的项目实施过程中，逐步就可以降低上游对后端的缺陷泄露。

    下面以对一个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：

    从上表可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障应该在集成测试和设计评审过程中就应该发现的。

    导致在集成测试过程中未能充分发现这些缺陷的原因主要有：

    1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；

    2、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；

    3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；

    这样，针对这些分析结论，我们就可以制定针对性的整改措施。如：

• 加强开发部的故障波及分析及波及分析验证工作；
• 项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
• 每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
  
• 利用缺陷分类来进行缺陷的根源分析

    对于测试出来的BUG进行缺陷分类，按照BUG的类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。

    下面以一个项目的系统测试故障为例进行分析：

    从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因：

    1、跨项目间的接口，接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时候才暴露出来；

    2、部门内部跨子系统的接口，由于本项目设计文档按功能规划编写的，而不是按照产品组件，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；

    3、系统设计基线化后，更改系统接口，没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗漏下来；

    那么我们可以针对性的制定改进建议：

    1、对接口文档的评审一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；

    2、对基线化的接口设计文档的变更一定要提交变更单给ＣＣＢ决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；

    3、概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审协调接口设计；

    以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。实际定义缺陷分类可能有很多个维度，如发现活动、引入活动、缺陷来源、缺陷类型、严重程度等。只要满足自己的缺陷管理、缺陷分析需求即可。

• 缺陷收敛趋势分析

    项目管理中一项非常重要但也十分困难的工作是衡量项目的进度、质量、成本等，统称为项目的状态，以确定项目是否能按期保质完成。这方面，测试提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。（注：此节所说的测试均指代系统测试）

    缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升；而发现缺陷数曲线应总体趋于下降；同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。如：

    项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目测试缺陷趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点，发现的故障数反而呈上升趋势，那么，这些点往往有一些特殊事件的发生。如：

• 在该时间段送测的回归版本增加了新的功能，导致缺陷引入；
• 该回归版本开发部没有进行集成测试就直接送测？等等。

    当然，这个统计周期也可以根据我们的项目实施情况进行。如按照回归版本的版本号进行统计、按周进行统计等。也有公司把缺陷收敛情况当作判断版本是否可以最终外发的一个标志。

    小结：

    通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。

    当然，这种分析来源于一个前提，我们需要规划一个好的Bug管理系统，满足我们这些分析的信息需要。另外，我们的研发过程是稳定的，其质量表现大体是一致的，这样数据反映的趋势才具备可信度。

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

    摘要：

    测试活动作为IT项目和产品开发一个重要的环节，通过发现产品或组件的缺陷，并反馈给开发组修复验证这些缺陷，从而在一定程度上保证了外发产品的质量。对这些测试活动发现的缺陷进行深入的分析，可以有助于我们进行质量预测、进行过程改进、量化的衡量产品质量。

    关键词：

    测试分析、过程改进、质量预测、过程能力、缺陷

    正文：

    项目研发过程中，我们通过单元测试、集成测试、系统测试发现了大量的缺陷。我们把这些Bug输入到Excel或者其他测试管理系统中，跟踪其解决。一旦Bug fix完成后，大多数情况下我们就把这份bug list束之高阁，偶尔能想到的用途就是拿出来衡量测试组的绩效，或者用来评估开发组的质量表现。

    一般来说质量分析有以下集中情况

• 利用缺陷引入-发现矩阵分析

    缺陷有发现阶段和引入阶段两个重要指标，发现阶段和引入阶段可以是软件生命周期的各个阶段，根据这两个阶段可以绘制出一个矩阵，从而分析出软件开发各个环节的开展质量，找到最需要改进的环节。

    开始例子分析之前先解释一下缺陷引入-发现矩阵的一些概念。

    矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动引入的缺陷泄露到后续各环节的缺陷数。

    缺陷移除率定义为：缺陷移除率=(本阶段发现的缺陷数/本阶段引入的缺陷数)*100%。如需求阶段一共引入了15个缺陷，需求评审时候只发现了2个，设计过程中发现了10个，编码和单元测试阶段发现了两个，还有一个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率=2/15*100%=13%。它反映的是该活动阶段的缺陷清除能力。

    反过来还有一个概念，缺陷泄露率，就是有多少本阶段引入的缺陷没有在本阶段发现而是被泄露到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%。显然，它等于[1-缺陷移除率]。它反映的是本阶段质量控制措施落实的成效。

    下面是一个分析例子：

    从上表可以看到，编码过程的缺陷大部分依赖系统测试发现。单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。详细见“四、利用泄漏的下游缺陷回溯过程有效性”

    另外，我们看到，需求阶段引入的缺陷绝大部分是在设计阶段发现的。这可能是我们大部分项目的一个现实，需求不稳定、需求不明确，很多东西需要在设计过程中才能明确下来。也许从这个分析结果中给我们一个启示，我们在设计评审时候，也需要重新审视我们的需求规格说明书，必要时候利用需求追踪矩阵这样的规矩方法来辅助我们发现上游需求的缺陷。把这样的机制固化起来，作为我们标准研发过程的一个要素或者过程指导书。

    当然，实际规划“缺陷引入-发现矩阵”时，可以依据自己的管理要求，对缺陷的发现活动和引入阶段进行细分或初分，并且在Bug系统中提交时，需要准确的填写这些属性字段。

• 利用缺陷的分布进行分析

    可以选某个阶段的测试缺陷进行分析，按照这些缺陷对应的产品组成部分来汇总这些数据。利用这样的分布，可以找出我们产品/项目的高危模块来。这些模块导致了我们产品的主要缺陷。主要用到的分析手段是数据透视表和柏拉图。让我们看看下面的例子：

    这是一个简单的OA系统，它只有5个子系统。我们把这些子系统各有多少缺陷列出来，找到了改善质量的关键模块是后台交易模块。

    像上图，这是一个较为复杂的MIS系统，有近20个功能块。这个时候，可以利用柏拉图识别出占80%问题的那少数模块，针对其采取强于其它产品组成部分的质量控制措施。

    需要指出的是：采用缺陷分布只是分析的第一步。它只不过提供了你分析影响产品质量的那些重点模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进行进一步的分析，识别缺陷的产生根源。

    当然，也有人认为绝对数去衡量缺陷的分布并不合适，所以有些人也会把缺陷按照严重程度对应一定的权重系数折算成分析意义上的标准故障。如上表，折算系数为，严重*10，关键*5，一般*3，次要*1，优化*0。

    这种分析需要我们的bug系统建立产品组件的概念，使得缺陷填报人能够正确的填报每个缺陷的产品组件位置。

基于Project的项目管理度量规划

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

摘要：

越来越多的公司运用项目管理系统来对项目实施管理。作为最广泛运用的项目管理工具Project Server，通过计划、跟踪监控采集了很多如项目管理相关的诸多数据。如何运用这些数据作合适的度量分析，让其更清晰的反映项目管理状态？本文正是带着这一问题进行阐述。

 

正文：

八、                   成本偏差率CV%度量[挣值分析1]

指示器含义：这个是常规的挣值分析和PMI推荐的挣值分析的方法。CV大于0（或者CPI大于1），则表示成本领先。反之，成本落后。CV%可以用于表示这种偏差的程度。

指示器定义：成本偏差率

可以在Project生成的 ViewàReportsàCost ReportsàEarned Value查看到。

BCWP、BCWS、ACWP、SV、CV、BAC、EAC、VAC等的值都可以看到（指标含义见本文末尾的附表）。可以在资源表中把人时的成本计算成1元/小时，则可以方便的显示这些值来，折算成人时数表示这些指标。

CV=BCWP-ACWP

CPI=BCWP/ACWP

CV%=（CV/ACWP）*100=（BCWP/ACWP-1）*100=（CPI-1）*100   表征成本偏差百分比；.

计划规则约定：

a、   需要保存一个特定的比较基准；

b、  需要更新计划时候申报实际完成的人时数；

c、   把资源的费用比设置成1RMB/Hours；

以上是挣值分析的三个指标值综合分析的图表。

 

以上是挣值分析的三个指标值综合分析的图表。

 

九、                   进度偏差率SV%度量[挣值分析2]

指示器含义：这个是常规的挣值分析和PMI推荐的挣值分析的方法。SV大于0，或者SPI大于1，表示进度超前，反之，表示进度落后。另外可以用SV%表示进度偏差的程度。

指示器定义：

查看方法和“七”一样。

SV=BCWP-BCWS

SPI=BCWP/BCWS

SV%=100*SV/BCWS=（BCWP/BCWS-1）*100=（SPI-1）*100              表征进度偏差的百分比

计划规则约定：

计划的要求和“七”一样。

 

十、                   完工百分比度量[挣值分析3]

指示器含义：

已经完工的工作量占总工作量的百分比。[相对于最近保存的baseline比较而言。]

指示器定义：

Finished% = BCWP/BAC

 [这里工时的费率折算为了1RMB per Hours，BAC表示完工总预算。此处取值为完工总工时估计。]

计划规则约定：

a、   设置资源的费率为1RMB Per Hours；

b、  需要申报实际的任务完成工时数；

 

以下各指标为进行进度分析触发重新估算专用。需要考虑这种偏差是典型性（即规律的，此后还会出现的）偏差还是非典型性偏差而作出推算，选用合适的分析方法。

 

十一、                   完工尚需预算 [非典型性偏差]推算

指示器含义：

根据PMBOK的约定，非典型性偏差即发生的影响预算的偏差不会在后续阶段有规律的出现，是偶发风险事件，故此时完工尚需的预算是不变的，和原来没什么变化。

指示器定义：

ETC=BAC-BCWP（or EV）

计划规则约定：

无。

 

十二、                   完工尚需预算[典型性偏差]推算

指示器含义：

根据PMBOK的约定，典型性偏差是指那种会规律性的，持续影响项目的事件导致项目的预算的变更。如，项目所在的国家和地区刚刚公布了每周四天半的工作日制度，那么原先的历时估算就需要变更了，完工的预算自然需要变更了。用于变更项目预算。

指示器定义：

ETC=（BAC-BCWP）/CPI=（BAC-BCWP）*ACWP/BCWP=BAC/CPI-ACWP

计划规则约定：

无。 

基于Project的项目管理度量规划

作者：罗耀秋            MSN: luoyear@netease.com               E-Mail：luoyear@163.com

摘要：

越来越多的公司运用项目管理系统来对项目实施管理。作为最广泛运用的项目管理工具Project Server，通过计划、跟踪监控采集了很多如项目管理相关的诸多数据。如何运用这些数据作合适的度量分析，让其更清晰的反映项目管理状态？本文正是带着这一问题进行阐述。

 

正文：

一、                   里程碑延误度量

指示器含义：

对重大里程碑的度量可以从宏观上给管理层以进度可视性，供管理层和项目经理监控项目的进度情况。

指示器定义：

里程碑延误率 = （当前结束的里程碑延误数/当前结束的里程碑数）*100%

计划规则约定：

对于处于UAT之前的项目，每个月至少要设置1个里程碑。并且在里程碑处标明该里程碑的目标和退出准则。

 

二、                   任务延误百分比度量

指示器含义：

对各开发小组（部门）和各项目的任务延误情况进行统计，从行政线和项目先上度量任务执行情况。

指示器定义：

[开发组/部门/项目] 延误任务百分比= [开发组/部门/项目] 延误任务总个数/已完成的任务总个数*100%

计划规则约定：

需要在Project计划的叶子计划加入一个文本字段用于记录任务的延误状态。并且需要建立任务申报机制去认定任务的延误状态。非里程碑任务每月基线化一次，此后的一个月内执行过程中的调整都记录为延误状态。

需要在企业资源的资源表中标注该资源的Group。

计划颗粒度要较为一致，一般以1-2周完成为限。

 

三、                   人员负载均衡度量

指示器含义：

防止矩阵组织中企业资源被跨项目的团队过渡分配，指导项目经理和HOD就过渡分配的资源问题进行协调，作为月度计划评审过程的考虑因素，从而避免不必要的进度风险。

指示器定义：

人员负载=（人员A在各项目该天的投入小时数/8小时）*100%

[在“Resource Usage”中可以导出各人的负载情况（小时数），相关人员可以导出成Excel进行计算和协调过度分配的人员。]

计划规则约定：

需要设置人员为企业资源，先与HOD和共享资源的项目协商该共享人员大致的使用比例，基于资源投入比去做计划（即明明该资源为两个项目共享，但两个项目排共享期该资源任务时其投入比均为100%，而不是协商其投入比之和为100%。）。

一些项目经理避免资源过度分配的操作方式：

如上图，在View->Resource Graph中可以看到哪些人在哪天被过度分配了。过度分配的那天柱状图会自动被标红。

如上如，项目经理也可以在View->Resource usage中把各人每天的工时分配情况拷贝出来放在Excel中，从而分析该人在各项目中总分配人时的情况，并可以查看该天该人员具体的任务安排情况，针对性的与相关PM和HOD协商资源。由此可见，对于跨项目资源，必要的计划评审与协调是非常必须的，并且评审前需要识别资源复用情况、跨项目的任务依赖关系、资源过度分配情况等，以便跨项目的计划评审与协调的针对性。

 

四、                   任务颗粒度度量

指示器含义：

按照PMI的经验值，可执行的任务存在一个80法则，即绝大部分任务应该分解到2周甚至1周内完成。这个有助于单个任务的目标管理和质量控制。

指示器定义：

任务颗粒度超过预定阀值的个数及比例[建议设置为7天，即5个工作日]

计划规则约定：

无。

项目经理自查任务颗粒度的方法：

按上图选择AutoFilter后，每个列的标题将出现一个带下拉的三角形。然后按照

Duration这个字段大于7的条件筛选出那些不合符颗粒度要求的任务从而进一步细分。

 

五、                   任务类型工作量分布度量

指示器含义：

这个收集的是计划值，可以度量项目对一些质量控制方面活动的投入是否充分。如编码阶段的编码/评审/测试的工作量比例值，可以反映出该项目的质量控制投入程度及规避不必要的质量风险。

指示器定义：

汇总各类任务的工时形成该项目的工作量任务类型分布。

计划规则约定：

项目计划需要设置任务类型这个字段。具体字段值需要进一步讨论确定。本文推荐如下：项目管理类-〉需求开发-〉顶层设计-〉详细设计-〉编码-〉Bug Fix-〉评审-〉开发测试-〉系统测试。

公司根据评审和测试等相关规范给出一定的指导值，对指导值分布的偏差项目组需要给出自己的理由，以证明充分考虑了过程中强化/弱化某类活动的理由及后续措施[如赶工和快速跟进过程中，对测试策略和评审策略的调整从而节约了一定的质量控制时间。这些被弱化的测试将通过加强系统测试阶段该module的功能验证测试来保证。并给出强化的功能验证测试的策略]。

 

六、                   任务阶段工作量分布度量

指示器含义：

这个收集的是实际值，以建立公司的类似项目的历史数据库，这些分布模型有助于项目经理类推进行各阶段的工作量投入的安排，也可以辅助公司层面进行年度/季度人力资源需求规划。

指示器定义：

项目层面——从实际申报的工作日志数据中统计该项目的信息，制作分布模型。

公司层面——拟合公司同类项目各自的分布模型，形成公司该类项目的分布模型及偏差值。

计划规则约定：

需要重新规划time sheet，设置任务阶段字段和任务类型字段。对任务阶段字段建议设置为：项目意向阶段 / 用户需求开发 / 项目需求开发 / 系统设计 / 概要设计 / 详细设计 / 编码及开发测试 / 系统测试 / 运行维护。Timesheet的申报按任务为颗粒度进行录入，而不是按时间周期为颗粒度进行录入（目前是按时间周期为1周录入）。

七、                   项目进度阶段分布度量

指示器含义：

这个收集的是计划的实际值，以建立公司的类似项目的历史数据库，这些分布模型有助于项目经理类推进行各阶段的历时安排，也可以用于项目经理监控项目进度。

指示器定义：

项目层面——从项目计划的里程碑实际历时收集该数值，制作分布模型。

公司层面——拟合公司各类项目的分布模型，形成公司层面的该类项目的进度分布模型，并给出各阶段偏差区间。

计划规则约定：

需要在项目计划中设置若干个里程碑，如：项目意向阶段 / 用户需求开发 / 项目需求开发 / 系统设计 / 概要设计 / 详细设计 / 编码及开发测试 / 系统测试 / 运行维护。然后在项目进度计划中跟踪这些里程碑的实际历时。

 

 

 

看到本版关于测试工具的讨论真是如火如荼阿。
不过我觉得测试缺陷的跟踪和管理其火力不应该集中在这些工具的应用上
而应该更多的集中在管理思想本身上吧。
我用过TD，bugzila，也自己组织开发过bug管理系统，也用过Excel管理
觉得工具并不是最重要的，重要的是
1、你如何规格化你的bug，使其满足所有人的信息需要；
2、如何跟踪bug的修复的各个环节和状态？
3、如何分析bug？[这个就可以大幅讨论很多东西了，有兴趣的也可以参见拙著《测试缺陷分析务实》]
4、如何管理测试用例和评价测试的充分性？
5、如何判断版本的放行？

代友急求一位对logiscope Audit熟悉的仁兄帮忙解决工具使用问题。请热心的朋友加tonyazona@hotmail.com，谢谢


代友急求一位对logiscope Audit熟悉的仁兄帮忙解决工具使用问题。请加tonyazona@hotmail.com

当然 本人绝不旁听拒绝来自深圳的热情网友的报告！

过程改进中有什么心得？
你知道本企业过程改进的目标和方向吗？
过程改进工作中的尴尬事件有哪些？
过程改进工作最大的阻碍是什么？
等等

一、 IPD背景
    集成产品开发（Integrated Product Development, 简称IPD）是一套产品开发的模式、理念与方法。IPD的思想来源于美国PRTM公司出版的《产品及生命周期优化法》（简称PACE——Product And Cycle-time Excellence）一书，该书中详细描述了这种新的产品开发模式所包含的各个方面。
    最先将IPD付诸实践的是IBM公司，1992年IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入停止增长，利润急剧下降。经过分析，IBM发现他们在研发费用、研发损失费用和产品上市时间等几个方面远远落后于业界最佳。为了重新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影响产品开发结果的情况下，将研发费用减少一半的目标。为了达到这个目标，IBM公司率先应用了集成产品开发（IPD）的方法，在综合了许多业界最佳实践要素的框架指导下，从流程重整和产品重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。
    IBM公司实施IPD的效果不管在财务指标还是质量指标上得到验证，最显著的改进在于：
    1、 产品研发周期显著缩短；
    2、 产品成本降低；
    3、 研发费用占总收入的比率降低，人均产出率大幅提高；
    4、 产品质量普遍提高；
    5、 花费在中途废止项目上的费用明现减少；
    在IBM成功经验的影响下，国内外许多高科技公司采用了集成产品开发（IPD）模式，如美国波音公司和深圳华为公司等，都取得了较大的成功。实践证明，IPD既是一种先进思想，也是一种卓越的产品开发模式。
    二、IPD核心思想和框架
    IPD作为先进的产品开发理念，其核心思想概括如下：
    a) 新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、种植还是改变方向。
    b) 基于市场的开发。IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD把正确定义产品概念、市场需求作为流程的第一步，开始就把事情做正确。
    c) 跨部门、跨系统的协同。采用跨部门的产品开发团队（PDT：Product Development Team），通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。
    d) 异步开发模式，也称并行工程。就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间。
    e) 重用性。采用公用构建模块（CBB：Common Building Block）提高产品开发的效率。
f) 结构化的流程。产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。
    IPD框架是IPD的精髓，它集成了代表业界最佳实践的诸多要素。具体包括异步开发与共用基础模块、跨部门团队、项目和管道管理、结构化流程、客户需求分析（$APPEALS）、优化投资组合和衡量标准共七个方面，IPD框架如下图所示。

    下面分别介绍IPD框架中的几个方面。
    三、市场管理
    市场管理从客户、投资、市场等产品生存的外在客观环境因素来影响产品的特性和生命。包括：
    1、客户需求分析
    可以说，没有需求就没有软件，缺乏好的、及时的市场需求是项目方向偏离和产品失败的最主要原因。IPD使用一种用于了解客户需求、确定产品市场定位的工具——$APPEALS进行需求分析。 $APPEALS从八个方面衡量客户对产品的关注，确定产品的哪一方面对客户是最重要的。$APPEALS的含义如下：$-产品价格（Price）；A-可获得性（Availability）；P-包装（Packaging）；P-性能（Performance）；E-易用性（Easy to use）；A-保证程度（Assurances）；L-生命周期成本（Life cycle of cost）；S-社会接受程度（Social acceptance）。
    2、投资组合分析
    IPD强调对产品开发进行有效的投资组合分析。如何正确评价、决定企业是否开发一个新产品，以及正确地决定对各个新产品的资金分配额，就需要测定新产品的投资利润率。只有明确了投资利润率的各种静态和动态的决定因素和计算方法，企业才能对产品战略做出正确的判断和决策，进而确定产品开发的投资。
    企业能否有效地掌握投入资金的对策，取得好的产品资金效果，提高资金运营效率，是一个大的战略问题，也是企业业务投资组合计划的任务。尤其是经营多种产品的生产企业，要正确地决定资金投入对策，还必须研究产品结构，研究企业各种产品的投入、产出、创利与市场占有率、市场成长率的关系，然后才能决定对众多产品如何分配资金。这是企业产品投资组合计划必须解决的问题。企业组成什么样的产品结构？总的要求应是各具特色，经济合理。因此，需要考虑服务方向、竞争对手、市场需求、企业优势、资源条件、收益目标等因素。
    投资组合分析要贯穿整个产品生命周期，在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、种植还是改变方向。通常在各个阶段完成之后，要做一次GO/NO GO决策，以决定下一步是否继续，从而可以最大地减少资源浪费，避免后续资源的无谓投入。
    3、衡量指标
    投资分析和评审的依据是事先制订的衡量指标，包括对产品开发过程、不同层次人员或组织的工作绩效进行衡量的一系列指标。 如产品开发过程的衡量标准有硬指标（如财务指标、产品开发周期等）和软指标（如产品开发过程的成熟度）；衡量标准有投资效率、新产品收入比率、被废弃的项目数、产品上市时间、产品盈利时间、共用基础模块的重用情况等。
    四、流程重整
    IPD中的流程重整主要关注于跨部门的团队、结构化的流程、项目和管道管理。在结构化流程的每一个阶段及决策点，由不同功能部门人员组成的跨部门团队协同工作，完成产品开发战略的决策和产品的设计开发，通过项目管理和管道管理来保证项目顺利地得到开发。
    1、跨部门团队
    组织结构是流程运作的基本保证。在IPD中有两类跨部门团队，一个是集成产品管理团队（IPMT），属于高层管理决策层； 另一个是产品开发团队（PDT），属于项目执行层。
IPMT和PDT都是由跨职能部门的人组成，包含了开发、市场、生产、采购、财务、制造、技术支援等不同部门的人员，其人员层次和工作重点都有所不同。IPMT由公司决策层人员组成，其工作是确保公司在市场上有正确的产品定位，保证项目保证资源、控制投资。
     IPMT同时管理多个PDT，并从市场的角度考察他们是否盈利，适时终止前景不好的项目，保证将公司有限的资源投到高回报的项目上。
    PDT是具体的产品开发团队，其工作是制定具体产品策略和业务计划，按照项目计划执行并保证及时完成，确保小组将按计划及时地将产品投放到市场。
PDT是一个虚拟的组织，其成员在产品开发期间一起工作，由项目经理组织，可以是项目经理负责的项目单列式组织结构。
    2、结构化流程
    IPD产品开发流程被明确地划分为概念、计划、开发、验证、发布、生命周期六个阶段，并且在流程中有定义清晰的决策评审点。这些评审点上的评审已不是技术评审，而是业务评审，更关注产品的市场定位及盈利情况。决策评审点有一致的衡量标准，只有完成了规定的工作才能够由一个决策点进入下一个决策点。下面是典型的产品开发流程：
    a) 在概念阶段初期，一旦IPMT认为新产品、新服务和新市场的思想有价值，他们将组建并任命PDT成员。
    b) PDT了解未来市场、收集信息、制定业务计划。业务计划主要包括市场分析、产品概述、竞争分析、生产和供应计划、市场计划、客户服务支持计划、项目时间安排和资源计划、风险评估和风险管理、财务概述等方面信息，所有这些信息都要从业务的角度来思考和确定，保证企业最终能够盈利。
    c) 业务计划完成之后，进行概念决策评审。IPMT审视这些项目并决定哪些项目可以进入计划阶段。
    d) 在计划阶段，PDT综合考虑组织、资源、时间、费用等因素，形成一个总体、详细、具有较高正确性的业务计划。
    e) 完成详细业务计划以后，PDT提交该计划给IPMT评审。如果评审通过，项目进入开发阶段。PDT负责管理从计划评审点直到将产品推向市场的整个开发过程，PDT小组成员负责落实相关部门的支持。
    f) 在产品开发全过程中，就每一活动所需要的时间及费用，不同层次人员、部门之间依次做出承诺。
    3、项目和管道管理
    项目管理是使跨部门团队集合起来更好地行动的关键。首先要有一个目标即项目所要达到的效果，一旦我们将客户的需求转换为对产品的需求时，就可以制定详细计划。该计划中的各部分将具体划分为每个职能部门的工作，即这个计划不只是研发部门的计划，也是公司各个部门共同的计划。 一个产品从概念形成到上市期间会涉及到许多不同的紧密相联的活动，就好象不同职能部门彼此之间是有关系的。同样在一个项目中他们彼此之间的活动也是有关联的，所有的活动加起来就是整个的产品开发。
    接下来安排活动的时间，然后对每个活动进行预算和资源的调配，在项目实施过程中还需要不断地与计划对照，因为没有任何一个计划是完善的，所以可以在细的层面上对计划进行一定的调整，但是PDT做出的承诺不能改变。整个项目的进行过程都需要PDT的参与，因此，PDT在产品开发全流程中自始至终存在。
    管道管理类似于多任务处理系统中的资源调度和管理，指根据公司的业务策略对开发项目及其所需资源进行优先排序及动态平衡的过程。
    五、产品重整
    IPD提高开发效率的手段是产品重整。产品重整主要关注于异步开发和共用基础模块（CBB）。
    1、异步开发
    异步开发模式的基本思想是将产品开发在纵向分为不同的层次，如技术层、子系统层、平台层等。不同层次工作由不同的团队并行地异步开发完成，从而减少下层对上层工作的制约，每个层次都直接面向市场。
    通常，在产品开发过程中，由于上层技术或系统通常依赖于下层的技术，因此，开发层次之间的工作具有相互依赖性，如果一个层次的工作延迟了，将会造成整个时间的延长，这是导致产品开发延误的主要原因。 通过减弱各开发层次间的依赖关系，可以实现所有层次任务的异步开发。
    为了实现异步开发，建立可重用的共用基础模块是非常重要的。
    2、共用基础模块
    共用基础模块（Common Building Blocks, CBB）指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果。由于部门之间共享已有成果的程度很低，随着产品种类的不断增长，零部件、支持系统、供应商也在持续增长，这将导致一系列问题。 事实上，不同产品、系统之间，存在许多可以共用的零部件、模块和技术，如果产品在开发中尽可能多地采用了这些成熟的共用基础模块和技术，无疑这一产品的质量、进度和成本会得到很好的控制和保证，产品开发中的技术风险也将大为降低。 因此，通过产品重整，建立CBB数据库，实现技术、模块、子系统、零部件在不同产品之间的重用和共享，可以缩短产品开发周期、降低产品成本。 CBB策略的实施需要组织结构和衡量标准的保证。
    不管是异步开发还是共用基础模块的实现，都需要很高水平的系统划分和接口标准制订，需要企业级的构架师进行规划。

松下幸之助认为,一个人的能力是有限的,如果只靠一个人的智慧指挥一切,即使一时取得惊人的进展,也肯定会有行不通的一天。
   因此,松下电器公司不是仅仅靠总理经营,不是仅仅依靠干部经营,也不是仅仅依靠管理监督者经营,而是依靠全体职工的智慧经营。松下幸之助的“集中智慧的全员经营”作为公司的经营方针。
   为此,公司努力培养人才,加强职工的教育训练。公司根据长期人才培养计划,开设各种综合性的系统的研修、教育讲座。
   公司有关西地区职工研修所、奈良职工研修所、东京职工研修所、宇都宫职工研修所和海外研修所等五个研修所。
   由此可以看出,松下所以取得如此巨大的成就,除特定的历史条件和社会环境外,他的经营思想的精华--人才思想奠定了他事业成功的基础。松下先生说:“事业的成败取决于人”,“没有人就没有企业”,松下电器公司既是“制造电器用品”的公司,又是“造就人才的公司”。
   松下认为,人才可遇不可求,人才的鉴别,不能单凭外表,人才效应不能急功近利,领导者不能操之过急。
   如何去获得人才,或许有些人认为要靠运气或缘分。但事实证明,人才是要去寻求的。天下万物都是必须常常有求才若渴的心,人才才会源源而至。
松下认为吸引人们来求职的手段,不是靠高薪,而是靠企业所树立的经营形象。
   目前所有中、小企业的烦恼,在于不易吸收人才,甚至于大企业也有同样的隐忧。就现在的日本来说,大都缺乏劳动人口,但是,在日本,初中或高中毕业后就做事的人,有好几万。因此,如果有意录用,就不可能找不到人,但如想雇用合适的人才,就必须使你的企业有吸引人的魅力。以经商而言,唯有培养这种吸引人的魅力,才能逐渐地争取到所需要的人才。
   松下认为争取人才最好不要去挖墙角
   松下认为被挖来的人不一定全部是优秀的人,当然,可依赖的人的确不少,可是还是有些不可靠的,所以还是不做的好。
   如果碰到有要想从事新的工作的人,只要这个新人人品好,就可以让他去学习,不必非要用有经验的人。
   公司应招募适用的人才,程度过高,不见得就合用
   人员的雇用,以适用公司的程度为好,程度过高不见得一定有用,而且有些人会说:“这种烂公司真倒霉。”如果换成一个普通程度的人,他会感激地说“这个公司蛮不错的”而尽心地为公司工作。
   “适当”这两个字很要紧的的,适当的公司,适当的企业,招募适当的人才,如果认真求才,虽然不能达到100%,但70%大概不成问题,达到70%,有时候反而会觉得更好。
    所以,程度过高,不见得就合用,只要人品好、肯苦干,技术和经验是可以学到的,即所谓劳动成果=能力×热忱(干劲)。
    提拨年轻人时,不可只提升他的职位,还应该给予支持,帮他建立威信。
    不过,提拨人才时最重要的一点是,绝不可有私心,必须完全以这个人是否适合那份工作为依据。松下认为,树立了这种提拨风气,有利于青年的成长,会带动整个公司各个方面的进步。
    松下先生要年轻的职员这样回答顾客提出“松下电器公司是制造什么的”问题,说“松下电器公司是制造人才的地方,兼而制造电气器具。”松下的心愿是这样的:事业是人为的,而人才则可遇而不可求,培养人才就是当务之急,如果不培养人才,事业成功也就没有希望。日本顾客这样评价:“别家公司输给松下电器公司,是输在人才运用。”
日本顾客这样评价:“别家公司输给松下电器公司,是输在人才运用。”
    对于人才的标准,松下这样认为:不念初衷而虚心好学的人,不墨守成规而常有新观念的人,爱护公司和公司成为一体的人,不自私而能为团体着想的人,有自主经营能力的人,随时随地都有热忱的人,能得体支使上司的人,能忠于职守的人,有气概担当公司重的人。
   现在松下公司课长、主任以上的干部,多数是公司自己培养起来的。为了加强经常性的教育培训,总公司设有“教育训练中心”,下属八个研修所和一个高等职业学校,这八个研修所是:中央社员研修所,主要培训主任、课长、部长等领导干部;制造技术研修所,主要培训技术人员和技术工人;营业研修所,主要培训销售人员和营业管理人员;海外研修所,负责培训松正国外的工作人员和国内的外贸人员,东京、奈良、宇都宫和北大阪四个地区社员研修所分别负责培训公司在该地区的工作人员,松下电器高等职业训练学校负责培训刚招收进来的高中毕业生和青年职工。
    松下的职工教育是从加入公司开始抓起的。凡新招收的职工,都要进入八个月的实习培训,才能分配到工作岗位上。
    为了适应事业的发展,松下公司人事部门还规定了下列辅助办法:
    第一,自己申请制度:干部工作一段时间后,可以自己主动向人事部门“申请”,要求调动和升迁,经考核合格,也可以提拨使用。
    第二,社内招聘制度:在职位有空缺时,人事部门也可以向公司内部招聘适当人选,不一定非在原来单位中论资排辈依次提拨干部。
    第三,社内留学制度:技术人员可以自己申请、公司批准、到公司内办的学术或教育训练中心去学习专业知识。公司则根据发展需要,优先批准急需专业的人才去学习。
    第四,海外留学制度:定期选派技术人员、管理人员到国外学习,除向欧美各国派遣留学生外,也向中国派遣留学生,北京大学、复旦大学都有松下公司派来的留学生。
    由于松下公司把人才培养放在首位,有一套培养人、团结人、使用人的办法,所以在松下体制确立以来,培养了一支企业家、专家队伍。事业部长一级干部中,多数是有较高学历的、熟悉资本主义管理的,不少人会一门或几门外语,经常出国考察,知识面广,年纪较轻,比较精干,而且雄心勃勃,渴望占领世界市场,有在激烈竞争中获胜的志向,这是松下公司能够实现高效率管理的前提。
    在如何培养人才上,松下有自己独到的见解:
    一、注重人格的培养
    名刀是由名匠不断锻炼而成的;同样地,人格培养,也要经过千锤百炼。松下认为,造成社会混乱的原因,可能在于忽略了身为社会人所应有的人格锻炼。缺乏应有的人格锻炼,就会在商业道义上,产生不良的影响。
    二、注重员工的精神教育和人才培养
    对员工精神和常识上的教导,是身为经营者的责任。松下力主培养员工的向心力,让员工了解公司的创业动机、传统、使命和目标。
    三、要培养员工的专业知识和正确的价值判断
    没有足够的专业知识,不能满足工作上的需要,但如果员工没有正确的判断事物的价值,也等于乌合之众,无法促进公司以至社会的繁荣。
    不过,培养员工正确地判断能力,不是件简单的事。全知全能的神,能具备先知先觉的见解。但凡人,却无法以无误的见解,来判断事物真正的价值。但是只要随时养成判断价值的意识,就会有准确地判断。这样,做事时就能尽量减少失败。
    所以,在平常应该多参考别人的意见,和自己的想法作比较,而想出更好的方式,做最妥善的决定。所以,应该鼓励员工不断地努力,相互学习,研究如何才是正确的价值判断。应该鼓励员工不断地努力,相互学习,研究如何才是正确的价值判断。
    四、训练员工的细心
    细心体贴,看起来似乎是不足以挂齿的小节,其实是非常紧要的关键,往往足以影响大局。因为在日新月异的现代世界上,如果人们犯一点差错,就可能招致不可挽回的局面,这种体贴而用心的表现,看起来不足挂齿,其实是至关重要的。
    五、培养员工的竞争意识
    松下认为,无论政治或商业,都因比较而产生督促自己的力量,一定要有竞争意识,才能彻底地发挥潜力。公司不仅要为当前贸易造就竞争强人,而且要为二十一世纪培养人才。
    六、重视知识与人才相结合
    知识是一种兵器,这种兵器要碰到人才,才能发挥它的威力。松下引用汽车大王亨利．福特说过的一句话:“超好的技术员,越不敢活用知识”。说明知识分子往往是弱者,容易陷于自己知识的格局内,划地自限,缺乏迎战困难,打破陈规的精神,以至于无法成大功立大业。
    松下认为,今日的年轻人,多受过高中、大学的教育,所以有相当的学问和知识。由于现代社会的变迁,分工很细,公司的工作项目也愈来愈复杂,所以年轻人具备程度的学问知识,在一方面来说,是必要而且是很好的事。但重要的是不要被知识所限制。不要只用头脑考虑,而要决心去做实际的工作,在处理工作的当中,充分运用所具备的知识。这样,学问和知识会成为巨大的力量。
    松下告诫刚从学校毕业的年轻人,要十分留心发挥知识的力量,而不要显示知识的弱点。
    七、恶劣环境促使成功
    松下强调真正的培养是培养一个人的人格,知识的传授只是教育的第二意义。他认为现在的教育虽名为教育,但不能算是真正的教育,真正的教育是提高一个人的人性。仅传授知识不能算是教育,知识的传授只是教育的第二意义。给成长中的人知识,是给他们兵器,绝不是教育本身。教育的中心,是以培养一个人的人格为第一,至于知识、技术之类,可说是附属的教育。
    一个具有良好人格的人,工作环境条件好,就能自我激励,做到今天胜过昨天,明天胜过今天,即使在恶劣的环境或不景气的情况下,也克服困难,承担压力,以积极的态度渡过难关,开辟胜利的新局面。
    适才适用,即在适当的位置上,配置适当的人才;人才适用,即通过人格的配置、信任和升迁,调动人才自动自发工作的精神。
    八、人才要配合恰当
    聚集智慧相等的人,不一定能使工作顺利进行,往往只有分工合作,才会有辉煌的成果。松下举例说,三个能力、智慧高强的企业家合资创办了一家公司,并且分别担任会长、社长和常务董事的职位。一般人都以为这家公司的业务一定会欣欣向荣,但没想到却不断地亏损,让人觉得很可思议。这家公司是一个大装配厂的卫星工厂,隶属于某个企业集团。亏损的情形被企业集团的总部知道之后,马上就召开紧急会议,研究对策。最后的决定是敦请这家公司的社长退股,改到别家公司去投资,同时也取消他社长的职务。
    有人猜测这家亏损的公司再经这一番撤资的打击后,一定非垮不可了。没想到在留下的会长和常务董事两人的齐心努力下，竟然发挥了公司最大的生产力，在短期内就使生产和销售额都达到原来的两倍;不但把几年来的亏损弥补过来,并且连连创造相当高的利润。
    而那位改投资到别家企业的社长,自担任会长后,反而更能充分发挥他的实力,表现了他经营的才能,也创造了不错的业绩。
    这其中奥妙就在于,人才要配合适当。在用人时,必须考虑员工之间的相互配合,如此才能发挥个人的聪明才智,这也是人事管理上的金科玉律。一般所说的因才适用,就是把一个人适当地安排在最合适的位置,使他能安全发挥自己的才能。然而,更进一层地分析,每个人都有长处和短处,所以若要能取长补短,就要在分工合作时,考虑双方的优点及缺点,切磋鼓励,同心协力地谋求事情的发展。
    怎样才能达成人事协调呢？松下认为不一定每个职位都要选择精明能干的人来担任。或许这个观点很难理解,可是,可以想象,如果把十个自认一流的优秀人才集中在一起做事,每个人都有他坚定的主张,那么十个人就有十种主张,根本无法决断,计划也就无法推动。可是,如果十个人中只有一两个特别杰出,其余的才识平凡,这些人就会心悦诚服地遵从那一两位有才知识的领导者,事情反可顺利进行。
     现在很多公司都拥有一流大学的毕业生,条件应该是得天独厚,但业绩并不如想象中的好,反之只有几个平凡员工的公司有时干得有声有色。其中原因当然很多,但人事协调的问题是最主要的因素。
     一加一等于二,这是人人都知道的算术。可是用在人与人的组合调配上,如果编组恰当,一加一可能会等于三,等于四,甚至等于五,万一调配不当,一加一可能会等于零,更可能是个负数。所以,经营用人,不仅是考虑他的才知识和能力,更要注意人事人的编组和调配.
.经营用人,不仅是考虑他的才知识和能力,更要注意人事人的编组和调配。
     九、任用就得信任
    松下说:用他,就要信任他;不信任他,就不要用他,这样才能让属下全力以赴。用人固然有技巧,而最重要的,就是信任和大胆地委派工作。通常一个受上司信任,能放手做事的人,都会有较高的责任感,所以无论上司交代什么事,他都全力以赴。相反地,如果上司不信任属下,动不动就指示这样、那样,使属下觉得他只不过奉命行事的机器而已,事情成败与他能力和高低无关,如此对于交代任务也不会全力以赴了。
    领导者都知道信任别人对工作会有所帮助,但却很不容易。上司在交代部属做事时,心中总会存着许多疑问,譬如说:“这么重要的事情,交给他一个人去处理,能负担得来吗？”或者想:“像这种敏感度很高,需要保密的事,会不会泄露出去呢？”领导者常会有这种微妙的矛盾心理。
     而更微妙的是,当上司以怀疑的眼光去对待部属时,就好像戴着有色的眼镜,一定会有所偏差,也许一件很平常的事也会变得疑惑丛生了。相反地,以坦然的态度会发现对方有很多可靠的长处。信任与怀疑之间,就有这么大的差别。
     因此对待要用之人,首先就要依赖,并且要抱着宁愿让对方辜负我,我也不愿怀疑他的诚意,如此可能更会赢得别人的效劳。
现代社会最大的缺点,就是人与人之间普遍缺乏互信互敬的胸怀,因此导致许多意识上的树立,甚至行为上的争执,造成社会秩序的混乱。领导者如果能培养起信任别人的度量,不但可以提高办事效率,还可以为这个冷漠僵冻的人间,增添许多光明与和谐。
    十、采用强过自己的人
   松下主张采用强过自己的人,认为员工某方面的能力强过自己,领导者才有成功的希望。即使一个才智出众的人,也无法胜任所有的事情,所以唯有知人善用的领导者,才可完成超过自己能力的伟大事业。然而一般人最容易犯的错误,就是高估自己的能力,而不肯接受他人的忠靠,领导者最应留意这点。
    十一、创造能让员工发挥所长的环境
    工作的性质往往会影响个人能力的发挥。人员的配置,有时会使他胜任高于其能力的工作,有时则只能发挥原来能力的一半。
    因此,人员的配置或运用很重要,运用适当,可以达到人尽其才,运用不当,则会埋没人才。如果从这个观点来观察大企业与中、小企业,就会发现中小企业的员工,往往工作效率较高,大企业能十分有效率地运用人才要差的多。当然也有少数例外。
    日本人的性情是:组织愈大的机构,愈不容易发挥效率。尤其政府机关的工作效率最差。公务员并不是不想好好地干,而是缺少使他们勤苗工作的环境。由于笼罩在不能施展才干的工作气氛中,容易有“多一事不如少一事”的倾向。大企业也有类似的情况。企业的规模愈大,所谓“官僚作风”愈浓厚。
    但是中、小企业如果有这种现象,就无法生存。因此,其员工不得不努力地工作。只有二十名或不超过五十员工的公司,彼此都充分了解对方的心情或动态,政策较容易贯彻,人员较容易动员。因此,在中、小企业中较能充分发挥每一个人的能力,而实际上,每个人也会很卖力地工作。
    世人往往认为中、小企业不稳固、不坚强。但是大企业往往只能发挥员工百分之七十的能力,中、小企业却能发挥百分之一百甚至百分之二百的工作效率。这就是中、小企业很大的长处,应该积极地发挥它。
   相对的,大企业则应该随时促进组织或制度上的专业化,分工的细密等等,创造能充分发挥员工能力的环境。
    十二、不能忽略员工的升迁
    适时地提升员工,最能激励士气,也将带动其他同仁的努力。提升员工职位,应以员工的才能高低做为职位选定的主要标准,年资和考绩应列为辅助材料。一家公司想求得发展的最好办法,莫过于制造的产品日益精良。因此,在工作上必须造就更优秀的人才,应采取“因才适用”的提升制度来配合作业。这种制度并不受年龄、性别的限制,完全依才干、品德、经验来衡量,是否可以胜任另一新的职务。但是,在实行这种职位提升的办法时,常会受传统年资观念的牵制与阻扰。
    按照年资考绩来提升员工有其好处,它的着眼点在服务时间的长短。虽然,年长者在智慧和体力方面,比年轻人差,但是,这个制度保障了年长者的日积月累的经验。如此的工龄和经验增强了领导力,年轻人也自然会表示爱戴及拥护,对于整个公司业务的扩展,会有很大的帮助。因此,工龄和才干必须相互配合,这样既使有才能的员工得以重用,又利于使周围员工信服。
    松下公司,就常实施这种制度。但是按这种制度提拨的人才并不是百分之百正确。有时,以为某人有八十分的程度,可是真正做起事来却往往只有五十分的能力。相反地,有的人办事能力却出乎意料之外。虽然这样,松下还抱着一种“为所当为”的信念。他们认为,为了公司的前途和利益,必须要有冒险的精神。如果确信了某人有百分之六十的能力,便可试用另一较高的职务。其中之百分之六十是判断,其余百分之四十就是下赌注,既然是赌博,就有输赢之别了,但常因公司的完全依赖和支持使他不负众望,将业务管理得有条不紊。可见,办理职员的职位提升,还不能缺少冒险的勇气。
    正是由于松下重视人才的培养,并把人才的培育与促进企业发展有机地结合起来,极大地提高了工作效率,改善了产品及工作质量,为企业创造了较好的效益。松下大目标的达成,正是建立在无数个人目标实现的基础上。
    为了发挥全体职工的勤奋精神,松下电器公司采取精神和物质双管齐下的办法,激励职工。在精神方面,公司提倡“全员经营”,宣传搞好经营是“职员自己的事”,职工是松下电器公司的主人翁。
    集思广益,全员经营,是松下电器公司一贯遵循的原则。在松下公司,每个人都把公司的事情当作自己的事来干。全公司没有上下的区别,谁想到了好主意,就提出来,共同经营松下公司。松下说:“如果职工无拘无束地向科长提出各种建议,那就等于科长完成了自己的一半,或者是一大半,反之,如果造成唯命是从的局面,那只有使公司走向衰败的道路。”对于职工提出的合理化建议,公司都认真对待,按成效分成1-9等,有的表扬,有的奖励,贡献大的给予重奖。总之,每一项建议,都会得到满意的答复。
   在物质方面,推行周休二日制,改变过去工龄和学历付酬的旧工资制,采用按照工作能力确定报酬的新工资制,并不断提高职工的工资收入。规定“三十五岁能够有自己的房子”的新的“职工拥有住房制度”;设立由松下幸之助赠给职工的私人财产二亿日元为基金的“松下董事长颂德福会”,实行支付给死亡职工家属年金的“遗族育英制度”;等等。
    公司采取的上述这些措施,对引导职工把公司的事业看成是“自己的事业”,从而燃烧起自己的热情,把首创精神用于工作,“产生着无法想象的伟大力量”。

您也可以就本案例其他的内容发表您的观点:
①松下公司的培训制度具体步骤是什么？
②松下公司的培训制度以什么为指导思想？达到什么样的目标？
③如果你是松下公司的总经理,你认为这个制度有没有不足之处,你将有一套什么样的思路？
④怎样看待松下聘用新员工制度？

不在工作状态？工作疲软原因分析及对策
　　原来高工作高效的自己怎么变得磨磨叽叽了？原本才思敏捷的自己怎么好像江郎才尽了？本来很认真敬业的人怎么变得应付差事了？干了半天也得不到上司的重视，怎么也提不起精神来了？
　　“不在状态”的情况很多人都出现过，有的人持续时间短，有的人却能持续几个星期甚至几个月；出现这种情况的间隔，有的人长一些，几年才出现一次；有的人短一些，一年会出现几次。怎样走出这种工作疲软的尴尬境地？不妨对症下药。
　　■ 情况一：高效快速派变成磨磨叽叽派
　　个案：做编辑的石磊最近就“沉浸”在这种情况当中。本来她是个做事非常有效率的人，但最近发现自己很懈怠，什么事都不愿意做，只想看碟、玩游戏，答应了别人的事情也往往拖到最后才能完成。不仅工作如此，连洗衣服这样的事也恨不得拖到快没有得穿了才开洗衣机。
　　石磊自己很痛苦，难道三十出头就到了更年期？还是青春期滞后了？当然不是理由。她也想每天都能拥有一个新的开始，可是近期以来养成的早上去麦当劳吃早餐、喝咖啡、看报纸消磨一个小时的习惯使她的每个新的一天都以缓慢的节奏开始，想快都快不起来了。
　　原因：习惯成自然，坏习惯拖了后腿
　　关键的解决之道：恢复快速高效的习惯
　　对策：
　　○ 改变已经形成的惰性
　　既然觉得在麦当劳消磨的那一个小时连带着消磨了一天的高效和节奏，那就狠下心来改变这个“坏”习惯。当然，早餐还是要吃，那不如在家里吃，一边吃早餐一边上网，同时做着两件事情，身体健康照顾到了，同时可以看看当天有哪些大事发生，有哪些新的邮件要回，有什么事情要处理。有了一个心里有数的早晨，这一天就开了个好头。养成节约早晨时间、有个快速开始一天的习惯，其余的事情就好解决了。只要开始强迫自己三天，以后就不会太难。
　　○ 重要的事情优先处理
　　一位在外企工作的女性这样比喻她的工作方法：假如有一盆水，里面既要放上大石头，又要放进小石头，怎样才能放进更多呢？当然是先把大石头放进去，再在空隙当中放进小石头。工作的效率由此而生。你先处理完当天最重要的事情，就等于把大石头放进了水里。用其余零碎的时间，也可以把次重要和不太重要的事情做完。这样一天下来，你会发现，原来我今天处理了这么多事情呢！自己心里也挺美的不是！
　　○ 今天的事情一定今天搞定
　　小时候都读过那首古诗：“明日复明日，明日何其多！”背的时候都明白着呢，可事到临头，就不自觉地会原谅自己：这也不是什么大事，明儿再说吧！给自己借口，这是一个特别特别坏的习惯。拖来拖去，等好多事情积在一起，不得不做了，一天要做很多天的工作，还有质量保证么？所以，不管用什么方法，一定要养成今天的事情今天解决的好习惯。你可以给自己鞭策，也可以给自己奖励，比如，坚持了一个星期，就请自己吃上一顿最爱吃的日本料理。
　　特别关照：总之就是养成一个习惯。习惯成自然嘛，让快速高效成为工作和生活的惯性，你就自然而然地恢复了往日的状态。
　　■ 情况二：才思敏捷趋向江郎才尽
　　个案：肖可的职业是策划。她自己曾经开玩笑说，所谓策划，就是以前所说的出馊主意、坏点子，现在称谓时髦了。不管怎么开玩笑，她的好策划还是挺多的。有一个做运动鞋的厂家找到她，要求她尽快打开销路。肖可想了个主意：在闹市的大街上，请20位青春靓丽的女大学生穿上厂家提供的运动鞋，跳起欢快活泼的舞蹈，同时不停地跺脚。路人很快就注意到这一队漂亮姑娘和她们脚下的鞋子。厂家对活动效果非常满意，肖可自己也颇得意。
　　但她近来却觉得自己的脑子好像进了水似的发木，好主意全跑了。常常是一个人闷坐一夜、又喝咖啡又抽烟，可还是没有让自己满意的创意出来。她疑惑：我脑子里该不是真的积了水吧？
　　原因：对自己的脑袋使用“过度”，以致一时“空虚”
　　关键的解决之道：重树对自己的信心；给脑袋一个补充营养的空间
　　对策：
　　○ 对自己要有信心
　　这种情况其实很多人都出现过，不必太大惊小怪，更不要自责，每天早上起来先跟你自己说三遍“我能行”。相信自己的能力，你才会有更大的空间开发自己。一时发“木”真的没什么大不了的。
　　○ 给脑袋放假
　　有时候你可能就是太累、太紧张、给自己弦上得太紧了，才导致所谓“江郎才尽”的假象发生。这时候，你不妨给脑袋放大假，什么也别想，做一些自己喜欢做的事，让心情轻松下来。最好的办法就是出去旅游度假，到山水与大海之间，体味一下自然的美妙，彻底歇上一个星期。回来以后，你或许会惊奇地发现：脑子又开始转了。人就是这么奇妙，也就是这么简单。
　　○ 给脑袋充电
　　也许你思维枯竭是把以前学过的东西都用光了，这时候自然就会觉得脑子“木”，如果是这种情况，那就去充充电吧，学一些新鲜有用的东西，脑子里有了新的储备，到用的时候才能往外源源不断地流淌。
　　特别关照：别自己吓唬自己，总是暗示自己“不行了”。只要你认识到这是工作当中一个正常的“断层”，是下一个高潮的衔接阶段，其余的事情都好办。
　　■ 情况三：“永远以工作为中心”到“工作只是一种谋生手段，不必太较真儿”
　　个案：于虹曾经是个凡事以工作为第一，工作就是生活的全部那种工作狂。在班上是工作，回家想的还是工作，跟新婚的丈夫聊天的话题也离不开工作，最后“整”得丈夫只好天天对着电脑打游戏，因为那比跟老婆聊天轻松、有意思。
　　就这样持续了好几年，在一批批新人陆续走上岗位，于虹从当初的新人变成如今的“老”人，她渐渐地发现，工作在她心目中的分量发生了微妙但是根本性的变化，她不再认为工作就是生活的一切，相反，工作只是一种谋生的手段，工作只是为了生活得更好。
　　在这种“思想”的指导下，于虹变得不那么较真儿了，以前为了一个工作上的细节，她能半夜不睡，只是为了让自己满意、让工作完美；而现在，她觉得差不多就行了，没必要把自己“作践”得那么惨，因为谁也不可能做到真正的十全十美。她有时候也觉得自己很奇怪，觉得不在工作状态，但是想调整又很困难。难道工作是手段，乐趣就没有了么？
　　原因：对现在所从事工作的疲惫；随着年龄增长，人生观发生变化
　　关键的解决之道：不要从一个极端走向另一个极端
　　对策：
　　○ 正视工作的作用
　　对于大多数人尤其是职员来说，工作的“用途”确实是为了谋生，是为了养活自己，是为了让自己生活得更好；很少有人会把工作当成生活的全部。于虹意识到活着不仅仅是为了工作上的成就而应该享受更多的人生乐趣，从某种意义上说，也是一个进步。
　　○ 应付差事不可取
　　即便再怎么认为工作只是生活的手段，也不能对付工作。“差不多”是工作的大敌，采取应付事儿的态度只会让自己的状态越来越差。你可以能力有限，但是不能用“世上没有十全十美”做借口，追求完美的态度不能改变。再退后一步说，假如在这个地方应付事儿，到了下一个地方还是应付事儿，长此以往，你的职业形象就会受损，到时候再想找能应付事儿的地方都找不到，这可是直接影响饭碗的问题。
　　○ 寻找工作的乐趣
　　工作是手段，但里面如果缺少了乐趣这剂润滑剂，它就会变得相当枯燥、折磨人，这恐怕也是于虹觉得不在状态的一个原因。假如你做同一个工作很长时间，已经找不到当初让自己兴奋的点，那就说明你也许应该换一个能让自己重新兴奋起来的职业了。
　　■ 情况四：本来很敬业，但觉得领导不重视自己，所以提不起精神来
　　个案：吴霏是那种领导一句表扬能顶1000奖金的工作人员，特别在乎别人对自己的评价，尤其是领导的看法。本来她一直业绩不错，但单位里新近换了领导，有很多重大的调整，一时没有注意到吴霏，她有点觉得自己不受重视。她不怕批评，就怕没有鼓励。好像自己努力半天，也没有人看得见。有那么几天，吴霏甚至想，何苦逼自己太紧，反正也没人理会。
　　关键的解决之道：找领导谈谈，沟通彼此的想法和观念
　　对策：
　　○ 沟通才能解决问题
　　吴霏后来实在憋不住了，就找新任领导谈话，诉说自己的苦恼：我觉得不在状态。领导很奇怪，你一直工作不错，为什么会有这种感觉？——如果不是这次谈话，吴霏不知还要认为没人重视自己多久呢——所以，如果你有什么想法、什么苦恼，不妨跟你的直接领导“摊牌”，彼此互相了解，解开心结，自然就回到了工作状态。
　　○ 改变用别人肯定自己的思维方式
　　领导很长时间没找我谈话，是不是我犯了什么错误？为什么要这么想？不如反向思维：领导不找我，那是因为我一直工作的不错。学会自己肯定自己，你的状态就会轻松很多，而轻装上阵也是制胜的法宝啊！

作者：Robert E . Kelley
原文摘要

本文中

　　•掌握…… 优秀工作者创造出比普通工作者眩目的工作成绩所依赖的九项策略。

　　•理解…… 主动地提出一些超出你工作范围之外，但对整个组织都有利的、大胆的、建设性的观点。

　　•网络…… 优秀工作者用来与那些将使其工作更加有效的专家联络的有效途径。

　　•增加…… 通过自我管理你的工作行为以及尝试从不同角度分析一个项目，使你对你的公司更有价值。

　　•影响…… 　　利用你优秀的组织知识和表达技巧来说服别人接受你的观点。


◆ ◆
　　管理者和工作者一直为一个重大的秘密所困扰：是什么样的特质使得一个优秀工作者可以创造出十倍于普通工作者的成绩。

通过在贝尔实验室和3M等公司近十年的研究，Robert E. Kelley和他的同事们终于发现了令人吃惊的结论。要成为一名优秀工作者，你无需高IQ、非常强的自信或者圆滑的社交技巧，事实上，你只需改进你的工作策略。

这个结论非常的有价值。因为在这样一个竞争激烈的时代，公司可由此使得他所有的雇员，而不仅是优秀工作者，都发挥出巨大的才能。

　　在这篇摘要中，你将学到优秀工作者所采用的九大策略。即使你已经成为一名优秀工作者，理解这九条策略也能帮助你增加你和你同事们的工作业绩。


◆ ◆
　　在我们讨论这九条策略之前，我们先来总结一下Kelley和他的同事Janet Caplan是如何得出这一结论的。在80年代中期，他们的调查小组花了两年的时间开展在贝尔实验室，世界上最早的研发组织的咨询项目。

　　贝尔实验室拥有许多世界上最好的工作人员，但他们中只有很少一部分成为"一抵十"的人物，那些能完成十份普通工作者工作的杰出工作人员。公司想知道，什么样的因素使他们产生这样的分化，从而可以雇佣到更多的优秀人才。

　　首先，Kelley要求管理者和工作者分别列出，当面临危机或开始一个重大的新项目时，他们认为值得求助的个人的名单。结果所得到的两组名单中，只有一半的名字是相同的。而且Kelley还发现，管理者和工作者对谁是优秀工作者的意见并不一致。

　　Kelley的小组于是又要求总经理、中层管理者列出那些名字同时出现在两组名单上的优秀工作者所不同于普通雇员之处。所提及的45个因素可分为三类：

1． 认识力的因素，如高IQ、逻辑能力、理性及创造力。

2． 个性因素，如自信、雄心以及冒险精神。

3． 社会因素，如个人技巧和领导才能。

　　Kelley接着面试了200名优秀和普通工作者以寻找他们在这45个因素上的区别。结果被输入计算机并分析了四个月。所得的结论是：并非这45个因素，包括高IQ、优秀的社交能力、充分的自信等，造成他们之间如此巨大的差异。

　　这就意味着，"这种优秀不是与生俱来，而是后天培养所得" 。如果人人所认为的那些使一个人优秀的因素都不是真正的源动力的话，那么任何人都可以通过改进工作方法而成为优秀工作者。


◆ ◆
　　通过数千个小时与优秀工作者的详细的面谈和对他们的跟踪观察，Kelley和他的小组终于掌握了他们的关键行为。正是这些关键的日常行为造就了他们出色的工作成绩。

　　例如，一个普通工作者在学习中通常需要一个星期的时间来写100行软件代码。而一个优秀的工程师只用一天的时间、四行代码就可完成同样功能，区别仅在于他打了两个电话请教专家，从而帮助他在1/5的时间内仅以四行代码就实现相同功能。

　　只要把这九条策略贯彻到你的日常生活中去，你就能极大提高工作能力。这九条策略按重要性的次序排列如下：

1． 主动性

2． 网络化

3． 自我管理

4． 洞察力

5． 下属关系

6． 领导关系

7． 团队工作

8． 组织知识

9． 表述能力

　　这些策略看起来并不新鲜，因为即使是普通工作者也会同意这些观点，但重要的是优秀工作者们"如何定义和排列这些策略"。

　　有趣的是，普通工作者也会列出同样的九条策略，但他们却以完全相反的顺序排列这些策略：表述能力第一，而主动性最后。

　　普通工作者对这九条策略有着完全不同的理解。下面我们先来看一下优秀工作者和普通工作者对这些策略的不同看法：

1. 主动性：普通工作者认为这意味着做更多努力来改进'自我'的工作，例如使用更快的计算机或主动做一些额外的工作，如计划一年一度的野餐会，来引起经理的注意。相反，优秀工作者认为主动性意味着在工作范围之外提出一些有益于同事和整个组织的，大胆的、建设性的建议。

2. 网络化：对普通工作者而言这意味着闲谈和传播小道消息。对优秀工作者则意味着开发与能对自己有帮助的专家联系的网络。

3. 自我管理：普通工作者认为这是帮助他们管理好自己时间和项目的技巧。优秀工作者则认为是发展一些能力和经验，使自己对于公司更有价值。

4. 洞察力：普通工作者认为这意味着如何使他们的观点受到最大的关注。优秀工作者则认为是尝试从不同角度看问题，如站在顾客、竞争者、同事、老板的角度看同一问题，以求提出更好的解决方案。

5. 下属关系：普通工作者认为是毫无保留的接受老板的指示，做自己分内的事。优秀工作者则认为是和上司一起合作完成公司的目标，即使两人在性格上存在差异。

6. 领导关系：对普通工作者而言，领导只意味着一种把自己的意志强加于人的权力。而优秀工作者认为领导是运用他的经验和影响力来劝说别人接受一项艰巨的任务。

7. 团队工作：普通工作者仅认为是在一个团队中与其他人共同致力于一个项目，各人完成属于自己的一部分。优秀工作者则认为该把各人的目标、行为和成果都结合起来。

8. 组织知识：普通工作者理解为对适当的人溜须拍马，而优秀工作者则认为是如何协调不同方面的利益，使得工作得以顺利完成。

9. 表述能力：普通工作者理解为通过圆滑的语言来吸引高层领导对他个人的关注。优秀工作者则认为这是一种技巧，它可以通过有效途径使得你的听众接受你所提供的信息。

　　如果你想成为一名优秀工作者，你就必须按我们所列顺序来发展。当普通工作者视圆滑的表述为个人表现的最高境界时，优秀工作者却相信，只有主动去提出了一个能吸引听众的观点后，这些表述能力才有意义。


◆ ◆
主动性

　　在这九条策略中，主动性是最能体现优秀工作者与普通工作者差异的一点。举个例子来看一下，贝尔实验室新雇了两个工程师，Henry和Lai。工作的头六个月对他们的安排是一样的，早上听课，下午完成工作任务。

　　Henry每天下午都把自己关在办公室里，阅读技术文件，学习一些日后工作中可能用得着的软件程序。他认为，问题的关键在于他是否能向同事们证明自己在技术方面是如何的出色。

　　而Lai除了每天下午花三个小时看资料外，她把剩余的时间都花在向同事们介绍自己和询问与他们项目有关的一些问题上了。当他们遇到问题或忙不过来时，他就自动帮忙。

　　当所有办公室的PC都要安装一种新的软件工具时，每个工作者都希望能跳过这种耗时的、琐碎的安装过程。由于Lai已经知道如何安装，她便自愿为所有机器安装这个工具。这使得她不得不每天早出晚归，以不影响其他工作。

　　六个月后，Henry和Lai都完成了工作安排。他们的两个项目从技术上讲完成得都不错，Henry的稍显优势。但Henry成了一个独行者，无法与同事分享他的能力。Lai则是一个有主动性的工程师，善于为别人提供帮助。经理认为她能够承担紧急的任务。

　　Kelley对Henry、Lai以及贝尔实验室中其他工程师的观察揭示了，任何一个具有专业技能，有竞争力的新雇员都必须在最初的6到12个月证明自己的主动性，否则就意味着你和别人毫无区别。在80年代末，当全国的经理都不得不开始裁员时，首选的将是那些缺乏主动性的雇员。

　　令人惊讶的是，Henry自认为具备主动性。没人要求他收集最新的技术资料或学习最新的软件工具，但他做到了，所以他可以把他的工作完成的比别人出色。但主动性并不意味着如何使你自己的工作更出色。对于优秀工作者来说，主动性意味着在工作之余，做一些事使所有的人收益。


　　优秀工作者从以下五个方面来体现主动性：

•首先，"承担自己工作以外的责任"。正如Lai所做的。

•第二，"为同事和集体做更多的努力"。正如Lai主动安装软件，为同事的项目提供帮助等，Henry只是为了优化自己的项目而做努力。

•第三，"能够坚持自己的想法或项目，并很好的完成它"。正如Lai所做的，尽管这要求付出许多额外的时间。

•第四，"愿意承担一些个人风险"来接受新任务，正如Lai冒忽视自己工作的风险帮助她的同事。

•第五，"他们总站在核心路线旁"，那是一条使所有工作者和管理者通向使用户满意、并给公司带来极大收益的道路。

核心路线是一些公司为获得收益和取得市场成功所必须做的直接的、重要的行动。工作人员首先必须踏上这条路线，然后才能为公司作出贡献。


◆ ◆
了解谁知道

　　要想踏上这条核心路线，光有主动性是不够的。要想获得好的收益，即使是优秀的工作者也需要一个庞大的专家体系来帮助他们完成工作。

　　第二个工作策略网络化是出色工作的关键。优秀的工作者明白，他们掌握的知识是有限的，不足以独立完成所有任务，他们必须知道谁懂得他们所未知的信息。他们经常会问，"怎样才能尽快获得我们所需要的信息，通过谁才能找到掌握着最佳信息的人？"

　　例如，一位管理顾问受命写一份报告以获得一份50万美金的合同。由于时间非常紧，他必须收集到尽可能多的关于那家生物公司所使用的生物鉴定过程的信息。他想起了以前的一位同事，那位同事现已去一家非常著名的公司（Genentech）工作。于是他拨通了她的电话，她把他介绍给了倡导这些鉴定过程的科学家。通过仅两个电话，他便获得了报告中所需的关键信息。

　　而在同一公司里，需要同样信息的另一位同事把他的问题提交给了电子公告牌。第二天，有40位专家等着回答他的问题。这些专家们相互之间有些矛盾。结果他不知道谁的答案正确，因为他无从判断这些答案的质量。他被信息压垮了，却不能找到真正需要的东西。

　　这两位顾问自己所掌握的信息（占60％）大致是相同的，但第一位顾问能很快弥补所缺乏的另40％知识，而且信息很可靠。这就是优秀工作者和普通工作者的区别了。

　　即使做为一名普通工作者，也能从网络中获得好处，只是他们反应速度慢，质量也不高。原因在于他们缺乏优秀工作者所具备的技巧。

　　优秀工作者在需要之前就已建好了网络。他们事先就注意寻找那些用得着的人，并与之建立联系，而不是在需要时才给这些专家去电话。例如，优秀工作者可能会听取某位专家的演讲，并在会后主动地介绍自己，问一些与主题相关的问题，收集他所感兴趣的信息。接着，他可能会送出一份自己在研究中写出的相关的文章，并告诉这位专家一些有关于他最喜爱的科学幻想小说家的即将举行的讲演的信息。当几个月后，他需要与这位专家联系时，他已为一切打好了基础。

　　除此之外，优秀工作者还不断完善自我，使自己也成为这个网络上有价值的一点。专家们更愿意与那些同样掌握着对自己有用的知识的人分享知识。

　　优秀工作者还注意发现那些知道如何找到专家的人。他们还尽可能地掌握更多的信息以减少专家所需花费的时间。对于这些提供信息者，他们除了给予公开的赞扬外，还会送上一份个人声明以示感谢，以此加强新的接触。


◆ ◆
自我管理

　　当一位聪明的工作者具备了主动性，并构造了一个网络来帮助自己开展工作后，他便会开始练习自我管理的艺术：他们开始对自己的成绩负责。

　　优秀工作者突破了普通工作者所认为的狭隘的自我管理的观念，认为自我管理不仅是管好自己的计划和安排好待做的工作。许多工作是由于你上司或同事的希望而不得不做的，但这些行为对公司不会有更多的价值。

　　优秀的自我管理者并不仅仅关心花在每项活动上的时间。他们会优化所有的活动，做那些与核心工作紧密相关的工作。核心路线是直接的、增值的路线，能使你的工作令顾客满意，公司收益。

　　因而，要做到优秀的自我管理，第一步就是评价一下你的工作是否与核心工作紧密相关。否则，当公司裁员时你将是其中的一位。你只有两种选择，要么找到与核心路线的联系，要么另谋工作。

　　假设有一家大公司的公关部职员，如果公关部对于这家公司意义不大，这名职员可以到公关公司或政治团体中谋求发展，或者设法做一些对目前所在公司有益努力，正如80年代Pfizer公司的几位公关部职员所做的那样。这些优秀的职员缩短了新药通过FDA检查的时间，把上市时间从10年减为7年，从而使公司在利润和市场份额上收益非浅。这些仍旧是公关工作，但不同的是紧密围绕核心路线展开。

　　大多数的普通工作者对他们的工作和职业没什么打算。他们不会考虑所从事的工作是否与公司的核心路线相关，或符合个人的发展计划。而优秀工作者则会仔细考虑他们愿意做什么样的工作，愿意与什么样的人共同工作，以及什么样的想法可转化为真正的项目。

　　总体而言，优秀工作者们使用以下方法管理自己：


1. 找到公司的核心路线，并懂得如何使公司获益；

2. 选择那些最感兴趣的、能够使他们发挥最大才能的工作和项目。

3. 他们经常思考和改进自己的工作。

4. 他们观察别人的日常工作并采纳那些对自己有价值的工作方法。

5. 他们尝试着在工作中做一些改变以培养更好的习惯。

6. 他们会向管理者建议改变一些工作纪律以便能够更好的完成工作。如，他们很可能会建议灵活的工作时间。

7. 他们会采取一些行动，以尽可能的在工作时间不受干扰。例如，在工作效率高的时间段不接电话。

8. 他们会在工作计划中留出一些时间以解决意想不到的困难或失误。

9. 他们的工作习惯是依轻重缓急安排计划以避免不必要的耽搁。

10. 他们学会接受偶然的几天或几个星期的工作低潮。他们了解自己的工作规律，而不会按照死板的规律工作，或是拼命工作14小时后累得好几天无法工作。

自我管理可以使你对你自己的工作负责。一旦你的老板认为你无需过多的管理时，你将可以自己控制自己的工作节奏。


◆ ◆
一幅大图

　　懂得自我管理的人无需太多的监督。因为他们已充分考虑到老板的观点。事实上，他们会试图站在与项目相关的每个人（包括顾客）的立场上考虑问题。

　　通过实践和经验，他们使自己的视野更宽阔。优秀的工作者总力图对自己的领域有更深更广的理解，这便是他们对问题有着深刻洞察力的基础。

　　例如，Sarah是Oracle公司的一名出色的软件开发人员。当她要求去做软件测试员时，她的同事都很吃惊，因为测试员被认为是最没前途的行当，他们只能测试别人写的软件，没有地位，更不会有创造带来的满足感。

　　Sarah则认为这是一个从更苛刻的角度来看自己的工作的学习良机。她可能学到同事们在编写软件时使用的一些技巧，并更好的熟悉那些可能导致软件失败的错误。

　　当两年后，Sarah重新回到软件开发部后，她已步入杰出者的行列，并帮助Oracle在硅谷大获成功。

　　象Sarah这样的优秀工作者会寻找更多的学习机会，拓宽自己的思路，他们尝试各种各样的问题和环境，从而对今后的工作有更深的理解。

　　优秀工作者总是尝试着从新的角度看问题，这些新角度可归纳为五个C：

1. 同事的角度（Colleague perspective）

2. 顾客的角度（Customer perspective）

3. 竞争者的角度（Competitor perspective）

4. 公司的角度（Company perspective）

5. 创造性的角度（Creative perspective）

　　其中最有价值的就是以一个工作小组以外的其他同事的眼光看问题。这样的过程在工作中很普遍，例如在贝尔实验室，某位工程师的工作必须通过一个与同事反复研讨的过程才能扩充为一个大项目。

　　普通工作者害怕和抨击别人的批评。而优秀工作者则认为这是一个良机，帮助他们从不同的角度找出可能遗漏的错误，接受有用的建议，同时他们也会寻找理由来拒绝不合理的评论。

　　优秀工作者也乐于以一个顾客的眼光来看他们的工作。尽管他们与销售部门基本无关，优秀工作者也会努力去理解顾客的需要和动机。

　　从一个竞争者的角度可以更好的评估你公司的竞争力。例如，优秀工作者会询问供货商："谁正在买最新的设备？谁正在搞革新？"

　　优秀工作者会请求老板解释自己的工作与公司的目标有何种关系，从而使自己能站在公司的立场上考虑问题。

　　最后，创造性的眼光可使得优秀工作者摆脱本行业的条条框框，接受其他领域中的优秀思想。

　　当一名普通工作者将这五个C贯穿到日常工作中后，就能成为一名优秀工作者。洞察力使你的视野宽阔，思维活跃，判断正确。


◆ ◆
　　下属关系

　　在所有的九条策略中，做一名好的下属是最难接受的一条。普通工作者总是惊奇的发现，优秀工作者不仅是一名好的领导，更是一名好下属。



　　一位工作者的下属风格取决以下两个方面：

1. 独立、严密的思考；

2. 主动还是被动。

　　根据这两点，有五种风格的下属关系：

•熟睡型（sheep）下属是被动的，他们完全依赖别人，只能完成简单的工作，总是被动等待下一步的工作安排。

•同意型（yes）下属，比熟睡型下属热情，但仍然依赖上司的安排。他们愿意做任何工作，但你必须告诉他们该做什么。

•过渡型（alienated）下属是一个独立的思考者，但他们被动的接受他们的角色。他们玩世不恭，不好好工作。

•实用型（pragmatist）下属能够执行指令，也能够提出一些有价值的观点，但工作不专心。

•优秀（star）下属从不停止思考，不盲目跟从。当他们与领导有分歧时，他们总是把公司的最大利益放在首位。他们以极大的热情完成工作。他们有很好的主动性和创造性，为了公司奉献出他们的最大才能。

　　下属关系是一种能指导你与公司内领导或权威相处的工作策略。

　　优秀的下属关系意味着，训练对任务、潜在问题和方法的独立的、严密的判断，帮助公司获得成功。优秀的下属即便与领导者之间存在着个性上的差异，也能和领导一起实现公司的目标。

　　根据Kelly的研究，虽然领导关系看起来更有魅力，但好的领导只是公司成功的10％，90％则依赖与下属如何将领导的思想转化为行动。

　　优秀的下属可以完成某个项目而无需过多监督，领导们可将注意力转到别处，因为他们完全可以相信：即使工作并未按他们所设想的在进行，但一定正被按一种最好的方法完成。

　　当优秀的下属与领导共同工作时，也不可避免的出现矛盾。优秀的下属会尽力去理解领导的意图。如果他们仍然认为有另外一条途径可使公司得到更多好处时，他们会按以下七条步骤表达自己的意见：

1. 预先行动。领导不可能获得所有的信息，因为他们有时离问题太远，有时候，他们会忽视决策所造成的不良后果。如果有充足的时间，一名优秀的下属会将其所知提供给领导，并忠诚的协助领导改进他的决定。

2. 发现实际情况。当领导还不清楚情况时，一名优秀的下属会把真实情况，而不是不完整的消息甚至小道消息告诉领导。

3. 寻找好的建议。了解到事实后，他们会用较明智的方法解释信息。他们会寻找所熟悉的其他部门的专家，让他们站在自身角度和公司领导的角度做出判断。

4. 采用恰当途径。每个公司都会有相应机制让员工表达自己的不满。优秀的下属会首选这条途径，向公司内的人而不是公司的竞争者表达自己的观点。

5. 做一名好的说客。优秀的下属总是站在公司的立场上看问题。他们会解释，领导如改变决定将给公司带来怎样的好处，反之将会受到怎样的损害。

6. 必要时要有勇气。如果面临的是法律或道德问题，优秀下属将会到董事长那里公正的说明这些将给公司带来的经济和名誉上的损失。

7. 团结别人。当优秀下属发现共同的呼声比个人的呼声更有效时，他会毫不犹豫团结他人。

当其他下属象熟睡者一样盲目服从上司时，优秀下属则会用他们的推理和说服力，只要他们确实认为方向不对时。使用以上七个步骤，你就能帮助你的领导做出更明智的决定。


◆ ◆
领导关系

　　在一个组织内部，并非每个领导都比别人级别高。许多团队和部门的"小头目"只是被任命满足某种需要或解决某个问题。

　　"大领导"总是以一种"自我为中心"的领导风格领导别人，"小头目"只是默默的工作在同事周围，尤其是在团队中。"小头目"没有直接的监督权力，也无权决定别人的工资。同事们只是自发的团结在"小头目"的周围，因为大家认为，如果团结起来就能解决更多问题。

　　要做一个好的"小头目"，你必须在以下三方面获得同事们的尊重：

1. 知识商：包括与团队目标相关的经验和好的判断力。

2. 个人魅力商：包括你懂得关心你的同事，与同事们目标一致，从而使他们愿意和你一起共同实现目标。

3. 动量商：意味着你愿意承担一些领导工作，帮助团队实现目标。

　　例如，当一群具有不同专业的顾问会见一位顾客时，其中一位有着丰富的工业经验，另一位可能是反馈控制方面的专家，第三位可能是市场策划专家，这时知识商就开始起作用了。

　　整个会见过程中，没有哪位是团队的领导。这几位轮流充当"小头目"的角色，只要某位的专业技能和实际经验能解决当时所面临的问题。

　　当然知识是非常重要的，但个人魅力商也必不可少。"小头目"要考虑到同事们的需要、技能和热情，因为他在他所领导的同事中并无正式的权力。他必须让同事们相信他象关心自己一样关心他们的利益。

　　优秀工作者从不假设自己完全了解别人。例如，当一个软件设计者被要求与其他六位同事共同开发一套新的Internet程序时，她会先检验一下自己对他们的看法是否正确。在第一次的会议上，她问了这样一个问题："John，在我们合作的上一个项目中，你曾说你的经验不够，现在情况怎样？本项目对硬件的要求很高。"

　　通过询问每一位成员他们的个人兴趣，她可以确保工作安排符合每个人的个人能力和口味。这种做法与"大领导"的自以为完全了解下属的作风成鲜明对比。

　　光有知识和领导技巧还不够，动量商才是关键。这是"小头目"赖以推动整个团队运作起来的主要技巧。无论是会议通知或是大项目的第一件工作，总是由领导发起。

　　领导必须计划会议，在高层领导面前代表整个团队，处理文件。他负责向小组传送消息，保证团队不是外界干扰。简而言之，动量领导关系是推动项目从开始到结束的一系列完整活动。

　　这三个知识，个人魅力和动量商是优秀工作者在工作中进行的三种主要活动。有时由一位优秀工作者完成这三项活动，有时则由不同的成员完成不同的活动。问题的关键在于，需要时这三项活动都由最合适的人完成了。


◆ ◆

团队工作

　　有时候工作任务很重，即使是优秀工作者也无法独立完成。比如，现在有些大型的、技术复杂的项目需要十个、上百个、甚至上千个具有不同背景和技术的工作者共同完成。每个团队内的领导关系都不一样。

　　在许多情况下，团队只是让费时间的代名词。例如，当Kelley问一些工作者为什么他们在某一天毫无收获时，最常听到的一句抱怨就是："太多团队会议了。"

　　在许多公司，团队工作无法取得成功的三个主要原因是：

1. 高层执行经理并不熟悉他们所鼓吹的东西。由于他们很多人是因为个人成绩出色而成为管理者的，所以这些管理者只是个糟糕的团队运作者，总给下属带来混乱的消息。

2. 团队工作与奖惩无关。当Kelley分析个人在团队中的表现与公司的奖惩制度之间的关系时，发现这种相关性为零。

3. 大多数人不懂得操作团队。很少有学校教授团队工作技巧，大多数工作者是在未受任何有益的指导前被硬塞进了某个团队。

　　尽管存在着这样一些问题，许多人还是被不情愿的塞进了一些团队。如果团对工作失败了，那么他们本身是不是个好的独立工作者又有什么意义呢？所以优秀工作者认识到管理好团队是保证工作有效率的重要一条。

　　第一步是慎重选择进入哪一支团队。让我们看一看Michela，一名世界上最大的消费品公司的优秀的生产经理是如何做的。她每周花70个小时的时间与团队里的所有成员保持联系，而她的工作仍不理想。现在她在加入一个团队前，总会问这样三个问题：

1. 这个团队的任务与公司的核心路线的关系怎样？什么样的付出可以得到好的回报？

2. 团队的任务能否用一到两句话表达？如不能，则该项任务有待进一步明确。

3. 这个团队完全有必要存在吗？同样的任务由一个人完成会不会更有效？

　　如果这三个问题的答案说明，这个团队值得加入，Michela会进一步决定这支团队对她是否合适？她的知识、经验和观点对这支团队是否有用？她的另一个条件是这项工作能否增加她在公司的影响或使她的个人简历更棒。

　　一旦她确信她应该加入该团队，她会考虑团队的其他成员是否有足够的能力和技巧完成任务；是否需要增加更为合适的人选或是只要少数人即能完成任务。

　　当Michela这样的优秀工作者被委派到某一团队，而她对团队的构成和任务有疑问时，他们会找他们的上司表明自己的观点。有时候研发部门的科学家会把自己所有的任务摊给上司看，并希望上司能重新考虑，以减轻过重的工作安排。

　　一旦优秀工作者致力于团队的工作时，他们会确保团队中的每一个成员都能接受自己的任务；他们确保任务被公平的分配给大家；他们在会上能很好的听取每个人的观点。团队中的每一员都会受到充分的尊重，他们的发言不会被无理打断。优秀工作者还会充分考虑内外顾客的意见。

　　那些在团队中表现优秀的工作者独立工作时往往同样出色。他们使用了其他一些优秀的工作策略，如：主动性、自我管理和洞察力等。

◆ ◆

组织知识

　　现代的工作越来越多的需要人们加入到团队之中，因为这样能创造出比出色的个人工作更为丰富的生产率。要想表现出色，相互交往的技巧和组织知识都很重要。

　　组织知识是一种可以协调各方面利益、解决矛盾、实现目标的能力。它包括关键人员的知识和促使大家意见一致的能力。

　　组织知识和表述能力一道被排在最后，因为他们依赖于其他工作策略的掌握。比如说，你需要首先有主动性，知道如何组建一个知识网络，知道如何以更宽的视野看问题等。

　　一旦你掌握了必须的技巧，你就可以沿着优秀者的蓝图发展组织知识。

　　首先，知道谁掌权。很多时候，正规组织的章程有些夸大最高头衔者的权力。

　　比方说，在一家大的报社，正规的章程规定编辑是新闻室里最有权威的人。而实际的报告显示最有权的是编辑的秘书，因为通常他们被授权推荐报道，建议改变工作安排，在编辑不在时主持会议等。根据洞察力和网络化这两条，有些工作者敏锐地察觉到公司里的真正掌权者。

　　第二步是理解公司的特点。掌握公司特点使得优秀工作者懂得如何得到他们想得到的东西且不会得罪人。

　　一家地区电话公司用了这样一条广告语："最尖端的技术"。公司的一位工程师知道公司实际上仅仅回收过时的产品，但公司的管理者们很难接受这样的批评。他无法做到直接面对管理者同时又保住自己的工作。于是他走出公司，与用户、供货商以及本行业的专家接触，证实了公司的竞争者正在开发新的产品和业务，把他的公司甩在了后面。

　　当他掌握了充分的证据后，他把意见提交给了高层管理者。由于他的意见非常有说服力，因而被任命去促进公司发展，使公司配得上那条广告语。

　　找到公司特点的最有效的方法是找到一位导师，他愿意与你分享他的见解。许多公司都组织教育，但工作者只能接受到一些基本信息，而不是更进一步的信息，比如在第一个项目中如何避开官僚主义的陷阱和自私的管理者。

　　如果这种教育关系是自然发生的，那么教育者更有可能跟你谈一些他们对组织的看法。优秀工作者懂得如何运用所掌握的主动性，洞察力和网络化三条策略，创造好的条件来建立这种关系。

　　例如，优秀工作者认识到这些教育者往往需要一些回报，无论这种回报是忠心、努力的工作或是帮助他们所喜欢的人成功等。

　　一旦他们知道了那些可能提供建议的人的动机，这些优秀工作者就能够获得指导。或者优秀工作者会在寻求帮助前，主动找一个在他们身边工作的机会。

　　无论有没有得到指导，优秀工作者都会尽快掌握工作中的一些礼节。他们会注意到是否"开门原则"真的意味着在没有预约时受到欢迎。

　　除了这些物理界线（比如办公室的门），优秀工作者还会考虑到一些"看不到的界线"，比如专家的工作范围。他们通过那些工作领域发生交迭的项目了解各位同事的领域。

　　尽管组织知识在整个九条策略中并不是最重要的，但也很有作用。你想主动提供好的建议来帮助公司，但如果你错认了掌权者或触犯了公司的规矩，你的建议将永远得不到采纳。


◆ ◆
表述能力

　　最后一条策略是表述能力，即说服你的听众接受你的建议的能力。不论你在其他方面的天赋如何，如果你无法说服你的听众接受你的观点，你就无法成为优秀工作者。表述能力将帮助你扩大影响力、稳固你作为一名优秀工作者的地位。

　　表述能力是一种收集信息，选取关键词，把他们组织起来并与他人分享的能力。当你在会议室中面对5～20名同事、高层管理者或顾客时，它将派上用场。

　　优秀工作者和普通工作者的区别仅在于如何了解听众并组织适当的信息。优秀工作者总是事先努力了解到谁是听众，并事先与他们接触，了解他们想听到些什么。

　　Stephen Chao的故事或许可以说明该如何去做。Chao在他30岁时就成为Fox电视台的总裁并负责新闻部。在一次专家讨论会上，他为了吸引观众，安排了一个令人吃惊的男性脱衣舞表演。

　　如果Chao知道谁将出席的话，他或许不会这么做。出席讨论会的有主管古典文学基金的共和党领袖Lynn Cheney，她的丈夫，国防部长Disk Cheney以及几位思想保守者。不仅他安排的表演不受欢迎，一小时后，Fox的主席Rupert Murdoch打电话通知他被解雇了。

　　优秀工作者懂得在不触犯任何人的前提下抓住观众的注意力。他们懂得如何以最吸引人的方式表现他们的东西，而不是简单的以年代顺序排列信息。他们在一开始就以戏剧化的令人激动的方式提出重要信息，而不是安排在最后，因为那时大多数人早已心不在焉了。

　　优秀工作者收集与听众相关的信息，并尽可能避免用纯技术语言来表达。比如，有一位大律师事务所的律师想就一家银行拒绝为非－美社区的居民提供抵押业务的事件提出起诉。为了赢得他的听众，他先了解到他们是一些成功的律师，对生活在那个社区的人一无所知。

　　这位律师知道，他首先得让他的听众们了解这些受害者。他首先展示了一些关于那个社区的居民的图片和资料，并详细描述了他们是如何艰难的寻找工作维持家庭的，之后他才就案件所涉及的法律问题作一些说明，而此时，他的听众早已被他的说服了。

　　下面我们回顾一下，要作出优秀的表述，你所必须具备的技巧：

1. 了解你的听众；

2. 巧妙的组织你的信息；

3. 使你的信息与他们相关，令他们感兴趣；

4. 尽量用日常词汇；

5. 设法使你的故事更精彩，而不要老一套。


◆ ◆
做一名优秀工作者

　　一名优秀工作者所具备的九条策略很好理解，也不难接受。记住这一切并非与生俱来的。只要遵循这个模型，你就能成为一名优秀工作者，能够更好的控制自己的发展，对公司也更有价值。

　　根据调查反馈的信息，那些开始使用这九条策略的工作者在8个月内都百分之百提高了自己的能力。与其他工作者相比，他们能更迅速的解决问题，工作质量也更高。

　　即使是优秀工作者，也能够因此得到提高。妇女、少数人和新手则提高了400％。这群人最可能因为无法获得丰富的信息而使工作受限制。我们所提出的计划可以使每一个人学到创造更高生产率的工作策略。

　　更高的生产率对你意味着什么？或许双倍的生产率就能使你的处境完全改变，从面临被解雇转为受到提升。如果你被认为是一名对公司有价值的人，实际上就意味着你可以获得富有挑战性的、令人满意的工作机会。由于这些工作技巧都是随时用的着的，可随身携带的，因此即使你另谋高就时仍然用的着。

　　由于优秀工作者是公司中最好的生产者，在竞争顾客和利润时，他们是最重要的资源。但仅十年前，公司并没有意识到这些优秀工作者的重要性：尽管优秀工作者可创造出高于普通工作者10～20倍的生产率，他们所得到的却仅比普通工作者高5％。

　　现在，管理者认识到优秀工作者是不可任意被替代的。优秀工作者是创造财富的源泉，公司都通过分配更多的利润份额来吸引和挽留他们。优秀工作者要求更高的起点工资、更多的利润份额以及高出个人支出几倍的股份收益的事情并不少见。

　　给优秀工作者的报酬离你也不远。正如Kelley的研究证明的那样，高智商、充分的自信和圆滑的社交技巧并不是成功的关键。只要在日常生活中贯彻这九条策略，你就能从普通工作者变为优秀工作者。

　　要提高你的生产率，你就必须把摘要中的这些观点变为你自己的，结合你的个性和工作风格来贯彻这九条策略。

　　对大多数人迩言，很快就能有10％的进步。6个月后，巨大的变化发生了。一年后，你就可以完全掌握那些只要优秀工作者才具备的技术并创造出极高的生产率。

　　要想成为优秀工作者，就从以下九点做起吧：

一、 要有主动性，能使你的公司获利；

二、 建立一个好的网络，帮助你把工作做的更好；

三、 在工作中做好自我管理；

四、 以更宽阔的视野面对机遇和挑战；

五、 培养下属关系技巧，与你的领导一起实现目标；

六、 运用领导关系，说服同事完成紧要任务；

七、 把优秀的工作带到团队中；

八、 通过了解你的组织，懂得你将与谁共同工作以及如何争取他们站在你这边；

九、 通过有效的表述技巧向你的听众表达你的信息。

　　你已经具备了使你表现不凡的技术才能和基本智能，现在是利用这些技巧把自己变为一名优秀工作者的时候了。

中国软件工业的冤枉路
作者： 黄绍良 来源：（来源：希赛网）时间：2005年07月18日
　　 
软件开发的冤枉路
    大部分软件开发从业人员常述说“很难把握客户的需求”。这句话基本上不应该从一个专业人员口中说出来，你听过一个装修工人告诉你不能把握他客户的装修需求吗？但这却是事实。如何能够“把握客户的需求”便成为软件工程中急需解决的问题。很多专家发表很多理论，应该如何才能够把握客户的需求，需要采用那些手段，那些方法等等。。。。但我可以把过去三十多年科技企业软件开发的经验告诉大家，我们基本不用去“把握”客户的“需求”。
    软件开发的冤枉路带来目前 IT 项目管理的另一段冤枉路，我们是否还需要继续朝这条冤枉路走下去，还是找寻我们软件工程的正确路线？希望各从业人员自己判断，并适当的做出结论。

国内对需求的解释

    从 72 年开始从事软件开发，到 79 年开始成为开发小组主管，到 84 年正式成为项目经理，一直到今天已经积累了三十多年的开发及二十多年的管理经验，最近这两年在国内从事教育及咨询的工作，发觉国内软件从业人员所谈的“需求”和我过去在国外执行软件开发时所谈的“需求”有很大的差异。我们在国外建设系统的时候，『需求』是技术人员建立的，不是从客户口中把握的。但国内的软件从业人员所谈的“需求”是在“调研”过程中由客户提出的。坦白说，客户基本不理解本身的需求，又如何能够告诉我们所期待的“需求”呢？又如何会认同从业人员收集到的“需求”及确认所谓“需求说明书”呢？试想想，当我们要研制一件产品的时候，我们会问消费者他们对产品的需求吗？也许我们会咨询他们的意见，但生产商会综合消费者的意见，本身对市场的理解，和最终客户群的采购“目的”来制定产品功能需求，最后成为产品的规格。才投入生产，推广到市场中。这个道理很简单，但我国的软件工业却认为软件工程与产品开发不是一样的，不能用同一直方法处理，一直在走冤枉路。

    从项目开始进行“调研”（另一个软件工业的重大误区），对客户的基层人员进行访谈，希望能够在调研期间让客户说出本身的需求，好能把握客户的需求，好能编写所谓调研报告或需求说明书，所谓调研是进行调查，继而进行研究，这是两个工作，但我们常把它变成一个工作来进行。国内对“ gather requirements” （收集需求）的理解是从客户的访谈、调查、研究过程中发掘客户的需求，由于客户对需求不明确，技术人员未能把握需求，所以一开始调研下去便是半天。

国外对需求的诠译

    国外软件行业基本没有一个所谓“调研”的概念。我们在项目的起始阶段只有“ factfinding ”（或 FF ，即“找寻事实”）。顾名思义， FF 的目的是理解客户如何执行工作，技术人员对客户进行访谈，目的并不是把握客户的需求，目的是理解客户目前如何执行本身的工作。访谈报告只包括目前工作如何在部门中实施，是现状的描述。所以往往能够得到客户的认同及确认。

    在访谈结果后开始对现状进行分析，考虑整个工作流程是否合理，如何才能够达到项目的目标，从如何达到项目的目标来决定项目的需求。

国内外的差异

    我们必须认识到一点， 软件开发的目的是为企业提升生产率（ Productivity improvement ），提升工作效率（ efficiency improvement ）及建立商业效益（ business benefits ），而不是为了满足某一些需求。如果项目的目的是为了满足某一些需求来解决一些运营上的问题，那么这些便是系统维护项目，不是系统开发项目。这些项目的需求通常比较明确，客户清楚的知道需要增加那些功能，可以直接告诉技术人员有关功能的需求。在现有系统中附加该功能，便能够完成项目，这方面的需求绝对可以得到各阶层人员的认同。

    软件开发是为了提供一套完整工具（软件加硬件）来完成一个部门或一家企业的“运营目标”，如何可以利用科技来使企业的运营更理想，是软件开发的主要原因。所以当我们完成分析后，明确的理解需要那些功能才能够让企业或部门能够更有效地达到目标，这些功能才是系统的真正需求。我们所说的“ gather requirements ”基本上是包括 Fact Findings 和分析（ Analysis ）两个阶段的结果，不是国内所执行的“调研”一个工作希望直接带出来的结果。

整体解决方案

    当完成分析后，有了全面的功能需求，接下来便需要让客户认识到他们的最终目的需要那些功能和如何可以利用科技（软件及硬件）的结合来完成，这便是我们所说的解决方案。这时候还没有对系统进行设计，只是让客户认识他们所希望的目标需要那些系统功能来完成。我们的目的是让客户认同只要我们的系统可以提供这些功能，便能够达到他们的最终目的。这便是确认需求的目的。同时在确认这些需求的时候，把项目的范围牢牢的建立起来。

客户的确认

    到这里，相信大家都知道为什么我们在国外可以让客户确认需求而国内的技术人员却未能让客户确认需求了？很多同业往往感觉困惑，为什么访谈结果可以让被访者接受，但每当要求对方主管确认的时候又被打回头票呢？在回顾国内把握需求的方法，希望从访谈的用户口中提供系统的功能需求，这是把我们的专业工作交给客户来执行，他们又如何能够完成我们本身做不到的工作呢？纵然访谈的客户可以很明确的认识到本身工作上的需求，同时可以确认你递交的调研报告或需求说明书，但这只属于他本人工作岗位及工作层次上的需求，而部门主管及企业领导的需求是比较全面，肯定与有关工作人员所提出的需求有所不同，这份调研报告又如何能够让用户主管或客户确认呢！

    未能把握整个解决方案的目标，未能分析整体工作的过程来建立目标的功能，出来的需求只能解决局部的问题，未能做到“解决方案”的目标。其实我们只需要确认业主的项目投资最终目标，从分析的结果来建立所需的功能，便能够有效地让客户认同这些主要功能，认同项目地需求。

开发的另一误区

    我常看到一些开发人员把过去一些案例让客户观看，希望客户从中可以理解本身的需求，然后在建设的过程中慢慢把需求建立起来，但这种方法往往让我们无法把握项目的真正范围，让范围不断蔓延，导致项目不断延误，未能有效的完成交付。每一个客户有本身的思想，有本身独特的需求，有企业本身的特色，观看别人的案例只让客户增加本身对结果的期盼，不能完全解决项目的最终目的。尤其是近年来的项目多是概念性的项目。所谓概念性项目是从商业概念所产生的项目，例如“一个客户管理系统”来对客户进行管理和提供客户的服务，建立客户满意度等类似的项目，又或者是客户需要建立一个“市场管理系统”来对企业产品销售进行有效的分析及开拓市场方向等项目。这些项目便是我们现在所说的“信息化”项目的建设。技术人员绝对不能够把握这些概念性项目的需求，也成为目前国内信息化过程的延误和信息化结果的最大障碍。九零年代中期，国际企业开始进行信息化，在无数惨痛教训后理解到技术人员本身的极限，对商业运营的最终目标并不认识，所以特意在软件行开发项目中建立一个新岗位，商业分析师（ Business Analyst ），商业分析师可以是资深的系统分析师，但必须曾经在工作的过程中对某一个行业的运营相当理解，这包括在某个行业中曾经负责开发多种不同的项目，对企业的运营需求和运营方向全面理解。也可能是一个部门的业务经理，经过培训后理解如何进行分析，如何建立商业模式等方法。才负责项目初期的信息收集，分析及设计工作。目的是因为技术人员对企业的业务并不认识，很难把握客户的真正需求，改由商业分析师来理解客户建立系统的最终目的，从目的中建立商业模式（ Business Model ），再从商业模式中建立主要的工作模块（ Process Modules ），从工作模块中建立运营流程（ Business procedures ），再从运营流程中建立项目需求，这时候才转交技术人员建立项目功能规格。

    我国要改善软件工程的困境，必须理解本身的问题，才能够提升我国软件工业的发展潜力。高校的老师及导师必须理解我国软件工业过去所走的冤枉路，才能够培育更优秀的技术人员和软件工程管理人员。软件服务商的领导必须认识本身企业的缺点，盲目去进行各种认证只能治标，不能全面解决企业本身的服务缺憾，需要建立本身的体系及制度，建立企业的开发文化，更需要全力提升管理人员，对软件工程的开发进行有效管理。而各应用单位的领导更需要认识本身必须投入项目的开发过程，才能够有效的让项目投资带来回报。