博客园_侯伯薇的凌云晓筑

程序员应知——关注细节

2011-10-28T07:04:00Z

曾经有一句话，叫做“细节决定成败”，充分说明了细节对于成功的作用。如果我们注意一下，就会发现很多因为注重细节而获得成功的案例。

产品的细节

苹果的系列产品我们都已经非常熟悉了，各种各样i打头的产品，对于细节已经给予了非常大的关注。尤其体现明显的就是在对用户使用的友好度和便利性方面的细节。iPad、iPhone和iTouch等产品都是大大的屏幕，而在正面就只有一个按钮，用户不必考虑到底需要按什么按钮。而系列产品的做工更是让人赞不绝口，这也是另外一个细节。

另外对于国内的电子书产品，bambook我感觉细节做得也很不错，首先所使用的硬件质量都很好，我已经用了快一年的时间了，每个按钮还和刚拥有的时候一样灵活；电池也一直非常耐用，充一次电基本上可以至少用大半个月，这还是因为我几乎每天上下班的路上都会使用它来看书。曾经在使用的时候遇到一位用汉王产品的人，和我抱怨那款电子书的问题，首先就是按钮，没用两个月就坏掉了；还有电池，刚开始的时候能撑一个多月，但不长时间之后，就只能撑几天了。按钮、电池，看起来都是很细节的东西，但确实直接影响到了用户的体验，从而影响了用户对于产品乃至于企业的印象。

服务的细节

以上说的是产品，对于服务也是一样，同样需要关注细节。最近一段时间最火的饭店应该就是“海底捞”了，有无数的故事让人来传说，其实他们的服务充分体现了关注细节这一特点，不仅仅是产品的质量，更包括了服务的质量，他们能够关注于客户的各种反应，从而做出让人最满意的服务，那样才获得了巨大的成功。尽管说“海底捞你学不会”，但我们至少可以学习他们关注细节这一点，呵呵。

程序员要关注细节

作为程序员，我们的工作有很多，一方面需要创造出各种系统，编写各种程序，制造各种产出物；另一方面要和客户沟通，为最终的业务用户服务。无论哪个方面，我们都需要关注细节，那样才能够把工作做得更好。

在创建产品方面，我想我们可以做的有：

所有程序外观、使用方式统一，从而让用户更容易地学习和使用
程序代码遵守规范，便于维护和修改
各种功能使用简单，程序帮助用户做尽可能多的事儿
协助用户改进不合理的工作方式，帮助用户提高工作效率
……

其实这还比较笼统，更细节的问题可能会是：

界面上的文字是否有错别字？
文字的大小、颜色是否符合规范？
各种提示信息是否规范，是否真正有助于用户发现并解决问题？
代码中的注释是否必要，是否能够正确地为代码提供补充说明？
……

如果能够做到关注细节，那么不管是对于用户，还是团队中的其他开发人员来说，我们所体现出来的就是一种专业的精神和专业的态度。

当我们需要与用户沟通，为业务用户提供各种服务的时候，同样需要关注细节，我们需要：

清晰地了解用户的需求，并根据需求设计出好的技术解决方案。
对于用户提出的问题，能够快速定位并及时修正。
与客户沟通的过程中，及时向客户反馈。
不仅要理解用户表面提出来的需求，还需要根据自己的理解，挖掘潜在的需求。
……

以上还更多的是针对工作方面，想要和业务用户更好地协作，我们可能还需要关注一些生活上的细节：

用户的姓名以及基本的自然信息，是否在一次介绍之后就能够清晰地记住？
用户当前的状态，身体状况如何，是否适合工作？
用户的某些习惯怎样，采用什么样的方式更有效？
用户对我们的服务是否满意，我们还需要在哪些方面需要提升？
在活动的时候不迟到，清晰、快速地阐述自己的观点
……

从以上内容看来，想要真正做到关注细节，还真的是不容易，而我们又应该如何做好这些事儿呢？我想可以从改变自身开始：

细心！这样才能够发现更多细节
积极！这样才能够更有效地利用细节
准备！这样才能够把握好细节，发现更多机会

以上就是我对于关注细节相关的看法，如果你也是个注重细节的人，并且有很多关注细节的好习惯，欢迎与我讨论，:)

本文链接

软硬兼施让客户满意

2011-10-17T06:03:00Z

--本文基于我在2011-9-10Qclub大连站上的演讲整理。--

IT业是服务业的一种，而IT人员作为服务业的一员，目的就是要让客户满意，这里所说的客户可能是公司内部的业务用户，也可能是公司外部的业务人员，但不管怎样，我们的目的应该是一致的。

想要让客户满意，我们要达到的工作效果如何呢？借用之前一位前辈的话，他当时是在阐述什么样的软件产品或者说软件系统能够容易销售，“有两条特性，一是帮客户省时间，一是帮客户省钱，如果这两条能够达到一条，那么就算是基本合格了，如果都能够实现，那么就不愁卖了。”同样，我们想要自己的服务令业务用户满意，同样应该达到上述的目的——省钱、省时间。如果借助我们的服务，能够帮助业务用户和公司赚更多的钱，那么我们的服务就更上层楼了，那应该可以借助人工智能的优势达成。

