yutao051的专栏

我曾在济南一家软件公司开发管理软件，那时刚刚完成北大青鸟的培训，所找的第一家软件公司，这家软件公司几十个人的规模。用jsp开发。刚进入公司就分配到一个项目组，该项目已做到一半了，该项目搞jsp就三个人，其中一个是我的头，一个搞数据库管理，一个搞jsp开发。在参与项目的过程中也产生了困惑。可惜当时没有机会也没有高人指导解决此困惑。后来随的工作经验的丰富以及跟各位朋友的交流，逐渐明白了困惑所在。特写

懂业务真的是那么容易的吗

软件工程在中国是喊得响亮，做的肤浅，打着敏捷的旗号用的其实是瀑布模型的比比皆是，懒于对软件工程的精益求精，实践中拍着脑袋做需求做设计，美其名曰白猫黑猫，抓到老鼠的就是好猫，这其实就是一个偷懒的借口而已。        没有软件工程的基本功，拿着国外提炼的标准模型感叹“到底怎么用啊”，提一个学习软件工程的建议，却说太复杂了，简单才是最好的，可是如果你把你理解的东西叫简单，不理解的东西叫复杂，这跟

我们常讲搞信息化的要业务为主，但业务究竟是什么呢，把企业的流程搞明白了，就是懂业务嘛！可是实际上企业的信息化依然还是成功率很低，这也代表了业务的观念有一定的偏差。        业务的本质依然还是需求，只是需求的一个分支，企业里搞管理的人都不是信息化专家，实在不知道信息化究竟能做什么，但根本的需求永远只有一个，就是简化管理的复杂度，无论什么企业的管理者，无论提的什么需求，其内心的核心需求是很简

在信息化领域里大都是以业务为主，技术为辅，这种模式其实是理念的差异，并不是必然的选择，要根据公司的战略来选择合适的理念。        无论怎么样的信息化领域，在面对不同的企业时，都会面临一个问题，很少不需要修改表就能满足企业需求的状况，二次开发的最好的结果就是只扩展一些字段，有些系统商会拒绝涉及修改表关系的二次开发，这种状况在信息化领域很普遍。造成这种状况的原因就是业务为主，技术为辅的开

最近参加了部门组织的拓展训练，常规的拓展训练大道理就不说了，我从另外角度观察到部门的工程技术人员的做事习惯依然还是感性为主，虽然部门的工作方面的交流应该是以量化的方式为主，但深入到个人的某些习惯中可以看到骨子里并不是一个习惯量化方式的，大多数人都因工作需要被量化了，在非工作的状态中就会表达出来真实的习惯。试想一下如果系统分析人员选拔了不习惯量化方式表达的人，其分析的结果会怎么样，方式方法还会自我改

敏捷模式是一个很好的模式，但也不是所有的小项目就一定能应用的模式，甚至是一个很挑项目的模式，最近在一个项目中通过实践对敏捷模式有了更进一步的理解。在这里先记录一些琐碎的心得。1、敏捷模式的项目参与者最好是100%的参与，哪怕项目中一个人不能做到，你都要小心考虑，星星之火总会有

业务和技术的关系，由于国内大多数都是搞管理软件的公司，所以业务至上还是有普遍的现象，无法摆正业务和技术之间的关系。真正决定价值的并不是业务，是需求，业务并不等于需求，是需求的一个组成部分。 业务是纵向了解领域知识，所谓纵向是指行业的业务知识只能在该行业用，有很大的行业独占性，无法做到行业间通用。 技术是横向的了解领域知识，追求的是跨行业的通用解决方案。很多基础软件就是跨行业的，比如数据库

我们经常讲软件工程或者其他行业或专业的工程，很少有人去谈软件工程到底是为谁服务的，不搞清这个在应用具体的软件工程时，难免会遇到效果不佳的情况，尤其是所谓MBA出来的所谓管理者在设计技术领域的流程时就会普遍的遇到的执行效果不佳的原因就在于此。  每个公司都会根据不同的工程理论设计自己的一套流程体系，这种流程体系大多数会倾向于为管理服务，不为技术人员服务，甚至也不是为客户服务的，如果是制造类

ISA95背后的抽象模式设计启迪