在实习的两个月里，作为技术人员，我经常是要和业务人员沟通的。特别是在接手大众人才网的工作后，每天的工作几乎都变成了应对业务人员无尽的需求。业务经常变化，结果导致技术也要跟着业务不停的变化。曾经有一次，上午根据业务人员更改的功能，下午就被业务人员要求修改回来。业务人员的这种不断变化的结果往往导致技术人员的无所适从，进而导致两方产生矛盾。技术人员认为业务人员变化太快，无所适从，业务人员反过来说技术人员服务态度不好。在双方的博弈中，不但沟通成本极大，而且往往导致合作双方合作不和，极大影像工作。
在原公司中，业务向技术提需求一般有两种方式
1、直接找技术人员当面沟通，直接进行修改。
2、提出书面需求，递交技术部主管，由主管安排人员进行修改。
规定虽然如此规定，但是在我实际的工作中，业务人员很少按照正规的过程提出书面需求，实际上往往正相反，业务人员更倾向于直接找到技术提出自己的需求。不管公司怎么规定，业务人员依旧我行我素，鲜有改观。相反，技术人员在屡次要求业务提需求正规化无效之后，抱怨更多，状态更差。
到底什么原因造成了如上结果呢？
首先是不是沟通方式不对呢，换句话说，是不是还有另外的更好的沟通方式？
我也曾经认为应该有一种更好的沟通方式，通过沟通手段的优化解决如上问题。虽然目前我还没有寻找到如此好的沟通方式，但是在与一位在大公司（新兴公司，国内目前最强）的朋友聊天中了解到，他们也是只有这两种提出需求的方式，而且同时并用。对于少数紧急问题，采用第一种直接沟通的方式。对于大多数问题来说，他们反而认为提出规范化的书面需求效果更好。
啊哈？怎么差距这么大呢？差距在哪里呢？
只要有公司能够成功运用这两条沟通方式，那么就证明方法本身没有错误，出错的地方在其他。
进而问朋友，他们公司的业务人员如何区分哪个需求紧急，需要采用当面沟通的方式，哪个需求并不紧急，还是采用书面提交好。因为根据我在公司的经验，业务人员在提交需求的时候并没有任务是否紧急，任务是否重要的区分。问他们任务是否重要，他们都说重要，问他们需要什么时候完成，他们都说越快越好。那我就怀疑，为什么朋友的公司的业务可以正确区分需求的紧急、重要程度呢？
朋友回答了一个很简单的道理，因为有项目管理。一个项目要求月底交货，那么15号提出的需求当然就不算紧急，当然需要提交书面需求了。
阿！原来不是方法问题，而是管理问题！
而且不是技术部门的管理，是业务部门的管理！
其实一进入公司，我就发现公司在技术管理方面比较薄弱。公司网站组的开发基本以一人为单位，顶多就是程序和美工的合作。公司在程序编写上没有任何规定，甚至连基本的源代码管理都没有。一直以来崇尚规范化管理的我在进入公司指出也是希望能够给公司带入规范化的技术管理。可惜，无奈的是，进入公司的我不但没有成功引入规范化管理，反而自己也被同化，开始做起了不规范的开发。
通过这件事情，我深刻地意识到，一个公司的规范化，绝对不仅仅是一个部门的事情。由于实习的公司是一个严重以业务为导向的公司，所以业务部门的行为不仅仅为其他部门提供了钱财，更为其他部门定下了基调。业务部门本身管理混乱，不正规，其他任何一个部门都无法规范化。特别像技术和业务这两个联系密切的部门，一方的混乱肯定造成另一方的不适应。特别当一方是主导部门时，更加加剧了这种影响力，结果导致另一个部门无法规范化。不管出台什么样的规定，到最后只能是应付公事，没人执行。
好了，原因清楚了，业务部门是这里的病因？
其实不然。如果一个公司一个部门并不规范还有情可原，当大多数部门都不规范的时候，原因何在？
局部的问题可以找部门经理，如果是全局出现问题，总经理的责任无法推卸。公司之所以在下级表现出管理的混乱，其根本原因还在于领导的意识。朋友所在的公司也不适什么老公司，也是城里没有几年。而且朋友所在的北京分公司现在才刚刚成立，更是处于创业初期，竟能如此规范。当然，总公司管理的积淀有所作用，但是不能否定的是，公司领导对于规范化管理的重视也是很重要的。只有领导的指示，下级才能执行，才能在执行的过程中产生竞争力。
其实，在我实习期间，公司已经出台了不少管理规定，对公司的行政过程进行规范。遗憾的是，先不说这些行政规范是否可行（公司在招聘人才方面的规范就有问题），单单说公司在规范出台的范围就有问题。公司出台的仅仅都是针对行政过程的规范，对于公司本身核心的业务和技术两大块却没有引入任何规范。
其实公司行政的规范可以说是必须的，也是容易的。但是公司业务和技术的规范确实灵魂的，因为只有规范这两块，才能真正培养公司的核心竞争力，打造公司特有的文化！
今天和朋友探讨的寥寥几句，突然幡然醒悟，察觉到如此道理。其实彼此之间的沟通往往还真是思想火花的根源。当然，此乃一家之言，仅供参考。
