1、相关干系人的通知。在需求变更的时候,最好对所有相关干系人都要进行通知和管理,很多时候,沟通的时候忽略了一些主要干系人,结果导致变更失控。2、需求变更的反馈。在进行需求变更的讨论和交流后,一定要反馈。反馈的时候,一定要告诉对方需求的实现目标和时间。因为有时候目标一致,因为人力资源问题,有时候双方的预期时间会不一致,这个时候,就需要双方重新协商,达成新的一致目标。3、需求变更的确认。当需要进行需求变更的时候,一定要有书面的文档和签字手续。这样,对双方的工作量都有明确的记录和认可。同时,确认书会让变更变得更有效和科学。临时发生需求变更,容易导致新的需求考虑得更加不周全,项目的风险、产品质量下降的风险都会加大,严重的还会导致产品偏离原本的产品定位或想法。频繁的需求变更,对产品、项目进度和团队积极性都有非常大的危害。项目经理一定要不遗余力避免需求变更的情况。下面来看看需求变更产生的主要矛盾以及如何应对。(1)由于实现难度而修改需求。这种情况往往发生在设计人员已经给出了设计图和切图,开发人员开始开发,在某一个地方遇到了实现难题,比如按照原本的需求方案,可能有性能问题,或者开发难度太大,工作量比预期的大很多,等等。这时候,只好用一个妥协的产品方案来替代原本的需求。于是,设计人员需要重新作图,开发人员也有部分工作需要调整。有的同学可能会说,这种情况可不能赖项目经理了吧?是开发人员实现不了导致推倒重来的。这里要特别指出,如果你想成为一名优秀的项目经理,千万不要有这种思考习惯。项目中出现的任何问题,都有项目经理的责任。那么,这种情况要如何避免呢?那就是尽早地邀请开发人员介入,在需求方案还未敲定时,甚至在需求发起和讨论时就邀请开发人员一起参与讨论,即使开发人员对产品方案不能给出建议,至少也可以了解需求的来源,并且及时指出一些技术实现的难点。这种实现风险大、成本高的地方发现和提出得越早,越能保障产品后续环节的顺畅进行。需求变更发生得越晚,新的需求方案输出得就越仓促,考虑得就越不周全,对产品和项目都有很大危害。风险提出得越早,除可以避免团队成员工作量的浪费之外,还可以让大家对需求变更考虑得更周全。所以,在这里项目经理要注意,让开发人员尽早了解和知道接下来要做什么需求,涉及哪些技术难点,这既是必需的,也是应该的。(2)对需求考虑不周全。比如项目经理小明设计用户注册流程,方案是用户需要填写手机号才能顺利注册。这个方案已经由设计人员给出效果图和切图,且进入了开发阶段。那么,在这个过程中,小明从公司内部的其他同类产品中了解到,用户对手机号非常敏感,如果手机号是注册时的必填信息,则很容易造成在注册流程中用户的流失。于是,小明只好修改产品方案,将填写手机号一项改成选填,增加填写常用邮箱作为注册用户的唯一标识。这就是典型的在需求方案设计阶段,没有全面考量方案的例子。当然,这与小明的经验也有关系,一般新人难免在设计方案时对一些情况不够敏感,会有疏忽和考虑不全的情况。这需要项目经理高标准要求自己,从各种角度审视、考量自己的方案,尽全力考虑周全,那么就会在相当大的程度上避免需求变更,并且本人也会有所收获、提升能力。 (3)还有一种非常无奈但是常见的情况,即老板提出的需求变更,或者真的由于产品方向改变而出现的需求变更。这种情况下,项目经理也并非完全没有责任。这时项目经理要思考,为什么老板在已经进入设计和开发的阶段才提出需求变更?是否因为老板之前并没有能够充分了解需求?这可能是因为老板太忙了,没有关注到这个项目,那么其实项目经理可以更主动积极地让老板了解产品项目的进度、整个需求的思考过程和最终方案。这样,如果老板有其他想法或不同意见,即可及早提出。(4)在设计图出来之后,或者开发原型出来以后,甚至在测试阶段,发现之前的需求方案不合理。这种情况一般是不应该发生的,项目经理的水平越高,发生这种情况的概率也会越低。但是人不可能完全不犯错,或者说,在看到真正的效果之前,甚至试用原型之前,有些交互体验的细节问题确实难以发现。这也是项目经理需要修炼自身的地方,平时应该多试用各种产品,体验各种交互和页面设计,这样才能在设计产品方案时不是单纯地拍脑袋,而是在有真正的操作体验的基础上去设计。但是也要说明一点,这种情况下的需求变更,不应该是非常重大的变更,一般都是交互体验或者页面内视觉逻辑的微调整。产品流程或产品逻辑的问题,应该在视觉效果图输出之前就能够被发现,而不是到视觉效果图或者产品原型阶段才能发现。因此我们看到,避免需求变更的主要思想就是,让信息在团队内部,产品与产品之间, 团队与老板之间,进行充分的交流和沟通,避免信息不对称或不同步的情况,在信息充分同步的情况下,才能更早地暴露问题,提前修改需求方案,不浪费设计和开发等资源。没有需求变更的团队是非常理想的,但是当理想照进现实,我们发现,事实上很少有需求不变更的情况。那么,当需求变更不可避免地发生了,该怎么处理,才能将危害降到最小呢? 其实,需求变更流程与产品的一般流程是一致的,首先是项目经理重新思考变更的需求, 全面考虑后输出新的需求方案,同时并行的是充分与设计、开发、测试等团队成员沟通,让大家了解需求为什么要变更,如何变更,以及修改后的方案会是什么样子,等等。在团队成员对变更后的需求都认可了之后,就要再次进入设计、开发、测试的阶段。在整个过程中, 项目经理同时要关注的是需求变更对整个产品版本进度的影响,一般需要设计、开发、测试人员重新评估工作量和提测时间,项目经理需要了解该变更是否会影响产品最终的发布时间, 如果确实有影响,无法通过协调其他时间来消化,那么要及时告知更大范围的团队成员。比如需求变更只涉及一个功能的开发和测试,但当这个需求变更会影响整个版本的进度时,就需要让整个产品版本涉及的所有开发、测试等人员知道版本发布计划的变更及原因。