其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。

现在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不说他们的好坏。从应用角度来说，ETL的过程其实不是非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的便利。但另一方面，开发人员容易迷失在这些工具中。举个例子，VB是一种非常简单的语言并且也是非常易用的编程工具，上手特别快，但是真正VB的高手有多少？微软设计的产品通常有个原则是“将使用者当作傻瓜”，在这个原则下，微软的东西确实非常好用，但是对于开发者，如果你自己也将自己当作傻瓜，那就真的傻了。ETL工具也是一样，这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开发效率。从使用效果来说，确实使用这些工具能够非常快速地构建一个job来处理某个数据，不过从整体来看，并不见得他的整体效率会高多少。问题主要不是出在工具上，而是在设计、开发人员上。他们迷失在工具中，没有去探求ETL的本质。

        可以说这些工具应用了这么长时间，在这么多项目、环境中应用，它必然有它成功之处，它必定体现了ETL的本质。如果我们不透过表面这些工具的简单使用去看它背后蕴涵的思想，最终我们作出来的东西也就是一个个独立的job，将他们整合起来仍然有巨大的工作量。大家都知道“理论与实践相结合”，如果在一个领域有所超越，必须要在理论水平上达到一定的高度

探求ETL本质之一
       ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据。其间，数据的抽取、清洗、转换和装载形成串行或并行的过程。ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。和OLTP系统中不同，那里充满这单条记录的insert、update和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般都是DBMS系统自身附带的工具，例如Oracle SQLLoader和DB2的autoloader等。
 
ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来说。
 
1、静态的ETL单元和动态的ETL单元实例；一次转换指明了某种格式的数据如何格式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以在运行时，当这个ETL单元创建一个实例时才指定。对于静态和动态的ETL单元，Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multiple instances，而且还不是默认选项。Powermart中将这两个概念加以区分，静态的叫做Mapping，动态运行时叫做Session。
 
2、ETL元数据；元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数据。主要包括每次转换前后的数据结构和转换的规则。ETL元数据还包括形式参数的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数，实参不在元数据管理范围之内。

3、数据流程的控制；要有可视化的流程编辑工具，提供流程定义和流程监控功能。流程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和转换只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操作。当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有找到很好的细分策略。比如，我们可以规定将装载一个表的功能作为一个ETL单元，但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个Hash表，要将这个Hash表装入内存两次。

4、转换规则的定义方法；提供函数集提供常用规则方法，提供规则定义语言描述规则。
 
5、对数据的快速索引；一般都是利用Hash技术，将参照关系表提前装入内存，在转换时查找这个hash表。Datastage中有Hash文件技术，Powermart也有类似的Lookup功能。

 探求ETL本质之二（分类）
       昨在IT-Director上阅读一篇报告，关于ETL产品分类的。一般来说，我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。它们包括

1、交互式运行环境，你可以指定数据源、目标数据，指定规则，立马ETL。这种交互式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。还有数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要牺牲一定的性能为代价。所以如果要处理海量数据的话，每次读取一条记录，每次对规则进行解释执行，每次在写入一条记录，这对性能影响是非常大的。

2、专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放在一些周边的功能上，例如读文件功能、写数据库的功能，而将精力主要放在规则的实现上面。这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关（这也是不可忽视的因素之一）。对于处理大数据量，处理复杂转换逻辑，这种方式的ETL实现是非常直观的。

3、代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要运行这个ETL过程，必须要编译才行。Datastage就是类似这样的产品，设计好的job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是什么。以前我设计的ETL工具大挪移其实也是归属于这一语言，编译后即可运行。这类工具的特点就是要在界面上下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完成读、写和转换函数。大挪移在这方面就太弱了，规则必须手写，而且要写成标准c++语法，这未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。另外一点，这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还有提供特定语言来实现高级功能。例如Datastage提供一种类Basic的语言，不过他的Job的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。

4、最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub一样地工作。将这种类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的方法，此类主要从数据处理角度。目前有一些产品属于EAI（Enterprise Application Integration），它的数据集成主要是一种准实时性。所以这类产品就像Hub一样，不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中去。

虽然，这些类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。

探求ETL本质之三（转换）
        ETL探求之一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？

一、宏观输入输出

       从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：
1、大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。

2、大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。

3、站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。

4、聚集。数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特定字段（维度），对度量字段再使用某种聚集函数。但是对于大数据量情况下，聚集算法的优化仍是探究的一个课题。例如是直接使用SQL的Group by，还是先排序，在处理。

二、微观规则
       从数据的转换的微观细节分，可以分成下面的几个基本类型，当然还有一些复杂的组合情况，例如先运算，在参照转换的规则，这种基于基本类型组合的情况就不在此列了。ETL的规则是依赖目标数据的，目标数据有多少字段，就有多少条规则。

1、直接映射，原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。

2、字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般对数值型字段而言。
3、参照转换，在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是比较合适也是最常见的，在整个ETL开始之前，它就装入内存，对性能提高的帮助非常大。

4、字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。

5、空值判断，对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作为特定一种维成员？这恐怕还要看应用的情况，也是需要进一步探求的。但是无论怎样，对于可能有NULL值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的值。

6、日期转换，在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。

7、日期运算，基于日期，我们通常会计算日差、月差、时长等。一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。
8、聚集运算，对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum,count,avg,min,max。

9、既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值。

 探求ETL本质之四（数据质量）
     “不要绝对的数据准确，但要知道为什么不准确。”
这是我们在构建BI系统是对数据准确性的要求。确实，对绝对的数据准确谁也没有把握，不仅是系统集成商，包括客户也是无法确定。准确的东西需要一个标准，但首先要保证这个标准是准确的，至少现在还没有这样一个标准。客户会提出一个相对标准，例如将你的OLAP数据结果和报表结果对比。虽然这是一种不太公平的比较，你也只好认了吧。
 
        首先在数据源那里，已经很难保证数据质量了，这一点也是事实。在这一层有哪些可能原因导致数据质量问题？可以分为下面几类：

1、数据格式错误，例如缺失数据、数据值超出范围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。

2、数据一致性，同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在帐务表中会出现一个用户表中没有的用户ID，在例如有些代码在代码表中找不到等。
3、业务逻辑的合理性，这一点很难说对与错。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。对这种情况，有什么办法吗？
 
       构建一个BI系统，要做到完全理解数据源系统根本就是不可能的。特别是数据源系统在交付后，有更多维护人员的即兴发挥，那更是要花大量的时间去寻找原因。以前曾经争辩过设计人员对规则描述的问题，有人提出要在ETL开始之前务必将所有的规则弄得一清二楚。我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生重大影响。

1、规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在探求之三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去很多手工操作了。

2、ETL开发错误。即时规则很明确，ETL开发的过程中也会发生一些错误，例如逻辑错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常开发人员没注意，一个大于等于号写成大于号就导致数据错误。

3、人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。

 探求ETL本质之五（质量保证）
       上回提到ETL数据质量问题，这是无法根治的，只能采取特定的手段去尽量避免，而且必须要定义出度量方法来衡量数据的质量是好还是坏。对于数据源的质量，客户对此应该更加关心，如果在这个源头不能保证比较干净的数据，那么后面的分析功能的可信度也都成问题。数据源系统也在不断进化过程中，客户的操作也在逐渐规范中，BI系统也同样如此。本文探讨一下对数据源质量和ETL处理质量的应对方法。

