水平决定眼界

眼界决定心胸

心胸决定态度

态度体现水平

----

所以，

务必-

谦虚，平和，倾听，认同，合作，上进。

有一段时间没有更新自己的个人空间了。一是断网半年，在公司基本不怎么上外网；二是确实懒了，每天疲于应付工作，基本没有什么心情去想一些东西，去总结一些东西，去疑惑一些东西，进而去学习一些东西。

最近有一点点想法：有关过程管理工作的环境论因素。

我们经常抱怨一个公司的过程管理环境，从表层看，是人员配合，领导重视，生存压力等因素。但从深层次发掘，我们就会发现这其实是质量成熟度要求（质量管理要求）层面的环境。

某些做应用软件项目的公司，可能干着一锤子的买卖，它用这种一锤子买卖的方式比做百年老店更能得到现实利益的，那么它的质量管理要求是一种情况。

某些业务导向型而非技术导向型的公司，软件团队管理复杂度也不算大，其软件对健壮性等质量属性要求又一般，比如各类mis，那么它对质量管理的要求又是一种情况。

还有一种是系统的复杂性较高，技术与业务并重，对质量有非常严格的要求，如军工和电信，以及调度等，这种项目和公司对质量管理又是另外一个要求。

也许我们思索一下在这三种质量要求条件下，我们最能给企业带来现实的质量和经营业绩改善的点是什么，着眼于这个小点，兼顾一些战略点，那么才能在某些特定的环境因素下使自己的质量管理工作得到认同，认可，从而产生实质效果。这样的思路，也有利于我们言必CMMI之教条。

－－－－－－－－－－－－－－

馨园主人 罗耀秋

笑面人是轻，

笃思心路明；

日省吾所短，

持之定有成。

看到本版关于测试工具的讨论真是如火如荼阿。
不过我觉得测试缺陷的跟踪和管理其火力不应该集中在这些工具的应用上
而应该更多的集中在管理思想本身上吧。
我用过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 ），再从运营流程中建立项目需求，这时候才转交技术人员建立项目功能规格。

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

我的msn：luoyear@netease.com

谢谢各位支持本坛子的兄弟姐妹

可用性测试为您带来的好处
简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。
本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。
在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。

使用反复、周期性的设计过程
反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
·        及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
·        综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
·        及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。
·        反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。
相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。

构思阶段
产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。
在构思阶段，通常进行下列可用性活动：
环境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。
环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。
环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。
竞争性测试
通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。
竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争 — 产品必须比现有的进程更有效、更好。
进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：
·        计算机使用经验
·        年龄
·        接受培训的程度
·        用户群之间的社会关系
·        特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。

规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic® 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。
任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。
一些要考虑的问题和活动：
·        此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
·        创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
·        在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
·        与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
1.        每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比较。
2.        评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案中违反的相关可用性原则。
3.        一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：
1.        对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
2.        对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
3.        一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
4.        指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
·        不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？
·        操作符是指软件允许用户采取的操作。
·        方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
·        选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
·        展示用户对于任务范围的总体模型。
·        展示用户如何对项目进行分组或分类的。
·        展示用户对项目之间的关系和相似性的看法。
·        将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如 Jakob Nielsen 所述，反复的可用性测试包括：
1.        用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
2.        情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
3.        简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。
4.        启发式评估 — 基于基本可用性原则来评价界面。

开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。
在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。
真实代码测试
让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。
可用性实验室测试
在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。
注意：   作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。

稳定化阶段
当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。
基准测试
对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。
要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。

为下一版本做准备
将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：
·        竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有关竞争产品的数据作比较。
·        现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建的软件来找出存在哪些问题，可在下一版本加以解决。
·        关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。

参考文献和资源
文献和书籍
·        Boehm、Barry W.Software Engineering Economics. NY: Prentice Hall, 1981.(ISBN: 0138221227)
·        Dumas、Joseph S. and Janice C. Redish.A Practical Guide to Usability Testing. London: Intellect Books, 1999. (ISBN: 1841500208)
·        Helander、Martin、Thomas K. Landauer and Prasad V. Prabhu, eds.Handbook of Human-Computer Interaction. North-Holland, 1997. (ISBN: 0444818766)
·        John, B. E. "Why GOMS?" ACM Interactions, vol. 2, no. 4 (1995): 80-89.
·        Microsoft Site Server Development Guide
·        Nielsen, Jakob. Usability Engineering. Boston: AP Professional, 1994。(ISBN: 0125184069)

简介
在工作中体现可用性
在创建软件的环境中，术语“可用性”表示一种方法，它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计，它从设计过程的一开始就将用户关心的问题和意见考虑在内，并提出在任何设计决策中用户的需要都应摆在首位。
这种方法最显著的特点就是可用性测试。在测试中，用户使用产品的界面进行工作，通过界面进行交互，就他们的观点和关心的问题与设计人员和开发人员进行交流。
本文讨论了可用性的概念，并讨论了为什么可用性在所有软件设计项目中都是一个重要部分。本文的第一部分定义了在软件开发环境中可用性意味着什么，以及它与衡量产品价值的其它方面间的关联。第二部分回答了一些常见的问题，包括：为什么可用性很重要，以及如何在开发过程中体现以用户为中心的设计理念等。本文在结尾处列出了一些书籍、论文和组织机构名称，帮助您加深对可用性的了解，并在项目中应用可用性。
本文中讨论的大部分概念在零售和内部软件开发中均有所应用。在阅读本文时，请注意“用户”和“产品”等词语，并思考如何将其应用到您的项目和最终用户中。

可用性定义
易于使用
可用性是衡量使用一种产品来执行指定任务的难易程度的尺度，它与实用性和受欢迎度等相关概念是有差异的。
可用性与实用性
决定产品可接受性的核心属性是其有用性，它用于评价实际使用产品时，是否能达到设计人员期望产品实现的目标。有用性的概念可以进一步划分为实用性和可用性。虽然这些术语间有联系，但它们却不能相互替代。
实用性指产品执行任务的能力。根据设计，产品执行的任务越多，其实用性就越高。
让我们以二十世纪八十年代末问世的典型 Microsoft® MS-DOS® 字处理程序为例。此类程序提供了多种强大的文本编辑和处理功能，但需要用户学习和记忆几十个令人费解的按键后才能执行这些功能。可以说此类应用程序具有很高的实用性（它们为用户提供了必要的功能），但其可用性却较差（用户必须花费大量的时间和精力来学习和使用它们）。与之形成对比的是，一个设计合理的简单的应用程序（如计算器）使用起来很容易，但其实用性却有欠缺。
这两种性质都是一种产品被市场接受所必需的，而且它们都是总的有用性概念的一部分。显然，若程序很好用但没有什么有价值的功能，那么没有人会使用它；如果程序的功能强大但却很难使用，那么用户也很可能会拒绝这个程序而转向其它的替代品。
可用性测试帮助您判断用户使用产品执行特殊任务的难易程度。但是，它并不能直接帮助您判断产品自身是否有价值、是否实用（在可用性测试中，用户可能会主动提出一些关于实用性的意见，但任何意见都应通过其它更可靠的研究方法予以验证）。
喜欢它与使用它
受欢迎度往往表示产品中可取的特性。如果人们喜欢某产品，就更有可能使用它，并将它推荐给其他人。但是，与实用性一样，您一定要小心不要将受欢迎度和可用性混淆。
人们喜欢某产品的原因往往与实用性和可用性无关。他们可能被产品的样式和引人注目的外观吸引，或被心目中所赐予的该产品的地位吸引。人们倾向于喜欢很好用的产品，但这并不是说人们普遍喜爱的产品就是可用的。
可用性是指人们是否可以使用该产品来执行他们需要执行的任务。可用性测试主要用于评价性能而不是评价喜爱程度，但标准化的调查问卷也可以用来衡量人们对产品的喜爱程度。
发现、学习与有效性
可用性包含很多方面，但通常这一术语特指发现、学习和有效性这三种属性。
发现表示针对某种特定的需要去寻找并找到产品的某一功能。可用性测试可用于确定用户找到某一功能所用的时间，以及在整个过程中用户犯了多少错误（关于定位的错误选择）。
学习表示用户弄清楚如何运用所发现的功能来完成现有任务的过程。可用性测试可以确定这个过程的长短，以及在学习该功能期间用户犯了多少错误。
有效性表示用户“掌握”了某项功能，不再需要进一步学习即可使用。可用性测试可以确定有经验的用户使用该功能时执行必要步骤所需的时间。
可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂，导致用户基本上每次使用时都要重新学习；对于这些功能，Microsoft 通常开发了使用向导，在整个使用过程中对用户予以指导。
光喊口号是不够的
软件设计人员有时以为简单的口号，如“使产品更可用”，就可以解决可用性问题。虽然对可用性的积极态度是重要的，但是只有在具体的产品创建环境中，通过对普通用户进行恰当的可用性测试，才能为设计人员提供所需的信息，使产品可以满足用户的需要。“使产品更可用”应当成为每个软件设计人员的座右铭，但是这句话只对那些了解“可用性”含义的设计人员才有意义。而对普通用户进行测试就是可以找到的最可靠的途径。