然而，上述只是我们的理想，它和现实之间往往会有很大的差距，在很多时候，业务人员并不认为IT能够帮他们省钱、省时间，更不用提生钱了。他们认为IT部门是烧钱的部门，每年的软件系统会花费大量的资金，但是并不能带来多少实质性的改变，甚至于无法很好地支持业务。更不客气的说法，IT根本就是浪费钱。

尽管IT人员，特别是销售工程师，都会苦口婆心地告诉业务部门的人们，IT系统能够帮你节省成本，你看，之前很多东西你都需要打印出来才能签字，我们现在可以帮你实现无纸化办公，这样可以节省不少打印的成本啊；还可以提高工作效率，你想计算机算数多快啊，电脑啊，总比人脑厉害的。

然而业务人员在经历了各种系统之后，并不那么认为，上面的那些话根本就是一大堆谎言，为什么呢？有如下问题：

诸多需求变更无法满足
输入麻烦，无法大块地复制粘贴，浪费更多时间
因为程序bug、网络、电力等各方面的原因，故障频发，而且一旦出现问题，造成的损失会很大
灵活性不够，很多在实际业务中很容易实现的操作因为系统的限制无法进行。

的确，软件系统因为各种原因，存在着上述问题，所以我们作为程序员，更应该从我做起，提高自己的能力，从而更好地让业务用户满意。接下来让我们从软能力和硬能力两个方面来叙述一下，如何才能够更好地提升满意度。

软能力

说到软能力，很多程序员朋友会认为没有技术能力重要，但是，我觉得这方面的能力在某些时候是保证我们能够让客户满意的重要条件，因为缺少了这些能力，我们甚至都无法了解到客户在什么地方不满意，为什么不满意，怎样做才能够让他们满意，又从何谈起提升满意度呢？

沟通能力

其实在任何工作过程中，沟通和交流能力都是非常重要的，特别是对于能够接触到最终用户的程序员来说，这一能力尤其重要。

不过在沟通之前，或者说在沟通之中，我们要尽可能地和客户成为朋友，因为只有成为朋友之后，才能进行更好的沟通。

这首先要求我们要摆正自己的位置。很多情况下，作为程序员，应该都至少拥有不错的学历，掌握的也是高新科技的知识，不可避免有些程序员会觉得自己高人一等，而业务用户特别是一般企业中的业务员，可能没有这么高的学历，计算机知识也不是特别丰富。然而他们也拥有我们所不知道的东西，三人行必有我师，在沟通的情况下，他们也是我们的老师，如果一味地拒人于千里之外，那么就根本谈不上什么沟通了。

接下来，想要成为朋友，我们可以从细节做起，对于一个人来说，比较重要的东西很简单，首先是名字，其次是生日，如果我们能够清楚地记住一个人的名字，并且在下次见面的时候就能够准确无误地喊出来，那么一定会赢得好感。如果能够在生日的时候送上一句祝福，那么也会带来意想不到的效果。而做到这两点，我们并不需要付出太多，只要留心就好。另外一个细节就是要了解业务用户的爱好或者兴趣，如果正好和自己的有重合的话，就可以经常讨论一下，那也是增进友谊很好的方式。

沟通的方式有多种，比方说：

面对面沟通
电话
即时通信工具（Messager、QQ、Gtalk等等）
邮件

个人认为优先选用前面的两种方式，那样会得到更好的沟通效果，沟通的效率也会比较高。因为这两种方式更为直接，而后面的两种方式则会因为距离而产生更多的误解和歧义。

分析能力

对待一个问题，哲学上有三个步骤的说法，也就是：发现问题，分析问题和解决问题，所以我们会看到，其实分析问题是一个承上启下的步骤，作用也是非常明显的。而想要提高分析能力，真正能够把问题分析清楚，绝对是解决问题的必要条件。

在此我想推荐高德拉特先生的《目标》等一系列图书，其中讲述的是，我们在分析问题的时候，要根据情况的变化而适时调整，不断地寻找流程中的瓶颈，其实也就是问题的关键点，找到之后使用一定的方法解决，但是，并非是解决了一个瓶颈之后就万事大吉了，因为解决了一个瓶颈之后，整个流程的瓶颈就会转移到另一个地方，我们必须加以调整。

另外，我在分析问题的过程中，经常会使用到思维导图，从了解这个工具到现在，我已经形成了习惯，每次分析问题的时候都会不自觉地拿出一张白纸，然后用笔在上面写写画画。

学习能力

当前的各种知识不断更新，因此对于想要解决问题的我们来说，学习是非常必要的。而对于想要解决业务问题，更必要的是要学习业务领域的专业知识。这并非是说IT相关的专业知识不重要，但想要更好地理解业务的问题，并更好地为业务用户提供解决方案，掌握业务领域的知识是非常重要的。

想要学习那些知识，一种途径是看书，但另一种更加有效的途径就是与业务用户多多交流，甚至在条件允许的情况下，融入到业务团队中，在一段时间内，和他们一起工作。那样得到的经验会非常宝贵，绝对是第一手。并且这非常有利于我们转换思考的角度，真正做到从业务用户的角度来思考问题。

在IT系统中存在IT的架构，或者说软件系统中有系统架构，在业务领域同样有业务的架构，只有二者可以完美地契合，IT的系统才能够更好地为业务服务，从而更有利于业务部门的发展。

硬能力