如何应对数据源的质量问题？记得在onteldatastage列表中也讨论过一个话题－"-1的处理"，在数据仓库模型维表中，通常有一条-1记录，表示“未知”，这个未知含义可广了，任何可能出错的数据，NULL数据甚至是规则没有涵盖到的数据，都转成-1。这是一种处理脏数据的方法，但这也是一种掩盖事实的方法。就好像写一个函数FileOpen(filename)，返回一个错误码，当然，你可以只返回一种错误码，如-1，但这是一种不好的设计，对于调用者来说，他需要依据这个错误码进行某些判断，例如是文件不存在，还是读取权限不够，都有相应的处理逻辑。数据仓库中也是一样，所以，建议将不同的数据质量类型处理结果分别转换成不同的值，譬如，在转换后，-1表示参照不上，-2表示NULL数据等。不过这仅仅对付了上回提到的第一类错误，数据格式错误。对于数据一致性和业务逻辑合理性问题，这仍有待探求。但这里有一个原则就是“必须在数据仓库中反应数据源的质量”。

        对于ETL过程中产生的质量问题，必须有保障手段。从以往的经验看，没有保障手段给实施人员带来麻烦重重。实施人员对于反复装载数据一定不会陌生，甚至是最后数据留到最后的Cube，才发现了第一步ETL其实已经错了。这个保障手段就是数据验证机制，当然，它的目的是能够在ETL过程中监控数据质量，产生报警。这个模块要将实施人员当作是最终用户，可以说他们是数据验证机制的直接收益者。

首先，必须有一个对质量的度量方法，什么是高质什么是低质，不能靠感官感觉，但这却是在没有度量方法条件下通常的做法。那经营分析系统来说，联通总部曾提出测试规范，这其实就是一种度量方法，例如指标的误差范围不能高于5%等，对系统本身来说其实必须要有这样的度量方法，先不要说这个度量方法是否科学。对于ETL数据处理质量，他的度量方法应该比联通总部测试规范定义的方法更要严格，因为他更多将BI系统看作一个黑盒子，从数据源到展现的数据误差允许一定的误差。而ETL数据处理质量度量是一种白盒的度量，要注重每一步过程。因此理论上，要求输入输出的指标应该完全一致。但是我们必须正面完全一致只是理想，对于有误差的数据，必须找到原因。

       在质量度量方法的前提下，就可以建立一个数据验证框架。此框架依据总量、分量数据稽核方法，该方法在高的《数据仓库中的数据稽核技术》一文中已经指出。作为补充，下面提出几点功能上的建议：

1、提供前端。将开发实施人员当作用户，同样也要为之提供友好的用户界面。《稽核技术》一文中指出测试报告的形式，这种形式还是要依赖人为判断，在一堆数据中去找规律。到不如用OLAP的方式提供界面，不光是加上测试统计出来的指标结果，并且配合度量方法的计算。例如误差率，对于误差率为大于0的指标，就要好好查一下原因了。

2、提供框架。数据验证不是一次性工作，而是每次ETL过程中都必须做的。因此，必须有一个框架，自动化验证过程，并提供扩展手段，让实施人员能够增加验证范围。有了这样一个框架，其实它起到规范化操作的作用，开发实施人员可以将主要精力放在验证脚本的编写上，而不必过多关注验证如何融合到流程中，如何展现等工作。为此，要设计一套表，类似于DM表，每次验证结果数据都记录其中，并且自动触发多维分析的数据装载、发布等。这样，实施人员可以在每次装载，甚至在流程过程中就可以观察数据的误差率。特别是，如果数据仓库的模型能够统一起来，甚至数据验证脚本都可以确定下来，剩下的就是规范流程了。

3、规范流程。上回提到有一种ETL数据质量问题是由于人工处理导致的，其中最主要原因还是流程不规范。开发实施人员运行单独一个ETL单元是很方便的，虽然以前曾建议一个ETL单元必须是“可重入”的，这能够解决误删数据，重复装载数据问题。但要记住数据验证也是在流程当中，要让数据验证能够日常运作，就不要让实施者感觉到他的存在。总的来说，规范流程是提高实施效率的关键工作，这也是以后要继续探求的。

 探求ETL本质之六（元数据漫谈） 

       对于元数据（Metadata）的定义到目前为止没有什么特别精彩的，这个概念非常广，一般都是这样定义，“元数据是描述数据的数据（Data about Data）”，这造成一种递归定义，就像问小强住在哪里，答，在旺财隔壁。按照这样的定义，元数据所描述的数据是什么呢？还是元数据。这样就可能有元元元...元数据。我还听说过一种对元数据，如果说数据是一抽屉档案，那么元数据就是分类标签。那它和索引有什么区别？

元数据体现是一种抽象，哲学家从古至今都在抽象这个世界，力图找到世界的本质。抽象不是一层关系，它是一种逐步由具体到一般的过程。例如我->男人->人->哺乳动物->生物这就是一个抽象过程，你要是在软件业混会发现这个例子很常见，面向对象方法就是这样一种抽象过程。它对世界中的事物、过程进行抽象，使用面向对象方法，构建一套对象模型。同样在面向对象方法中，类是对象的抽象，接口又是对类的抽象。因此，我认为可以将“元”和“抽象”换一下，叫抽象数据是不是好理解一些。

常听到这样的话，“xx领导的讲话高屋建瓴，给我们后面的工作指引的清晰的方向”，这个成语“高屋建瓴”，站在10楼往下到水，居高临下，能砸死人，这是指站在一定的高度看待事物，这个一定的高度就是指他有够“元”。在设计模式中，强调要对接口编程，就是说你不要处理这类对象和那类对象的交互，而要处理这个接口和那个接口的交互，先别管他们内部是怎么干的。

元数据存在的意义也在于此，虽然上面说了一通都撤到哲学上去，但这个词必须还是要结合软件设计中看，我不知道在别的领域是不是存在Metadata这样的叫法，虽然我相信别的领域必然有类似的东东。元数据的存在就是要做到在更高抽象一层设计软件。这肯定有好处，什么灵活性啊，扩展性啊，可维护性啊，都能得到提高，而且架构清晰，只是弯弯太多，要是从下往上看，太复杂了。很早以前，我曾看过backorifice的代码，我靠，一个简单的功能，从这个类转到父类，又转到父类，很不理解，为什么一个简单的功能不在一个类的方法中实现就拉到了呢？现在想想，还真不能这样，这虽然使代码容易看懂了，但是结构确实混乱的，那他只能干现在的事，如果有什么功能扩展，这些代码就废了。

       我从98年刚工作时就开始接触元数据的概念，当时叫做元数据驱动的系统架构，后来在QiDSS中也用到这个概念构建QiNavigator，但是现在觉得元数据也没啥，不就是建一堆表描述界面的元素，再利用这些数据自动生成界面吗。到了数据仓库系统中，这个概念更强了，是数据仓库中一个重要的部分。但是至今，我还是认为这个概念过于玄乎，看不到实际的东西，市面上有一些元数据管理的东西，但是从应用情况就得知，用的不多。之所以玄乎，就是因为抽象层次没有分清楚，关键就是对于元数据的分类（这种分类就是一种抽象过程）和元数据的使用。你可以将元数据抽象成0和1，但是那样对你的业务有用吗？必须还得抽象到适合的程度，最后问题还是“度”。

       数据仓库系统的元数据作用如何？还不就是使系统自动运转，易于管理吗？要做到这一步，可没必要将系统抽象到太极、两仪、八卦之类的，业界也曾定义过一些元数据规范，向CWM、XMI等等，可以借鉴.

　　在说服时，你首先应该想方设法调节谈话的气氛．如果你和颜悦色地用提问的方式代替命令，并给人以维护自尊和荣誉的机会，气氛就是友好而和谐的，说服也就容易成功；反之，在说服时不尊重他人，拿出一副盛气凌人的架势，那么说服多半是要失败的．毕竟人都是有自尊心的，就连三岁孩童也有他们的自尊心，谁都不希望自己被他人不费力地说服而受其支配．

