从业务需求到系统功能开发的问题

从业务需求到系统功能开发的问题

来到一个快要上线的项目，浏览一下相关的开发文档，发现一个普遍的问题，几乎存在于所有因功能增强而设计的functional spec中：机械地找出相关系统表，字段；依样画葫芦地把客户需求转述成业务逻辑；或者煞有介事地加上两张流程图。业务需求实现没有？实现了；文档符合规格吗？完全符合；测试结果如何，一切顺利；形式上无懈可击，看上去很美，实质却是两个字：死板。除了死板还是死板，没有弹性，没有充分考虑其他功能发生变化时的影响。后果就是业务需求改变后，大量地重复劳动。

为什么会这样呢？原因大概有两条：1、敷衍，应用顾问让key user写完spec后，甚至不看一眼就立即提交开发。2、顾问对增强开发缺乏系统性的思考，或者对系统本身的逻辑和观念不甚了了。

SAP是一个很有弹性的系统，而我们在做功能性需求开发的时候，却没有按照系统既有的观念去设计，有些地方，甚至还就出现hard code，真是惨不忍睹！

不由得想问一句实施顾问们都是干什么的？在去年的项目中，有个顾问因为客户不甚合理的需求，提交了一个spec，洋洋洒洒好多页，竟然还要改系统标准程序。标准程序不是不能改，但是为了这种需求改，太不值了吧。哪怕这是一个合理的需求，先考虑重新写一个程序也比修改标准程序风险小啊。当然尽量满足客户的需求不是坏事，但是也要学会说不，不会说不的顾问，只能说明他还不够专业。

大量的二次开发并不可怕，可怕的是没有规范，甚至违背系统观念的乱开发。

随着市场扩张带来的顾问群体的膨胀，顾问的整体基本专业素质和专业精神也大大降低了。这是问题唯一合理的解释。

从业务需求到系统功能开发的问题

来到一个快要上线的项目，浏览一下相关的开发文档，发现一个普遍的问题，几乎存在于所有因功能增强而设计的functional spec中：机械地找出相关系统表，字段；依样画葫芦地把客户需求转述成业务逻辑；或者煞有介事地加上两张流程图。业务需求实现没有？实现了；文档符合规格吗？完全符合；测试结果如何，一切顺利；形式上无懈可击，看上去很美，实质却是两个字：死板。除了死板还是死板，没有弹性，没有充分考虑其他功能发生变化时的影响。后果就是业务需求改变后，大量地重复劳动。

为什么会这样呢？原因大概有两条：1、敷衍，应用顾问让key user写完spec后，甚至不看一眼就立即提交开发。2、顾问对增强开发缺乏系统性的思考，或者对系统本身的逻辑和观念不甚了了。

SAP是一个很有弹性的系统，而我们在做功能性需求开发的时候，却没有按照系统既有的观念去设计，有些地方，甚至还就出现hard code，真是惨不忍睹！

不由得想问一句实施顾问们都是干什么的？在去年的项目中，有个顾问因为客户不甚合理的需求，提交了一个spec，洋洋洒洒好多页，竟然还要改系统标准程序。标准程序不是不能改，但是为了这种需求改，太不值了吧。哪怕这是一个合理的需求，先考虑重新写一个程序也比修改标准程序风险小啊。当然尽量满足客户的需求不是坏事，但是也要学会说不，不会说不的顾问，只能说明他还不够专业。

大量的二次开发并不可怕，可怕的是没有规范，甚至违背系统观念的乱开发。

随着市场扩张带来的顾问群体的膨胀，顾问的整体基本专业素质和专业精神也大大降低了。这是问题唯一合理的解释。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/190059/viewspace-476633/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/190059/viewspace-476633/