客户就是一群孙子

    标题纯属押韵，主要是聊一聊关于需求。
    对于普通客户来说，不明确的需求代表了他对自己的业务本质不清楚，就商业来说，就是说赚钱了却不知道钱怎么赚来的，于是和这样的客户打交道就会出现这种情况，他的需求不断的在改变，因为目标的不清楚导致需求的不清楚。那么对于这样的客户该怎么办呢？你要做正确的引导，得告诉他钱怎么赚来的，是处于商业链什么位置，这个位置的特点是什么所以才赚到钱的，说白了你比他还懂，完全可以自己开公司去了。
    靠，对企业做正确的引导，你明白是什么意思吗？
    就国内而言，本身就缺少需求工程师，而且国内的需求工程师的能力非常令人怀疑，从他们的教学课程来看，也只是停留于设计层需求阶段，也就是大家有可能偶而会用一下的UML，用例等等，对于用过这些做项目的兄弟可能会发现，如果是复杂业务，最后的结果要么是不得其门而入---最后做出来的图到底要怎么和程序逻辑联系在一起。或者是根据最后做出来的图进行程序设计，做出一个奇怪的复杂的难以维护的东东。为什么是这样？因为设计层需求不过是业务流程，而不是需求，真正的需求是域层需求,是企业的目标。
    很可惜，虽然知道了需求的本质，但大家不一定做的到。第一个不一定是关于企业的目的，要想了解这个东西，就必须知道企业到底是干什么的，所谓干什么，不是指它在办工厂，卖东西这类表象，而是必须知道这个企业的本质，就像我上面举的关于商业的例子，你的钱怎么赚来的，在大环境中处以什么位置，位置的特点是什么，有了这个了解，你就很容易明白他让你开发的系统要做什么，因为他提出的那些稀奇古怪的要求实际上都指向一个目标，就是他的生存发展---怎样更好的生存发展。你都不知道它的企业的位置，你怎么帮他生存发展。当然，大部分的企业也和你一样，不知道自己干什么，所以大家都不知道干什么的话，互相骂孙子是系统允许的。当然，骂孙子我也骂，但这里只是提示你自己考虑一下，如果你真的想要了解企业的本质，你需要有多大的知识面。第二个不一定是，就算你现在真的想学对真实需求的分析，据我估计也是5年以后才有可能有成绩，MBA大家都知道吧，很多年轻人去学，最后的结果是求道者多如牛毛，得道者寡如麟角，因为有些东西不是学了就可以
用，阅历，经验的培养不是一朝一夕的，而这个不是一朝一夕能有的东西就包括需求分析，你要了解，你要进行需求分析的可是各种业务本质，不只包括商业逻辑。
    有了以上的了解，大家就明白偶为什么要对‘对企业做正确的引导’做出‘靠’的表述，就程序员而言，其相当于所做程序公司的经理，至少是人事经理，因为你们所做的程序，规定了客户公司的人员如何动作，照理说这是对客户很重要的，不能忽悠。可现实情况是，不忽悠不行，国内99%程序公司根本没有我这个级别的需求分析人员（纯属自夸），程序员从头到尾全包，而面对的客户99%都是需要‘正确的引导’的情况，这相当于什么需求呢？---做软件+企业顾问，需求分析里有一个无理需求的例子，就是客户要求此程序能够提高公司10%的利润，这是完全不合理也是无法保证达到的，利润和很多因素有关，要做也是专门的企业管理公司来做。就国内公司而言，要么你自己需求确定，要么多付钱，我们一起花时间和你进行‘企业顾问’方向的研究，毕竟时间是有成本的，否则的话，我的意见就是---客户就是孙子，该忽悠就忽悠。另一个不忽悠也不行原因是---哪有那么多程序员像我一样即懂技术又懂‘企业顾问’（也是自考）。当然，对政府的操作又是另一回事，这些TM拿着铁饭碗的，跟群猪一样，偶至今没见过能和猪交流的，你要做的只有一件事，该给红包回扣自己看着办，反正靠的是关系，做的不好可以升级（也可以叫修补），每升一次加一次钱，这样可以充分的证明你的技术有多强劲，又可以增加收入。就算他们觉得不好用，不要你开发了，反正下次找别人开发，这活也落到别的程序兄弟身上。
    好了，最后谈谈运用域需求加业务本质进行分析后的程序是个什么样，是一种逻辑高度抽象加属性扩展的小功能块，适用于任何需求，这些块的耦合非常低，这么说吧，每个块都只知道它自身，而不知道它在程序中的位置，最糟糕的是这些块里的逻辑只有些普通的增删改查，如果去掉这些功能块所代表的意义，你的感觉就是在操作一个普通的表，表代表的含义是你确定的，就像把功能块组合起来代表的含义由客户确定一样，客户要叫他进销存也好，叫他OA也好，对你来说已经没有意义了，他们对你看来都一样，都是一堆数据，最重要的是你理解怎样组合他们（业务本质），方法大于技术。
    为什么要说最糟糕呢？因为即使功能块组合，也只会有普通的左右连接操作，不涉及报表的话，几乎全是普通操作，随便找个上两星期程序课的新手都能做出来，TMD,老子白学那么多年编程了。