| 验收难！ 在项目实施（这里讨论的是项目实施，不是产品研发）的全过程中，往往会出现这样的问题，从需求讨论到研发完成，这个阶段内，时间是相对可控的，就是说你可以做一个计划，而这个计划往往可以在一定程度上按时完成。而交付客户测试验收的时候，客户会不断提出一些问题让你修改，这些问题你按照客户的要求修改之后，客户又会提出另外一堆修改意见，这样反复着使你觉得验收遥遥无期，而这些要求往往都只是为了使用上有那么一点小方便。 不知道各位是否有同感？ 遇到这样的问题各位是如何处理的？或者各位又是如何避免这样的问题的? ------Solutions------ 我们是应该尽量把软件的做的实用易用，但不可能做的完美，也不可能满足所有人的习惯。 避免这些问题，可以在需求上做文章，降需求定的严格些，让客户盖章确认，但是，最后我们可以拿着这个盖章的需求确认书拒绝客户吗？又能拒绝到什么程度？ ------Solutions------ 但是，最后我们可以拿着这个盖章的需求确认书拒绝客户吗？又能拒绝到什么程度？ 如果需求浮动很大，那么就要考虑重新合同了 ------Solutions------ 划拉出一些要求，如要做，加时间，加钱，否则不干，也干不了。 ------Solutions------ 开发前没有与客户订合同与具体的业务需求确认书？ ------Solutions------ 到验收的时候再来确认，好像没什么好办法 ------Solutions------ 各位在签订合同前（或开发前），需求能做的什么程度？ 能确定每个功能的流程吗？能确定每个界面的输入输出吗？ （我们公司做不到，因为合同都是市场人员签的，他们只会吹） ------Solutions------ 客户提出下面这样的要求，你们能拒绝吗？ 1、某些查询增加几个查询条件 2、某些查询结果多显示几个字段或少显示几个字段 3、某些功能加几个合计 4、某些操作要有批量操作功能 5、点击某个地方要弹出某种信息 6、某些查询要按某些字段排序 这些修改看似简单，但多了也是很浪费时间的，而且客户会在你满足了他的这些要求后再提出一些累似的要求。各位遇到过这样的问题吗？如何处理的？ ------Solutions------ 这种情况确实总是出现。但是目前似乎没有什么比较好的办法解决。 只要定制软件都有这个问题。 ------Solutions------ 我认为可以分阶段进行。 ------Solutions------ 开发前拿到客户的需求确认书是很重要的，如果没有就开发的话……估计只能自求多福了。 不过需求确认书只能确认系统的业务流程和功能规格，用户如果反复要求修改操作界面什么的，也确实没什么办法。某某说的那些要求很有代表性，是典型的麻烦用户，现在好像也没什么办法，做到的只能是把阶段分得细一点，尽量让尾款少一点，因为这些钱基本上也是没指望拿到了。 ------Solutions------ 客户说不按我们的改就不给尾款。 开发说不给尾款我们就不给程序。 看谁能挺过谁，哈哈。 ------Solutions------ 我们之所以无法回绝客户的修改要求，往往是因为我们在需求讨论阶段没能将我们的目标软件的细节交流清楚，所以客户才会在这些细节上不断的给我们找麻烦。那么我们是否可以想办法尽力将细节讨论的清晰明确呢？ 大家都知道原型法，不知道有多少用过，用过的发表一下看法共大家收益。 个人认为，需求讨论阶段应该快速作出软件原型，让客户确认。客户确认后，将原形界面附到需求说明书中让客户确认认可。这样应该可以避免客户事后说，我要的界面不是这样的，应该是那样那样的。大家觉得这样是否可行？ 某某说的很有道理“把阶段分得细一点”，分阶段收钱，分阶段验收。但这需要软件的各个模块之间有一定的独立性，否则不容易操作。 某某说的是大公司和小公司的做法，我们这些不大不小的公司是注重客户关系的，不该那么做。 欢迎经验丰富的项目实施者共同讨论相关话题！大家共勉！ ------Solutions------ 现在的平台开发通常都不会一帆风顺的，所以在需求时要力求准确，同时开发人员也要多为客户着想，不要光想着偷懒，尽量考虑方便和较好的性能。不记得哪本软件工程的书里写的程序员不用太聪明，也不用太动脑子，简直就是纸上谈兵。 前不久给客户做了四个系统，主要是增删改查，条件查询之类。客户两度要调整数据库结构，有一个系统还调整了三次，我还是给他做了。主要是自己开发了一套工具，可以生成查询和结果集页面。因此最繁锁的工作已经不费力了。 所以说做程序时也要为自己做一些方便的工具，帮别人减少重复劳动时也应该帮自己减少一些，这也算是一点经验吧。 ------Solutions------ 一点不错，兄弟也常遇到这样的问题。怎么解决？只好按客户的意思改了，不改就不能验收，不验收就不给钱。晕呀。。。我感觉产生这种问题的原因还是一来开始时系统没有分析明确，二来我们程序员没有站到客户使用者的立场上考虑问题，考虑软件的实用性。 ------Solutions------ 分析一下需求，简单就改一下，耗时间的，以后改，验收了，还有个后期维护的问题，就留到后期维护在做。但是这只能解决此时问题，造成这样的局面，还是没有准备把握客户的需求，我觉的某某说得对，应快速作出软件原型，才不会有这么多的麻烦 ------Solutions------ 一次能验收通过的项目真得很少，那怕真验收通过了，客户使用中往往还会出现各种各样的问题，个人根据以往经验觉得： 1、需求要彻底，要找到真正的用户，了解真正的需求； 2、系统设计要灵活，便于扩展，便于维护； 3、按有些软件工程书上所说的采用原型法，或者采用迭代式，一个功能模块开发完成后，立即让客户进行体验和验收，如此反复。 其实解决的问题的方法都差不多，大家其实都知道，但往往运作的时候就不那么简单了，因为所有的事情都不是你说了算！ ------Solutions------ 客户提出下面这样的要求，你们能拒绝吗？ 1、某些查询增加几个查询条件 2、某些查询结果多显示几个字段或少显示几个字段 3、某些功能加几个合计 4、某些操作要有批量操作功能 5、点击某个地方要弹出某种信息 6、某些查询要按某些字段排序 从技术实现角度来讲，以上功能在C/S桌面程序端非常容易解决，我们桌面端开发用Delphi，项目做多了，这些要求都非常普遍，所以一般都做成通用组件，开发时只是一个方法调用。 但如果开发B/S基于浏览器的程序，虽然也能实现，但比较麻烦，运行效率、用户体验、开发周期都是一个问题，这可能也是B/S不成熟的地方吧，个人觉得以后的运行环境应向C/S桌面端回归，因为基于浏览器程序最大的优点就是部署、维护容易，而且能跨平台，如果C/S桌面能很好地解决这些问题，B/S浏览器将不具有太大优势。 ------Solutions------ 最好在签合同时就声明一点：在验收阶段提出新的意见要收费 ------Solutions------ 在验收阶段提出新的意见要收费 你是客户你签合同吗？ ------Solutions------ dd ------Solutions------ 其实往往这些问题在整个项目过程中都会出现，但有一点是必须要认知的是上线运行后，就不能再提出类似的修改，否则当初的需求分析及确认用处到哪里去了？在分析确认书的时候就明确输出的内容，甚至重要的方式。道理很简单，这与后台应用设计及压力相关，不可能无休止地替换界面元素。 在上线运行后，所有修改都要分等级，那些是必须立即修改，不修改会影响生产系统，哪些是可以延期修改的。因为不可能在一个稳定运行的系统上每天去换代码。 替换生产环境需要各方签字，甲方IT部门，甲方业务部门或使用部门，乙方共同确认。所有修改也是这样。 每周出项目状态报告，抄送给各方的领导层，让他们知道验收不了的原因。 |