除了上述的软能力之外，想要实现解决业务问题的方案，我们还需要增加硬能力，也就是技术能力。对于程序员来说，这方面的能力主要指的就是语言和工具。但是，学以致用，我们不仅仅要学习这些知识，还要了解到它们的优点和缺点，那样才更有利于使用它们来解决问题。俗话说，尺有所短，寸有所长，我们要做的就是取长补短。

使用合适的语言和工具

在软件开发的过程中，对于每个项目都会有一些规范和限制，但是对于一些特定的工具类程序，或者是那种即抛性的小程序，我们就可以采用一些在常规开发过程中不可能使用的方法来做，那样会取得事半功倍的效果。

比方说，在大型项目的开发过程中，我们一般不会使用中文作为变量名，但是，之前我开发的VBA宏程序中，因为用到了很多保险术语，想要为之起合适的英文名非常难，而且那些单词可能过段时间之后自己都不认识，所以里面很多变量名都使用了中文，这样对于开发以及后续的维护都带来了很大的方便。

尽管说在那些程序中可以比较随意地使用一些平时不能使用的方法，但并不意味着可以不注意代码规范，比方说缩进、命名规则等等，如果代码的格式很乱，那样的代码的可维护性还是会很差，而且那些问题应该是程序员最基本的素养，在任何程序中，即便是即抛性的小程序中，也需要认真对待。

另外，就是可以根据需要采用一些不常用的语言和工具，在项目开发过程中，很多东西都是只需要临时维护，对于那些程序，最重要的就是开发的时间，尽可能快递把程序提交给用户使用，才能够发挥出应有的作用。所以，在这种时候，尽管在核心的系统中我们可能使用的Java、.NET等等，我们大可以采用诸如F#、Python等动态语言，或者其它工具诸如Reporting Service等等，那样就可以通过缩短客户的等待时间而获得更高的满意度。

组合的方式解决问题

正如上面所说的，各种语言和工具都有自己的优势和劣势，所以，在某些时候，我们可以对其进行组合来解决问题，那样会发挥出各种语言和工具的优势，而避免各自的劣势。

比方说在之前的一个小型的项目中，我们就采用了多种技术的组合来解决问题。项目的目标是要生成一些数据，然后以sftp的形式上传到某个网站中，该网站的厂商会做后续的处理。

所要生成的数据因为实在Oracle数据库中，所以最合适的语言就是Oracle自身的PL/SQL，我们使用存储过程来开发了这部分功能，从而可以避免网络传输，而且不需要高级语言通过数据库连接来调用数据库。并且在数据库中设置了相关的Job，在特定的时间就会生成相应的数据。

由于安全性的限制，在数据库中的操作就到上面为止了，接下来我们采用C#并而借助enterprise library库来生成相应的文本文件。

最后一步上传，我们并没有使用.NET中的类库，因为它对于sftp的支持比较麻烦，所以我们直接建立进程，调用putty来执行上传操作。而该操作使用的东西很简单，就是批处理文件（.bat）。

这样，我们在项目中组合了多种技术，这样开发的时间被大大缩短，效果也很好，而且在各个环节，我们可以监控到中间的产物。

结论

由上述内容我们可以看出，在很多企业中，IT的最终目标就是要解决业务的问题，而想要更好地达到这个目的，我们就要软硬兼施，提高自己在各方面的能力。

本文链接

浅谈DBA的角色以及与业务的关系

2011-09-30T02:23:00Z

--本文的内容来源于我和赵元杰老师的一次聊天，赵老师是非常资深的Oracle专家，对Oracle的根本原理以及对既有数据库的优化有非常深的造诣和非常丰富的经验，他对于技术的钻研精神，非常值得我们这些后辈学习。

当前，在很多公司中，不管是IT公司还是非IT的企业，都会配备DBA这样一个职位，负责管理相关的数据库。然而，很多时候，DBA这个职位的位置却有些尴尬。

一般，一个企业的IT团队会分为两个部分，一部分我们可以称之为基础设施或者基础架构（Infrastructure）团队，他们会负责管理企业的计算机硬件、服务器、网络设备、电话等等；而另一部分一般称为应用开发，负责与软件开发相关的工作。

那么DBA应该归属于哪个团队呢？从程序员的角度来看，DBA当然应该归属于应用开发团队。然而，实际情况并非如此，因为DBA要负责管理数据库服务器，所以很多时候都会被划分到基础架构团队。而且，一般来说，数据库的结构设计工作，都是由应用开发团队来完成的。DBA并不会根据应用开发的需要来对数据库服务器进行规划，而只是简单地保证有足够的数据库空间供应用开发团队使用就好了。

同时，开发团队也不一定认可DBA称为开发团队的一员，当前很多企业都在搞EA（Enterprise Architecture），也就是企业架构，期望IT的架构能够和业务架构相互匹配，从而让IT能够更好地为业务服务。在这里，IT的架构研究更多着重在企业的各种应用服务器，重点也在于应用开发方面，而并没有把数据库的架构那纳入进来，或者说没有把它提到一个足够高的位置上来。

另外，现在有了云技术，越来越多的企业会把数据放在云存储上，从而降低公司的成本，如果真的把所有的数据都放到云端的话，那么DBA这个角色就没有在企业中存在的必要了。

然而，我们是否认真的考虑过，数据库的架构是否要和业务的架构匹配呢？或者说，DBA是否需要了解业务，才能够更好地完成自己的工作呢？

