无处不在的二八原理
无处不在的二八原理
2009-03-26 作者：编程随想 来源：编程随想的blog
| 什么是二八原理 我估计看我博客的人里面，应该有很多人听说过二八原理（如果你之前从来没听说过，那你的知识面有 太窄的嫌疑）。但是知道二八原理的人有很多却不会（或者不善于）运用。直接的后果就是你在各种事情上付出了很多时间与精力，但是回报却很少。鉴于该原理非 常非常的实用，我打算专门写一个系列来聊聊和它相关的话题。 ★什么是二八原理 按照惯例，先说说什么是二八原理（如果你已经知道二八原理，可以跳过这部分）。二八原理（又名80/20原理、帕雷托原理）最早是由意大利的经济学家帕雷 托提出来的，具体的定义请看这里。通俗地讲，就是因果的不对称。20%的原因导致了80%的结果；而其它80%的原因只产生20%的结果。当然，这里提到 的二八开的比例不是绝对的，从三七开到一九开都有可能。 为了给不了解它的人一点感性认识，我举几个例子： 少数有钱人掌握了社会的大部分财富（帕雷托就是从财富分布中发现该原理的） 公司里大部分的销售业绩由小部分的销售人员创造 大部分开发人员只使用少数的编程语言，而大量的编程语言几乎没人用 大部分的bug都集中在少数开发人员身上 ★如何运用 首先，这个原理的关键处就在于它挑战了传统的理念。比如小时候老师经常教导我们：“一分付出一分回报”。用数学的术语讲，就是付出和回报是呈线性相关的。 很多人受此影响（可能是潜意识的影响），都习惯于平均分配时间、精力来处理问题。结果就导致我前面所说的投入很多，回报很少。因此，要运用二八原理之前， 你先得改变自己头脑中的思维定势，要以“不平等”的观点来看周围的问题。（关于改变思维定势，关键还是靠自己，我帮不上太大忙） 其次，你得学会如何区分重要与次要。这个就属于方法论的问题。我之前写过几个帖子都和这方面有关，比如：“如何选择IT技术书籍”和“做正确的事”，之后 我还会继续写相关的帖子（有些包含在本系列中），希望对大伙儿能有所帮助。 最后，为了给大伙儿加深点印象，我们来看一段乔布斯的名言： 我每天都会对着镜子自问：“如果今天是我生命的最后一天，我还会做我今天打算做的事情吗？”假如连续好几天都是否定的回答，那我就必须有所改变了。 在软件开发中的应用 上次聊了“什么是二八原理”，接下来得说说如何运用了。由于本博客主要谈IT技术，显然要先来说 说和程序员有关的那些事。为了不至于太抽象，我们以开发文本编辑器为例（这玩意大伙儿都熟悉，省得费口水解释），来说说不同职责的开发人员在开发过程中该 如何具体运用二八原理。 ★需求分析 需求分析在整个开发过程中占的工作量不大，但是产生的影响巨大（这又是一个二八原理的例子）。既然需求分析如此重要，照理说应该安排最强的人来搞。但实际 情况往往不是如此：很多公司负责需求分析的人并不胜任这项工作。我经历过几个不太成功的项目，其问题的根源都和需求分析有关。 需求分析最要紧的是：搞清楚用户到底想要什么？如果这个问题搞错了、搞偏了，后面的步骤做得再好也是白搭（比如客户想要一个文本编辑器，结果你搞了个图形 编辑器给他）。这方面其实有很多的道道，限于篇幅就不展开了，大伙儿如果有兴趣，以后可以单独说一下。 在搞清楚“用户想要什么”之后，接着要整理出功能列表（也有叫Feature List），并筛选出大约20%的重点功能。这个步骤是我今天主要想介绍的，因为这个步骤和后续的各项开发密切相关。一般来说，功能筛选的依据有如下几 个： 1、用户经常用的功能（比如save、copy、cut、paste） 2、宣传的卖点（要能够超出同类软件，吸引眼球） 3、和用户利益密切相关的功能（这种功能不允许出错，比如存盘功能） 这个筛选的过程要尽早完成，而且最好是产品人员、开发人员、测试人员三方的头头一起讨论，以保证立场客观、观点全面。筛选出重要功能点后，其他人员的工作 安排要"以重点功能为纲"，有所侧重。 ★项目管理 如果你是个项目经理，在排项目计划时，就得尽量优先安排重点功能的开发/测试，而且要安排能力强的人员来完成。按照我以前的做法，重点功能排计划至少得留 出1/3的时间余量，以防万一（事实证明，几乎每个稍大点的项目都会出现万一）。至于非重点功能，尽量排到后面，安排能力一般的人开发/测试。 然后，在项目进行过程中，肯定要有定期的例会。作为项目经理，你应该主要关注重点功能的进度情况和风险情况。 一旦项目有延期的风险，就从非重点功能开始裁减（俗称砍功能）。由于是裁减非重点功能，不至于产生致命的影响。 ★设计界面 设计界面时，你得保证所有的常用功能都放在显著的位置（比如工具条）；还得保证它们用起来方便（比如提供快捷键和右键菜单支持）。 对于卖点，它不一定是常用功能，它的目的是激起用户的购买欲望和使用欲望。因此你要把它们设计得比较酷，有噱头。 对于利益相关的功能，大部分情况下都是侧重于业务逻辑实现。如果它既不是常用功能、也不是卖点，那么界面设计方面倒不一定要额外花大力气。 其它的非重点功能，只要按照常规方法设计，不用花太大精力。 ★编写代码 我发现很多开发人员有几个通病：先做有趣或容易的功能，然后再做无聊或者繁琐的功能；对自己有兴趣的功能投入精力多，对自己没兴趣的简单应付。 以上这些都是开发的大忌。作为一个职业的开发人员，不应该以自己的兴趣和喜好来决定开发的轻重缓急。正确做法应该如下： 你首先得用主要精力完成上述所说的重点功能，而且要保证它们的代码质量尽可能好，尽可能方便维护（重点功能往往是经常有需求变更，经常被修改的）。 对于重点功能中的“常用功能”，要保证时间性能够好（能快速响应）。对于"用户利益相关的功能"，要保证bug尽可能少（尤其是安全性、稳定性、健壮性的 bug）。 至于其它的非重点功能，只要不出明显bug，有点小缺陷无伤大雅。 ★测试 如果你是个测试人员，你同样要把主要精力用于测试那些重点功能。对于"用户利益相关的功能"，多进行一些健壮性测试、稳定性、安全性等测试（比如测试保存 大文件是否会出错）。对于常用功能，主要进行易用性和性能测试（比如拷贝、粘贴是否易用）。 至于其它功能，只要进行普通的测试，保证它不出现明显和严重bug即可。要知道Windows 2000发布的时候，尚遗留上千个未修复的bug（当然都是低优先级的），微软不也照样发布。 ★产品演示 有些软件开发完之后，会搞一些Demo进行宣传。如果你是负责进行Demo的人，你肯定要把主要的Demo时间用来秀软件的卖点，这样给客户的印象最深 刻，效果最好；至于非卖点的功能，都未必要提及。 在管理方面的应用 前两周由于聊了“每日构建”系列和“C++对象之死”系列，把二八原理系列给搁置了一些时间。今 天终于又回到这个系列上了。我估计列位看官中，可能有不少人打算将来往管理方向发展，所以在聊完“二八原理在软件开发的应用”之后，咱们就来聊聊管理方面 的话题。 如果你已经在管理岗位上干活，希望后面的帖子能够对你有帮助；如果你尚未担任管理职能，但是将来有这方面的打算，也可以先大概了解一下。事先声明：管理方 面帖子聊的内容只是我个人的经验，仅供大伙儿参考 :-) 在开始讲后续的“人员招聘”、“员工激励”等内容之前，先得说一下“三种人”的问题。由于列位看 官大都在IT圈内混，所以今天我们就拿软件业来说事。但要记住，三种人的划分其实也适用于其它行业。 按照二八原理，优秀的员工在整个行业中大约占5%-20%；同理，糟糕的员工也大约占类似的比例。剩下那60%-90%的员工，我们称之为平庸的员工（说 好听点叫普通的员工）。熟悉数学的同学可能会想到这类似于正态分布。为了形象点，找了一张正态分布图来比划一下（见下图，绿色表示优秀员工、红色是糟糕员 工）。
关于优秀的程序员有什么特点，在以前的帖子“怎样才算是优秀开发人员”里已经描述过了，这里就不 再啰嗦。 至于什么是糟糕的程序员，我给出几个特征，大伙儿自个琢磨一下，身边有没有这样的人。 ◇不诚信 ◇老油条（包括没责任心、没工作热情、混日子等） ◇拒绝学习者（具体特征详见“关于自学能力”） ◇低级Bug大户（80%的低级Bug出自少数糟糕的程序员） 另外，有些糟糕员工还有一种很要命的传染性，会导致周围的平庸员工向糟糕员工转化。我猜测古人所说的“一粒老鼠屎”，大概说的就是这种现象吧。 扣除优秀的和糟糕的，剩下就是平庸的。平庸的程序员一般都循规蹈矩，既没有特别突出的贡献，也不会犯什么严重的过失。所以平庸的员工属于“沉默的大多 数”，一般不引人注意。 有同学要问了：讲管理怎么扯到“三种人的划分”上去捏？其实“三种人的划分”是非常重要的。由于 管理工作的本质属于和人打交道的范畴。当你搞明白三种人的划分并且知道你周围哪些人属于哪种类型，你就可以在管理的各个方面充分发挥优秀员工的积极因素、 充分消除糟糕员工的消极因素。 三种人的问题搞明白之后，咱们该来讲讲具体的操作层面的话题了。 关于招聘（如何找到优秀的软件开发人才） 今天咱们先来聊聊招聘的话题。为啥要先聊招聘捏？因为招聘工作是其它各项管理工 作的源头（先得有人可管才能谈管理嘛）。并且招聘工作有其特殊性：招聘方面的失误传递到了后续的环节，其影响会成倍放大。这个现象非常类似于软件开发流 程：如果需求阶段出了问题，该问题到设计阶段会放大十倍（设计人员会骂娘），到编码阶段会放大百倍（程序员会抓狂），到测试阶段...... 费了这许多口水之后，大伙儿应该看出招聘工作的重要性了吧？既然知道了重要性，下面我就来个现身说法，讲一下当初搭建开发团队的经验。 ★先确定比例 在上一个帖子里，我们已经介绍了优秀员工的稀缺性（只占5%-20%）。所以你不要指望团队里所有人都是优秀员工，这不现实（尤其是在中国）。如果你有这 种企图，那你就会陷入完美主义的焦油坑。 另一方面，如果整个团队中优秀员工的比例太低（甚至趋向于0），那也非常棘手。这样的团队效率会很差，基本上干不了太多实事。而且要改良这样的团队，难度 也是大大滴。 所以，根据我个人的经验，让团队中优秀人员的比例略高于业界平均水平是比较合适的（大概在1/5到1/3）。只要保证大约这个比例的人是优秀的就差不多 了。 ★再确定顺序 比例确定好了，后面就是招聘顺序的问题。一定要先把优秀的人搞到手，再去招平庸的人。这个顺序很重要。因为先进入团队的优秀人员会在团队中形成一个良好的 氛围（包括思考模式、沟通效率、学习气氛、编码风格等）。这样就有利于影响后进入的普通开发人员并使其融入其中。久而久之，就可能形成良性循环。 以盖房子来打个比方（我对盖楼不熟，说错了别丢臭鸡蛋）：盖房子要先把钢筋水泥框架搭好，后面再来沿着框架砌墙。只要水泥框架做的尺寸不差，那么砌墙也错 不到哪儿去；反之，如果框架搭歪了（甚至搭错了），墙就很难砌好，房子也就成危房了。 从这个例子可以看出：团队中的优秀人员就相当于团队栋梁。一定要先搞定栋梁，后面的事情就好办多了。 ★如何找到优秀人才（不太合适的途径） 既然顺序也确定了，接下来就是动手找人了。由于优秀开发人员比较稀缺，所以不能纯粹依赖传统的招聘方式（到招聘网站登广告）。当然，不排除传统方式也能找 到优秀人才，但是效率挺低的（个人感觉，简历中不到1%能算是优秀）。所以我一般用传统方式来招平庸程序员。 可能有同学会说：“费什么劲啊？直接找猎头公司不就得了。”确实，通过猎头能够比招聘网站更有效地找到一些优秀的人才。不过猎头公司找来的人有一个缺点： 由于这些人已经在猎头的档案库挂了号，所以将来猎头可能会经常来找他/她怂恿跳槽（人家猎头就是靠这个吃饭的），导致这些人的稳定性下降。当然啦，如果你 很有把握留住优秀人才，那也就无所谓了。 另外，上述两种方式还有一个共同的不足：对应聘人缺乏了解。一般只能通过简历、面试、笔试这几招来探探底细。但是，大凡准备简历和面试的人，无不把自己包 装得很光鲜，个个看上去都很完美的样子。至于笔试，我觉得笔试考察人的角度难以做到全面。因此笔试结果或许可以判定某人不合适，但肯定无法用来确保某人合 适。“不了解应聘人”导致的最大风险在于：可能让糟糕员工（何谓“糟糕”见上一个帖子）混入团队中。 ★如何找到优秀人才（比较高效率的方式） 前面批判了传统模式的种种缺点，接下来就得说一下我个人觉得比较有效的几种方式了。 1、通过朋友/熟人介绍 我这里所说的“朋友/熟人”，是指你比较了解和信任的人，并且也是混迹在软件开发界的。因为开发人员一般都有自己的社交圈子，圈内的人互相都知根知底。所 以，通过朋友介绍的话，就容易知道应聘人到底有几斤几两。 比如我当初开始组建团队时，有两个骨干人员就是通过熟人推荐进来的。 2、通过网上社区（比如BBS、邮件列表、SNS） 一些高质量的网上社区（比如TopLanguage论坛）会浓缩一些精英人才在其中。可以到这种地方观察一段时间，看看社区成员的发言，如果感觉某某人比 较中意，就可以先用邮件私下沟通一把。假如谈下来情投意合，就可以直接拉过来入伙了。 我以前有个同事，经常混迹于国外某Linux开发论坛，后来被一老外看上（那老外在找kernel程序员），然后去了某外企。 3、通过挖墙角 说实话，这招有点损，但仍不失为一个有效的办法。这个方法的针对性挺强，找来的人基本不会令人失望。 使用这个方法的难点在于要了解被挖角的人，明白他/她真正看重什么，然后再投其所好，才能见效。要知道不同的人看重的东西是不一样的（我后面的帖子会具体 说这个问题）。比如对于某些高端的人才，薪酬往往不是其最看重的，因为这种人不是很缺钱。 上述三种方式各有千秋，要视具体情况来灵活运用，效果才会好。 转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址： |