　　有一位中学老师接管了一个差班班主任工作，正好赶上学校安排各班级学生参加平整操场的劳动．这个班的学生躲在阴凉处谁也不肯干活，老师怎么说都不起作用．后来这个老师想到一个以退为进的办法，他问学生们：“我知道你们并不是怕干活，而是都很怕热吧？”学生们谁也不愿说自己懒惰，便七嘴八舌说，确实是因为天气太热了．老师说：“既然是这样，我们就等太阳下山再干活，现在我们可以痛痛快快地玩一玩．”学生一听就高兴了．老师为了使气氛更热烈一些，还买了几十个雪糕让大家解暑．在说说笑笑的玩乐中，学生接受了老师的说服，不等太阳落山就开始愉快地劳动了．

　　二、争取同情，以弱克强

　　渴望同情是人的天性，如果你想说服比较强大的对手时，不妨采用这种争取同情的技巧，从而以弱克强，达到目的．

　　有一个15岁的山区小姑娘，不幸被拐到上海．当天晚上，天下着小雨，小姑娘的房门打开了，一个中年上海“阿拉”走了进来．小姑娘的心跳到了嗓子眼儿．不过，她还是很快地镇静下来，机智地叫了声：“伯伯！”中年“阿拉”一愣，人像是被魔法定住了似的．
小姑娘小心翼翼地说：“我一看伯伯就是好人，看你的年龄，与我爸差不多，可我爸就比你苦多了，他在乡下种田，去年栽秧时，他热得中暑……”说着说着，眼泪就哗哗地流下来．“阿拉”的脸涨得通红，短暂的沉默后，低低地说了一句：“谢谢你，小姑娘．”然后开门走了．
面对强壮的“阿拉”，何不让自己显得更弱小，来激发他的同情心呢？聪明的小姑娘正是这样做的．
一句“伯伯”，一下子拉开了两人年龄距离，让“阿拉”不由得想起自己那同样处于花季的儿女．同情的种子开始在他心头萌发了．接着小姑娘又不失时机地给他戴上一顶“好人”的帽子，诱导他的心理向“好人”标准看齐．用“我爸”和“阿拉”对比，进一步强化了“阿拉”的同情心理．

　　三、善意威胁，以刚制刚

　　很多人都知道用威胁的方法可以增强说服力，而且还不时地加以运用．这是用善意的威胁使对方产生恐惧感，从而达到说服目的的技巧．在一次集体活动中，当大家风尘仆仆地赶到事先预定的旅馆时，却被告知当晚因工作失误，原来订好的套房（有单独浴室）中竟没有热水．为了此事，领队约见了旅馆经理．

　　领队：对不起，这么晚还把您从家里请来．但大家满身是汗，不洗洗澡怎么行呢?何况我们预定时说好供应热水的呀！这事只有请您来解决了．

　　经理：这事我也没有办法．锅炉工回家去了，他忘了放水，我已叫他们开了集体浴室，你们可以去洗．

　　领队：是的，我们大家可以到集体浴室去洗澡，不过话要讲清，套房一人５０元一晚是有单独浴室的．现在到集体浴室洗澡，那就等于降低到统铺水平，我们只能照统铺标准，一人降到１５元付费了．

　　经理：那不行，那不行的！

　　领队：那只有供应套房浴室热水．

　　经理：我没有办法．

　　领队：您有办法！

　　经理：你说有什么办法？

　　领队：您有两个办法：一是把失职的锅炉工召回来；二是您可以给每个房间拎两桶热水．当然我会配合您劝大家耐心等待．这次交涉的结果是经理派人找回了锅炉工，４０分钟后每间套房的浴室都有了热水．

　　威胁能够增强说服力，但是，在具体运用时要注意以下几点：

　　第一，态度要友善．

　　第二，讲清后果，说明道理．

　　第三，威胁程度不能过分，否则反会弄巧成拙．

　　四、消除防范，以情感化

　　一般来说，在你和要说服的对象较量时，彼此都会产生一种防范心理，尤其是在危急关头．这时候，要想使说服成功，你就要注意消除对方的防范心理．如何消除防范心理呢？从潜意识来说，防范心理的产生是一种自卫，也就是当人们把对方当作假想敌时产生的一种自卫心理，那么消除防范心理的最有效方法就是反复给予暗示，表示自己是朋友而不是敌人．这种暗示可以采用种种方法来进行：嘘寒问暖，给予关心，表示愿给帮助等等．

　　有个“的姐”（出租车女司机）把一男青年送到指定地点时，对方掏出尖刀逼她把钱都交出来，她装作害怕样交给歹徒３００元钱说：“今天就挣这么点儿，要嫌少就把零钱也给你吧．”说完又拿出２０元找零用的钱．见“的姐”如此爽快，歹徒有些发愣．“的姐”趁机说：“你家在哪儿住？我送你回家吧．这么晚了，家人该等着急了．”见“的姐”是个女子又不反抗，歹徒便把刀收了起来，让“的姐”把他送到火车站去．见气氛缓和，“的姐”不失时机地启发歹徒：“我家里原来也非常困难，咱又没啥技术，后来就跟人家学开车，干起这一行来．虽然挣钱不算多，可日子过得也不错．何况自食其力，穷点儿谁还能笑话我呢！”见歹徒沉默不语，“的姐”继续说：“唉，男子汉四肢健全，干点儿啥都差不了，走上这条路一辈子就毁了．”火车站到了，见歹徒要下车，“的姐”又说：“我的钱就算帮助你的，用它干点正事，以后别再干这种见不得人的事了．”一直不说话的歹徒听罢突然哭了，把300多元钱往“的姐”手里一塞说：“大姐，我以后饿死也不干这事了．”说完，低着头走了．在这个事例中，“的姐”典型地运用了消除防范心理的技巧，最终达到了说服的目的．

　　五、投其所好，以心换心

　　站在他人的立场上分析问题，能给他人一种为他着想的感觉，这种投其所好的技巧常常具有极强的说服力．要做到这一点，“知己知彼”十分重要，惟先知彼，而后方能从对方立场上考虑问题．

　　某精密机械工厂生产某项新产品，将其部分部件委托小工厂制造，当该小厂将零件的半成品呈示总厂时，不料全不合该厂要求．由于迫在眉捷，总厂负责人只得令其尽快重新制造，但小厂负责人认为他是完全按总厂的规格制造的，不想再重新制造，双方僵持了许久．总厂厂长见了这种局面，在问明原委后，便对小厂负责人说：“我想这件事完全是由于公司方面设计不周所致，而且还令你吃了亏，实在抱歉．今天幸好是由于你们帮忙，才让我们发现竟然有这样的缺点．只是事到如今，事情总是要完成的，你们不妨将它制造得更完美一点，这样对你我双方都是有好处的．”那位小厂负责人听完，欣然应允．

　　六、寻求一致，以短补长

　　习惯于顽固拒绝他人说服的人，经常都处于“不”的心理组织状态之中，所以自然而然地会呈现僵硬的表情和姿势．对付这种人，如果一开始就提出问题，绝不能打破他“不”的心理．所以，你得努力寻找与对方一致的地方，先让对方赞同你远离主题的意见，从而使之对你的话感兴趣，而后再想法将你的主意引入话题，而最终求得对方的同意．有一个小伙子固执地爱上了一个商人的女儿，但姑娘始终拒绝正眼看他，因为他是个古怪可笑的驼子．