常见问题
为什么要强调可用性问题呢？
如果您还没有在产品设计过程中将可用性因素考虑在内，您可能会问：可用性为什么是必要的，或可用性为什么是可取的？毕竟，不进行任何可用性工作，也可能发售一个可以工作的、没有错误的产品。但是，通过引入以用户为中心的设计理念可以使产品在很多方面得以很大改进。
减少用户拨打技术支持电话的次数是执行可用性测试的最佳理由。较差的可用性是用户拨打软件技术支持热线的主因，而每个软件公司主管以及信息服务经理都知道产品支持的成本是多么昂贵。此外，用户不得不寻求技术支持增加了用户对产品的潜在不满情绪。如果用户发现贵公司的产品使用起来十分容易，那么他们就不必频繁地打电话寻求技术支持了。
对于内部使用的软件，之所以将可用性作为开发过程中的一个重要部分，其原因还在于它减少了培训费用。对用户而言，可用性强的软件学习起来比可用性不受重视的产品学习起来要容易得多。用户能够更快地了解产品的各项功能，并能长久地掌握它，这直接减少了培训费用和时间。
可用性测试有助于促进用户对产品的接受程度。有很多因素决定了用户对产品的接受程度，这些因素包括可用性、实用性和受欢迎度。对于零售产品，用户的接受程度往往直接影响对产品的重复购买或对产品的忠诚度，这说明用户可能将产品推荐给其他人。对于内部应用程序，用户的接受程度决定用户是否愿意使用该软件执行任务，而这些软件就是针对这些任务设计的，这有助于提高生产效率。提高可用性是提高用户对产品的接受程度的一个因素。
可用性可将您的产品与您的竞争对手的产品区分开来。如果两个产品在实用性方面从本质上讲是一样的，那么人们很可能认为可用性更好的产品高出一筹。此外，由于 Microsoft® Windows® 的外观和感受以及随附的编程准则划定了基本用户界面的使用区域的标准，因此很多执行相似功能的程序其外观与操作在相当大的程度上是相似的。这些相似性表明，即使可用性上的细微差异也会对用户的喜好产生重大的影响。
最后请记住，每个产品最终都要进行可用性测试。用户每次使用您的产品时，都是在对它进行可用性测试，而他们对可用性优劣的意见将会影响他们是否继续使用该产品。将产品推向市场之前，对产品进行测试，可以有助于确保用户对产品的满意程度。
它的花费是多少？
软件设计人员和项目经理往往担心，如果采用以用户为中心的设计过程并执行适当的可用性测试，恐怕要占用大量的时间并花费大量的金钱。事实上，花费在关注用户方面的时间和金钱通常是相当少的，而且与不这样做而导致的花费相比，这点花费也是微不足道的。
例如，设想一下在开发周期的后期而不是在前期（产品仍处在开发阶段时）对设计进行修正您要花费多少时间和金钱吧！如果您一直等到 Beta 测试时期才使用户接触到产品以便进行可用性测试，就会发现自己不得不将花费了大量时间开发的程序的各部分分拆重做。而若等到产品真正发布时，如果要根据负面反馈进行修改或支持较差的设计，因为产品支持的庞大开销或用户对产品的接受程度较差等原因，很可能要支付高昂的费用。
合理的可用性研究通常只需要两周或更短的时间，并可以显著减少开发周期后期进行修改所需的时间和金钱。进行测试所需的花费将根据您的产品的性质以及所测试的界面部分的不同而有所不同。
可以认为可用性测试与代码测试是类似的。成功的项目经理在计划开发项目时总是会考虑到代码测试。他们并不认为代码测试是项目时间表或预算外的额外部分，而是将代码测试作为开发过程的一部分而计入成本。因为若不进行代码测试，那么花费反而会高得多。对于可用性测试，情况也是如此。
怎样获得可用性？
在理解可用性的重要性基础上，软件设计人员有时试图“获得”一些可用性，就好象可用性是一种成分，他们可以简单地把它添加到产品中，这样产品就更可用了。然而，可用性应当是设计过程本身的一部分，不是您可以在设计过程的随便某一地方添加的“东西”。可用性专家提到“用户关注的”与“以用户为中心的设计”的原因是：可用性取决于将用户的需要一直作为设计过程的中心。以用户为中心的设计根据需要的不同，包含的内容不单单是在界面中按照一组规则，对按钮和菜单布置进行管理。可用性测试是对设计工作进行检查的良机，而不是在产品中“添加”可用性的一种方法。
Gould、Boies 和 Lewis (1991) 为以用户为中心的设计定义了 4 个重要的原则：
·        及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
·        综合设计：设计的所有方面应当齐头并进的发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
·        及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。
·        反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
为什么应当将用户融入进来？
设计人员应当认识到他们自己不是普通的用户。与一般的用户相比，他们对正在开发的系统有着更深入的了解。因此，对大多数用户而言不明确或造成混淆的界面，可能对那些从事项目设计工作的人员来说是非常清晰的。某些软件设计人员可以在一定程度上代表普通用户，但他们绝对不能代替实际使用产品的真正用户。
因此，通过在早期关注普通用户的需要，并根据用户测试结果经常改进设计，以用户为中心的软件设计人员会提出更好的设计，并生产出更好的产品。
更好的设计将得到用户更好的认可。零售软件增加买进点的利益是很明显的：这增加了销售额。对于为内部使用而开发的软件，认可也是十分重要的：买进点增加将导致生产效率增加，并减少了对技术支持的需求。显然，从开发的一开始就将用户融入进来，并向用户表明您看重他们所关心的问题和需求，这将使用户更愿意协助您开发出更好的软件。
遵循这些准则就足够了吗？
Microsoft 为 Windows 计算平台开发了一系列界面准则，以此确保 Windows 程序具有一致的外观和感受。其它公司为非 Windows 计算平台开发了类似的准则，并且象 Jakob Nielsen 这样的专家撰写了大量关于设计可用 Web 页的文章。通过关于这些主题的大量信息，设计人员有时认为生产可用产品所需的全部工作就是严格遵守准则和规范。
这种想法的错误之处在于：准则在本质上是通用的。准则必须应用到各种各样不同的情况之中，因此它不能总是针对您正在设计的特定的应用程序制订最佳的行动方案。遵守一组合理编写的准则有助于您设计出风格一致的界面，但是您不能保证它是可用的，除非通过真正的用户对它进行了测试。当您的确要使用准则时，不要象使用详尽的说明书一样，希望根据准则执行的方法所生成的所有结果都是最好的。两个设计人员可以用两种不同的方法实施同一个准则，而两种实施方案对特定情况却不一定同等适用。而且，有时候严格遵守准则可能导致很差的结果，或在准则之间发生冲突。只有采用以用户为中心的设计，才可以在问题产生前排除它们。
对这个问题的另一种理解方式是：应当使以用户为中心的设计理念成为设计决策的决定因素，而不是以用户界面准则为决定因素。
是否需要创建可用性实验室？
不要以为可用性测试就意味着创建昂贵的实验室，在天花板上安装摄像机，安装单向镜，以及采用其它以小组为中心的设陷技术。的确，进行大量测试的公司通常认为建立专用的实验室十分方便，并且可用性顾问往往可以为客户提供各种各样的设施和设备，但您也可以在各种各样的设置和环境中执行有用、有效的可用性测试。
一种方法只需要一个测试人员（该测试人员对有人参与的研究工作与数据收集十分精通），在用户工作时坐在用户后面观察用户如何执行任务，这在会议室或办公室里就可以轻而易举地办到。Dumas 和 Redish (1999) 提供了大量关于使用观察法进行测试的信息。
随着可用性测试的进一步进行，您可以添加诸如摄像机、单向镜等设备，或其它帮助实时观察和记录用户显示器的工具。不必一下子添加所有的设备，即使一件一件地添加，也可以使您从可用性测试中获得更多有价值的东西。
另一种方法是，您可以将测试外包给可用性顾问。关于为您寻找合适顾问的几点提示信息，请参见下文的“我如何开始？”。
我如何开始？
一旦您决定将以用户为中心的设计原理运用到您的开发过程中，就需要决定是自己雇佣可用性专业人员还是将可用性测试外包给供应商。
可用性专业人员协会 (UPA) 有一份供应商指南，有助于找到为您执行测试的可用性顾问。
有些咨询部门还可以帮助您创建您自己的可用性实验室或开发内部的可用性程序，在您的设计过程中引入可用性理念。
如果您宁愿自己雇佣可用性专业人员，那么 Human Factors and Ergonomics Society 有职业介绍服务，使您可以找到潜在的雇员。很多可用性专业人员还属于 ACM Special Interest Group on Computer-Human Interaction (SIGCHI) 和 UPA，您也可以在他们的出版物和会刊上刊登招聘广告。
无论您选择哪种途径，请记住：您将要雇佣的是测试服务人员，而不是那些自己访问您的界面，并告诉您界面上有哪些错误的人员。设计人员不是普通用户的原则同样也适用于可用性专业人员。
关于这些公司和组织的信息，请参见下文的“资源”，您从中可以找到更多的关于可用性测试和以用户为中心的设计的内容。

