第一次做需求：从失败到成功教材.pdfVIP

第一次做需求 ：从失败到成功 小雪碎碎念 ：这是一篇写给初入门的学习文章 ， 品策划的规范流程 ，很多时候 品经理要 面对很多东西 ，想了很多写了很多也整理了很多 ，但是总是觉得不够 ，下面的文章可以帮你 更好的整理思路。 说服力 ：从场景化出发的用户价值 “按钮应该放在右边 ，这符合规范 ！”“但是用户习惯在这边寻找按钮 ，放那边不够自然。”“这个可以 做啊 ，但是用户会觉得很好用。”“有没有更好的方案 ，为什么一开始就要做那么复杂的操作呢 ？” 这样的讨论总是在 品经理评审需求的时候出现。大家目标都很一致 ：为了用户和 品的发展。但 每个人的视角或有不同 ，这时 ， 品经理就应该具备上帝视角。什么是“上帝视角” ？就是指 品经 理不仅可以看到主流用户的需求 ，还可以看到其他伙伴各自的出发点 ，可以和他们进行良好沟通 ， 推动 品实现。前文曾谈到为什么需要 品经理这个职位 ，我认为 ， 品经理在整个项目中不仅需 要对需求负责 ，更要成为伙伴之间的“润滑剂”——可以和 品经理PK 需求 ，也能和开发人员探讨技 术方案的实现 ，还可以和设计师聊一聊最新的设计风格 ，最关键的是 品经理需要了解用户。 但事实上 ，谁都觉得自己更了解用户 ，觉得自己本身作为一个用户没有被满足需求。这种情况时常 出现在每次的评审中 ，这就要求 品经理可以做适当的沟通。前文出现的激烈争论并非是坏事 ，对 于需求来说 ，可以越辩越明 ，但对于决策来说 ，却不符合呆伯特会议规则 ，无法说服其他伙伴同意 品经理的方案。还有一种可能的情况 ，即 品经理强势地要求开发工程师或者设计师按照自己的 理解去进行 ，通过“项目时间”和“老板需求”来强迫他们“心甘情愿”地实现需求。这种“狐假虎威”的做法 有时候有效 ，但对于 品开发来说 ，并不是一件好事。 在 品开发过程中 ，如果相关人员都没有被 品经理说服并同意 品经理的方案 ，就容易 生情 绪——而情绪化的结果则是潜伏在 品开发过程中的各种风险都会不断出现。例如 ，开发工程师没 有准确地理解需求 ，马马虎虎地完成功能 ，忽略了相关逻辑和细节实现 ，或者将这位 品经理的需 求优先级放低 ，不断拖延……这种情况很常见。我私底下和一些工程师关系不错 ，有时候就会问 他们 ，为什么有的需求完成度很低 ，有的时候需求bug 会特别多 ？他们会回答 ：“不想做或者有其他 优先级的事情。如果充分理解了需求 ，我们也是很乐意去做的。但是平时 品经理都不和工程师一 起玩 ，没有太多的革命友谊 ，所以大家都是公事公办 ，公事公办的后果就是先做其他事情。” 品经理们 ，去施展你们的影响力吧 ！准确地阐述用户需求和价值 ，让伙伴们认可你的方案 ，这对 于方案的实现有着重大的意义。用户需求时常被挑战的重要原因之一就是缺乏场景 ，大部分时候把 自己当作用户并不能很好地反映客观情况 ，需求往往是伴随着场景而变化的。正如 《探索需求》中 所言 ：“除此之外 ，人们并不经常购买他们所需要的东西 ，却常常追求他们并不特别需要的东西 ，即 使这种期望是短暂的。” 场景化需求才会 生“期望” ，而不考虑场景提出的需求 ，虽然客观存在 ，却不一定是最想要和最需 要被满足的。因此 ， 品经理在面临日常的方案挑战时 ，一定要关注将需求和场景结合起来 ，如果 可以考虑用户的使用习惯和行为数据 ，则会更加具备说服力。 第一次做功能——从失败到成功 第一次做功能 ，对于许多 品经理来说 ，意义非凡。但对于一个入门者来说 ，第一次做功能往往需 要人进行辅导。在腾讯内部 ，导师一般会安排刚入门的 品经理承担一些简单的需求 ，并会进行对 应的指导。即便如此 ，看过本书前几章的 品经理可能依然会有点茫然 ：“虽然我都知道该怎么做了 ，但是如何开始第一步呢 ？” 许多人在 品分析时表现得头头是道 ，但一面临实践操作往往就发现 ，理论再靠谱 ，也难以应用到 现实中来。记得我第一次跟进的需求是做一个阅读文章的功能。当时我画了思维导图 ，又用PPT 做 了几个线框图做说明 ，还写了Wo rd 版本的需求文档。但事实上 ，这几个东西都没有起到太大作 用——因为每个 品经理做需求的第一步 ，不是动手去做 ，而是思考。 第一次做功能 ：产品设计阶段 三思而后行 ，这是我的个人经验。如果一个 品经理在接到任务之后 ，不假思索地就开始要各种 资源 ，拉设计师和工程师讨论需求 ，肯定会受到各种挑战和不信任。任何一个需求都应该被拿来好 好思考 ，清楚了整个流程 ，考虑了各种情况都会有哪些效果 ， 品经理的心里才会有底 ，才能有效 地传达需求