给一个32字的决定改变不容易被扼杀的需求:考虑整体目标，考虑使用价值，找准机会，做好沟通；不要害怕质疑，不要想传播声音，灵活解决，有理有据。
听说某公司产品经理因为随意更改需求被愤怒的程序员打伤，至今昏迷不醒！
在网上经常看到，在新产品开发的整个过程中，需求发生了变化。产品开发的同学写的代码落空了，测试的同学发现的bug还得再找。每个人心里都有委屈。产品经理作为需求的管理者，非常容易承受民众的愤怒，他怕死。一旦解决的不是很好，就非常容易造成朋友之间的分歧。
有人试图解决需求变化的概率，但很快就会发现，需求变化在很多情况下是产品经理自己无法控制的，甚至是商品发展趋势全过程中的必然经历。因此，必须将需求变更纳入管理方法中，称为需求变更管理方法。
今天讨论的需求变更管理计划必须建立两个前提条件:
适用商品、产品研发可以通畅沟通的团队。针对外包项目等需求与开发设计责任人没有同一团队的状况，仅作参考。适用产品研发周期时间短，迅速发布的产品迭代。针对产品研发周期时间动则半年的软件开发新项目，必须导入更繁杂的需求变更步骤。一样，针对商品总体方位上的大调节，也不适合文章内容中提及的方式。需求之际充足沟通互联网运营的产品R&D，是团队满足客户需求的一次情怀之旅。不过是集体活动，提前约法三章很重要。在开始旅行之前，团队的每个成员都必须就一些基本问题达成一致:
注重团队工作的有效性。每一个需求变化都代表着团队的努力，我们无法接受随时会发生的变化。产品经理作为需求的控制者，不可能每天换一个花心。今天重要的，明天就会完美。他要事先想清楚自己想要什么，拒绝拍脑袋做管理决策。
最好少改变自己的需求，但一定要接受改变的存在。产品经理不是神，不可能什么都知道。团队必须对产品经理的工作保持一定的容忍度，不谈论改变就去拍砖。我的习惯是配合新团队，一定会和从事产品研发的朋友坦诚相见。我肯定我的能力会有限，需求会有变化，但我可以 *** 纵，不会装懂给大家看。适度降低大家对自己工作的估计，有利于提高大家的服务质量。
在开始产品开发之前，产品经理有责任与所有团队就这个产品开发的总体目标、方法和考虑方法达成一致。对团队需求的理解直接危及销售业绩的达成。许多团队的产品和产品R&D之间的关系停留在产品经理编写需求，产品R&D团队制定需求的事实上。他们很少互相交流为什么要做，怎么做，把办公室变成了拧螺丝的生产线。
分享一个我和团队伙伴沟通整体目标、方式、考虑方式的常用方法:BML实体模型，也就是在什么情况下，作为一个产品经理，我用哪些数字逻辑来解决这样一套方案。发布后，我可以关心数据信息主要表现在哪些连接点，哪些数据信息会再次迭代更新，哪些数据信息会考虑到转型发展。
我们不必把所有的问题都推到需求定义上。事先沟通再详细，也会有疏忽和遗忘。全程沟通有利于改善团队的自然环境。对于一个知识面很高的团队来说，很多事情都可以通过眼神交流来完成。如果还有距离感，一定要多说话。产品经理可以在午餐、晚餐和他的休息日，请产品研发的朋友听听他们对需求的理解，这样可以防止理解不一致带来的变化。
分辨需求转变是怎样产生的需求定义环节再优秀，也撑不住时间的冲击。需求终究会改变。那么解决这个问题的第一步就是搞清楚它是怎么产生的。一般来说，大概有以下几种情况:
1、自身没想清晰对于每天都在看新品的产品经理来说，经常会出现这种情况。刚做好设计，刚做了审核，第二天发现了新方案。
2、老总/业务流程需求方发生变化有些产品经理自己都不会轻易拍脑袋，却吃不下老板的日常，爱拍脑袋。他们的胳膊拧不过大腿，只能换。对于老板需求的解决方法，可以参考之前的文章《举报老板，你的需求不靠谱》。
3、环境变化了还没放货，我就发现销售市场已经变了。市场机会不可预测。比如，以前我是踏踏实实做百度云盘的。突然天津说我完全免费，360也说我完全免费360g，这个时候百度云盘已经坚持不下原来的产品开发节奏了。
4、认为发生变化这种情况也经常发生。很多团队都有沟通盲区，大家都会瞎，对于最后的结果没有统一的总体目标。出现不一致的时候，大家会说是需求变化。
分辨是不是进行需求变更需求是有可能改变的，但不一定要切断产品研发的原有节奏，进行需求改变，磨练产品经理的管理能力。在正常情况下，你必须做三个区分:
1、需求转变的力度首先确定需求变化的力度，是完成步骤的变化还是关键点的推进。
如果是阶跃变化，产品经理必须格外谨慎。在考虑这样的需求变化时，一定要分析目前的方法是否真的不能满足总体目标。比如为了让客户更容易找到内容，人人计划做一个内容分类的导航栏。现在，他们觉得力不从心，想做一次搜索，大概意味着之前的工作都白费了，对团队士气伤害很大。一般情况下，除非原方案基本不能达到一个相对满意的结果，否则不要在迭代更新中进行调整。
如果是关键点的改进，比如一些创意文案或者小互动动画，对原有步骤的改进，也可以纳入进一步考虑的范围。
2、使用价值与成本费的衡量是否明确提出新的要求，将极大地促进该产品研发总体目标的实现，并能极大地提高对客户需求的考虑水平。此外，在新的需求被明确提出后，产品R&D团队改变所花费的精力大小。
实际效果预估非常好，低成本的需求变更，积极主动推动实际效果预估非常好，成本增加的需求变更，推迟解决实际效果不明，低成本的需求变更，审慎处理，决不很多资金投入实际效果不明，成本增加的需求变更，果断防止无论是出于自身、老板还是自然环境的需要，这些标准都可以使用。关键是 *** 纵总产出，需求变化已经从原来的工作中切断了。如果你发现有太多的东西需要改变，那么你应该首先反思你的需求定义的有效性。
注:测算可参考俞军的客户体验公式:新体验-旧体验-改变成本。
3、新项目排期是不是接纳转变在确定需求值得更改之后，我们还必须考虑当前新项目的进度情况。
如果新的项目进度很着急，不能更改，最好忘记需求更改。领导们都说，进步永远比完美更关键。在管理决策需求变更的整个过程中，需要与需求方和团队做好沟通。每个角色都有自己应用或抵制的理由，产品经理有责任统一任何人的认知能力后再实施改变。
需求变更的沟通在我们明确实施需求变更后，还有一些善后处理必须得到保障。
1、改动需求文本文档需求变化后，非常容易出现沟通不一致的情况。要尽快修改好需求文本文档，重新发出去，避免朋友靠一句话的需求想象或纯粹的口头沟通来重新开发设计，费时费力，容易出错。
注意:对于团队来说，我们都是使用电子邮件来共享和存储需求，在整个项目风险管理过程中，非常容易出现需求文本文档版本号混乱的问题。产品经理要在团队中推动创建一个好的需求文本文档智能管理系统，比如GIT。
2、表明变更状况无论是公布还是非正式的，大家都要把需求的变化告知相关的朋友，包括需求者和产品研发的朋友。
尤其是测试的朋友，很多时候在讨论需求的时候，开发和设计或多或少都会参与，但是通常测试的朋友在发现完成与需求不符的时候才知道需求发生了变化。这也会导致他们重复工作，降低测试质量。
每个人都必须至少弄清楚两件事:
(1)说明需求变化的原因。
如果是自己的锅，请主动背。如果是老板的锅，请充分沟通理解，正面背诵，不要把自己变成老板的传声筒。回，关注变更的使用价值，让相关人士确立变更的实际意义。每个人都期望自己做的事情是有使用价值的，对改变后的使用价值进行清晰的描述有利于接下来的工作。
(2)建立新的项目进度计划。
对于产品研发的朋友来说，新项目的排期变化与否，决定了每个人阶段性的压力。如果我们能够获得开发和设计时间来改变需求，我们就可以在工作中保持节奏，并相对轻松地解决变化。如果新项目日程无法更改，大家都要加班，请准备零食饮料全程陪同。
对于需求方来说，最初的计划很可能会有一系列后续措施。如果需求变化会造成新项目的延期，一定要事后通知朋友注意调整工作计划。另外，这又是一次告诉需求方，是大家团队为了需求的变化而买的单，以后一定要更加谨慎。
注:如果老板是需求方，最后评估是需要调整当前新项目，尤其是其他新项目的进度安排，需要做好向上管理。因为年级中间通常存在信息不对称，存在整体新项目优先级不一致的可能，需要立即沟通。
别的的本人习惯性和疑难问题1、担忧别人恶意差评，害怕做需求变更很多同学担心被朋友K改，尤其是一些设计方案前期没有充分考虑的关键问题。一旦产品研发完成，商品生也不敢做明确的改变，放弃了对商品感情的合理把握。
在这种情况下，我有一个习惯，就是在每次产品开发之前，都会和产品开发的朋友承诺一个产品体验变化期。当第一版产品出来的时候，我可以集中精力从头到尾体验产品，在感受中发现关键问题。有了事先的沟通和新项目的安排，人们对感情的变化会更加宽容。
2、忍气吞声的做需求变更还有一部分同学回避了别人的需求，都是找产品开发的朋友来纠正，却不知道改变的原因和程度。长此以往，这样的变革层级会让产品R&D团队东奔西跑，把自己变成需求方和产品R&D团队之间的麦克风，缺乏团队的信任。一定要回到出发点，考虑客户的需求，区分需求变化的使用价值。
3、死抠排期，漏改问题有时候因为档期已定，人们担心危及发布时间，甚至忽略了真正的问题。事实上，对于互联网技术产品研发的新项目，进度安排从参考功效开始，有助于考虑新项目的进度。即使有严重的新项目不能慢下来，比如618、双十一，也要根据发布后的危害来决定是否做出改变，而不是只按进度行事。
总结最后把不容易被干掉的送礼需求换成32个字:
考虑整体目标，考虑使用价值，找准机会，做好沟通；
不要害怕质疑，不要想传播声音，灵活解决，有理有据。
创作人:蔡钦宇，微信微信官方账号:斜门外道(xmwd-666)
文章作者为@蔡钦宇，未经批准严禁拦截。
注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）