资源
文献和书籍
Beyer、Hugh 和 Karen Holtzblatt。Contextual Design: Defining Customer-Centered Systems。San Francisco: Morgan Kaufmann, 1997。(ISBN: 1558604111)
Dumas、Joseph S. 和 Janice C. Redish。A Practical Guide to Usability Testing。 London: Intellect Books, 1999。(ISBN: 1841500208)
Gould、John D.、Stephen J. Boies 和 Clayton Lewis。"Making Usable, Useful, Productivity: Enhancing Computer Applications。" Communications of the ACM (January 1991): 72-86。
Hackos、JoAnn T. 和 Janice C. Redish。User and Task Analysis for Interface Design。New York: John Wiley and Sons, 1998。(ISBN: 0471178314)
Nielsen, Jakob。Usability Engineering。Boston: AP Professional, 1994。(ISBN: 0125184069)
Shneiderman 和 Ben。Designing the User Interface: Strategies for Effective Human-Computer Interaction。Reading, MA: Addison Wesley, 1998。(ISBN: 0201694972)

极端编程（eXtreme Programming，XP）的特点及讨论

转摘自XPchina.com

XP在很多方面都和我们传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。

特点如下：

不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布得软件开发的全过程。每个周期都进行充分的测试和集成。这样的好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的风险。

在软件设计中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件得合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中得熵值。

在专业分工中，提出在开发团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。

也有专门的软件架构的设计师，首先进行软件整体架构的设计。这种设计一般使用UML语言。

在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验，这样，可以获得客户的更多的反馈，使需求可以在开发前确定。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。通过不断的测试来保证软件的质量。在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。

在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。

在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长，适应自己的情况。当然，在每个问题上都要有唯一的决策人，同时，也要经过充分的交流和沟通。角色轮换就是在项目中，一个人在不同的周期中担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，要对整个项目的完成负责，任何人都可以对工作的任何部分提出自己的建议。任何人都可以从事任何工作。任何人都要对整个项目熟悉。这样做的优点是可以充分的锻炼人、可以发挥每个人的积极性、可以使项目不依赖于某个特定的人，方便今后的软件的维护，通过工作内容的变换可以提高人工作的兴趣。通过角色轮换还可以使每个人都劳逸结合，方便相互理解，避免由于不理解而造成的各种配合问题。

保证8小时工作制，避免加班。

（我加几条：要有充分的培训、要有每个人的提升空间、制定报酬要根据对企业的贡献大小，而不是职位的高低，允许下属比上级薪酬更高，薪酬的高低取决于绩效评定，同时绩效评定要尽可能量化。并且推行淘汰制。同时有有效的招聘制度。有强有力的后勤保障制度和轻松的企业文化。）

提出了成对编程的思路，就是每个模块的编码都是两个人一起干，共用一台电脑。这样，一个人编码时，令一个人就可以检查代码，或对编码的思路进行思考，写文档等。不再有另外的测试人员，两个人同时完成代码的测试，并且使先写测试程序然后再编程。这样避免了编程人员和测试人员的矛盾。也解决了一个人自己检查的局限性。两个人共同检查可以避免大多数的错误。在共同编程中还可以进行经验的交流和传授。也避免了将一个工作一直干下去的无聊，交流增加了情趣。并且两个人共同工作也增加了工作量的弹性，使项目计划的瓶颈工作能尽快解决。根据成对编程的思路，开发小组也可以分为两个小组，一个小组进行开发，另一个小组作改进和bug修正等工作。也有同样的效果。

在人员的分工上要灵活，要保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。

每天或隔天，开一个站立会议（保证开会时间尽量短），来解决工作时间不一致和相互打扰工作的情况。在每个迭代周期也有一个计划和分工等的全体大会

XP的实施方法就要求能适应工作中出现的问题，不断对xP进行改进，而不能照搬套用。

XP的目标就是发挥人的最大积极性，保证充分的交流。

XP得优势是能很好得适应需求得更改、设计框架得更改。

XP采用和建立一个通常框架相反得方法来适应需求，而是尽量简单。

问题：
有没有感觉实施xp的前提条件很多，如果这些条件不能满足就不能充分事实xp.例如8小时工作，工作环境等。

8小时工作可以说即是前提又是结果，如果不能8小时工作，让开发队伍有充分休息，大家怎么能结成pair，高效的开发？而如果开发效率低下，大家有怎么可能只8小时工作。--notyy

XP可以说是各种思想的大集合，实际上XP的核心特点就是原型法的软件开发方法。其它的各种特点可能不一定是XP独有的，只是针对目前软件工程中存在的问题，分别提出了很多思路独特的方法。这些方法并不是一个紧密的整体，相互直接有可能分离、独立。因此，了解了XP的方法，可以只应用它的几个特点，不一定全部照搬。比如成对编程、8小时工作制、轮岗等，都可以单独实施。－－tomz

这个观点不认同，XP核心特点并不是原型法的开发方法。原型法的关键是在通过原型获取需求后，要毫不犹豫的抛弃原型，重新开发，因此原型可以是很粗糙的，代码质量可以是很拙劣的。而且因为原型是用来获取整体需求，所以要求原型要完整，覆盖到整个项目的各功能点。 而xp是迭代开发，并没有一个包含所有功能的“原型”版本，而且对每一个“小版本”都有很高的质量要求，比如总共有10个功能点，原型法要求做一个覆盖所有10个功能点的粗糙版本，而XP要求先做一个有2个功能点的版本，然后再每个开发周期往上面加两个功能点，并且这包含两个功能点的版本是要“确实完成”的，是要经过充分的测试，重构、提炼的，让人放心的小版本。这一点与原型法有很大差别。 ----notyy

