技术不要臆想业务

    在数据的分析中，总是离不开业务与技术人员相结合，业务人员需要详细的描述业务需求，而技术人员总是在业务人员的需求上建立分析模型，在整个的配合过程中分析人员总是会遇到这样活着那样的问题，最终结果将如何谁都无法预料，但是结果往往都会出乎我们的意料，有似乎都与业务人员和技术人员相连，区别就是这些数据技术看着不方便，业务看着鸡肋一般，最终该如何去判定一个分析的成功性成为了难题，这些数据的成功性也成为了难题，应该如何去做？才能够达到业务的需求体现技术的价值成为了很多技术人员苦恼的问题，有些时候还是不要想得太多才好。

    在技术的过程中，你是否想多了？

    接触过很多技术人员，在征询分析需求的时候，甚至业务人员还没有发话的时候，他总是说我觉得应该是这样的一个模型，这样的一份数据，这些都是有用的，很多时候我们都无法说服他，甚至业务人员都无法说服，原因就是你在用他的系统，他设计的流程，自认这些数据都应该是你业务人员需求的，可很多时候技术人员在前期实施维护系统的时候固定的流程不一定合理，甚至就是因为这样一个流程导致业务现在都无法做一些必要统计，而此次分析需求就是要解决这些问题，但业务人员的思路被这样一些先入为主的概念打乱了，本来的需求被模糊了，怀抱一种，咦，这样做好像可以，这些数据好像就是我需要的。真是因为源于这些想法技术人员的自信心越来越强，做出来的分析模型甚至凌驾于业务之上，从而忘记了业务的本真，贴近业务才是最好的，所有错了不自知，或者是因为业务人员对技术的畏惧，相信在早期实施中很多实施工程师都遇到过这些的情况，业务人员说不敢操作，怕把说句弄坏或者弄乱了，本来很简单的操作在实施过程中可能要话费更多的时间来完成，即使源于业务人员一种思想，技术人员不推介的就是软件做不到的，这样导致很多需求最终是技术人员的臆想加上业务人员的估计完成的，这样的一个需求，在真是的应用过程中必然不伦不类，那么这些问题是怎么出现又应该怎么避免。

   首先还是技术人员的问题，技术人员应该从根本上去杜绝臆想业务，的确，在整个系统 的应用过程中可能是你实施的，也是你为当时的业务量身订造的一个业务流程，但这些数据仅限于当时，也许业务已经在变，你还不知道，而业务人员又上报提出新的需求，发生实际业务与系统业务出现一定的脱节状况，这样还基于错误的也业务去做的分析必然得不到理想的结果；另一种情况技术人员求大而全，总觉得这个数据有用，那是数据也应该有用，然而业务真正有用的数据存在更多的则是垃圾数据，非业务核心数据，最近单有的企业关心的可能是人员的时间素质而这个定义很可能在备注中，而技术人员大多只知道备注是附言，不重要更多的关注学历等，可能这是一个不恰当的例子，只是因为业务人员在使用的时候可能开发出很多专有的使用方式，技术人员不知道，造成一种错觉；然而这种错觉也不是无缘无故出现的，只是因为可能第一次使用系统的时候技术人员过于权威，能不能，行不行都是技术人员在掌控，久而久之技术人员总有自己是权威的概念，慢慢的与业务脱离，所以臆想业务的技术人员也就成为顺其自然了。

    这些问题的规避要从技术人员自身来完成，首先先把自己的位置防端正，不要代替业务人员做决定，自己的思想可以发表，但一定是作为业务人员的附属，不要试图去主导这些需求和数据，也不要出现觉得这样会更好，应该是询问这样做之后又没有用，更好有用可以再分析的附录上加以补充，而不是去取代，即使偶尔自己的臆想是对的，也不要试图去完全取代业务人员的分析，业务他比你更懂，现在已经不是早起的系统可不可以，而是他需要的系统可不可以，一定要把需要放在首位，所有业务人员应该指导技术人员去完成分析，而不是技术人员去询问甚至主导业务。

   所有现在对技术人员又提出了一个新的挑战，技术人应当怎么去引导业务人员对系统对系统分析提出需求，这样做的难度绝对不亚于实施一个系统，实施系统技术人员占主导地位，为引导业务人员的时候技术人员在一个重要的辅助地位，不仅需要完成业务了解，教会业务人员使用系统，更多的是教会业务人员去理解系统，认识系统，这样才能够使业务人员能够准确而合理的提出自己的需求。在这些工作的过程中大家都需要提高自身的素质，对业务了解对系统的认识，还需要不定时有针对性的对系统使用人员进行系统知识培训和讲解。

    系统永远的只是一个工具，如何正确的使用这个工具才是技术人员应该考虑的问题，现在的系统应用越来越广泛，使用人员的素质都在不断的提高，在系统中技术人员所需要做的工作也在更加的专业化，业务的了解比不可以，但是应该从主导地位退出来在引导的过程中完成分析。大到一个系统，小到一张单据，应当如此。