如果深入了解数据库的运行原理之后，我们会发现DBA了解业务是非常必要的，不妨举例说明：

大家都知道，在Oracle数据库中可以设置很多表空间，而不同的表空间可以放置在性能不同的存储设备上，那么在哪里放置什么样的表空间，而在表空间里存储什么样的数据就有讲究了。

比方说对于经常会用到的数据，像一些基础数据，就需要放在性能高的地方，而不会经常使用的数据，像日志、备份数据，就可以放在性能低的地方。

比方说有时效性的数据，对于最近的数据或者说今年的数据，就应该放在性能高的地方，而十年前的数据，可能需要归档了，就可以放在性能低的地方。

再比方说各种数据存储的问题，各个部门所要使用的数据表之间都会有很多关系，而把这些数据存储在相近的位置，那么在获取数据的时候就会比较快，而如果散落在各个角落，那在获取数据的时候就比较麻烦，性能也低。

另外，还有一些Oracle专有的技术，像各种类型的索引，对于各种不同的数据，采用不同的索引，最终的性能也不同；还有对数据表的分片（partition）技术，也必须在了解了业务之后才能够作出比较合理的选择。

由上面的内容，我们可以看出来，想要真正保证数据库的设计和运行的性能，DBA非常有必要了解业务的一些信息。

而当前的很多DBA的工作方式却很无奈，对于表空间，他们可能只会建立一个非常大的表空间，然后把所有的应用数据都放在一起；在开始的时候，也没有办法对数据库的存储设备等进行有效合理的规划，根本的原因还在于他们无法了解到业务的信息。

综上所述，作为DBA，需要更多地参与到系统的建设中来，而不是单纯地对服务器进行管理，而且需要了解更多的业务知识。

你的观点如何？

本文链接

与Janet关于敏捷测试若干问题的Q&A

2011-09-29T02:08:00Z

前日，加拿大的敏捷测试专家Janet Gregory来到大连，程序员社区为其举行了小型的聚会，大家一起共进晚餐，期间大家提出了很多问题，Janet基于自己的经验给出了很好的建议，大家受益良多，不敢独享，简单在此记录，供大家讨论。

Q：当前团队所从事的项目比较小，因此在结对编程之外，没有安排专门的测试人员。但随着团队的增大，是否有必要增加这样的角色？

A：首先要确定团队是否已经出现了问题，也就是说，没有专门的测试人员，项目的质量和进度会发生很大的问题。敏捷的目的在于解决问题，如果没有问题，那么就说明当前的机制能够满足当前的需要，并不一定要进行调整。

当团队增大的时候，有专门的测试人员是必要的，因为测试人员的思维和开发人员的思维是不一样的，往往可以从另一个角度发现问题，从而更好地保证质量。特别是在做产品的时候，更有必要有测试人员（有些小型的项目里面，客户会代替测试人员从事测试的工作）。

在做比较大的项目的时候，需要识别出很多用户故事（user story），然后根据这些用户故事，把所要做的工作切分成小块，然后以迭代的方式进行，迭代的周期最好是一周或者两周，每次迭代的时候要召开整个团队的迭代会议，让大家都明确这次迭代中所要完成的用户故事。

Q：迭代会议需要哪些人员参加？

A：整个团队，包括设计人员、开发人员、测试人员，最好还能够把客户也加入进来，这样可以在会上明确所有的问题。并且应该是整个项目组的成员都要参加，并不是说，不做某一个功能，就与之无关，就不需要了解那个部分的内容，每个人都需要对整个项目有全盘的了解。

另外重要的是要举行每日的站立会议，那也是交流的重要方式。

Q：当团队需要增加专门的测试人员时，可以有两种选择：1）招聘专门从事测试的人员 2）从有意愿的程序员中选择，转换为测试人员的角色。这两种哪一种更好一些呢？

A：开发人员和测试人员的思维方式应该是不同的，所以最好有专门从事测试的人，而不是从程序员中挑选。尽管拥有一定的编程知识能够更有益于找到程序中的缺陷，并且可能更好地帮助开发人员找到原因，甚至定位缺陷的原因，但思维是首先要解决的问题。

另外，开发人员和测试人员应该是相互合作的关系，这种合作不一定是在开发人员完成了程序之后，可能在开发人员写代码之前，测试人员就可以编写测试案例，然后和开发人员讨论，比方说：你看，我有这么多的测试案例要在稍后测试，你可以先了解一下。有了这种提前的合作，开发人员在编写代码的时候就会避免很多错误，从而提高程序的质量。

Q：一个人可否兼任两个项目的测试人员？

A：不建议。因为这样就无法满足每天工作八个小时的要求，因为会有在两个项目之间切换的时间，不仅仅是环境、工具、技术的切换，还包括思维的切换。在加拿大，和美国不同的是，人们的加班比较少，因为在工作的八个小时之内都能够正常运转，尽可能地完成工作。每周工作四十个小时的团队，并不一定比整天加班的团队完成的工作少，更不一定会拖慢进度。

Q：在敏捷团队中是否一定要使用TDD（测试驱动开发）？

A：这里的经验是来自于他人，并不是我（Janet）自己的经验。并非所有团队都愿意转为TDD，但是使用了TDD的团队都反馈说，他们很喜欢这种方式，不想再回到原来的方式了。但是，对于TDD来说，开始的起步是最困难的，因为那需要转换工作的思维方式。