啊，我是门外汉，确实没有搞清“迭代”和“原型”的区别。用词有误。那就是说：“XP的核心特点是迭代”。－－tomz

我感觉部分岗位的集体主义的软件开发也是XP的很有用的方法。但不知道在中国是否符合国情。－－tomz

本文是根据IBM一个开发团队的XP故事总结的，在www.linuxaid.com.cn网站上看到的。但现在在IBM和linuxaid网站上都找不到这个文章了。－－tomz

精彩文章，可否转载？--notyy

转载没问题，这只是我的一个读书心得，没有发表过。不过你要转载到哪里？这里不是你的网站吗？已经贴上来了啊？－－tomz
question:
“在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。 ”
notyy兄，能详细讲一下吗？ 先编码后设计，有点不理解他的优点。。你先讲一下好吗？ 踏冰
世界上并没有先编码后设计的开发方法。xp的开发方法是边设计边编码。
所谓先编码后设计里的设计是指软件架构的设计，指先设计（和编码）局部的功能，在进行了几个周期的开发，有了足够多的需求和经验后再提炼出体系架构，是一种自下而上的设计方式。
好处是避免了先设计软件架构后编码的方式中容易出现的设计脱离实际，无法编码实现等问题。
缺点是早期设计变化剧烈，不断的refactoring，可能几个开发周期后，经过大量修改后设计会和第一个开发周期时所做的设计相差巨大。 但另一方面，这也正好说明，在编码前先设计软件架构，是非常困难的，很容易在后期发现难以克服的问题。--notyy
2002-8-30 23:51:13 tomz
极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接，前两者容易和最终编程产品脱节，容易做很多无用工，而对编程者来说，代码是最好的表达工具，所有的结构设计思想都马上可以用代码来表达，因此，不需要先对别人描述架构，只要编出来，别人自然懂了。
使用架构来表达毕竟了用编程直接表达在结构上会有脱节的地方。
另外，极端编程不明确区分设计者和编程者，编程者就是设计者，自然，程序代码就成了比较方便的架构表达工具。将两步并作一步，自然节省设计时间。
当然，并不是事先没有沟通，而是极端编程认为口头交流是最有效的，因此，就用不到架构描述工具。

计算机和通信技术的迅速发展，特别是Internet技术的发展与普及，为企业内部、企业与外部提供了快速、准确、可靠的信息交流渠道。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备支持系统。正是由于这样的市场需求与技术发展现状，为我国的IT行业带来了空前发展的机遇，特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力，其中软件质量保障在其发展过程中占有重要的位置。 众所周知，印度已成为世界上软件业增长最快的国家，目前每年软件业产值达数十亿美元，并且还在以每年30%～50%的速度增长。比较我国和印度的软件产业，就不难发现:中国拥有巨大的软件市场和世界公认的软件开发资源，在基础研究和对技术前瞻性的把握上，也有自己的优势，就整体社会经济环境而言也优于印度。此外，中国的软件开发人员费用比较低廉，仅是世界市场的1/3左右。虽然中国人并不缺乏软件开发的天赋，但是在越来越强调规模化经营的今天，先天不足的管理痼疾使我们举步维艰，难以摆脱小作坊式的软件开发模式。而印度软件业从一开始就立足于为美国软件企业服务，并遵循其软件开发的管理模式，与国际标准接轨。
管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
1.软件企业的组织结构
(1)A公司结构
图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。

图1
* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。
(2)项目组结构
1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
2) 汇报关系为:
Team Member->Team Leader->PC->EM->研发总负责人。
3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
1级:Software Engineer，刚毕业的本科生和研究生。
2级:Senior Software Engineer。
3级:Project Leader。
4级:Project Manager。
5级:Senior Project Manager。
3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。
A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。
A公司通常的项目组为4到5人，最多不超过10人。
以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。可以看出，A公司的组织结构非常清晰，各个部门分类非常细，任务明确，软件生产的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总经理，层层管理，沟通渠道畅通。而在我国，管理的不规范往往首先体现在公司的组织结构上，集中表现为部门的缺失和管理的交叉上。我国的软件公司，大部分规模较小，开发人员超过100人的公司很少。在印度，软件公司无论大小，都是“麻雀虽小，五脏俱全”，绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为，国内的软件企业要想有效地保障产品质量，首先就要在构架合理的组织结构上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构不合理，其他方面再下功夫也是徒劳。有人说，因为国内软件企业规模小，所以造成结构设置的欠缺，但笔者认为恰恰是因为没有建立一个规范化的组织结构，才会使软件产品质量不保，进而严重影响了企业的发展扩大。
2.项目计划
凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。
项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。
大概很多人都听过这样一句话：“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响，但对于软件企业而言，却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象？究其原因，笔者认为主要是因为对计划的重视程度不够，计划过于笼统、粗糙导致可执行性太差，再加上一些人为因素的影响，必然会产生这样的后果。
如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。
因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。
3.项目管理
当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：
(1)开发阶段和项目周期
开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
(2)流程
* A公司对流程比对项目更重视。
* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。
(3)计划
1) 计划详细、周到。
2) 流程中明确定义开发阶段。
3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
* 进入条件，输入;
* 验证方法;
* 结束条件，输出。
4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。
5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。
(4)Review
按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。
在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。
(5)QA
QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。
(6)度量数据
CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。
(7)团队精神
印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。
(8)培训
印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。
(9)配置管理
在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
(10)记录
记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
1)与客户和其他项目组的所有往来必须邮件记录。
2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。
3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。
4)记录比较准确、比较客观。
5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。
以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:
1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。
3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。
4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：
1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
2）合理的时间表――为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。
4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
5)沟通――在适当时机进行预排和检查;充分利用团组通信工具―电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。
4.PC（项目经理）
项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。
（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：
* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。
* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。
*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。
（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。
（3)总的说来，PC安排工作有这么几个特点:
a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。
b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:
* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。
* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。
* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。
* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。
d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。
e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。
f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者， 笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。
总结　　
以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在这个问题上不妨采取“拿来主义”的办法，对于好的，事实证明是成功的经验，首先是“占有”，然后才是“挑选”和“创新”。如果能把印度的管理经验真正领会并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用。

