Talk to COO 合理化建议和沟通

2009年初,我们公司开始了重新设计和开发库存管理系统,可以用革命(Revolution)来形容,有点背离了Agile提倡的进化(Evolution)主旋律.

基调比较简单:

1) 改变Slow-by-slow(row-by-row)慢之又慢的数据处理模式, 启用(bulk loading)打包成批处理.
2) 合理denormalization,减少不必要的表连接.
3) BASE第一步: Function split功能拆分 和 Asynchronous process 异步处理.
异步处理,必然引出数据复制和消息系统, 我们的消息系统数据量一大,就会僵死. 我选择了数据库staging table(数据驿站)来缓存修改的数据,对于staging堆栈表,根据简单处理过的时间键,做列表分区,做到冗余数据的最高效利用 (我一向认为队列消息属于被复制的冗余数据).
关于设计时间相关的历史数据模型,数据建模宝典(Data Modeling Essentials - Third Edition)推荐了两种方法,一种是Audit Trail(记录数据偏移,从起点累积),一种是Snapshot(历史镜像),我在不同场景都有采用,以后找机会做细节示范.

有一个业务逻辑的改革遇到了较大的阻力,最后决定直接找COO商议,结果还是很理想的,清除了数据处理设计的最后一道障碍.
跟产品经理和项目经理谈了很多次,结果是"多一事不如少一事,事不关己,高高挂起",这伙人才懒得从公司盈利的高度考虑问题,所以要转向那些能做决定,能从大局着眼的人士.

下面简单介绍一下这个高投入低回报的业务功能:

就是维护书商的产品分类,上传图书数据的时候,捎带检查图书分类表. 每行图书数据里面,包含了图书分类,一个或者多个,如果是新的分类,就在书商图书分类表里增加一行.
如果删除了某个图书分类包含的所有书籍,就在书商图书分类表里删除掉这个图书分类.

经常是上传几百万本图书信息,却对书商图书分类未动毫毛,白白浪费掉系统处理能量 来做无谓的检查.

为啥雅虎没落了,谷歌兴旺了.因为Yahoo在做分类目录,Google再做搜索.
这个年代,很少有人再通过分类目录一层一层的下钻去找到感兴趣的内容了,一个关键字查询,结果根据相关性排序,一下找到结果.


有兴趣的产品经理,数据处理设计师和开发人员, 可以看看这个功能的链接:
http://www.abebooks.com/servlet/BooksBrowse?vendorclientid=65646&page=CLIENT