|
【李焕林的回答(15票)】:
【邱智钢的回答(5票)】: 最理想的情况：
【fj-jay的回答(4票)】: 首先，看这个需求变更是否合理。如果合理，那么是肯定要变的。 其次，如果同一个地方他反复变更需求，那么就要想是不是客户自己根本没有明确想要什么。这时候就该缓缓，等客户想清楚了再定。 再次，同样是一个地方他反复变更需求，也有可能是你拿出的东西并不是他想要的，这时候就要尽量引导客户把需求描述清楚，然后在理解客户想表达的意思的情况下，抽象出结果，再确认。 最后，如果客户的需求不合理，就应该尽量和客户解释哪里不合理，合理的情况下应该是怎么样的。要让客户理解为什么不合理。如果实现他不合理的需求，等以后客户明白过来时，还会要求改的。 【许晓风的回答(4票)】: 首先，各位必须明白客户为什么要变？产品应用越多，客户对产品的理解越多，需求就会越深越广。因此，需求变更是必须的。我觉得所有讨论都应该基于此讨论才有意义。 1，减少变更 1）客户参与前期系统设计；2）范围尽量细化；3）对变更进行分析，满足变更背后的需求，客户自然就不会要求变更了。 2，拥抱变更 1）准备变更：从设计阶段就必须将容易变更作为设计约束； 2）接受变更：没有不合理的要求，客户所有的要求都是有目的的。满足其要求背后的需求，而不是机械的满足要求。 3）变更系统化：客户所有的变更都是有原因的，要理解变更的目的，积极帮助客户满足变更背后的需求，而不是简单的头痛医头，脚痛医脚。 4）变更阶段化：在前面的需求未实现之前，新的变更需积极排队等待。积累一定的变更后阶段性实施有利于团队执行。 5）通报变更：及时的和客户沟通其变化的要求，帮助客户和团队更好的理解客户需求。 btw, 在现实工作中，经常遇到那些变更便骂客户，骂产品，骂系统工程师，背后里肯定也在抱怨领导的童鞋，比遇到变更还让人郁闷。 【maggie的回答(3票)】: 1、项目开始时，要求客户有一个客户方项目经理，所有的意见通过他来传达。 2、如果客户的水平有障碍，免费给客户做项目管理培训，提高客户团队的认识，也能显示你的专业性，增强客户的信心。 3、签订合同时，明确项目的范围，需求的范围，需求变更的处理流程，服务范围，额外费用收取标准。 4、签订合同前，和客户确定好功能列表划分优先级，最好每个功能都有用户界面。把这部分作为技术附件，合并在合同中。 5、项目执行过程中，阶段性反馈客户项目进展，UI定稿之后和客户及早沟通，前期需求变化要比拖到后期代价小很多。 6、每次和客户开会要写会议纪要，如果客户不愿意手签，发邮件并确认收到了邮件。 7、期间，客户有需求变更，如果没有影响到版本的进度，尽量满足，但让客户知道这次变更你花费的额外工时和对目前版本造成的影响，让他知道你为了做这件事付出了代价。 8、如果客户的变更影响到了目前的版本进度，超出了合同的需求，那么你应该专业地书面提交变更方案设计，人工时，产生费用，对目前版本的影响，交付时间变更，以上要详细告知客户，由客户来决定是否要变更。如果客户非要坚持变更，还要保证工期，那么和用户一起分析需求的优先级，应该把哪些功能砍掉或者在后续的版本中完成。 9、客户坚持说让员工加班，或者增加人手可以按时完成，你应该有理有据地告诉他这样会导致项目的质量下降，建议在给客户培训项目管理理念时灌输这个思想。 10、一般软件合同中会承诺一定时间的免费升级，升级范畴，可以把变化的部分统一放到升级版本中，这样不至于影响目前版本的交付质量，而且还有利于提升客户的满意度。 11、遇到政府客户，我的经验是不止要和技术负责人搞好关系，还得有人能搞定他的领导。 12、唯一不变的就是变化，我们要做的是在变化面前付出代价最小。 13、如果你是一个靠服务，外包项目生存的团队，一个可复制的成功项目流程就非常重要了，最好有一个透明化的项目管理平台，部分开放给客户，让客户知道项目执行的细节，督促他去访问了解项目进展情况，看似你暴露了开发细节给客户了，但实际上你会省很多力。 【黄慧堃的回答(2票)】: 这个问题很难从单一某一方面解决，从接洽一开始就必须有效引导以及严格管理。 客户需求经常变是因为没发现他心里的终极需求，还是在听他表面上的需求。比如做ERP，客户的本意不是要做ERP而做ERP，他是要解决他的生产问题、成本风险控制问题，有效沟通需求的标准是 站在他的角度帮他解决了问题，而不是帮他做了ERP。如果你能直接解决了，夸张点说ERP都可以不做。还一种情况就是你只想忽悠客户把单子赶紧了结了，这种心态客户不变才奇怪。 有了这样的心态，你就有办法引导客户产生需求，解决需求，而不是让客户需求变化，如果会变化，你一定变得比他更快。 当然创意型的产品可能和上面不同，需求更多的尝试和实践，因为客户是伟大的网民。 【张静的回答(1票)】: 1. 前期需求分析一定要详细，用户提出的只是一个想法，一个好的产品经理，应该将用户的想法形成一个完善的产品。 2. 需求阶段尽量考虑全面，充分引导用户，充分将产品合理化并且尽量避免漏洞。 3.不要停留在口头交流，一定要制作原型及需求，并且充分让用户理解需求，并尽量让用户理解需求并纸面确认。 4.需求变更不可避免，尽量将不必要的需求变更削减，需要的需求变更分优先级，分阶段。 5.产品没有完美的，用户在变，市场在变，领导在变，尽量按原定计划完成，在一个成型的产品基础上变更，会比在开发阶段不停的变更有意义。 6.非要变的情况下，做好风险评估，将风险提前告知。 【王逸尘的回答(1票)】: 给政府部门打工，一个方案改了半年，一个局长关心你的图片，关心你的每一个细节，总是提出自己的看法，一天一个想法的人默默走过。什么合同，什么讲解在这里都是不合适的 【史飞的回答(1票)】: Scrum中提供的一个建议：尽可能把客户拉到产品的开发流程中 当然这比较理想，如果碰到实在实在不靠谱的客户，频繁的需求变更搞不好会导致成本高过收益，那么还是算了吧 如果没法放弃，对方又很强硬，那就只能提一个半真半假的、客户绝对不会接受的后果给他，“这个功能改没问题，但是会导致1234567……” 类似这样的吧 【徐国锦的回答(0票)】: 提前思考，让用户用到你的新产品后才突然发现，原来生活可以更美的！原来你的产品可以做到这样，创新是企业进步的灵魂，苹果是这样，facebook也是！有难度，但是，创新型企业和创新型人才却是必须的！ 【王茜的回答(0票)】: 开发模式要有相应的变化和调整。 【IAmExBug的回答(0票)】: 确定产品开发流程，UI确定之后不再接受改动。 【孙健的回答(0票)】: 变化是必须的，买卖双方都不能被一纸合同限制住。 可以每天确认，已做的和将要做的。 【黄华元的回答(0票)】: 前期把用户需求了解透了 而且要适当启发用户潜在需求 最后合同缺定一下 在变加钱 吧 【daocaoit的回答(0票)】: 合同，书面确认机制，正确的引导，沟通技巧，强制手段 【张捷的回答(0票)】: 这要看我为用户做的是什么。 如果为用户做的是服务，比如第三方支付等，根据客户提出的要求，当然应该对服务做出改变。满足客户要求的目的就是为客户创造价值。 如果做的是产品，需要大量成本做前期研发等，就应该讲清楚变动所增加的成本和带来的收益，和客户协商，双方达成一致。 【吴晓菲的回答(0票)】: 弄死他 【谢隼的回答(0票)】: 项目的需求需要评审,所提出的需求都应该可以追溯.在后期变更时,如果是不伤筋骨的需求,可以适当妥协.如果是整体架构或业务都调整了,这种应该需要斟酌. 【肥老泡泡的回答(0票)】: 1，前期谈需求的时候可以多了解一下 2，如果是加强型的需求，可以改，告知客户风险 3，如果是纯属需求方个人爱好改的，解释它，晓之以理，动之以情，还不行就把价钱调高一点吧 4，我最恨外包甲乙方那种方式，他说什么都得听，遇到这样的人，只能磨了 【shirley的回答(0票)】: 客户一般都需要令他们最满意的产品，所以在某程度上是很难满足的，不过，可以从客户心理方面着手。 【zhaosj的回答(0票)】: 签合同的时候是不是偷懒了呀 【卫琦的回答(0票)】: 尽量妥协。实在不行，……，打死他吧！ 原文地址:知乎 |
|
|
