!
20 个解决方案
#1
项目内的需求有没有开发完成？客户满意度如何？客户关系如何？等等。这些信息没有，很难有一个建议的。
通常的建议可以是和客户商量，这4个新需求我给你做了，但项目得给我结了。如果对口头协定不放心，就写一个会议纪要双方签字确认，包括双方领导也要签字
通常的建议可以是和客户商量，这4个新需求我给你做了，但项目得给我结了。如果对口头协定不放心，就写一个会议纪要双方签字确认，包括双方领导也要签字
#2
这还是初级问题？
呵呵
看销售怎么承诺的了，合同如果没有约束力，就靠关系了，
主要是项目经理怎么跟客户沟通了
先看看目前客户的态度，
不妨与客户吃饭聊一下
之后了解关键的问题，纠结在哪里
项目总要有范围，太大了不好定就阶段交付，*教导我们：零敲碎打牛皮糖
一点点的交付赢得信任，把钱结了再进行下一次合作
打官司是最终迫不得已的步骤，不建议
总之别人说什么都是扯淡，自己要去实践，多花心思和时间，须知此事必躬行
祝你成功～～
呵呵
看销售怎么承诺的了，合同如果没有约束力，就靠关系了，
主要是项目经理怎么跟客户沟通了
先看看目前客户的态度，
不妨与客户吃饭聊一下
之后了解关键的问题，纠结在哪里
项目总要有范围，太大了不好定就阶段交付，*教导我们：零敲碎打牛皮糖
一点点的交付赢得信任，把钱结了再进行下一次合作
打官司是最终迫不得已的步骤，不建议
总之别人说什么都是扯淡，自己要去实践，多花心思和时间，须知此事必躬行
祝你成功～～
#3
项目需求SRS已在设计前完成，由于框架太大了，客户满意度在初期是比较认可的，但已超过原定计划，因为项目面对沟通客户不是最终用户，他们与项目人员沟通是认可的，但一旦三方进行沟通，即马上翻脸，站在对方的立场说话，所以比较复杂，分批交付我们也有想过，但用户如不接受的话，恐怕不好好办阿，谢谢！
#4
谢谢！是否可认为关系上的解决是辅助条件呢，合同条款恐怕不会描述的那么细阿，如果对方再增加的话，我们如何说服他们接受需求变更呢，我感觉很难阿，特别对方强势时，这中间是否完全由项目经理去执行呢，有什么技巧方法可以分享一下吗，谢谢!
#5
如果还划算，就接着干；
如果眼看就不划算了，就放弃掉；
把变更分清楚：需求 还是 问题，如果是问题，赶快改，保证用户能用；如果是新增的需求，就成本权衡，小的可以，大的坚决不干
如果眼看就不划算了，就放弃掉；
把变更分清楚：需求 还是 问题，如果是问题，赶快改，保证用户能用；如果是新增的需求，就成本权衡，小的可以，大的坚决不干
#6
没有控制好项目范围，让范围蔓延了啊，这样做很危险。
#7
该回复于2011-11-17 09:06:36被版主删除
#8
软件项目中最怕出现与最终用户隔着一层，而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形，因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
#9
软件项目中最怕出现与最终用户隔着一层，而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形，因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
#10
我也有这样的疑问。。。
#11
既然是老得项目，需要尽快完成现有的需求。需要和客户沟通，让客户了解项目在实际环境应用中再去校验功能。
很多凭空的想法是随着客户的思维在不断变化，没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。
很多凭空的想法是随着客户的思维在不断变化，没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。
#12
原型法 多迭代 严谨的控制需求变更
#13
这个问题是大多项目不能按时结案的通病，所以是问题，但并不简单，有以下建议：
如果系统不影响正常业务开展的话（如果连正常业务都不能开展，那你什么也别说了，改到能开展为止），那应该要求完成项目验收，并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法：把需求清单全部列出来，找业务操作人员逐个确认OK或不OK，不OK的全部转到问题清单内，然后把经过确认的需求清单放到客户领导面前，领导也只能签了，最多是跟你纠结问题清单中的问题，大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢：因为客户的新需求和问题均来源于未验收的项目，项目验收完成，则项目中的新需求就按新需求处理方式来处理了，问题清单中的问题通常不会搞出新的问题来，所以只需要逐个解决就行了，再多也不怕。
下面业务人员不跟你确认需求清单怎么办：中止业务人员应用上的一切支持（包括新需求），并书面通知项目监管人员目前情况（优期是客户方高管），召开会议，并汇报具体情况，同时附上你所收集到的需求清单完成情况；通常情况下，如不重大问题，客户方高管会主动提出来让业务确认掉并完成验收的，因为客户方高管一般也有考核的，他们也想早点结束。
如果系统不影响正常业务开展的话（如果连正常业务都不能开展，那你什么也别说了，改到能开展为止），那应该要求完成项目验收，并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法：把需求清单全部列出来，找业务操作人员逐个确认OK或不OK，不OK的全部转到问题清单内，然后把经过确认的需求清单放到客户领导面前，领导也只能签了，最多是跟你纠结问题清单中的问题，大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢：因为客户的新需求和问题均来源于未验收的项目，项目验收完成，则项目中的新需求就按新需求处理方式来处理了，问题清单中的问题通常不会搞出新的问题来，所以只需要逐个解决就行了，再多也不怕。
下面业务人员不跟你确认需求清单怎么办：中止业务人员应用上的一切支持（包括新需求），并书面通知项目监管人员目前情况（优期是客户方高管），召开会议，并汇报具体情况，同时附上你所收集到的需求清单完成情况；通常情况下，如不重大问题，客户方高管会主动提出来让业务确认掉并完成验收的，因为客户方高管一般也有考核的，他们也想早点结束。
#14
补充一下，不管是直接面对客户，还是通过第三方，都可以这样解决，因为你的验收对象就是需求提供者，应该不可能出现需求来自于终端客户，而验收权有第三方决定，如果不幸真是这样，如果你能解决掉的话，那我向你致敬！
#15
有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。
#16
那么弄不好就是这个中间商什么都不懂，却要硬要把持。这确实不好办，除了下套否则的不到钱。
其实用户遇到了那种不懂装懂的中间商，也是下套的。用甜言蜜语忽悠他们，可就是故意不相信他们这种人“能找来什么好干活的人？”。所以你们可能其实是被中间商给害了，还说中间商认可你们呢！
#17
那是没有激情做真正的产品、只要给自己发工资就满足了吧？！
#18
其实这类项目根本不需要“结”，就留个小尾巴好了，然后赶紧产品化。等你们产品花了，同一产品有了至少10个其它用户，告诉用户没有时间应付他们了、你们正在研究怎么了解他们的拖欠款问题，你看他们急不急？
其实就是搞项目不搞产品的毛病。
其实就是搞项目不搞产品的毛病。
#19
提两点：
1.为客户做系统的时候最好能加一些咨询在里面，需要对客户的商务有些了解，对每一个功能都知道为什么做，如能提出更好的方案给客户（毕竟你是IT专家，从IT的角度可能有其他方案）就是附加价值。
2.做好从第一天就让客户知道，添加功能和改动原有设计都不是免费的，而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次，并给出可能的后果（有的时候偏重时间上，有的时候偏重费用上）。
在IT产品的开发中在和客户多交流，有一点进展就交流一下，最好是能和终端用户交流。剩下的事就都是政治问题了。
1.为客户做系统的时候最好能加一些咨询在里面，需要对客户的商务有些了解，对每一个功能都知道为什么做，如能提出更好的方案给客户（毕竟你是IT专家，从IT的角度可能有其他方案）就是附加价值。
2.做好从第一天就让客户知道，添加功能和改动原有设计都不是免费的，而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次，并给出可能的后果（有的时候偏重时间上，有的时候偏重费用上）。
在IT产品的开发中在和客户多交流，有一点进展就交流一下，最好是能和终端用户交流。剩下的事就都是政治问题了。
#20
面对比较强硬的客户时确实会另大家很头疼。既然已经答应了人家的后续需求，就把这4个功能做好。但是一定要有书面的东西出来请双方领导签字，这是依据。建议后续加需求时与客户沟通放到二期中实现。
#21
#1
项目内的需求有没有开发完成？客户满意度如何？客户关系如何？等等。这些信息没有，很难有一个建议的。
通常的建议可以是和客户商量，这4个新需求我给你做了，但项目得给我结了。如果对口头协定不放心，就写一个会议纪要双方签字确认，包括双方领导也要签字
通常的建议可以是和客户商量，这4个新需求我给你做了，但项目得给我结了。如果对口头协定不放心，就写一个会议纪要双方签字确认，包括双方领导也要签字
#2
这还是初级问题？
呵呵
看销售怎么承诺的了，合同如果没有约束力，就靠关系了，
主要是项目经理怎么跟客户沟通了
先看看目前客户的态度，
不妨与客户吃饭聊一下
之后了解关键的问题，纠结在哪里
项目总要有范围，太大了不好定就阶段交付，*教导我们：零敲碎打牛皮糖
一点点的交付赢得信任，把钱结了再进行下一次合作
打官司是最终迫不得已的步骤，不建议
总之别人说什么都是扯淡，自己要去实践，多花心思和时间，须知此事必躬行
祝你成功～～
呵呵
看销售怎么承诺的了，合同如果没有约束力，就靠关系了，
主要是项目经理怎么跟客户沟通了
先看看目前客户的态度，
不妨与客户吃饭聊一下
之后了解关键的问题，纠结在哪里
项目总要有范围，太大了不好定就阶段交付，*教导我们：零敲碎打牛皮糖
一点点的交付赢得信任，把钱结了再进行下一次合作
打官司是最终迫不得已的步骤，不建议
总之别人说什么都是扯淡，自己要去实践，多花心思和时间，须知此事必躬行
祝你成功～～
#3
项目需求SRS已在设计前完成，由于框架太大了，客户满意度在初期是比较认可的，但已超过原定计划，因为项目面对沟通客户不是最终用户，他们与项目人员沟通是认可的，但一旦三方进行沟通，即马上翻脸，站在对方的立场说话，所以比较复杂，分批交付我们也有想过，但用户如不接受的话，恐怕不好好办阿，谢谢！
#4
谢谢！是否可认为关系上的解决是辅助条件呢，合同条款恐怕不会描述的那么细阿，如果对方再增加的话，我们如何说服他们接受需求变更呢，我感觉很难阿，特别对方强势时，这中间是否完全由项目经理去执行呢，有什么技巧方法可以分享一下吗，谢谢!
#5
如果还划算，就接着干；
如果眼看就不划算了，就放弃掉；
把变更分清楚：需求 还是 问题，如果是问题，赶快改，保证用户能用；如果是新增的需求，就成本权衡，小的可以，大的坚决不干
如果眼看就不划算了，就放弃掉；
把变更分清楚：需求 还是 问题，如果是问题，赶快改，保证用户能用；如果是新增的需求，就成本权衡，小的可以，大的坚决不干
#6
没有控制好项目范围，让范围蔓延了啊，这样做很危险。
#7
该回复于2011-11-17 09:06:36被版主删除
#8
软件项目中最怕出现与最终用户隔着一层，而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形，因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
#9
软件项目中最怕出现与最终用户隔着一层，而这一层缺乏足够的权威和能力控制需求的情况。楼主就是典型的这种情形，因此需要好好考虑下怎么解决这个隔着一层的问题。
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
在项目初始化阶段就要判断这个风险，如果实在难以避免，宁可放弃掉这个项目。
就你这个项目来说，如果想从实质上解决问题，只有想办法与最终客户直接接触，或者说是以否定掉你现在接触方的哪一方进行接触，确定最终需求和那一方的期望，才能拿出办法来；
#10
我也有这样的疑问。。。
#11
既然是老得项目，需要尽快完成现有的需求。需要和客户沟通，让客户了解项目在实际环境应用中再去校验功能。
很多凭空的想法是随着客户的思维在不断变化，没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。
很多凭空的想法是随着客户的思维在不断变化，没有一个最终的目标的。只有在应用过程中才能发现客户更像要什么。
#12
原型法 多迭代 严谨的控制需求变更
#13
这个问题是大多项目不能按时结案的通病，所以是问题，但并不简单，有以下建议：
如果系统不影响正常业务开展的话（如果连正常业务都不能开展，那你什么也别说了，改到能开展为止），那应该要求完成项目验收，并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法：把需求清单全部列出来，找业务操作人员逐个确认OK或不OK，不OK的全部转到问题清单内，然后把经过确认的需求清单放到客户领导面前，领导也只能签了，最多是跟你纠结问题清单中的问题，大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢：因为客户的新需求和问题均来源于未验收的项目，项目验收完成，则项目中的新需求就按新需求处理方式来处理了，问题清单中的问题通常不会搞出新的问题来，所以只需要逐个解决就行了，再多也不怕。
下面业务人员不跟你确认需求清单怎么办：中止业务人员应用上的一切支持（包括新需求），并书面通知项目监管人员目前情况（优期是客户方高管），召开会议，并汇报具体情况，同时附上你所收集到的需求清单完成情况；通常情况下，如不重大问题，客户方高管会主动提出来让业务确认掉并完成验收的，因为客户方高管一般也有考核的，他们也想早点结束。
如果系统不影响正常业务开展的话（如果连正常业务都不能开展，那你什么也别说了，改到能开展为止），那应该要求完成项目验收，并在验收报告中明确遗留问题清单及解决时间。
用户不肯验收解决办法：把需求清单全部列出来，找业务操作人员逐个确认OK或不OK，不OK的全部转到问题清单内，然后把经过确认的需求清单放到客户领导面前，领导也只能签了，最多是跟你纠结问题清单中的问题，大不了你们商量解决掉其中的某几个就签字。
为什么要这样做呢：因为客户的新需求和问题均来源于未验收的项目，项目验收完成，则项目中的新需求就按新需求处理方式来处理了，问题清单中的问题通常不会搞出新的问题来，所以只需要逐个解决就行了，再多也不怕。
下面业务人员不跟你确认需求清单怎么办：中止业务人员应用上的一切支持（包括新需求），并书面通知项目监管人员目前情况（优期是客户方高管），召开会议，并汇报具体情况，同时附上你所收集到的需求清单完成情况；通常情况下，如不重大问题，客户方高管会主动提出来让业务确认掉并完成验收的，因为客户方高管一般也有考核的，他们也想早点结束。
#14
补充一下，不管是直接面对客户，还是通过第三方，都可以这样解决，因为你的验收对象就是需求提供者，应该不可能出现需求来自于终端客户，而验收权有第三方决定，如果不幸真是这样，如果你能解决掉的话，那我向你致敬！
#15
有时候硬性把开发归阶段、看戴成项目都不合理。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。
就把开发团队看成是售后、维护。老板有手段能挣钱就做唄。
#16
那么弄不好就是这个中间商什么都不懂，却要硬要把持。这确实不好办，除了下套否则的不到钱。
其实用户遇到了那种不懂装懂的中间商，也是下套的。用甜言蜜语忽悠他们，可就是故意不相信他们这种人“能找来什么好干活的人？”。所以你们可能其实是被中间商给害了，还说中间商认可你们呢！
#17
那是没有激情做真正的产品、只要给自己发工资就满足了吧？！
#18
其实这类项目根本不需要“结”，就留个小尾巴好了，然后赶紧产品化。等你们产品花了，同一产品有了至少10个其它用户，告诉用户没有时间应付他们了、你们正在研究怎么了解他们的拖欠款问题，你看他们急不急？
其实就是搞项目不搞产品的毛病。
其实就是搞项目不搞产品的毛病。
#19
提两点：
1.为客户做系统的时候最好能加一些咨询在里面，需要对客户的商务有些了解，对每一个功能都知道为什么做，如能提出更好的方案给客户（毕竟你是IT专家，从IT的角度可能有其他方案）就是附加价值。
2.做好从第一天就让客户知道，添加功能和改动原有设计都不是免费的，而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次，并给出可能的后果（有的时候偏重时间上，有的时候偏重费用上）。
在IT产品的开发中在和客户多交流，有一点进展就交流一下，最好是能和终端用户交流。剩下的事就都是政治问题了。
1.为客户做系统的时候最好能加一些咨询在里面，需要对客户的商务有些了解，对每一个功能都知道为什么做，如能提出更好的方案给客户（毕竟你是IT专家，从IT的角度可能有其他方案）就是附加价值。
2.做好从第一天就让客户知道，添加功能和改动原有设计都不是免费的，而且时间上可能有延迟。然后每次遇到这样的情况都要强调一次，并给出可能的后果（有的时候偏重时间上，有的时候偏重费用上）。
在IT产品的开发中在和客户多交流，有一点进展就交流一下，最好是能和终端用户交流。剩下的事就都是政治问题了。
#20
面对比较强硬的客户时确实会另大家很头疼。既然已经答应了人家的后续需求，就把这4个功能做好。但是一定要有书面的东西出来请双方领导签字，这是依据。建议后续加需求时与客户沟通放到二期中实现。