此外，Janet还和大家演示了如何使用积分扑克，那是一种很好玩的方式，可以用来评估user story所需要的工作量，而且是比较有效的。

贯穿始终，Janet始终在强调要以人为本的敏捷思想：

人和人之间的关系很重要，包括团队与客户，团队中的各个人员之间，都应该是一种合作的关系，而不是对立的关系；
要积极地交流和反馈，了解情况和状态并加以调整。
招聘新人的时候，不仅仅要看特定的技术，那可以通过培训的方式教给他们，更重要的是看他是否能够很好地融入到团队中。

不知不觉，大家聊了差不多三个小时，仍然意犹未尽。不过只能彼此告别，希望以后还有机会做这样的交流。

如果你对于敏捷和测试方面有什么看法，欢迎对本文进行评论，:)

本文链接

QClub大连站，期待大家参与

2011-07-18T01:09:00Z

时隔10个月，有一次要在大连举办社区活动了，上次还是在微软精英社区的支持下，这次变了，是在InfoQ的支持之下。

其实很久之前就在准备，但是由于各种原因，延迟了一个月有一个月，回想起来，实在有些遗憾。

但是，不管怎样，就快要成功举办了，这个周六，期望能够顺利完成。

InfoQ中文站已经帮忙建立了报名网站：

http://www.infoq.com/cn/vendorcontent/show.action?vcr=1528

感谢大家的支持，希望是一次成功的活动，:)

本文链接

CRM系统的两个核心

2011-06-28T14:29:00Z

随着“客户是上帝”这一句话越来越深入人心，各家服务型企业也把客户关系看得越来越重要，随之而来，软件公司开发出各种CRM软件，以此来管理客户关系，以求能够更好地管理客户关系，为客户提供更好的服务，最终获得更大的商业利益。

然而，了解一下当前的CRM系统市场，会发现其实很多产品并没有体现出客户管理的理念，而是简单地把CRM系统做成了另外一种MIS，尽管里面会对客户信息有管理，也会提供所谓的商机管理等等形式，但相互之间没有形成一个整体，也就没有成为真正意义上的系统。

那么，真正有意义的CRM系统应该是什么样子的呢？我认为，这样的系统应该具备两大核心：一是客户评价体系；二是为客户提供有差别服务；二者相辅相成，缺一不可。

客户评价体系

虽然都是客户，都是上帝，但是相互之间还是会有很大的区别，对于一家公司来说，最根本的目的就在于创造利润，因此对于客户的分级我们可以简单地分为：

高利润客户
一般利润客户
低利润客户

第一种客户是企业最喜欢的了，和这样的客户进行业务往来越多，企业的收益也就越大，也就越有利于企业的发展，所以企业应该尽量维持较高的投资回报率，获得更大的收益。

第二种客户会占企业客户中的很大比例，这些客户是企业稳定的基础，正是因为这类客户的存在，公司的发展才能够比较平稳，不会出现忽高忽低的情况。但并不意味着企业应该安于现状，而是应该尽力把这类客户向高利润客户转换。

第三种客户对于企业来说是鸡肋，即便进行了很多的业务活动，但也无法为企业带来很大的收益，对于比较极端的情况，可能还会出现入不敷出的局面。当然，客户资源还是非常宝贵，又不能轻易地舍弃。所以，对于此类客户，企业的决策要谨慎，但最好可以有办法转换到前两类客户群中。

那么，想要对客户进行划分，企业要基于什么样的标准呢？

首先，要基于客户的基本信息，比方说企业的规模、企业所处的行业、企业的盈利状况、企业是否是上市公司、企业的高管层的地位等等，都有助于我们评价客户。

其次，就要基于与客户之间的业务往来的信息了，比方说订单的金额，交易频率，是否及时付款等等，此外，还要关注业务负责人对客户的评价，毕竟有些内容不是用数字就可以体现的。

这两点就需要我们开发人员在系统中建立评价的模型，根据各种属性和活动来评价客户，最基本的方法就是积分，而且要体现出，高积分客户对应高利润客户。

这里的模型不是一成不变的，根据企业的具体情况，还需要定期调整各种参数，使得模型能够最好地反应出实际的情况。

为客户提供有差别的服务

既然已经有客户评价体系区分出不同等级的客户，那么接下来要做的就是要为不同的客户提供不同的服务。

对于CRM系统中所做出的客户评价，我们需要把它与企业中的各种其他系统结合起来，毕竟CRM系统中没有，也不应该有大量的业务数据，那些数据应该是存在于各种业务系统中的。

比方说，对于不同级别的客户，我们要提供不同的报价，或者说不同的折扣率，这就需要与业务系统之间相关联，在报价的时候可以通过CRM系统中的评价数据作为参考。

再比方，对于不同级别的客户，付款期限也会有所不同，高级别的客户宽限期更长，因为他们的信用度也更好，此处就需要与财务相关系统有接口。

再有，对于有call center系统的企业，对于不同级别的客户，接入电话的方便程度也可以做相应调整，并且对于所谓的VIP客户，可能会有专线可供接入，此处又会与电话中心的系统交互。

相关的例子还有很多，这会根据企业系统情况的不同而不同，不管怎样，我们的目的就是要让客户能够体会到作为高级别客户的好处，从而达到一种双赢的局面。

