本文分享了一位开发者在企业管理系统开发过程中遇到的挑战，尤其是在理解和实现客户需求上的困难。开发者通过原型开发模式尝试理解业务关键需求，但在实际操作中发现对业务流程的理解存在偏差，导致设计错误。文章探讨了软件开发中需求收集的难点，指出在敏捷开发环境下，即使参考《人月神话》等经典著作，也难以避免在客户需求理解上的误差。开发者呼吁重视与客户的沟通，以确保软件设计真正符合客户需求。
从过完年后就一直在为公司内部开发企业管理系统，我坦然并不在行，虽然之前自己做过ERP的实施顾问，对SQL Server 也有一定的掌握。但是，我担心的是业务，更头痛的是无穷无尽、纠结不清的业务需求！
当前只有我和另外一个同事一起开发，其实在去年就已经有个初步的系统原型出来了，但是年底提交给其它部门试运行时竟然没有人去理会，没有人认真测试过系统是否符合本部门的业务需求。
现在又继续开发，目的是为了从一个销售订单确定下来后，从生产计划安排到采购物料入库这个前期的流程能走下去。为了应对之前的情况，我决定采用原型开发模式，首先针对某个部门了解本部门的关键需求，确定哪些工作可以由系统来进行，哪些始终要人为来完成。然后我们会开发一个最基本的界面，随意加载一些示例数据，然后就直接在这个部门进行系统演示，当然，由于我们自己对业务本身不了解，很多时候会出现系统实现与实际的业务情况不一致的情况。
例如，我们当前进行的品质部，系统为了实现单据流转，从采购下了采购单后，直到物料到了公司就会产生一个来料单，那么，采购部会将这个来料单转发给品质部进行来料检验。一开始我们认为品质部可以根据这张来料单对物料进行品质检验，然后在系统中填写检验人、检验日期、检验数量等，最后生成一份来料检验记录。
我们出现了一个较为严重的设计错误：我们的检验人和一些检验结果判断是对整张来料单进行的，但经过在品质部进行演示才知道：“一般一张来料单里有不同的物料，我们品质部里的任何人可以对任何一组物料进行检验和判断。并不是对整张来料单进行判断的！”
我们所做的并不是客户所要的！！！
我们在设计的时候错误的认为只要是品质部里的人检验物料就可以了，并不关心谁检验，但是品质部里的又说：“这会涉及到责任问题，因为如果这批物料你判断为合格，如果到真正使用的时候才发现有质量问题，那就要追究品质人员的责任了，所以来料检验还需要一步检验的审核才行！”
我们又一次忽略了···
再次思考这个问题：“我们所做的，就是客户所要的！”，有多少软件能真正做到这个？到底我们的命中率是多少？
有人或许会说：“那是因为你前期的需求工作没做好！”，但问题是，需求何时才称得上做好了？，有一个标准吗？我也看过《人月神话》，也知道敏捷开发方法，但实际的工作环境每个公司都有所不同，具体来说应该是每个人都不同，有不同的需求，有不同的期望！
在面对开发时间和实现功能的压力下，很多时候根本无法获取完整的需求，而客户自己很多时候都不知道自己具体需要软件实现哪些功能，只有在他们真正看到软件跑起来后，有个界面给他看看，这时他才会说：“哦，你这样做是不行的，我们要的是实现这样的功能···”。
我们所做的，就是客户所要的！！！
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
