个人外包项目全记 - Best Partner （十二）意译的烦恼

正文：（十二）意译的烦恼

在整套系统开发的过程中，我一直采用‘意译’的模式，对Gentleman所提出的需求进行改进设计，但也有例外的情况。系统中有一个模块是给工厂下生产通知单，在这个模块的处理上，就出现了问题。

公司当前的做法是依据合同中的产品数量，给工厂下达生产。一份合同由多种货物组成，每种货物的订购数量和外销价是不同的。实际工作中都是将一种货物中所有的订购数量都制定一家工厂生产，当时，我从逻辑角度上分析，认为存在这种可能，即一种货物分交给两家以上的工厂生产。

所以我在设计中提出了改进模块的设计思路，并汇报给Gentleman，他当时的反应显得有些犹豫。因为现在的实际工作中是不存在这样的情况的，如果系统能实现到这种程度，肯定是更灵活，因此他就准许了我的设计思路。

这个模块的设计和实现过程中，由于要实现到同一种产品分配给多家工厂，并且订购数量要动态分配和回收。所以需要考虑到情况就复杂了很多，时间自然也多花了N倍。最终实现出来的效果是非常不错的，操作员可以清楚地看出每份合同下达的生产通知单，以及每种产品的生产数量。

但以上所认为到的程序最佳实现效果，都仅仅是我个人认为的状态。当把这个模块拿到具体业务员那测试操作的时候，问题就显现出来了。他们都反映麻烦，第一，从思路上和现状有点差别，感觉别扭；第二，在操作步骤上又多了一步操作，耽误时间。最后，Gentleman在考虑再三后，让我把这个改进模块功能去掉，依旧实现最原始的需求。

后来我总结此次教训，虽然模块的功能更灵活、更强大，但客户只需要他想要的，改进模块一定不能成为画蛇添足。