为客户提供了有差别的服务之后，会让高利润的客户更加努力保持，一半利润的客户看到目标，为了达到高利润客户的标准，进行更多的业务活动，而得到更好的评价之后，就会获得更多企业所提供的服务，这样就形成了一种良性的循环。

想要实现CRM的两个核心，IT人员还是有很多需要做的工作，而且都不是非常容易，相信随着时间的发展，技术的进步，CRM系统必定会在企业的发展过程中起到越来越重要的作用。

本文链接

程序员应知——善于借鉴

2011-05-26T01:05:00Z

最近几天对D语言有了一些了解，据说能够具备和C、C++一样的高性能，语法类似于C#和Java，并且支持当前比较流行的语言——像Ruby和Python——的一些新特性，而且微软还提供了Visual D的插件，可以安装在Visual studio中，从而使用它来开发D语言的程序。

我们会发现，其实这门语言，在很大程度上是以往各种语言长处的结合（不知道是否实现了这一点，但目的应该是这样），与其说是一种新的语言，不如说是在借鉴了很多语言之后，组合出的一种语言。

由此我们可以发现，借鉴具有很强的力量。通过借鉴，我们能够创造出一些新的有自身特色的东西来。

说到借鉴，就不能不说创新，曾经有位朋友拿微软和苹果做过比较：微软最近几年来，在技术上一直没有非常明显的创新，似乎总是跟在别人的后面走，比方说云计算，比方说手机开发，再比方说服务式的web应用等等。而苹果的东西似乎每一种都具有很强的创新性，iPad、iPhone、手表式的ipod，还有传言中的裸眼3D功能的iPad等等，都让人能够眼前一亮。

的确，创新很棒！能够产生不错的效果。相比之下，借鉴似乎就要差一些，而且“山寨”和借鉴之间也有些搞不清楚。然而，我们也应该看到，创新其实也是建立在借鉴的基础之上，而且借鉴也能够产生很不错的效果。毕竟，创新力不是说说就能具备的，也需要长时间的积累和思考，而且还有一些天赋的成分在里面，试问世界上又能有几个乔帮主级别的人物。而借鉴往往更适合我们这些普通人，能够让我们从中受益。

作为程序员来说，也有很多地方都可以采用借鉴的方式来提升自己的能力。

比方说前几天我在百度Web app开发大会上的演讲中，谈到Web应用前端设计如何能够美观的时候，我就借鉴了版面设计的理论（来自于《写个大家看的设计书》），web应用的设计也应该遵循重复、对齐、对比、亲密性四种原则，那样就会达到美观的效果。而谈到设计需要规范的时候，我也借鉴了项目中经常会使用的代码规范，对于前端设计也一样要有相应的规范，那样才能够更利于开发和后期的维护工作。

再比方说之前的一篇blog中，我谈到了如果《以投资的观点学习编程》，这正是在听了公司投资部经理关于投资的一场讲座之后想到的，学习编程和投资一样，也有不少可以触类旁通的地方。

不仅仅如此，软件这个年轻的产业，本身很多方法都是从其他传统行业借鉴过来的，软件架构在很大程度上借鉴了建筑学的知识，而精益的理论更是来自于生产行业，我们能够看到，软件行业的发展与对其他行业的借鉴是分不开的。

而作为程序员，我们应该借鉴什么呢？

首先我想要借鉴已有的程序和项目，当我们想要完成一项任务的时候，不一定要从零开始，毕竟不是考试，我们完全可以先查看一下是否已经有类似的程序或者类似的项目，看看他们是如何完成的，而且在完成的过程中是否有相关的经验和教训，那些都是非常宝贵的财富。当然我们不是要完全地复制，而是要“批判地学习”，在理解了已有内容的基础上，加上自己的思考，从而创建出最适合我们自己的程序。在这个过程中，借鉴本身就是学习和提高的过程。

其次我想可以借鉴在非计算机领域解决问题的方式。我们知道，计算机真正广泛应用在解决问题上，也就是几十年间的事儿，之前遇到问题，传统的行业中一样可以解决，也都形成了不少方法论。那正是我们需要借鉴的地方，不一定在解决问题的时候完全要依赖于计算机，先从非计算机的方式入手，放宽一下自己的视野，可能会有更好的效果。

想要真正实现良好的借鉴，我想我们要时刻有借鉴的准备，机会总是留给又准备的人的，当我们在平时的生活中，或者是在各种书籍中，发现好的解决问题的方法时，就可以试着思考一下，是否可以借鉴到计算机领域中，这样，在以后编程解决问题的时候，可能就会不自觉地使用了。切不可把自己处于一种封闭的状态，对外界的事情不闻不问，更可怕的就是完全排斥了，根本就不接受外界的思想，那样“闭关锁国”的话，如何才能发展呢？（这里貌似也是借鉴，:)）

关于借鉴，你的想法如何，欢迎在此评论，也欢迎通过我的微博：@侯伯薇和我交流，:)

本文链接

程序员应知——循序渐进

2011-05-24T01:14:00Z

作为程序员，我想每个人都对于提高和进步非常渴望，也期望自己有朝一日能够从菜鸟变成大师级的人物，能够做出很棒的系统，能够得到他人的尊敬和赞赏，当然还可以得到不菲的收入。

然而，想要达到那个层次，不可能一蹴而就，必须要踏踏实实，一步一个脚印，逐步提高。这在每个行业或者说每个人的成长过程中都是一样的，所以我们必须要把握每一个提高的机会，从一点一滴做起。古语云：不积跬步，无以至千里，道理也是一样的。

