产品经理怎么改需求，才不会被研发“砍死”？
|
副标题[/!--empirenews.page--]
奉上不会被砍死的需求变更 32 字口诀：目标出发，衡量价值，判断时机，做好沟通；不怕质疑，不甘传声，灵活应对，顺理成章。
听说因为随便改需求，某公司产品经理被愤怒的程序猿砍成重伤，至今昏迷不醒！
经常在网上看到，在产品研发的过程中，发生了需求变更。研发同学辛苦写的代码泡汤了，测试同学好不容易找出的 bug 得重新再找，每个人心里边都有一股怨念，产品经理作为需求的管理者，很容易承受人民群众的怒火，千夫所指，惶惶不安。一旦处理不好，很容易导致同事间的矛盾。 有人尝试着消灭需求变更的可能性，但很快会发现，需求变化很多时候根本不是产品经理自己就能控制的，甚至它就是产品发展过程中必然的经历。所以，需求变化必须纳入管理，我们称之为需求变更管理。 今天我们谈的需求变更管理方法，必须要明确两个前提： 适用于产品、研发能够畅通沟通的团队。对于外包项目等需求与开发负责人不在同一团队的情况，仅供参考。适用于研发周期短，快速上线的产品迭代。对于研发周期动辄大半年的软件工程项目，需要引入更复杂的需求变更流程。同样，对于产品整体方向上的大调整，也不适用文章中提到的方法。需求伊始充分沟通互联网产品的研发是一次团队满足用户需求的体验之旅。既然是集体活动，事前约法三章非常重要，开始旅行之前，团队的每一位成员都需要就一些基本问题达成一致： 尊重团队的工作成果，每一次需求变更都意味着团队努力的消耗，不能接受随时随地都在发生的变化。产品经理作为需求的把控方，不能每天换个花样，今天要方的明天要圆的，提前想清楚自己要什么，拒绝拍脑袋做决策。 需求最好少变，但必须接受变化的存在。产品经理不是神，无法全知全能，团队需要对产品经理的工作保持一定的容忍度，无须谈变更就上板砖。我的习惯是和新团队合作，一定会找研发的同事们开诚布公一次，明确告知我能力有限，一定会发生需求变更，但是我会控制，不给大家瞎指挥。适当降低大家对自己工作的预期，有助于提高大家的满意度。 开始研发之前，产品经理有义务就本次研发的目标、手段和衡量方式，与整个团队达成一致。团队对需求的理解，直接影响着业绩达成。很多团队的产品和研发的关系都停留在产品经理写需求，研发团队做需求，至于为什么做，如何做，双方很少沟通，把办公室搞成了拧螺丝的流水线。 分享一个我常用来和团队伙伴沟通目标、手段、衡量手段的方法：BML 模型，即在什么样的背景下，作为产品经理，我依托什么逻辑设计了这样一套解决方案，上线之后我会去关注哪些节点的数据表现，什么样的数据表现会继续迭代这个方案，什么样的数据表现会考虑转型。
不要把所有问题都推到需求定义阶段。事前沟通再详尽，也会有疏漏和遗忘。过程中的沟通，有助于改善团队环境。对熟悉度很高的团队，很多事情可以靠眼神交流。如果还存有陌生感，一定要多聊，产品经理可以在午餐、晚餐及其他休息时间找研发同事听听他们对需求的理解，能够避免理解不一致带来的更改。 分清需求变化是如何发生的再优秀的需求定义阶段，也顶不住来自时间的冲击。需求终究还是会发生变化的。那么处理的第一步，是弄清楚它是怎么发生的。常见的可能有以下几种情况： 1、自己没想清楚这种情况对于天天都在看新东西的产品经理来说经常会发生。刚做好的设计，刚做完评审第二天就发现了新的方案。 2、老板/业务需求方变了有的产品经理自己不会拍脑袋，但是架不住老板日理万机爱拍脑袋，胳膊拧不过大腿，只好变更。关于老板的需求处理，可以参见之前的一篇文章《报告老板，你的需求不靠谱》。 3、环境变了产品还没上线，发现市场已经发生了变化。市场机会瞬息万变。比如之前本来稳扎稳打地做着百度云，忽然金山说我永久免费了，360也说我永久免费360G了，这时百度云也没法坚持原来的研发节奏。 4、以为变了这种情况也经常发生，很多团队的沟通存在盲区，每个人都在瞎子摸象，对于最后的结果没有统一的目标，当发生不一致时，大家就会说这是需求变化了。 判断是否发起需求变更需求可能有了变化，但是否有必要打断原有的研发节奏，进行需求变更，非常考验产品经理决策能力。一般情况下，我们需要做三个判断： 1、需求变化的幅度首先确认需求变化的幅度，是实现流程的转变，还是细节上的优化。 如果是流程的变化，产品经理需要格外慎重。在考虑这样的需求变化时，我们需要分析现在的手段是否真的无法满足目标实现了。比如为了让用户能更方便查找内容，我们计划做一个内容分类导航，现在觉得不足够，想做一个搜索，这可能代表着之前的工作全都打水漂了，对团队士气有很重大的影响。一般情况下，除非是原来的计划几乎不能达成相对满意的结果，否则不要在迭代中做调整。 如果是细节上的优化，比如一些文案或者小的交互动画，对原有流程的完善，那么也可以纳入到进一步考虑的范围内。 2、价值与成本的权衡新的需求提出是否对本次研发目标的达成有较大的促进，能够极大程度地提高对用户需求的满足程度。同时新需求提出后，研发团队修改所花费的精力大小。 效果预期很好，成本低的需求变更，积极推进效果预期很好，成本高的需求变更，延后处理效果未知，成本低的需求变更，审慎处理，绝不大量投入效果未知，成本高的需求变更，坚决避免这几项原则无论是对于来自自己、老板还是环境的需求都可以适用。重点是控制好总量，需求变更总是打断了原有工作。如果发现太多事情都需要做变更，那么我们应当首先反思自己需求定义工作的有效性。 注：权衡可以参考俞军的用户体验公式：新体验 – 旧体验 – 变更成本 3、项目排期是否接受变化判断完需求值得变更之后，还需要考量当前项目排期情况。 如果项目排期非常紧张，并且无法变化，最好忘掉需求变更。大佬们说了，完成永远比完美更重要。在决策需求变更的过程中，需要和需求方、团队都做好沟通，每个角色都有自己支持或者反对的理由，产品经理有义务在实施变更之前，统一所有人的认知。 需求变更的沟通当我们确定实施需求变更后，还有一些善后工作必须做到。 1、修改需求文档需求变更之后，很容易出现沟通不一致。需要尽快修改需求文档，重新发出，避免同事们靠一句话需求脑补或者纯口头沟通继续开发，费时费力还容易错。 （编辑：源码门户网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