——采访印度NIIT CEO有感,一篇有趣的文章，论述中印程序员之间不同的另外一个方面
今天下午采访印度NIIT的CEO Vijay Thadani。NIIT是印度最大的IT培训机构，业务遍及38个国家和地区。同时，NIIT Tech. 也是一家CMM5的软件企业。
采访的详细内容大家会在CSDN的新闻里看到。我倒不是觉得这次采访有多么精彩，不过为了准备这次采访，我做了一些功课，查了一些资料，倒是真有些感触。
最大的感觉，我们还在喋喋不休的争论该不该走印度道路，印度已经一骑绝尘而去。我的同事邹震在一篇采访稿里总结说，印度大型现在软件企业的开发人员规模不是几百上千，而是几千上万，最大的InfoSys，其开发人员规模马上就要达到三万二千人，在软件工程化方面，印度已经走到了世界的最前列。现在再谈该不该走印度道路，谈要不要与印度竞争，已经是很可笑的事情了。而且，印度软件业并不象我们自我安慰的那样，安于外包的现状睡大觉，而是已经挺进自主技术领域，并在美国本土与IBM开展竞争。套句俗话，人家在产业升级！这样下去，5年之后，我们该讨论是不是要走越南道路了。
牢骚发过了，说点正题。
我问了这位CEO一个问题。我说中国程序员跟印度兄弟不一样，都很躁，几年拿不到高薪，得不到提升，就受不了了。印度兄弟好像不同，能忍。是不是这样？
他说不对，印度程序员也一样急躁，也想快快地拿高薪，早日升迁，这一点，全世界的程序员都差不多。
下面是最重要的话。
“差别在于，中国程序员把编程当艺术。这很正确，编程就是一门艺术。但是我们印度的程序员不但知道编程是艺术，而且认识到艺术背后还需要有纪律。你有你的艺术，我有我的艺术，她有她的艺术，只有通过纪律把我们的艺术整合起来，才能完成有价值的工作。我听说中国的程序员更擅长自由思考(free thinking)，所以在游戏软件方面很成功。印度软件的强项在于业务解决方案，在这个领域里，纪律格外重要。通过培训掌握技术之后，只要大家能够严格遵守纪律，认真把工作作到位，就能成功。”
艺术背后还有纪律，也许这就是印度软件成功的理念基础。对我们很多人来说，编程的最大魅力来自于创造的乐趣，来自于“不走寻常路”的乐趣，来自于超越的乐趣。如果编程是一件规规矩矩的机械工作，我想很多人都不会走上这条路。可是这当初驱使我们走上编程之路的乐趣，也许正是导致中国软件业始终无法壮大的本质原因。至少这位印度人是这么认识的。
我一向不赞成走印度道路，因为印度模式是最适合印度的软件发展模式，中国不是印度，当然不能走印度道路。但是印度成功的经验是可以借鉴的。印度人遵守纪律，于是就主攻业务类软件，接单定制，合同开发，建立超大型的软件企业。那么我们中国人的特点是什么？应该选择怎样的路线？建立怎样的软件产业结构？我不知道是否有人认真讨论过，不过似乎大家更多地在讨论“是走印度模式还是美国模式”这样的伪问题。我有的时候真的很奇怪，怎么我们就非得走个洋路线才能活下去？
这位CEO说中国的游戏软件很成功，不用多想也知道他没搞清楚，大概是听说中国网络游戏何其火爆，殊不知中国网络上的游戏，大多是韩国造。Free thinking? 我好像记得10多年前，人们说中国足球的优势是“灵巧”。

内容:

       功能驱动开发模式FDD
http://www.huihoo.com/development/fdd.html
FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发的一套针对中小型软件开发项目的开发模式。
FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。简单地说，FDD“是一个以Architecture为中心的，采用短迭代期，目期驱动的开发过程。它首先对整个项目建立起一个整体的模型，然后通过两周一次‘设计功能-实现功能’的迭代完成项目开发”。此处的“功能”是指“用户眼中最小的有用的功能”，它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度的跟踪均是以上述“功能”为单位进行的。在FDD中，它认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在FDD中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进程进行精确及时地监控。
FDD的使用需要有相应工具的支持，Peter Coad等人开发出了一套扩展的UML（FDD UML Extensions），并在Together中实现有关的功能，详细内容可参见后文。
在FDD中，存在“主要功能集”、“功能集”、“功能”等概念，它们之间的关系及示例如下所示：
主要功能集 = 功能集1 + 功能集2 + …
功能集 = 功能1 + 功能2 + …
其中，主要功能集是在初始阶段根据用户的需求所制定出来的比较粗的，有待于细化的对开发项目所需要功能的描述；功能是在开发过程细化的结果，在每个迭代期中需要实现若一干个功能，这些功能的集合被称之为功能集。
在FDD中，它将开发过程划分为如下五个阶段：
l         制定整体的模型
l         根据优先级列出功能的详细列表
l         依据功能制定计划
l         依据功能进行设计
l         实现功能
每个阶段的定义又是通过被称之为：ETVX的方法从下面四个方面加以描述的：
l         Entry：Specify clear and well defined entry criteria for the process；
l         Task：列出所有要实现的任务列表，名称，是否需要实现，任务描述；
l         Verification：；制定对过程结果的评批标准；
l         eXit：过程结束时所需的结果；

FDD过程示意图
在FDD中主要存在三类人员：主要开发人员、类的所有者、功能团队，它们各自的含义如下：
l         主要开发人员：用于领导其它开发人员进行DBF/BBF的开发，对开发工作进行监督（例如对设计及代码进行审查）。主要开发人员的数量由项目整体的大小所决定，如果需要加快开发进度则可以再培养新的主要开发人员。与其它开发人员相比，主要开发人员具有更高的开发效率。Fred Brooks在几十年前就提出了：增加开发人员数量只会降低开发效率。但对于小型的，以用户功能驱动的轻量及的开发过程此原则并不适用。在此过程中采用增加人员的方法可以提高开发的并行效率。
l         类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专门负责算法的开发人员。虽然FDD是面向用户功能的，而不是面向类的，但用户最终关心的是那些他们需的功能，而并不关心在开发时采用何种框架模式，所以在此以类为单位进行人员分配与开发的宗旨并不矛盾。
l         功能团队：开发时功能会被分配给主要开发人员，再由主要开发人员根据实现此功能所需类的所有关系找到有关的开发人员从而构成一个临时的（最多两周）的团队。一名开发人员可以同时负责多个类的开发工作，即他可以在同一时刻处于多个功能团队中。因此在每个DBF/BBF中功能团队的人员均可能发生变化。在此团队中主要开发人员处于核心地位，团队内部的交流也是经及为中心的。采用这种方法可以加速开发进度，并且主要开发人员还可以对过程进行必要的监控，保证设计与实现的一致性。从更高的角度来看，主要的系统设计师又负责监控各功能团队中的主要开发人员。
采用FDD方式进行开发时，各阶段时间的分配关系大致如下所示：
l         Develop an overall model                     10% initial, 4% on-going
l         Build a features list                             4% initial, 1% on-going
l         Plan by feature                                          2% initial, 2% on-going
l         Design by feature, build by feature              77%（两周一个迭代期）

DBF/BBF中各阶段时间分配关系：
l         DBF
²        Walk through the domain              1%
²        Design                                40%
²        Inspect the design                3%
l         BBF
²        Code/test                             45%
²        Inspect the code                   10%
²        Promote to build                   1%

需要注意的是：上述Coding的过程中还包含有单元测试的内容。此外单从DBF/BBF的过程来看，设计所有的时间要比编码的时间长（40% : 45%），但考虑到FDD的整个实施过程（包括前期的建模过程），设计的时间还是比编码的时间要长的（45% : 35%）。
在FDD中另一个重要的，并且也是十分有特色的部分就是它的报告功能。每周Release经理要召开一次会议，会议一般限定于30分钟以内，在会上每个主要的开发人员全面地介绍其所做的工作，并标识出相应的项目状态图。通过这种口头上的交流，可以确保各主要开发人员能对项目的其它部分有一个充分的了解。会后，Release经理还要根据有关内容更新数据库中的信息并生成相应的报告，这个报告将发送给项目团队、用户以及主要的管理人员。



为跟踪项目开发状态需要使用数据库对有关内容加以保存，在数据库中应保存如下信息：
l         类型（问题域、人的交互活动、系统交互活动）
l         标识（功能集前缀+序列号）
l         状态（正在处理、不再需要、正常）
l         主要功能集
l         功能集
l         文档引用信息
l         活动事件
l         主要开发人员
l         问题域分析时的计划日期，实际日期
l         设计时的计划日期，实际日期
l         设计复查时的计划日期，实际日期
l         编码时的计划日期，实际日期
l         编码复查时的计划日期，实际日期
l         提交构造时的计划日期，实际日期
l         备注

项目计划表

功能详细列表
另外，有关类及类的所有者的信息保存在其它的表中。根据数据库可自动生成有关报告。

项目已完成功能统计表

