无处不在的二八原理[1]：在软件开发中的应用
无处不在的二八原理[1]：在软件开发中的应用
上次聊了《 什么是二八原理 》，接下来得说说如何运用了。由于本博客主要谈 IT 技术，显然要先来说说和程序员有关的那些事。为了不至于太抽象，咱们以“开发文本编辑器”为例（这玩意大伙儿都熟悉，省得费口水解释），来说说不同职责的开发人员在开发过程中该如何具体运用二八原理。
需求分析在整个开发过程中占的工作量不大，但是产生的影响巨大（这又是一个二八原理的例子）。既然需求分析如此重要，照理说应该安排最强的人来搞。但实际情况往往不是如此：很多公司负责需求分析的人并不胜任这项工作。俺经历过几个不太成功的项目，其问题的根源都和需求分析有关。
需求分析最要紧的是：搞清楚用户【到底】想要什么？如果这个问题搞错了、搞偏了，后面的步骤做得再好也是白搭（比如客户想要一个文本编辑器，结果你搞了个图形编辑器给他）。这方面其实有很多的道道，限于篇幅就不展开了，大伙儿如果有兴趣，以后可以单独说一下。
在搞清楚“用户想要什么”之后，接着要整理出功能列表（洋文叫“Feature List”），并筛选出大约20%的重点功能。这个步骤是俺今天想重点聊的，因为这个步骤和后续的各项开发密切相关。一般来说，功能筛选的依据有如下几个：
1、用户经常用的功能（比如：save、copy、cut、paste）
2、宣传的卖点（要能够超出同类软件，吸引眼球）
3、和用户利益密切相关的功能（这种功能不允许出错，比如存盘功能）
这个筛选的过程要尽早完成，而且最好是产品人员、开发人员、测试人员三方的头头一起讨论，以保证立场客观、观点全面。筛选出重要功能点后，其他人员的工作安排要"以重点功能为纲"，有所侧重。
如果你是个项目经理，在排项目计划时，就得尽量优先安排【重点功能】的开发/测试，而且要安排能力强的人员来完成。照俺以前的做法，重点功能排计划至少得留出1/3的时间余量，以防万一（事实证明，几乎每个稍大点的项目都会出现【万一】）。至于【非】重点功能，尽量排到后面，安排能力一般的人开发/测试。
然后，在项目进行过程中，肯定要有定期的例会。作为项目经理，你应该主要关注重点功能的进度情况和风险情况。
一旦项目有延期的风险，就从非重点功能开始裁减（俗称砍功能）。由于是裁减 非 重点功能，不至于产生致命的影响。
设计界面时，你得保证【所有的】常用功能都放在显著的位置（比如工具条）；还得保证它们用起来方便（比如提供快捷键和右键菜单支持）。
对于卖点，它不一定是常用功能，它的目的是激起用户的购买欲望和使用欲望。因此你要把它们设计得比较酷，有噱头。
对于利益相关的功能，大部分情况下都是侧重于业务逻辑实现。如果它既不是常用功能、也不是卖点，那么界面设计方面倒不一定要额外花大力气。
其它的【非】重点功能，只要按照常规方法设计，不用花太大精力。
俺发现很多开发人员有几个通病：先做有趣或容易的功能，然后再做无聊或者繁琐的功能；对自己有兴趣的功能投入精力多，对自己没兴趣的简单应付。
以上这些都是开发的大忌。作为一个职业的开发人员，不应该以自己的兴趣和喜好来决定开发的轻重缓急。正确做法应该如下：
你首先得用主要精力完成上述所说的重点功能，而且要保证它们的代码质量尽可能好，尽可能方便维护（重点功能往往是经常有需求变更，经常被修改的）。
对于重点功能中的【常用功能】，要保证“时间性能够好”（通俗地说，就是快速响应）。对于【用户利益相关的功能】，要保证 bug 尽可能少（尤其是安全性、稳定性、健壮性的 bug）。
至于其它的【非】重点功能，只要不出明显 bug，有点小缺陷无伤大雅。
如果你是个测试人员，你同样要把主要精力用于测试那些重点功能。对于"用户利益相关的功能"，多进行一些健壮性测试、稳定性、安全性等测试（比如测试保存大文件是否会出错）。对于常用功能，主要进行易用性和性能测试（比如拷贝、粘贴是否易用）。
至于其它功能，只要进行普通的测试，保证它不出现明显和严重 bug 即可。要知道当年微软发布 Windows 2000 的时候，尚遗留上千个未修复的 bug（当然都是低优先级的），人家不也照样发布嘛。
有些软件开发完之后，会搞一些 Demo 进行宣传。如果你是负责进行 Demo 的人，一定要把主要的 Demo 时间用来秀软件的卖点，这样给客户的印象最深刻，效果最好；至于【非】卖点的功能，甚至都不用提及。
几种和开发相关工作就介绍到这里，最后送给大伙一句话：【 Work Smart, Not Hard! 】
下一个帖子打算聊一下 二八原理在管理中的应用 。
★需求分析
需求分析在整个开发过程中占的工作量不大，但是产生的影响巨大（这又是一个二八原理的例子）。既然需求分析如此重要，照理说应该安排最强的人来搞。但实际情况往往不是如此：很多公司负责需求分析的人并不胜任这项工作。俺经历过几个不太成功的项目，其问题的根源都和需求分析有关。
需求分析最要紧的是：搞清楚用户【到底】想要什么？如果这个问题搞错了、搞偏了，后面的步骤做得再好也是白搭（比如客户想要一个文本编辑器，结果你搞了个图形编辑器给他）。这方面其实有很多的道道，限于篇幅就不展开了，大伙儿如果有兴趣，以后可以单独说一下。
在搞清楚“用户想要什么”之后，接着要整理出功能列表（洋文叫“Feature List”），并筛选出大约20%的重点功能。这个步骤是俺今天想重点聊的，因为这个步骤和后续的各项开发密切相关。一般来说，功能筛选的依据有如下几个：
1、用户经常用的功能（比如：save、copy、cut、paste）
2、宣传的卖点（要能够超出同类软件，吸引眼球）
3、和用户利益密切相关的功能（这种功能不允许出错，比如存盘功能）
这个筛选的过程要尽早完成，而且最好是产品人员、开发人员、测试人员三方的头头一起讨论，以保证立场客观、观点全面。筛选出重要功能点后，其他人员的工作安排要"以重点功能为纲"，有所侧重。
★项目管理
如果你是个项目经理，在排项目计划时，就得尽量优先安排【重点功能】的开发/测试，而且要安排能力强的人员来完成。照俺以前的做法，重点功能排计划至少得留出1/3的时间余量，以防万一（事实证明，几乎每个稍大点的项目都会出现【万一】）。至于【非】重点功能，尽量排到后面，安排能力一般的人开发/测试。
然后，在项目进行过程中，肯定要有定期的例会。作为项目经理，你应该主要关注重点功能的进度情况和风险情况。
一旦项目有延期的风险，就从非重点功能开始裁减（俗称砍功能）。由于是裁减 非 重点功能，不至于产生致命的影响。
★设计界面
设计界面时，你得保证【所有的】常用功能都放在显著的位置（比如工具条）；还得保证它们用起来方便（比如提供快捷键和右键菜单支持）。
对于卖点，它不一定是常用功能，它的目的是激起用户的购买欲望和使用欲望。因此你要把它们设计得比较酷，有噱头。
对于利益相关的功能，大部分情况下都是侧重于业务逻辑实现。如果它既不是常用功能、也不是卖点，那么界面设计方面倒不一定要额外花大力气。
其它的【非】重点功能，只要按照常规方法设计，不用花太大精力。
★编写代码
俺发现很多开发人员有几个通病：先做有趣或容易的功能，然后再做无聊或者繁琐的功能；对自己有兴趣的功能投入精力多，对自己没兴趣的简单应付。
以上这些都是开发的大忌。作为一个职业的开发人员，不应该以自己的兴趣和喜好来决定开发的轻重缓急。正确做法应该如下：
你首先得用主要精力完成上述所说的重点功能，而且要保证它们的代码质量尽可能好，尽可能方便维护（重点功能往往是经常有需求变更，经常被修改的）。
对于重点功能中的【常用功能】，要保证“时间性能够好”（通俗地说，就是快速响应）。对于【用户利益相关的功能】，要保证 bug 尽可能少（尤其是安全性、稳定性、健壮性的 bug）。
至于其它的【非】重点功能，只要不出明显 bug，有点小缺陷无伤大雅。
★测试
如果你是个测试人员，你同样要把主要精力用于测试那些重点功能。对于"用户利益相关的功能"，多进行一些健壮性测试、稳定性、安全性等测试（比如测试保存大文件是否会出错）。对于常用功能，主要进行易用性和性能测试（比如拷贝、粘贴是否易用）。
至于其它功能，只要进行普通的测试，保证它不出现明显和严重 bug 即可。要知道当年微软发布 Windows 2000 的时候，尚遗留上千个未修复的 bug（当然都是低优先级的），人家不也照样发布嘛。
★产品演示
有些软件开发完之后，会搞一些 Demo 进行宣传。如果你是负责进行 Demo 的人，一定要把主要的 Demo 时间用来秀软件的卖点，这样给客户的印象最深刻，效果最好；至于【非】卖点的功能，甚至都不用提及。
几种和开发相关工作就介绍到这里，最后送给大伙一句话：【 Work Smart, Not Hard! 】
下一个帖子打算聊一下 二八原理在管理中的应用 。
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/02/80-20-principle-1-software-developing.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/02/80-20-principle-1-software-developing.html
文章版权归原作者所有。