　　这天，小伙子找到姑娘，鼓足勇气问：“你相信姻缘天注定吗？”姑娘眼睛盯着天花板答了一句：“相信．”然后反问他，“你相信吗？”他回答：“我听说，每个男孩出生之前，上帝便会告诉他，将来要娶的是哪一个女孩．我出生的时候，未来的新娘便已经配给我了．上帝还告诉我，我的新娘是个驼子．我当时向上帝恳求：‘上帝啊，一个驼背的妇女将是个悲剧，求你把驼背赐给我，再将美貌留给我的新娘．’”当时姑娘看着小伙子的眼睛，并被内心深处的某些记忆搅乱了．她把手伸向他，之后成了他最挚爱的妻子．

1) 描述线程与进程的区别？

线程(Thread)与进程（Process）二者都定义了某种边界，不同的是进程定义的是应用程序与应用程序之间的边界，不同的进程之间不能共享代码和数据空间，而线程定义的是代码执行堆栈和执行上下文的边界。一个进程可以包括若干个线程，同时创建多个线程来完成某项任务，便是多线程。而同一进程中的不同线程共享代码和数据空间。用一个比喻来说，如果一个家庭代表一个进程，在家庭内部，各个成员就是线程，家庭中的每个成员都有义务对家庭的财富进行积累，同时也有权利对家庭财富进行消费，当面对一个任务的时候，家庭也可以派出几个成员来协同完成，而家庭之外的人则没有办法直接消费不属于自己家庭的财产。

2) 什么是Windows服务，它的生命周期与标准的EXE程序有什么不同

Windows服务是运行在windows后台指定用户下（默认System）的应用程序，它没有标准的UI界面，想比标准的EXE程序，Windows服务是在服务开始的时候创建，而在服务结束的时候销毁，而且可以设置服务是否与操作系统一起启动，一起关闭。它支持三种方式：１）自动方式 2）手动方式　３）禁用 。自动方式的时候，windows服务将在OS启动后自动启动运行，而手动方式则必须手工启动服务，禁用的情况下服务将不能被启动。另外标准的EXE默认使用的当前登录的用户，而windows服务则默认使用System用户，这在对系统资源访问的时候特别需要注意。

3) Windows单个进程所能访问的最大内存量是多少？它与系统的最大虚拟内存一样吗？这对于系统设计有什么影响？

这个需要针对硬件平台，公式为单个进程能访问的最大内存量=2的处理器位数次方/2，比如通常情况下，32位处理器下，单个进程所能访问的最大内存量为:232 /2 = 2G 。单个进程能访问的最大内存量是最大虚拟内存的1/2，因为要分配给操作系统一半虚拟内存。

4) 什么是强类型，什么是弱类型？哪种更好些？为什么?

强类型是在编译的时候就确定类型的数据，在执行时类型不能更改，而弱类型在执行的时候才会确定类型。没有好不好，二者各有好处，强类型安全，因为它事先已经确定好了，而且效率高。一般用于编译型编程语言，如c++,java,c#,pascal等,弱类型相比而言不安全，在运行的时候容易出现错误，但它灵活，多用于解释型编程语言，如javascript,vb等

5) PID是什么？在做系统的故障排除时如何使用它？

PID是进程编号，在系统发现故障的时候，可以根据它寻找故障所发生的具体进程，并且可通过visual studio.net等ide将故障进程附加到进程中进行调试(debug)

6) 单个TCP/IP端口上能够被多少个进程侦听？

可以为多个，多个为端口复用 （多谢蛙蛙池塘的提醒）看下面代码

端口复用 Socket socket1 = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);             Socket socket2 = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);             socket1.Bind(new IPEndPoint(IPAddress.Parse("127.0.0.1"),8235));             socket1.Listen(10);             socket2.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);             socket2.Bind(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 8235));             socket2.Listen(10);             Console.Read();

7) 什么是GAC？它解决了什么问题?

Gloal Assembly Cache，全局应用程序集缓存。它解决了几个程序共享某一个程序集的问题。不必再将那个被共享的程序集拷贝到应用程序目录了，其实这道理很简单，.net应用程序在加载的时候，会首先查看全局应用程序集缓存，如果有就可以直接使用，没有再到应用程序目录进行查找。

中级.NET开发人员

1) 阐述面向接口、面向对象、面向方面编程的区别

面向接口更关注的是概念，它的原则是先定义好行为规范，再根据行为规范创建实现，严格的来说，面向接口应该是面向对象中的一部分吧，因为面向对象也强调的是依赖倒置原则，也就是实现依赖于抽象，而抽象不依赖于具体实现，更具比较的应该是面向接口与面向抽象对象，我的体会是面向接口更加灵活，但实现时候，稍微有些代码冗余，而面向抽象可以结合面向接口，先定义接口，再定义抽象类，在抽象类中处理一些公共逻辑，再实现具体实现类。面向对象是对复杂问题的分解。面向方面的编程是一种新概念，它解决了很多面向对象无法解决的问题，比如面向对象技术只能对业务相关的代码模块化，而无法对和业务无关的代码模块化。而面向方面正是解决这一问题的方案，它的关键思想是"将应用程序中的商业逻辑与对其提供支持的通用服务进行分离"。

2) 什么是Interface？它与Abstract Class有什么区别？

接口(Interface)是用来定义行为规范的，不会有具体实现，而抽象类除定义行为规范外，可以有部分实现，但一个类能实现多个接口，但只能继承一个父类

3) 什么是反射?

程序集包含模块，而模块又包括类型，类型下有成员，反射就是管理程序集，模块，类型的对象，它能够动态的创建类型的实例，设置现有对象的类型或者获取现有对象的类型，能调用类型的方法和访问类型的字段属性。它是在运行时创建和使用类型实例

4) 使用ASMX的XML Web服务与使用SOAP的.NET Remoting的区别?

Web服务使用的消息机制，而Remoting采用的RPC. Web Service能用于不同平台，不同语言，Remoting只适用于.Net。效率上Remoting高于Xml Web Service

5) 类型系统是由XMLSchema表示的吗？CLS是XMLSchema表示的吗？

不清楚

6) 从概念上阐述前期绑定（early-binding）和后期绑定（late-binding）的区别?

这个就像是强弱类型的比较相似，前期绑定是在编译的时候就确定了要绑定的数据，而后期绑定是在运行的时候才填充数据。所以前期绑定如果失败，会在编译时报编译错误，而后期绑定失败只有在运行时的时候才发生

7) 调用Assembly.Load算静态引用还是动态引用？

动态

8) 何时使用Assembly.LoadFrom？何时使用Assembly.LoadFile？

呵呵，这个比较有意思,相比LoadFile，LoadFrom则显得不地道，因为它娶媳妇的时候，是让人家穿上嫁妆，坐上马车，还得带着人家的妹妹来，：）用它加载的是程序集，这就要求同时将此程序集所依赖的程序集加载进来。而LoadFile就地道的多，它是加载程序集文件的内容，只将传入参数的文件加载，不考虑程序集依赖，但如果有相同实现，但位置不同的文件用LoadFrom是不能同时加载进来的，而LoadFile却可以。由于LoadFile加载的是文件，所以调用它之后，可能因为缺少必要的依赖造成无法被执行。

9) 什么叫Assembly Qualified Name？它是一个文件名吗？它有什么不同？

它不是一个文件名，相比文件名，Assembly Qualified Name（程序集限定名称），更能确定一个程序集，它包含文件名，但同时包含版本，公钥，和区域。因为同样一个名称的文件可能有不同的版本和区域，此时单独靠文件名称，可能会造成不能确定程序集的正确性。

10) Assembly.Load("foo.dll"); 这句话是否正确？

错误，正确的应该是Assembly.Load("foo"); 或者Assembly.LoadFrom("foo.dll"); （多谢 Tristan(Guozhijian)的提示更正）

