一点思考

昨天和同事讨论系统升级的问题，同事说能否用一个基于表灵活的增、删、改、查的机制来演进系统。这个问题应该困扰过不少小伙伴，接触一个项目，经过短暂的新鲜感之后,就发现这个项目还是增、删、改、查的那一套，没有任何挑战...

首先项目是增、删、改、查操作组成的，这个说法有没有问题，个人认为是没有任何问题的。从大的范围来讲信息流的包括产生、传播、采集、加工、编码、存储、使用。大体上也是那四个大的操作。谷歌和百度的最大价值不就是可以提供了一个可以查询的功能吗？那么这说法有什么不足呢，个人认为最主要的就是可能会丢失“why”。即为什么这么做，这么做有什么限制限制是什么。

同时有可能会引入一些潜在的问题。

第一点 没有管理好涉众(项目干系人)的期望 这种思想和容易转变成我们手里有个锤子，看什么都想钉子。有时候甚至忽略项目干系人的期望，而项目的最大价值在于满足涉众的期望，而涉众的期望是通过“业务功能”来满足的。就像一千个读者眼里有一千个哈姆雷特，不同涉众对项目的期望是不一样的。操作员期望就是操作简单，省心、可以早点下班；甲方老板的期望一般是把业务支撑好，提高组织效率，增强竞争力，可以从市场上获取更多的回报(或者更好管人、管事、甚至就是为了看着爽)；乙方老板甲方尽快验收付款，同样投入尽可能多销售；运维人员希望来自客户的骚扰更少、维护更简单；研发人员学到更多的研发知识，让钱包鼓一点，成就感更多一点。忽视涉众的期望，注定会为项目实施的过程中平添许多障碍。

第二点 降低参与者的回报 首先我们需要理清一个思路就是组织的利润是怎么来的，就是利润=收入-成本。对开发组织来讲 利润=需求-设计（这个观点来自潘加宇）。需求是解决“产品好卖”的问题，设计工作致力于“降低成本”的问题，设计降低成本是说我们通过优化流程、通过设计提高组件的复用能力来降低成本。这个公司对互联网公司基本也是适用的。

甲方不会因为您的工程师懂的相关的算法、熟悉更多的框架而买单，作为服务的提供者必须通过计算机领域的知识来满足用户的业务期望。一般来讲这是事情是需求人员或者产品人员来做，首先这里就引入了一层角色。业务领域的知识就在那里，不会因为工程师的不主动参与就不存在，反而会因为工程师的刻意回避而产生很多问题，简单粗暴定位是因为开发人员对业务知识了解得不到位而造成的，这个时候组织怎么办，增加更多的产品经理来跟工程师沟通，增加更多的质量保证人员，更多的参与者同时会增加沟通的成本，这些人员成本、沟通的成本都会统统算到“成本”里 。但是甲方的费用就那么多，怎么办？降低参与者的回报呗！

同时因为开发人员和运维人员离交付的产品最近，也可以讲位于工序的下游，往往需要背更多的“锅”，但业务信息的流程是: 用户->需求(产品)->设计->研发,单问题反馈的流程一般却是 用户->运维->研发，业务知识层层传递，到开发人员这里已经有多少失真和丢失了呢。更有甚者如果需求、产品经理本身技能匮乏、对业务知识了解就不充分呢？ 这些二手业务知识会不会把开发人员带沟里去呢，因为这些项目最终的维护这一般不会是需求和产品经理而是开发和运维人员，这其实变相等于开发和运维在为需求和产品经理的过失买单，这种现象是否合理呢？看来研发人员为了维护自身的权利也要积累一些业务上的知识。

在做项目的时候客户需求不明确，是变更是会导致返工和工期延长，但谁又能保证不是我们把需求做错了呢？

第三点 增加系统演变难度 对业务知识的忽视，导致工程师以功能角度来组织代码，系统中的代码缺少逻辑，或者逻辑大量重复。在新增功能的时候，之前的流程和代码的缺少系统，开发人员为了“稳妥”往往会重新写一套相关逻辑，同样的业务知识遍布系统各处，一旦修改工作量急剧上升，导致大量的加班加点。 随着时间的流逝Bug像田鼠一样，永远打不完，而定位、维护代码成为灾难，更不要说优化与扩容了。这个时候维护这个项目的工程师信心也会越来越低，伴随的人员的更迭，如果组织没有跨的话，会有一个新的团队站出来"原来的一套问题太多我们重来一套吧!"。经过昼夜奋战系统出来了，但是站在更长时间流来看，这其实不过是一种循环。

这种现象不会因为我们采用面向过程、面向对象的软件方法(其实这两种方法论往往都没有得到很好的实施，就是用来背锅的)、采用了J2EE的平台，.NET平台，采用了..牛X的框架而得到缓解。

理想的业务框架是把一些业务知识封装进去，提供一个良好的开发规范，达成一个统一的共识。但是这需要我们首先走出已计算机领域为沟通语言，尽量以业务语言来沟通，同时需要不断优化迭代我们的业务知识。

说的蛮多，那么这种现象背后存在的原因是什么呢？个人认为大概也有以下几点

第一点 分析业务需求费事费力 因为现实中我们接触到的需求往往是模糊的，参与者具备的知识背景是不一样的，需求分析人员和用户人员沟通对信息的编码和解码导致信息的失真、丢失严重。也就是需求人员获取到的需求真实度不高，像需求人员常用的采集需求来描述他们工作。好像需求是怪怪的小蘑菇，静静躺在森林里，而他们则是采蘑菇的小娘，唱着欢快的歌，一蹦一跳的就把需求采集回来了。但需求并不是蘑菇，需求人员要能够象猎人一样，用锐利的眼睛发现隐藏在丛林中的猎物，像侦探一样，用缜密的思维判断出伪装成好人的凶手。

第二点 从短期回报和可行性角度 从精神和物质领域来看回报。首先从精神领域弄清楚一些业务问题的成就感远没有掌握一些新知识来的大，同时技术更牛的人往往更容易获取 开人员的欢迎和尊敬而掌握更多业务知识的人。第二开发流动性非常大，虽然用户不会因为懂不懂一些新的框架、名词而买单，但软件公司会！第三、业务领域知识复用度不高，可能只有这个公司甚至项目会用，囿于工期和沟通成本等原因，导致获取详细业务知识难度过大。

第三点 缺乏专业知识的引导 很多开发人员是计算机专业出身，对计算机领域知识掌握的很好，但对软件工程领域的知识就相对匮乏、业务领域知识就更是要从头开始琢磨。因为计算机科学更多和设备打交道，而软件除了设备还有人、业务流程，甚至还承载许多人主观上的期望。软件工程领域知识很大一部分就是如何把业务领域知识通过工程化的手段映射到计算机领域。

说了这么多是不是要求研发人员都去做需求呢，其实不是的。而是要求我们多积累一些软件工程的知识，可以用工程化手段去实现业务需求，不是要求每个研发人员都成为领域的专家（这也不现实），只是要求我们在开发过程中关注业务知识，同时以业务领域的知识进行沟通，降低信息在编码、解码过程中的失真和丢失率，领域知识的复用来降低“设计”的成本，提高组织的利润。