FDD中扩展的UML
FDD 过程 #1: 开发总体模型
Entry Criteria:
客户已准备好建立一个系统。他已经有采用某种形式保存的需求列表。此时用户可能还不能完全分清楚什么是他“必面要的”，什么是他“想要的，最好有的”，但这没有关系。
Tasks:
组建建模团队        项目管理        必须        建模团队是由来自于领域以及开发方面的永久性人员组成。在建模的过程中也可以从其它项目中人员以便有更多的人可以参与并对模型进行评估。
领域分析        建模团队        必须        领域专家对问题域进行介绍，此过程可能是20分钟也可能是几个小时，需根据具体的问题域情况决定。在介绍时所涉及的内容应比问题域稍大一些。
学习资料        建模团队        可选        学习各种资料，包括：组件模型、传统的或者是采用use-case方式描述的功能需求书、数据模型以及用记手册。
生成非正式的功能列表        系统设计师 主要程序员        必须        建模团队生成非正式的功能列表，至于具体的细化和完善留到下一阶段进行。如果需要的话，应将有关的参考资料一并注明。
开发子模型        划分为小组形式的建模团队        必须        系统设计师提出最初的组件或者是入手点。根据对问题域的理解，小组使用原型及组件创建出类图。创建过程如下：首要关心的是类以及它们之间的关系，然后是类所包含的函数，最后才是类所具有的属性。在寻找类的函数的过程中可以参考对问题域的理解，最初的功能列表，以及原型中所建议的函数等方法。同时还需要生成一个或多个非正式的序列图。
开发模型        系统设计师 建模团队        必须         
记录候选模型        系统设计师 主要程序员        必须        记录员（可以由团队人员分别担任）记录下来工作中所评估过的比较重要的但未被采用的模型，以便于将来在项目中参考。

Verification:
内部及外部的评审        建模团队        必须        参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。

Exit:
结束过程时，团队必须提交如下内容，并且这些内容已经过开发经理以及系统设计师的审阅及批准：
-          类图，包括：类、类间关系、类的函数以及属性。类及类间关系建立起了模型的大致轮廓。根据最初的功能有列表以及非正式的序列图而来的函数展现出系统的功能，并且是后续开发过程中建立详细功能列表的前提。此外还应有非正式的序列图。
-          非正式的功能列表。
-          其它可供选择的模型信息。

FDD 过程 #2: 创建功能列表
在此阶段，团队标识出所有的功能，对其加以分组，为其设定优先级，并设置相应的权重。
在下面的活动中，小组工作的重点在于功能，因此领域专家可以不再需要。
Entry Criteria:
建模团队已成功地完成了FDD第一阶段的工作，开发出了系统的整体模型。
Tasks:
组建功能列表团队        项目经理 开发经理        必须        功能列表团队是由来自于领域专家以及开发方面的固定人员构成的。
标识功能 创建功能集        功能列表团队        必须        团队首先从上一阶段得到的非正式的功能列表入手，接着：
                -          将模型中的函数转换为功能
                -          将模型中的moment-intervals转换为功能集（并将功能集再组织成主功能集），头脑风暴，选择，添加功能以便实现用户所要的以及所想的。
                在此采用下述格式进行描述：
                -          针对功能： <action>the<result><by | for | of | to>a(n)<object>
                -          针对功能集：<action><-ing>a(n)<object>
                -          针对主功能集：<object>management
                此处的object可以指一个人、一个地点或者一件事（包括：角色、某一时刻、某一时间段或者是描述）
为功能集以及功能设置优先级        功能列表团队        必须        通过“Feature Board”为功能集以及功能设置优先级。优先级的划分：A（必须实现），B（最好能实现），C（如果可能则实现），D（以后再实现）。设置时是依据用户的满意程序所定的。
分解复杂功能        功能列表团队        必须        在系统设计师的带领下开发人员对功能进行查开，以便找到那些无法在两周之内完成的功能，对此类功能应将其细分为更小的功能或步骤。

Verification:
内部及外部的评审        功能列表团队        必须        参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。

Exit Criteria:
    本阶段结束时，详细的功能列表必需已经产生了，并且将功能进行分组形成主功能集以及功能集，此外这些内容已经过开发经理以及系统设计师的审阅及批准。

FDD 过程 #3: 根据功能制定计划
根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。
Entry Criteria:
功能列表团队已成功地完成了FDD第二阶段的工作，并已形成详细的功能列表。
Tasks:
计划制定团队        项目经理        必须        计划制定团队由项目经理、开发经理以及主要开发人员给成。
制定功能以及功能集的开发顺序        计划制定团队        必须        计划制定团队设置开发的先后顺序，并制定出最初的针对功能集或者主要功能集的完成日期。
为类指定实现人        计划制定团队        必须        根据开发顺序以及功能的重要性为每个类指定特定的实现人。
为主要功能集以及功能集指定相应负责的主要设计人员        计划制定团队        必须        根据开发顺序以及功能的重要性为每个主要功能集或者是功能集指定相应负责的主要开发人员。

Verification:
内部及外部的评审        计划制定团队        必须        参与此项目的计划制定人员进行内部自评，外部评审是必须的，并且是由更高一级的管理人员进行。采用“由顶向下”的方式让所有的开发人员均对此计划进行评估。通常一些开发人员由于过分保守会希望延长开发时间。但另一方面，项目经理或者是开发组长又会觉得“每个人都具有与我相同的能力”从而认为可以提前完成开发。在此应进行相应的平衡。

Exit Criteria:
本阶段结束时，开发计划已经产生了，并且这些内容已经过开发经理以及主要设计师的审阅及批准。计划中应包括以下内容：
-          一个整体的开发日期
-          针对每个主要功能集、功能集、功能指定有关负责人（CP）以及完成时间
-          针对每个类，指定负责其完成的开发人
注意：
    为便于为功能设置优先级，可以创建一个称之为FFB（待实现功能板）。

FDD 过程 #4: 根据功能进行设计（DBF）
根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。
Entry Criteria:
计划制定团队已成功地完成了FDD第三阶段的工作。
Tasks:
组建DBF团队        主要程序员        必须        主要开发人员从已有的类中找与可能与特点功能有关的类，然后找到负责实现这些类的开发人员并将他们组建成功能实现团队。开始进行功能的设计，如果需要的话，还可以请领域专家加入。
问题域学习        功能实现团队 领域专家        可选        （本步骤是可选的，主要依赖于功能的复杂性而定）领域专家将对问题域进行一个一般性的介绍，他只介绍与功能有关的内容，但这并不是为理解与功能有关的上下文所必须的工作。
学习有关参考资料        功能实现团队        可选        （本步骤是可选的，主要依赖于功能的复杂性而定）根据功能列表中所列的参考书目以及其它的可拿到的资料，功能实现团队的成员进行学习，以便获得与功能相关的详细的信息。
创建序列图        功能实现团队        必须        根据对功能的理解以及原有的非正式的序列图和组件，功能实现团队创建一正式的，详细的序列图。同时应记录下可选择的其它方案、决定以及注释。主要的开发人员将序列图添加至项目模型中（同时也要更新相应的类图）。
实现类及其方法的原型        功能实现团队        必须        每位类的实现人员根据序列图更新有关类及类中的方法，这包括：方法的参数、返回值、错误处理以及消息的发送。
设计复查        功能实现团队        必须        功能实现团队完成对设计的复查。如果主要开发人员认为有关功能的设计比较复杂并对其有所担心的话，他可以从别的地方请若干人员一起进行复查。
记录设计复查活动        文档人员        必须        团队中的文档人员针对类的实现人按顺序将有关设计复查的活动记录下来。

Verification:
设计复查        功能实现团队        必须        功能设计团队通过对序列图的“走查“实现内部的复查。外部评审是必须的，以确保存有关功能均以实现。

Exit Criteria:
本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：
-          功能及其相关参考资料（如果有的话）
-          详细的序列图
-          更新后的类图
-          更新后的类及其方法原型
-          开发团队认为有价值的其它实现方案