11) 做强签名的assembly与不做强签名的assembly有什么不同？

强签名的程序集可以做成com，而不做强签名的就不行，同样强签名程序集可以安装到GAC中，而不做强签名的确不能。

12) DateTime是否可以为null?

不能，因为其为Struct类型，而结构属于值类型，值类型不能为null,只有引用类型才能被赋值null

13) 什么叫JIT？什么是NGEN？它们分别有什么限制和好处？

Just In Time 及时编译，它是在程序第一次运行的时候才进行编译，而NGEN是所谓的pre-jit，就是说在运行前事先就将生成程序集的本机镜像，并保存到全局缓存中，适用NGEN可以提高程序集的加载和执行速度，因为它可以从本机映像中还原数代码和数据结构，而不必像jit那样动态生成它们。感觉和缓存的道理大同小异。

14) Finalize()和Dispose()之间的区别?

Finalize（）用于隐式释放资源，Dispose()用于显示释放资源 （Finalize()的确相当于C++中的析构函数（多谢Jeffrey Zhao提示更正）

15) using() 语法有用吗？什么是IDisposable？它是如何实现确定性终结的。

有用，实现了IDisposiable的类在using中创建，using结束后会自定调用该对象的Dispose方法，释放资源。不明白什么是确定性终结

16) tasklist /m "mscor*" 这句命令是干嘛的？

列出所有使用了以" mscor"作为开头的dll或者exe的进程和模块信息

17) in-proc和out-of-proc的区别

in-proc是进程内，进程内能共享代码和数据块，out-of-proc是进程外，进程外的互操作需要用进程间通讯来实现。

18) .NET里的哪一项技术能够实现out-of-proc通讯？

.Net Remoting技术或者WCF技术

19) ASP.NET在Windows XP, Windows 2000, Windows 2003上分别跑在哪个进程里面？

Xp : aspnet_Wp.exe Windows 2000 : aspnet_Wp.exe Windows 2003 : w3wp.exe

有人说：你把程序员都不当人，94天，一天都不休息啊。

我想答曰：94天，是工作时间。不算双休日在里面。也就是说，实际的开发周期长度是94+3个月之中的所有双休日。我只所以按照94天算，是算94天工作日，并没有把双休日都算进去。你试着想想，你都休息了，你怎么跟客户算费用的时候把双休日也好意思算进去。所以说，算费用，按94天算合理。

另外有人说了：根本不是全体人都干94个工作日。你按全体人干94个工作日算，这也太黑客户了吧。

我想答曰：这个详细开发过程我会以后一篇篇文章详细道来。我在这里先简短说一下：你以为调研完就把调研文档一转给下一阶段的人就算OK了？你以为直到代码编写完后才测试？你以为直到测试完后才写文档？这样的串行，根本无法保证产品开发质量，也无法适应国内这种“说过的话可以不算合同可以一撕两半”的需求朝令夕改的状况。我会以后讲到全程研发团队配合的方法。所以说，确实需要整个团队研发94个工作日。

由有人说：楼主在这里搭建自己的梦想空中楼阁呢，都是在遐想或瞎想。现在谁这么报价啊。水清则无鱼，你也讲了。谁也不是冤大头。吃饭KTV澡堂一条龙，外加回扣搞定他。

我想答曰：现在的客户都是荤素全收。吃饭KTV洗澡加回扣，这些都是正常流程。但桌下的归桌下，桌上的还要看你桌上的。现在需要的是面上好看面下也好看，既要捞了实惠还要项目做的好。现在企业打单的竞争都已经不是一两层的竞争了。先开始比关系，发现竞争对手关系也不弱。比价格，发现还是差不多。再往上加竞争层，比谁的功能强，比谁的售前方案和演示做的好，比谁的实施承诺和服务承诺好，比谁能够客户化修改，比谁能在现场驻扎时间长，比谁派的实力干将厉害，比谁客户化修改次数无限改动幅度无限。等等等等，比到大家觉得这单子签了也是个擦屁股事，坚持到最后的就胜出。如果洗洗澡吃吃饭给点回扣就能搞定，那销售就简单多了。过去可以，但现在不行了。未来更不行了，喝酒吃饭玩，那是工作之外的；谈到工作，还要怎么正规怎么来。想混水摸鱼报个价过关，以后出了时间问题和质量问题，谁的位子都可能丢，这个险没人敢冒。

当然，今天也不是对上一篇文章做FAQ问答。今天咱们仍然续接上回，给大家分享一下实施费用计算。

一个项目实施团队，由项目经理和培训专员两类角色构成。往往一个项目实施团队一名项目经理负责，若干培训专员组成。若干培训专员根据客户所购买系统模块数来定人数，一般一个子系统派一名培训专员。
 
项目经理的职责为：
1项目范围界定
2制定项目计划
3组织项目成员
4协调相关人沟通
5保证项目质量
6推进项目进度
 
而项目经理，也分为高级项目经理、中级项目经理、项目经理。分别对应5年、3年、2年项目管理经验的实施项目经理。当然，不同级别的项目经理和培训专员，薪水都是不一样的，能力也是有高低差异的。
实施阶段分为项目调研期、项目数据准备期、项目培训期、项目上线运行期、项目验收期。

项目调研期，项目经理负责项目范围界定、制定项目计划、组织项目成员。培训专员收集项目详细资料，以利于项目经理界定项目范围和制定项目计划。

项目数据准备期，培训专员负责培训基础数据准备负责人员需要准备什么数据，数据如何编码，什么样的数据算是合格数据，培训数据准备操作员如何进行数据准备操作录入，帮助校验录入的数据是否正确。项目经理负责客户设计数据准备过程中出现的特殊数据处理方案。

项目培训期，由项目经理负责培训计划和培训协调组织，培训专员负责培训。

项目上线运行期，项目经理负责推进项目保证项目平稳全面的上线，培训专员负责现场指导手把手深度培训。

在项目验收期，会对前期所做的工作进行总结，指出不足，报告以后系统维护的重点和注意事项，对项目上线效果给与评估。

我遇见过这样的客户：不用我们培训。我们提供了详细的数据准备规范文档，系统初始化手册、业务功能使用帮助文档。他们也不需要我们定制化修改，他们自己培训自己上线。他们甚至不需要我们做项目效果咨询评估。

我们有不同级别不同费用的项目经理和培训专员可以让客户选择。当然，项目实施周期阶段，客户也可以选择。

有的客户需要定制化修改，我们就签项目调研期。他们不需要我们做培训，那么就把培训期的费用去掉。如果不需要我们辅助指导数据准备，那就把数据准备期的费用去掉。如果上线不需要我们监控切换过渡异常，也可以把上线运行期费用省掉。

客户可以根据自己家的IT建设复杂情况、历史遗留问题情况、人员素质情况、人员规模情况来决定每个阶段签多少天。但是，例外的是：我们的培训是单算费用的。

这样，实施费用=（所选级别的项目经理每天费用+N套子系统x所选级别的培训专员每天费用）x实施天数。

项目经理和培训专员级别不同，就有不同的每天实施费用。而实施，是由于出差到客户现场的，所以软件公司要支付员工出差福利补助，这部分钱当然需要从客户实施费用中拿了。实施过程中花费的电话费、餐费、住宿费、交通费，样样都需要钱，这都要考虑到实施费用中。

对于培训。有正规的培训专员，也有正规的培训课程、培训课本、培训练习、培训考试。靠嘴皮子培训，靠一份使用帮助文档对着每个界面操作来培训，这种土包子方法已经无法在正规性和专业性上让客户满意买单了。

