| 【相关分析】（76个分析） |
|
|
时间：2013-07-15
题目：具体问题具体分析
分析：已有功能优化不算需求. 为了节约项目成本,应当先与客户协商增加需求带来新的工作量和时间的延长,客户是否能接受,如果工作量超过10%的偏差,超过部分由客户承担,10%以内我方负责;如果因为新需求使项目延期,给客户表明对他不好,说服其不要增加需求.建议方到下一期系统升级中实现.
|
|
|
时间：2012-02-15
题目：需求和开发过程的脱节是导致问题产生的根源
分析：一般而言，在需求商谈和需求确认过程中，甲方由于未对乙方开发实际的效果或采用的技术方法并没有可估计的参照，故需求确认并不能作为之后功能出问题的依据；在测试过程中，很可能会出现与需求不符之处，主要原因其实还是需求分析人员与开发实施人员在沟通中，以及与甲方在需求实现过程中的沟通不够充分导致的。因为甲方需求人员一般并不会完全了解乙方的实现手段和技术方案。故需要双方共同对测试中的问题进行分析，并采取相对于双方均可接受的方案进行功能改进和优化。如功能改进会延长工期，需要由甲方进行认可。
|
|
|
时间：2011-10-31
题目：甲方需求与成本控制遇到问题
分析：1.之前上线的功能是否已经与客户签字确认进行验收？如果验收则新的功能优化为新需求
2.如果上线功能未签字验收，那么以前的功能需求和设计是否与客户签字确认，如果确认了，现在的优化与原来的相差太远则也可以当新需求处理，因为是客户的变更造成了我们工作量的增加。
3.如果之前的签字确认都未做，那么你只能认了，以后工作中注意就是。
4.你的目的是解决成本，客户的目的是通过系统建设一套可用的系统，你们要统一目标，走曲线救国的路线。
5.不要只顾解决成本，能省的就省要从长远的目标去考虑，要不然现在少了这个少了那个，做种客户用起来这也是问题那也是问题客户口碑都没了以后还怎么做项目，而且客户要是强势的话你非但省不了共走还会由于之前的偷工减料造成后期维护量很大
同意楼上观点
|
|
|
时间：2011-10-24
题目：个人建议
分析：1.之前上线的功能是否已经与客户签字确认进行验收？如果验收则新的功能优化为新需求
2.如果上线功能未签字验收，那么以前的功能需求和设计是否与客户签字确认，如果确认了，现在的优化与原来的相差太远则也可以当新需求处理，因为是客户的变更造成了我们工作量的增加。
3.如果之前的签字确认都未做，那么你只能认了，以后工作中注意就是。
4.你的目的是解决成本，客户的目的是通过系统建设一套可用的系统，你们要统一目标，走曲线救国的路线。
5.不要只顾解决成本，能省的就省要从长远的目标去考虑，要不然现在少了这个少了那个，做种客户用起来这也是问题那也是问题客户口碑都没了以后还怎么做项目，而且客户要是强势的话你非但省不了共走还会由于之前的偷工减料造成后期维护量很大。 个人意见仅供参考、
|
|
|
时间：2011-10-16
题目：甲方需求与成本控制遇到问题
分析：1、已有功能优化不算需求
2、需求增加必然会造成成本的增加，既要节约项目成本就要优化。
|
|
|
时间：2011-10-14
题目：甲方需求与成本控制遇到问题解决
分析：1 已有的功能的BUG不应算需求
2 都已经在测试阶段了，需求肯定确认过了。所以新增需求还是应该看下项目成本。
|
|
|
时间：2011-10-13
题目：项目后期出现的问题协商解决
分析：1。对于已有功能上出现问题提出的优化不算需求；可以查阅签订合同细则上的功能要求；
2.需求增加问题，需要看需求在功能上是否原有系统能覆盖，如果可以则可以协商费用细则，如果此需求已超出合同条款范围，或者重立项，或者协商在原有合同中作变更；
|
|
|
时间：2011-10-11
题目：甲方需求与成本控制遇到问题
分析：1、已有功能优化不算新增需求。
2、关于节约项目成本问题。在原定需求前期下，是尽量控制成本，不要超过成本，并没有强求节约。所以关键是如何在既定成本范围内，实现功能需求。
|
|
|
时间：2011-10-11
题目：因事利导
分析：目前项目执行中此类问题太多了。关键是做好如下工作：
1.对比合同和项目实施中的一些文字资料，用资料说话。不要对没有记录的信息做无谓的争吵。
2.对变更做出成本预估，结合公司实施该项目的战略考虑是否向甲方提出增加费用。
3.坚持多沟通，多协调。
|
|
|
时间：2011-10-10
题目：需要视情况
分析：如果在原有功能基础上增加少量要求，可以不计较成本，或牺牲少许利润来满足客户（通常在中国国情下适用，国外公司未必行得通）；如果增加了大量的要求，或者原本的合同里面没有针对此部分做要求，建议适当支付给开发商费用作为增补，合情合理。
|
|