FDD 过程 #5: 根据功能进行设计（BBF）
在DBF工作的基础上，每个类的实现者完成类的各个方法。此外他还需完善基于类的测试方案并实现类一级的单元测试。根据主要开发人员的意见，功能实现团队可能还需在进行单元测试之前先进行源代码检查。当代码编写并检查后开发人员就将其放入配置管理系统中。在所有的类均已完成并Check-In之后，主要开发人员将代码提升以便进行构造。
Entry Criteria:
功能实现团队已成功地完成了FDD第四阶段的工作。
Tasks:
实现类及其方法        功能实现团队        必须        根据DBF中的详细的序列图类的实现人员完成类的方法的实现。此外他也要为测试实现有关的测试方法。主要开发人员则需添加针对功能的测试方法。
代码检查        功能实现团队        必须        主要开发人员负责安排一次针对BBF的代码检查，检查可以在单元测试之前也可以在其后。一般检查是由功能实现团队成员加以完成的，如果主要开发人员认为需要的话，也可以请团队以外的人进行检查。
代码检查记录        文档人员        必须        团队中的文档人员针对每个类的实现人将有关的代码检查活动记录下来。
单元测试        功能实现团队        必须        每个类的实现人员均需测试相应的类的代码以及此类所支持的功能。作为所有功能的集成者，主要开发人员对整个功能进行测试。
Check-In代码并对其进行构造        功能实现团队        必须        代码一旦编写完成并经过检查和测试，类的实现人就可以将其放入配置管理系统中。当所有的类均已完成Check-In并且可以正常工作时，主要开发人员将提升代码以便进行构造，同时更新在功能列表中的有关功能的状态信息。

Verification:
代码检查及单元测试        功能实现团队        必须        功能实现团队必须进行代码检查。文档人员应记录有关活动。

Exit Criteria:
本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：
-          实现了类的方法并对代码进行了检查和单元测试
-          按顺序针对每个类的方法的单元测试记录
-          类已被开发人员Check-In，主要开发人员已提升代码进行构造并同步更新功能状态。

再论"业余"和"专业"
----致力职业化 提高成功力
文档版本
版本
创建时间
创建人
备注

1.0.0926.1
2003-9-26
郑昀
第一稿

1.0.0927.1
2003-9-27
郑昀
第二稿

SQWebMail之烂
外面比较盛行的一种qmail的Web界面，是SQWebMail，还算是比较受人追捧的，而且框架搭也算是好的。
但你看看他的源代码。不说别的，只要看主程序sqwebmail.c的源代码就知道了，严格说，这整个工程一点也不符合软件工程编码规范。
sqwebmail-3.3.1文件夹下有818个文件，27个子文件夹，但是注释呢，命名规范呢？其中代码耦合性也太强，动一发而牵全身，很不好维护。这竟然是一帮大学里的教授后来改进的版本，一砣：

/*

** Copyright 1998 - 2001 Double Precision, Inc.  See COPYING for

** distribution information.

*/