针对培训，每个子系统都有自己的培训课程。而且分的很细，成为多门课程。有针对最基层操作人员的，有针对小组长管理的，有针对科长管理的，有针对该系统的信息科系统维护人员的。

而且，由于客户的IT水平不一。所以即使针对某一角色，如最基层的操作人员，也有初级课程和高级课程。

每门课程都有课时长、参加人员需要具备的技能条件要求、合理的培训人数限制（培训人数太多会影响教学质量）。

而且，培训都有次数。

这样的话，培训讲师费用=（某一级别的培训专员某门课程的培训费用）x培训次数。

我们有个培训课程列表让客户选择打勾，客户调整自己需要的培训次数，就会自动计算出来培训费用了。

培训，除了培训讲师费用，还有培训课本可以选择。因为培训课本都是印刷的，所以培训课本也是收费的。每本书价格都有不同，明码标价。买多少本，客户自己计算。

所以，整个实施费用，都是可计算的。给客户一套实施费用计算表，客户根据自己的财力和想达到的效果来调节参数，就可以选择适合自己的项目经理、培训专员、实施阶段、培训课程、培训课本。

要么继续混水摸鱼，打包了整个铁板一块的实施方案（现在软件都讲究积木化，为什么实施不能量贩式）给客户一个总数字，等待未来被淘汰掉。要么把选择和决定的权力交给客户，去主动拥抱未来。（我想起过去的商店和现在的超市）

如果你觉得未来还是浑然一片水而不是DIY的时代，那么，请继续....

饭肯定是不能白吃的。朋友告诉我：唉，烦心啊。客户不成熟，是麻烦事。客户太成熟，也是个麻烦事。

我说，此话怎讲？

我朋友说：你看，我过去跟单，客户对软件不懂，但他却知道有个华军软件园，里面有可以免费下载的管理软件。我报个两万的价格

客户直晃脑袋说：我以为你们的软件600块钱就能买到，怎么你们要杀人啊？

我朋友一脸苦难相：两万块您都觉得贵啊。我们可是带技术支持，还有培训，还要给您做定制化开发呢。我给您这两万的报价，也已经是我插草标卖人的价儿了。

客户还是直晃脑袋：谁不知道你们软件开发，就一台电脑一个人，啥费用也没有，就卖我们两万。你看我们，进原料买地建厂房招人买流水线搞运输招商做广告打价格战，我们可是水深火热啊。我们全是成本，毛利极低，赚的都是血汗钱。你们呢，啥原材料也不进，流水线也不买，也不建厂房，居然卖两万，你说你们的利润多高？

我朋友无语。

我朋友就盼着能有个了解软件行业艰难的企业CIO能互表衷肠。

这回他总算遇见了。

大活儿。这次可是大活儿。我的朋友这样评价这个项目。

原来是一家企业，计划要给它的全国经销商渠道开发一套管理软件，以能管理全国进销存的情况。但是这次就是由于是个大活儿，所以客户方要求把价格报清楚了，不能开发费+实施费+...=总费用这么简单。他需要我给他说出个道理。为什么这么多。而且这个企业CIO最难搞的就是，他明告诉我，别跟我说你们一个开发人员的每天费用是3000块。你开发人员月工资9万啊？

这回我是折了。我过去都是做小单子，和客户反正也有关系（现在哪个上三万元的单子是打陌生电话打出来的？），于是就囫囵吞枣就把单子签了。水清则无鱼，看似软件利润高，但软件这个东西看不见摸不着不好销售啊，报的价格高了谁都觉得你利润高，不吃你吃谁。所以到处都是爷，哪个门都得把香烧到了，最后落手里其实我也剩不下多少个子儿。还得给员工发工资，还得请客送礼，还得交税，还要交办公室租金，每月这费那费都是要钱的。苦啊。

我故意逗他：那你干脆关了公司，回去继续当程序员。

我的朋友诡秘一笑：呵呵，还是比给别人打工赚的多。别跟我打岔了，快给我想个方法，怎么报价让他觉得合理。

我说：看到了吧。耍嘴皮的哑了口，混天黑的犯了愁。以后，拍脑门的时代就算一去不复返了。客户也不是冤大头，你说个10万就给你10万。你以后不给说清楚了，谁也不会跟你签单。

我朋友说：那你快教教我啊。

我说：唉。我遇到的问题和你不一样，但我的解决方法也能解决你的问题。

我过去遇到的问题是：我一直在琢磨如何提高销售收入。否则，这么老路子做软件，费死劲也挣不了几个钱。所以，我在研发过程管理上引入了一些方法，引入专职的项目经理、公共代码开发、测试员，来收集需求、控制需求、安排进度、把控质量。在产品制造上我引入了美工来美化界面，引入了文案编写了精美的帮助文档、产品白皮书、演示版和视频教学。让销售拿出去给客户打单，一看PPT一看产品演示就感觉这是个专业的产品。另外，我在实施和咨询和技术支持也下了大功夫，让这种专业性一直连贯的保持下来，否则就会让客户感觉签单前很专业，一签了单子就糊弄人，这样生意就没得做了。

有时候你会遇到这样的场景：客户说你的东西太贵了，而你的回答往往是一点不贵啊，我才给您报3万块，您的企业一年的流水就一个亿呀，您坐的宝马车一次保养就3000多块。您看，软件能全体员工用，而且能提高您企业的运营效率，才3万块，多值啊。

但客户还是觉得贵。为什么呢？不是他掏不起这三万块钱，他可能请他的客户吃饭，一顿饭就能吃3万块。他为什么觉得他吃饭3万块不贵，而3万块买你的软件就贵呢？原因就在于他觉得你产品不值3万块。但到底值多少钱，他也不了解软件成本构成，所以他按心理估计，给你的报价上打个5-7折应该没错。

而软件这个东西，尤其是管理软件这个东西，就非常类似古董字画一样。在识货的人看来，他非常值。在不识货的人看来，一文不值。而管理软件的销售人员，尤其是销售这个行当，正规的管理方法很少，大部分都是术和案例，喜欢出新招出奇招，而对按部就班的流程运作颇为不感冒，所以对固化流程的管理软件也是觉得没什么大作用，比EXCEL贵还比EXCEL难用，所以也讲不出来这个管理软件该值多少钱。客户也不知道值多少钱，销售也不知道值多少钱。这样，双方的价格磋商，就成了互相猜心。客户觉得打他个5折，他估计就实在了。而销售呢，估计客户能承受xx万的价格，所以我就报个xx万。价格和软件成本没了关系。到底这个项目做到最后是赚是赔，都不清楚。反正单子我是签了，我的销售任务完成了。

我就是为了应对这种销售和客户乱猜拳互博弈谈价格，才出此方法。

我先给你说说软件开发费怎么报。下次再请我吃饭，我再跟你说如何给实施报价。

产品开发由以下阶段构成：
1客户调研、客户调研报告编写
2功能设计、功能设计说明书编写
3开发
4测试
5帮助文档、培训课程、培训演示版本编写

其实，产品开发完毕后，还必须由开发部的文档组对实施部门的培训专员和项目经理进行内训，否则产品知识无法通过培训专员和项目经理传递给客户。这个内部培训也都是有成本的，而客户和你，往往都会遗漏的。

由于功能说明书为内部产品开发使用，所以功能说明书不会销售给客户。如果客户非要连功能说明书都认为是他的产品的一部份，那么他也需要花钱买走。这也是文案人员和项目经理辛苦劳动的成果，又不是自动产生的。有付出就必然要求回报。

产品开发团队由如下人员构成
1客户调研团队
2产品开发团队
3产品测试团队
4产品文档教育团队