前几天一位医学专业的朋友谈到了医学上的微创新，他说，如果看医学上一两年的发展，似乎没有什么特别大的进步和创新，但是，这并不意味着医学上没有进步，当我们回头看十年前，再与当前的情况作比较的话，就会发现已经有了很大的创新，而这些创新并非是一下子就出来的，而是经过十年来一点一点的微小的创新积累出来的，其实也就是一个量变引起质变的过程。

再说一个程序员会非常熟悉的例子，大家一定都玩过游戏，比方说《暗黑破坏神》《魔兽世界》等等需要打怪升级的游戏，里面的设定并不会让玩家一下子从菜鸟成为超级高手，那样游戏的趣味性就大大下降了，玩家必须通过不断的积累，累计经验值，然后在一定的时候升级，在到达一定的级别的时候才能够学会某种技能。其实在这里面，每一次小的升级都可以对应行业中的一次微创新，而学到指定级别下的技能，则可以对应一次变革性的创新。

类似的例子举不胜举，只要稍微注意，就能够发现。

然而，作为程序员，想要成为高级程序员，想要获得架构师、系统分析师、DBA等等诱人的称号，有时候却会比较急躁，在自己的能力还没有达到的时候，就匆匆上马，接受自己的能力范围之外的工作，就为了那个“名”，结果却往往会得不偿失，一方面有拔苗助长的嫌疑，另一方面对于项目也是一种损害，做出了不好的架构，系统分析不到位而导致客户不满意，诸如此类的情况，在我们身边相信大家都见过吧。

所以，想要真正做好项目，做好程序员，我们还是需要循序渐进，然而到底应该怎么做呢？我的建议，仅供参考。

对于刚刚踏入软件行业的同学来说，当然就是多多编写代码，在参与的各个项目中学习并且积累经验。在这个阶段我们会感觉进步非常快，很快就感觉可以做很多具体的工作了，个人也会非常有成就感。但是，此时千万不可被胜利冲昏了头脑，不能觉得自己已经再也无法从项目中、从团队的成员那里学到东西了，觉得项目离开自己就做不下去了。相反，这个时候应该继续保持低调，以空杯子的心态努力学习更多的知识。

做了三年左右的程序员之后，我想大家都会有一个飞跃，积累出来的经验得到总结，也有了自己的思想，这个时候，很可能项目中所能够学到的东西已经无法满足需要了，所以就要找寻其他积累经验的方式。当然跳槽、换项目是一种方式，而另一种方式就是多多从各种渠道——包括网站、书籍等——学习知识，了解行业的动态，另外还要多多与其他人交流，那样会产生很多想法，从而更好地引起个人的思考。

到了七八年或者十年左右，可能会迎来另一次飞跃，做过的项目很多，积累的经验很多，思考的成果也很多，真正形成了自己的风格和思想，这个时候仍然不能放弃学习和交流，而另一方面，思考会变得更加重要，并且也是要确定自己发展方向的时候了。到底是做项目经理，还是架构师，还是系统分析师，或者DBA等等，在对自己有了比较清醒的认识之后，就可以确定自己的目标了，然后就要为之做各个方面的积累，准备迎接下一次质变。

上面的内容仅仅是我的建议，时间的长短和具体的做法会因人而异，在以后的我也无法给出建议，毕竟我也还在等待下一次升级。我想大家所要了解到的就是不能放弃学习和提高，而要不断进步，那样经过一段时间之后，一定会有变化的。

其实我们在工作的过程中，循序渐进不仅仅体现在个人的成长上，对于代码的修改也一样，特别是对于遗留代码，想要完善的时候，也需要使用循序渐进的方式。

之前曾经看过对于系统是要重构还是重写的讨论，更多人倾向于重构，毕竟那是一种循序渐进的方式，不断地对代码进行修改，质量一步一步提高，形成一定的积累之后，就会发现代码的质量会发生很大的改变。而重构本身，也提倡小步前进，道理是相同的。

如果进行的是重写，则进行的是一种革命式的修改，然而，一切重头开始，不可避免会因为没有积累，而导致所要耗费的人力物力财力都非常大。

总之，作为程序员，应该了解到这个很重要的原则——循序渐进，也希望能够听到大家的想法。

本文链接

程序员应知——再谈放宽视野

2011-04-26T00:49:00Z

上一篇博客《程序员应知——放宽视野》发布之后，收到很多朋友们的评论，大家也认同我的观点，觉得对于程序员来说，放宽视野是非常必要的，然而，也有很多人提到，那篇博客写的比较泛泛，并没有指出如何来放宽视野，我也意识到了这个问题，所以想再继续谈一下“放宽视野”这个话题，:)

我想，想要真正放宽视野，首先要做到的一点就是把自己的姿态放低，不要认为程序员这个职业比其他职业高级，甚至在很多传统的职业跟前，我们还是要谦虚地去学习，也就是一种空杯子的心态，那样才能够把其他领域的知识装到我们的杯子里面。另外，要始终有把其他行业的知识与IT知识联系起来的意识，也就是说不能打无准备之战，要时刻做好准备，从其他领域吸取自己所需要的内容。