static void do_output_form_loop(FILE *f)
{
     if (strcmp(kw, "a") == 0)
         {
              …
         }

         else if (strcmp(kw, "d") == 0)

         {

              …

         }

         else if (strcmp(kw, "D") == 0)

         {

              …

         }

         else if (strcmp(kw, "G") == 0)

         {

              …

         }

         else if (strcmp(kw, "r") == 0)

         {

              …

         }

         else if (strcmp(kw, "s") == 0)

         {

              ….

微软的源代码
让我们再来看看微软的源代码，这个源代码大家机器上都有，不是什么秘密，就在C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC下面，看看人家怎么做的，再看看sqWebMail。

    咱们不讨论算法意义上的有无漏洞，兹为了说明代码的可读性，举一个最简单的例子，微软的工程师是这么写一个strlen的经典实现：

/***
*strlen.c - contains strlen() routine
*
*       Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
*       strlen returns the length of a null-terminated string,
*       not including the null byte itself.
*
*******************************************************************************/

#include <cruntime.h>
#include <string.h>

#ifdef _MSC_VER
#pragma function(strlen)
#endif  /* _MSC_VER */

/***
*strlen - return the length of a null-terminated string
*
*Purpose:
*       Finds the length in bytes of the given string, not including
*       the final null character.
*
*Entry:
*       const char * str - string whose length is to be computed
*
*Exit:
*       length of the string "str", exclusive of the final null byte
*
*Exceptions:
*
*******************************************************************************/

size_t __cdecl strlen (
        const char * str
        )
{
        const char *eos = str;

        while( *eos++ ) ;

        return( (int)(eos - str - 1) );
}

    当然，微软的STL实现版本是公认的可读性差，我也看不过眼，换了STLPort了事。
想跟Microsoft,Oracle,CA,IBM竞争吗？
在我看来，我不管你是什么软件公司，管你是什么主义战士，就一个原则，要是不会写文档，不会写注释，写个函数连个输入输出异常注释都没有，那你就别在这行混了，不够丢人现眼的。有时间也翻翻软件工程，软件管理的书，看看那个书上赞成软件没有注释，没有文档？
    花钱买享受，这是人生的一个基本原则，干吗在那里吭哧吭哧一代人又一代人反复看着同一批糟糕的源代码，还给自己脸上贴金“源代码剖析”，那是因为你不剖析都不行。简直就是浪费生命。公司要赚钱，要快。没本事写注释的人就开掉，没本事遵循软件工程的人就开掉，这就是我的原则。想加入CMM的行列吗？最起码你的公司要过ISO9001吧？
你们公司有吗？就靠没注释没文档？能过吗？能够跟Microsoft,Oracle,CA,IBM竞争吗？

自由软件的“自由”含义：
自由软件，一般指遵循GPL或LGPL规则的程序。GPL或LGPL规则要求源代码公开，并且允许你在遵循GPL或LGPL的情况下享有共享和修改自由软件的自由。
    当我们谈到自由软件（free software）时，我们指的是自由而不是价格。我们的GNU通用公共许可证决意保证你有发布自由软件的自由（如果你愿意，你可以对此项服务收取一定的费用）；保证你能收到源程序或者在你需要时能得到它；保证你能修改软件或将它的一部分用于新的自由软件；而且还保证你知道你能做这些事情。
    首先，GPL规则中并没有要求软件的维护者一定要提供详细的文档和注释（而且我找了几个著名的自由软件源代码看了一下，注释还是有的，只不过没有详细到每行代码都有的地步。）。我认为详细的文档和注释作者是作为服务提供的，而服务是要收费的。国内的第一个开源软件项目Minigui（一个极好的中文图形界面，可以只有2兆大小），他提供源代码和用户使用说明的详细文档，至于开发文档和函数库说明，他会收取600元的费用。我认为这个价格只是个成本价，假如你连这点费用都不肯付的话，那就没什么好说的了。
至于微软，由于你根本就见不到源代码，所以根本不存在为他的文档和注释发愁的情况。不要说你们公司能见到部分源码，你们是微软的合作伙伴，那别的人呢？而自由软件的源码是对所有人开放的。更何况你们也只能见到一小部分源码而已。而且微软决不会允许你把他的产品移植到别的操作系统上或一些新的机器上的，这些工作只有他自己才能做，因为你见不到所有的相关源代码。而自由软件就可以，你可以把他移植到任何一个操作系统上，包括windows。一个新的cpu芯片出来，没多久就会有一个黑客把linux移植上去，而这个黑客并不是linux的维护者，为什么他可以作到这样的事呢，因为自由软件是源码公开的。
    我认为微软之所以提供详细的文档和接口说明，部分原因是他不提供源代码，不得不这么做，否则别人就没有任何办法去使用他的产品了。当然了，微软产品的简单易用是出了名的。可是由于你没有源码，很多时候为了达到某个目的，除了微软替你去做，你是根本无法完成的。例如高性能和新的功能。你难道可以命令微软去做这一切么？
    所以，不要对自由软件有这么大的意见。假如你想要详细的文档，你可以购买他们的服务。如果维护者不是某个公司，而是个人行为的话，你可以和他本人联系（一般他都会留下e_mail），也许他不收费就会提供给你的，即使收费，我想也不会比微软更贵的！

做Coding，还是多一点职业道德
专业做Coding，还是多一点职业道德，多看看软件工程的书。想想如果是你开公司，你难道会鼓励你手下的人不写注释，不写文档吗？
有机会的话，读读《Code Complete》(http://www.csdn.net/develop/Read_Article.asp?Id=10997)，这本几十年前的书，就已经说得很明白了：

交流和合作
    真正优秀的程序员应学会怎样和别人工作和娱乐，编写可读代码是对程序员作为组中一员的要求之一。
    计算机也就同其它人一样能读懂你的代码，但是它要比其它人更能阅读质量差的代码。作为可读性原则，你应将修改你的代码的人时刻记在心上。开发程序首先应同程序员交流，其次则是和计算机交流。
    绝大多数高水平程序员喜欢使自己程序的可读性强，并抽出充足的时间这样作。虽然只有一些人能坚持到底，而且其中一些人还是高水平的代码编写者，对开发中程序员级别的了解，有助于解释什么地方适合于此原则：
    级别1：初学者
    初学者是能使用一种语言基本能力的程序员，这样的人能够使用子程序、循环、条件语句和其它许多语言特征。
    级别2：中间者
    中间级程序员有使用多种语言的能力，并且至少非常熟悉某一种语言。
    级别3：专家
    编程专家对其语言或环境或对这二者有着很深的造诣，这种级别的程序员对公司有价值的，而且有些程序员往往就停留在这个水平上。
    级别4：大师
    大师有着专家那样的专业知识，并能意识到编程只是15％和计算机交流，其余85％是和人打交道。一般程序员只有30％的时间甚至更少。大师所编写的代码与其说是给计算机看倒不如说是给人看的。真正的大师级程序员所编写的代码是十分清晰易懂的，而且他们注意建立有关文档。他们也不想浪费其精力去重建本来用一句注释就能说清楚的代码段的逻辑结构。
    一位不强调可读性的高水平代码者可能停留在级别3的水平上，但是问题还不止如此。依作者本人的经验，人们编写不可读代码的主要原因在于他们所编代码质量较差。他们并不是自言自语地说：“我所编代码不好，所以我要使其难以读懂”，而是他们并不能完整地理解自己的代码以致于不能使其是可读的，这就使他们只能停留在1或2级的水平上。我所见的最差的代码是由一个任何人看了她的程序后都会望而生畏的人所编写的。最终，她的上司威胁说如她再不改正就要解雇她。她的代码是不作注释的，并且其程序中充满了如x，xx，xxx，xx1和xx2这样的全局变量。她的代码给了她大量的机会显示她的改错能力。
记住我们是专业程序员，我们的视角一定要和业余的区分开来。
我们不是自由软件工作者。
我们是靠这个赚钱的。所以，你用不着替他们辩护。因为你天生应该喜欢让你赚到更多钱的事物。
我赞同微软的商业运作方式。我赞同付费服务。因为我也是靠这个吃饭的。
不管是微软，还是IBM，都有许多这方面的专家现身说法，多读读这些人的书。别相信那些小公司的或者在校的学生，有时候他们的话是毒药，会毒害你的心灵，蒙蔽你的双眼，让你看不清楚商业社会里面的游戏规则。
"业余"和"专业"
下面摘录透明采访软件思想家Gerald Weinberg的访谈摘录，在http://www.umlchina.net/touming.html：

　　 "业余"和"专业"
　　 "程序开发"这个词所蕴含的行为方式是无穷无尽的。　　
　　一位业余程序员可能刚刚用六条语句写就了一个BASIC程序，可以用来求解二次方程的根，便开始就程序开发的理论与实践侃侃而谈--最令专业程序员们反感的，莫过于此。
　　 --《程序开发心理学》，第7章
　　 《程》：我注意到您多次强调"业余程序员"和"专业程序员"之间的差异……
　　 GW：因为我认为这是一个非常重要的观念。并不是"以编程为生的人"就有资格自称"专业程序员"的，但真正对软件学科起到推动作用的全然是专业程序员。这并非贬低业余程序员，任何一门学科都有业余爱好者，这无可厚非。但有必要划清业余选手和专业选手之间的界限，这样业余选手也能找到自己努力的方向。
　　 《程》：可是，如今软件的范围如此宽泛。从政府机关到航天飞机，从移动电话到超级市场，到处都有软件。各种软件之间的差异如此巨大，我们又该如何区分专业程序员和业余程序员呢？

　　 GW：在我看来，首先应该考虑的是他们编程的目的。如果只是为一己私利而编程，如果编程的结果对别人毫无影响，这就是业余程序员的编程方式。
　　举个例子吧，计算机系的研究生在知识的深度和广度上都已经相当不错了，但他们通常只是为自己编程--为了学习、或者为了拿到学位，所以他们仍旧只是业余程序员。如果他们在学习之余还有一份工作，为别人开发实际使用的软件，这时他们就是专业程序员。
　　请记住，专业程序员未必都很出色，业余程序员也可能出类拔萃，但他们编程的目的是不同的，这决定了他们之间本质性的差异。
　　 《程》：自从知道您对"专业"和"业余"的划分之后，我就一直想了解您对共享软件（share-ware）的看法。很多年轻程序员怀着淘金梦去做共享软件，您认为共享软件对于软件行业有什么贡献？
　　 GW：几乎所有的共享软件都是垃圾。虽然商业软件和开源软件也有不少垃圾，但共享软件几乎全是垃圾。我曾经试用过一些共享软件，但仅仅是尝试而已。如果我要掏钱买一个软件来用，我一定要求有一家值得信赖的公司为它提供支持。至少在美国，值得信赖的软件公司并不多。很多公司开张不到五年就倒闭，然后他们的顾客再也得不到任何支持。而共享软件，它们的用户能得到的保障就更少了。不，至少我不会去买这样不可靠的软件。
　　如果从软件行业的角度来说，共享软件给年轻人们灌输了很糟糕的习惯，让他们以一种业余选手的方式工作。共享软件的作者们习惯于单打独斗，总是凭着自己的爱好工作，这种牛仔式的工作方式至少是缺乏专业精神的。
小结
      我的想法就是，共享软件或者帮别人打零工的制作流程，给了年轻气盛的程序员们一种缺少项目管理的开发环境，这是不太好的修炼方式，容易走火入魔。
“即使是一个不够完美的东西，在某个特定时期也有他存在的价值”，这个辩证法我当然同意。但是我认为一个项目的源代码最基本的构成因素就是代码和注释和文档，这是三要素，如果没有这些东西，就像生下个儿子却没有JJ一样，根本就没有面世的必要。所以这不是完美不完美的问题。

开源项目和商业软件，如果不遵守基本项目生存规则，无论其中有多么高的高手参与，一样会失败。
我赞同商业开发模式，但不反对开源，如果做得好，我们也会拿来主义。如果做得只是一个徒有代码和功能的开源项目，那我觉得他会走向衰亡。看看SourceFouge上的那么多东西，真正有几个能够为商业社会所采用？几率有多大？其实像有着优秀项目的人，如果归拢到公司里，可能会有更大的发展。因为商业公司有足够的财力推广，有足够的人力包装。
欢迎指正和讨论。
本文档所包含的信息代表了在发布之日，zhengyun_ustc对所讨论问题的当前看法。
本文档仅供参考。
用户必须遵守所有适用的版权法。在不对版权法所规定的权利加以限制的情况下，如未得到 zhengyun_ustc和CSDN.Net明确的书面许可，不得出于任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。

Thank CJW
Written by zhengyun_ustc ( at ) hotmail.com