客户调研团队，由项目经理和培训专员构成，亲自到客户现场去调研。每个调研团一般由2名人员构成，1名项目经理，1名培训专员。由于不同经验的人当然工资待遇不同，而工作的质量也就不同。所以我们的调研项目经理，也有高级调研项目经理，中级调研项目经理，调研项目经理三个等级。你如果作为客户，你敢把企业的需求和流程梳理交给一个刚毕业出来的毛头小子么？他对企业的感觉连企业的一个看门人都不如。当然，不同等级的调研项目经理，调研一天的工作费用当然也是不同的。与之匹配的调研助理（培训专员）也是有不同的经验等级的。

调研费用，按调研团队人数和工作天数和他们的工作费用和调研家数计算。出差过程所花费的交通、住宿、餐费不包含在他们的工作费用中。调研是调研费，这是调研的工作，但出差产生的费用是出差的费用。如果你把这些都整到一块，你的调研费用肯定看起来很高，客户又质问你怎么一天3000块了，还不如报的时候就清楚的报。哪里都需要钱呀。

一般，调研周期为两周。先是调研收集客户现有状况细节，然后进行现有状况梳理。梳理理解后，总结疑问，并与调研方开会，双方就疑问和目标和需求进行讨论。最后是根据多次讨论进行调整，得出最后的调研报告。

我为啥说需要两周呢。因为一个企业有许多部门许多岗位。你要把客户的整个组织结构和岗位职责和流程，和他们的现状问题，和他们的需求目标，都需要调查清楚，而且还要和他们协商统一认可好如何改进，否则你怎么设计适合他们的系统。没有两周的调研和讨论和反复修改磨合，你出来的软件更是痛苦，调研3天，开发1月，实施和不断修改2月，维护修改和稳定和技术支持3月。最后客户还抱怨你的软件太不稳定，N多需求都没有做，当然不能付尾款了。你不答应他们的需求，你就拿不到尾款。于是，需求修改更新，发现又引出了其他的BUG和需求，噩梦循环啊。

咱们说说调研。

例如，调研10家客户。客户分布在东北、华北、华东、华南、华中、西南、西北。调研需要2周的时间。如果遇到星期六日还需要出差进行工作，那么休息日加班费就按国家规定累计。

这样来算一下费用。高级调研项目团队，中级调研项目团队，标准调研项目团队，（每个相应等级的调研项目经理每天的调研工作费用+他的每天对应的餐费交通费通讯费住宿费+每个相应等级的调研助理每天的调研工作费用+他的每天对应的餐费交通费通讯费住宿费）x10天工作日x10个城市，你看看多少调研费用吧。你用一个EXCEL做个自动计算就OK了。你把这个公式内置到EXCEL中，客户只需要选择自己想要等级的调研人员，填写要调研一家的天数，再填写要调研的总家数，调研费用自然就出来了。如果客户觉得不能接受，就让客户自己玩这个计算公式，直到他自己都觉得确实没什么水分了作罢（他也不是变态狂，以榨干软件公司逼死软件公司为乐。所以，他认可的是一个合理的报价，而不是离谱的报价。他认可的合理的利润还是手下留情的）。

想想吧。没有跟客户要一点浑水摸鱼的费用。都是大家都能认可和理解的费用。假设，一个在本行业信息化工作了5年的调研经理，他的月薪水达到6000块应该没有人质疑吧。那么他这个人每天最低的成本就是200元。再说了，这个员工消耗的其他办公费用与福利与税金也是有均摊成本的（企业总不能无原因生钱吧。钱肯定还是要从客户这个源头来）。

另外，我还没有计算调研团队在这2周的调研时间内，还有4天的休息日，如果工作的话，这个加班费用还没算呢。你可以算一下。

调研完了，就要开发了。你以为雇佣几个编码人员就能搞定了。那样的搞定也是活稀泥的，最后不断修改的成本能让你把赚的钱都吐出来。所以为了以后不秋后算账，我们就得从一开始好好做（如果你想赚更多的钱，可以把我给你讲的配置都缩减了。当然，质量和效果也就缩减了。一文价钱一文货，谁也不白给。国内软件如此现状，就是为了多赚钱，最后把客户给的合适的费用都缩减了，但是给客户报的却是达到100%效果的人员数量和人员素质和人员天数。这个中间差就是个小九九了）。

产品开发团队，一般由以下角色构成
1开发总监1名
2架构师1名，公共代码开发人员2名
3业务开发组长1名，主要代码开发1名，辅助开发1名。每个子系统由3名人员构成。假设有4个子系统，就需要有12名开发人员

产品测试团队，一般由以下角色构成
测试员1名。假设有4个子系统，就需要有（4+1）=5名开发人员，其中+1是公共代码测试。

产品文档团队，一般由以下角色构成
1每个子系统一个文档编写与内部培训人员。假设有4个子系统，就需要有4x1=4名文档人员。

所以，一个产品开发过程，以4个子系统为例，共需要参与开发人员
1客户调研团队 2名
2产品开发团队 16名
3产品测试团队 5名
4产品文档团队 4名

共计27名参与者（估计许多人会说我三五杆枪能有这么多人么？楼主真是搞笑痴心妄想白日做梦。我报这个人数，是为了计算一个能达到客户效果的一个合理人员配置上。国内软件公司往往无法满足，所以效果就不断衰减。不过，我一般都建议三五条枪的企业最好能从实施部门抽调过来调研、文档、测试人员，这样人数可以缩减，但要做的事情不能缩减，这样效果衰减的就不会很厉害。很多三五条枪的企业现状都是做一单骗一单砸一单，就是什么人也没有，两个开发人员从调研到设计到开发到测试到实施到支持都这两位老哥。甚至干脆一个人全挑。这样的现状如果不去想办法改观，软件质量和软件竞争力仍然无从提高。）。

客户调研周期14天。产品开发周期60天，产品测试周期10天，产品文档周期10天，产品内部培训周期10天。由于产品测试周期和开发同步测试，自己独立出来的10天是综合测试。产品文档周期10天也是如此。而产品内部培训周期10天，是必须在产品文档发布后才能培训。
所以总的项目周期会是14+60+10+10=94天，27名参与者。才能保证一个产品（4个子系统+1个系统管理系统）开发的质量。

平均每人6000元月工资算（因为有低工资的培训专员和辅助编程，也有中等工资的各职责经理组长，也有高工资的总监，所以拉平6000元，应该也算比较合理。）。一个产品的开发大约是6000x3月（94天）x27人=486,000费用（这可都是成本，诸位客官都看到了，里面没有加任何企业的利润点）。再加上30%的毛利，共486,000+145800=631,800。大约63万开发费用和3个月的时间才能保证4个业务管理系统的软件质量和进度。

这些人的成本，你都可以做一个计算公式，明明白白得算。在客户要求的质量、时间限制内，使用多少人，使用多高工资的人，一算，成本就出来了。成本出来了，再加上你希望的合理毛利，就得出了你应该报出来的价格了。否则，你拍脑门报价，做到项目结束，你还真有可能亏损了。那些被项目拖死的公司还少吗？

30%的毛利，剔除销售费用和税金和管理费用，纯利在15%以下。也就是说，年销售1000万，纯利才150万，其他都产生了费用支出。根本无法支撑下一年的生产再发展。

这样来看，软件公司确实活的挺惨。

这样来深入计算软件公司一个软件的成本和利润，我想那个说600元软件的客户该理解了吧（当然，那些总觉得老板是黄世仁的程序员，心里或许也能舒坦舒坦）。

一个问题：销售在客户面前总是夸大公司的能力，在项目谈判时，总是这也可以实现，那也可以实现，但实际项目执行时，却发现根本就很难执行。但销售对实际的执行并不了解，而且也许如果不这么做的话，可能根本就无法签单，如何解决这个矛盾？