具备了以上两个前提之后，我们就要开始把自己的视野放宽，充实自己的知识了。对于任何知识都是一样，我觉得所要遵循的过程，或者说三种必要的方式就是“学习、思考和分享”，学习的过程可能是阅读大量的书籍，也可能是参加各种培训，或者向他人请教；学习获得的知识还没有经过提炼，我们需要经过思考这个过程，把其中所要吸取的知识提炼出来，使其真正成为属于自己的智慧，那样才能够发挥出更大的能量；而分享的过程也非常重要，不仅我们可以把自己的想法表达出来，获得他人的反馈，而且能够根据这些反馈以及思想的碰撞进一步地学习和思考，从而形成一个良性的循环。（对于此，更详细的内容可以阅读一下我之前的一篇博客《程序员应知——学习、思考与分享》）

接下来的问题可能就是，要把视线落在哪个领域，才能够对我们做好编程的工作起到很好的作用呢？这个问题我想是因人而异的，在此我仅把自己的一些感受说给大家，做个参考。

首先一个必要的领域就是工作中所要接触到的业务领域。多年以来，我更多地是在从事业务系统相关的系统开发，所以相关的业务领域知识就比较重要了，有了这些知识，我们可以更好地和业务人员交流，也可以更好地理解业务所提出的需求，并且能够在需要的时候为业务部门提出比较合理的意见和建议。这些年来，我涉及到的业务知识包括：生产、贸易、建筑机械租赁以及现在所从事的保险行业，这些知识对系统开发起到的作用是显而易见的。并且经济学和财务的知识也非常重要，毕竟每一家公司都会涉及到这些内容，是属于必不可少的领域知识。

接下来需要了解的领域我想应该是管理学，毕竟每个系统的开发都是项目，都需要进行管理，比方说资源的掌控、进度的把握等等，这都会需要管理学方面的知识。曾经看过的《目标》那个系列的书，还有《一分钟经理》系列、《人月神话》（请允许我把这本书也归到管理学范畴，呵呵），还有大学的管理学课程相关的教材，都对我更好地管理自己、管理团队起到了很好的作用，更多的心得是，要确定问题，找到自己的目标，然后用最直接的方式达到目的，消除各种浪费，相信很多朋友都会有相关的体会吧。

此外，我们也不能放松对自己的修炼，不仅仅是自身的情商修炼、影响力修炼，还有一些我们所必需的软技能，比方说沟通的能力、演讲的艺术、制作PPT的技巧等等，都会对我们更好地进行学习、思考和分享起到很重要的作用。

很多朋友会说，还有一个很重要的方面——哲学，没错，这是指导一切学科的知识，当然我们不能忽略，在工作和学习中我们经常会利用哲学的一些思想来解决问题，比方说：主要矛盾和次要矛盾，矛盾的主要方面和次要方面，世界万物都处于运动变化之中等等。

以上就是我的一些想法，希望能够和大家一起继续放宽视野，更好地做好程序员这份工作，:)

本文链接

程序员应知——放宽视野

2011-04-25T04:00:00Z

前几天和朋友一起交流的时候，他提到了一点问题，作为程序员，有时候会比较narrow-focused，总是觉得IT这个行业是高新技术行业，自己掌握的知识都是最新的知识，而其他行业都需要和我们学习。

古语有句话叫做：万般皆下品惟有读书高，现在放在程序员身上似乎也有一些贴切了。

之所以有这样的想法和情绪，一方面可能是金钱的作用吧，一般来说，在IT公司中的朋友或者是做IT的朋友们，薪资会比做传统行业的人高一些；另一方面可能是和所学习的知识相关，毕竟是一门新兴的行业，最新的就是最好的，很多人都是这样的认识；再可能就是由于做IT的人都太忙了，根本没有时间去关心其他行业的情况，这也造成了大家视野在一定程度上会有些狭窄。

其实，我们根本就没有资本认为自己的工作比其他行业要高级，相反，我们有很多很多需要和其他行业学习的地方。

原因是不言而喻的，仅仅从行业发展的年限来说，没有几个行业的年限要比IT行业短了，多年的积累形成了行业的模式和特点，也形成了很多的派别和模式，而众多派别之间的争论和相互学习，也促进了行业的进一步发展。

而且，反思一下软件开发过程中的各种方法论，很多都是从其他行业借鉴过来的。架构、模块化的思想，很大程度上借鉴了建筑学；规范、流程借鉴了生产行业的经验；而最近很流行的敏捷方法，同样也借鉴了其他行业中的管理思想，特别是看板、精益方法，都是从日本的制造行业中学习得到的。

因此，我们可以看出，了解一下最基本的方法论（比方说哲学思想）和管理思想，然后反思我们在软件开发过程中的方法和管理思想，触类旁通，会有更多不错的想法出来。

当然，有人会认为，很多语言啊、数据库等等方面具体的知识还没有学会，哪里会有时间学习那些非计算机领域的知识呢？我想，那些具体的知识固然非常重要，但是多多了解其他领域的知识，一方面可以让我们的精力有所转移，从而不会固守一隅，钻进牛角尖，从而获得一定程度的放松和休息，另一方面，多做些储备，在学习具体的知识时，就会有灵光一现的情况发生，那是更加珍贵的体验。

总之，我们要多多了解各方面的只是，放宽自己的视野，那也会让我们与各种各类的人交流起来更加容易，好处很多，希望大家都会有体会，:)

本文链接