我说你这个问题很普遍。大部分的前期跟单、签单都是销售在做。一般小公司，老板就是最大的销售，所有的大单子都是老板在跟。有的老板认为管理软件是管理的事情，管理软件有没有效果，和管理方法有关系，而和软件没多大关系，软件开发只是把管理方法实现编码而已。而且老板自己也平时挺注意IT界这些新产品的东西，什么Blog、工作流、BI、SAAS、地图、搜索引擎、大众点评也都知道。所以自觉自己技术感觉和商业感觉和管理感觉都不错，没什么名字，就造个名词，什么LAN方法，什么ANL方法，造呗。所以签单的时候，往往领着一个销售助理就上场了，PPT熬夜做的很漂亮，从麦肯锡、罗兰贝格中COPY了不少好看的图。关系再加上临场发挥，单子就算搞定了。

单子签好后，程序员根本不知道合同都签了些什么，合同都放在了财务和老板的手里。到了项目调研、项目开发或项目实施阶段才遇到客户的狙击：咿，我们要的XX功能你们怎么没有？

#@#$，我，我不知道呀。谁跟你说的？

你们合同里答应我们的呀。

我没见过合同。项目经理浑身在颤抖：你这该死的销售。

无独有偶，上个星期也有一个网友跟我诉他的苦：

一次，销售人员和老板一起在客户那里开会，客户的一个人说如果你们的软件中能和地图结合在一起，实时跟踪状态，那就非常妙了。老板一听，眼睛一亮。这可是我们软件的亮点啊。地图很好做，现在网上好多地图网站，都提供API，我们能很快实现。（我KAO，老板还知道的真不少，佩服，佩服）。

老板把他（开发经理，手下3人。来项目干项目那种，人手缺了还得自己组装机器掐网线，捎带给老板调调打印机或公司上网的路由器之类）叫到老板的座位旁，说要在软件的哪里哪里加一个地图，能怎样怎样的实时跟踪。

项目经理对地图不熟悉，但也听说过地图API这类事情。于是自己熬夜研究地图网站提供的API。但地图的API是地图网站公司做的。地图网站公司估计是做产品做的脑袋木了，根本没考虑这些想集成他们地图的开发商。可能提供出来API，只不过是为了秀一秀现在流行的Open API，表示自己的技术先进或开放。实际做事，没戏。于是告知老板，做不了。

老板急了，这可是咱们的软件亮点啊，有了这个亮点....。人家都提供API了，你们只是调用一下，又没有让你们做地图网站，我看很多网站都集成了人家的地图API。人家能做到，你为什么做不到？

项目经理开始解释地图API提供的技术缺失。但老板无法听懂。

于是，项目经理被老板认为技术不行。他现在很苦恼，老板不当自己回事，客户那里又被客户指挥来指挥去，下属干活还很烂，说明白了的功能被程序员实现的极不顺手，真想操刀把程序员的代码都大块删除了自己三两句代码给他改了。自己这个项目经理当的还真郁闷。看着人家销售跟着老板吃香喝辣，和客户一起吃饭唱歌，还能报打车费，和老板说说笑笑，老板有什么事都第一个人家知道，而自己就是个被老板指使干活的打工仔，郁闷的不行，想跳槽。

我问这位网友：人家为什么能跟着老板吃香喝辣？

网友说：还不是因为他会拍老板马屁呗。

我说：不。每个人都喜欢被别人捧，老板也是人，也不例外。但老板是开公司的，开公司是要赢利的，老板要赚钱的，光会拍马屁，如果不能给公司带来收入，老板也不养这样的马屁精。老板比谁都精。之所以老板很喜欢人家销售，就是因为在老板看来，销售是把钱能拿回来的人。假如没有单子，全体人就得喝西北风。

网友很不服：销售他再牛，他吹的天花乱坠能把客户忽悠晕了，也得我们这帮人去给他收拾屁股去。你再能说说出个花儿来，客户看不到真货也不会给钱的。

我说：人家为什么能跟老板一起到客户那里去开会交流，和客户沟通，而你不行呢？直到人家签下单子来告诉你让你做的时候，你才知道有个项目来了。

网友说：他不就是人长的精神，嘴会说，会做个PPT，会写个方案呗。要我，我也能写。满篇都是虚词，什么这架构那架构都是扯淡，客户都是不是傻子没个明白人？

我说：那我看看你的PPT。

他说：我没写过正式的PPT。没有机会啊。

我说：那你给客户实施，给客户培训时没有PPT？

他说：我们从来没有那玩意。谁来写。我写？我就是个干活主力，我加班开发都忙不过来，我还写文档？

我说：那你给我讲讲你们的产品的好处。

他说：我们根本没有产品。老板签什么单子我们就做什么单子。项目来了，客户要什么我们就开发什么，我们就是个编程机器。

我说：那你说说你现在这个项目对于客户的意义。

他说：都是老板的关系，整点事而已。其实一点没有意义。

我无语了。这样的项目经理，我看他再做3年也会是现在这样。光有抱怨，遇到问题抱怨问题，而不是去解决问题。问题不解决，仍然是问题。而这个问题对他的影响又很大，而他认为是别人的问题。其实，不管是谁的问题，只要是阻碍我的问题，我都要解决，千方百计去解决它。因为我知道，我受了影响，我如果连自己都不去救自己，就没有人救我自己了。

我面对这位郁闷的网友，我给了他一个建议：

你要先学会做PPT，不断对比销售的PPT，改进自己，超过销售的PPT。先给客户展示，让客户认同，然后要找时机展示给老板，让老板认同。我建议你作PPT，并不是让你炫PPT技巧。而是为了让你梳理自己的思路，将彼此关联的事物能条理清晰的结构化出来，并且能有重点的表达出来。想、做、写、说，对于一个成功的人来说都是必不可少的。

另外，你身上散发的程序员气质太浓。你需要把自己定位成一个项目经理，给自己加入经理的气质。否则，你给客户讲你自己做的PPT，客户觉得很变扭。因为他认为你就是个写程序的，你讲PPT就不是你应该干的事。这样，会阻止你的PPT得到客户的认同。你所做的事，一定要和你的气质匹配。你把自己定位成编码机器，那么老板当然把你就定位成编码机器了，那么老板干嘛要带一个编码机器去客户那里呢？

网友沉默了。

我也沉默了。我也回想起了我艰难起步的阶段。那个时候公司所处状况和这位网友说的情形很相似。我是职业经理人，而非老板。我面临的突如其来的项目（其实销售和老板已经酝酿已久，但自己一点风声都没有，老板和销售，谁也没有和我讲过）也是很郁闷（一点过程不让你参与，直到项目定型才让你参与）。直到有一天，老板内部开会，我说：我说说我的一些个人观点。于是，我打开了自己的PPT，给大家讲了起来。

老板说，这个PPT是你做的？

我说：对。

于是，我的机会越来越多（谁说开发人员只会闷头写代码，而不会讲和写？）。

后来，公司软件业务在我的推动下蒸蒸日上，老板给与研发部的资源也越来越多，对研发也越来越重视，我的手下逐步在我的带领下发展出来专职的测试、文案、公共代码开发人员。然后我的职位和职责也越来越高，我管理的人越来越多，部门也统管了好几个。我没有太多的精力放在做销售用产品和技术文案上面了。但是，老板没有发现这个变化。每次打单，还要叫我参加。看来，我需要一个人来接替我的这个角色。

 我需要物色一个人：

1他首先必须懂得客户业务，否则和客户交流一看就是个外行。

2他最好能干过开发。否则他也会和销售一样，不知道能不能技术实现，一律放炮答应下来。