需求生命周期中,我们究竟该做什么？.pdfVIP

需求的生命周期中 ，我们究竟该做什么 ？ 产品经理们在处理来自不同地方的需求时 ， 着不同的工作方式和方法 ：分类管理、定期维 护等不一而足。那么 ，对于需求的整个生命周期来说 ，我们究竟应该怎么做呢 ？ 下面是我的经验。 一. 获取阶段 需求的来源 很多。业务越复杂 ，需求就越杂。一个淘宝 ，产品需求就可以拆分成分类、检索、 排序、商品展示、营销活动、支付、配送、售后等等。 你的职级越高 ，也代表着身边人提需求的可能性越大。初入行的产品专员或助理 ，主要是得到被安 排的任务 ；初级产品经理 ，需求来源主要是用户和上级 ；产品负责人 ，需求来源就要增加老板和其 他相关部门 ； 而作为老板 ，谁都可能跟他提产品需求。 所以在获取到需求这一时刻 ，就 必须做一个判断 ，并且记录 。如果不做判断堆在那里 ，等做的时候 根本没办法梳理出头绪 ，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯。获取 到的再小的需求也记下来 ，不要指望你随时能想起来每天听过的每个需求。 做判断的内容具体是什么呢 ？ 第一 ，判断需求本身的重要性 同样是页面写错了一个字 ，把 「登录」写成 「登陆」 ，和把 「奖励 15 元」写成 「奖励 50 元」 ，重 要性不言而喻吧。 个大致的预估。 第二 ，考虑需求来源 需求来源会表明一些事情 ，要慎重思考。比如老板提到的 ，未必是目前你能理解的 ，但他认为特别 重要 ，就暂且把这个当成特别重要的 ，这是政治任务。再比如是用户提到的 ，但细想他并不是目标 用户 ，他的需求就不必太关注。 第三 ，简要得到需求背景 我自己工作中 三类需求绝对不记 ：没说清楚原因的 ，不记 （你做个 XX 出来 ，别管那么多 ）；不 说清逻辑的 ，不记 （啊 ，这里我也没搞懂 ，你先看看 ）；不是实际遇到的 ，不记 （哎 ，我觉得可能 人会这样用 ）。 需求背景没搞清楚 ，完全是浪费时间。 一句话的记录 ，但不说背景 ，也是浪费时间。记的时候 ， 我会确保格式是问题 + 方案 ， 「XXX 在用我们的 XX 功能时 ，感觉 XXX ，我们可以尝试 XXX 这 样的方案」。 最后 ，依据这三个因素 ，判断属于大致哪个类别的。一般的需求管理都会分 P0- P3 或者 P1- P4 ，总 之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求 ，就是你感觉是 P2 的 ，暂且 先标为 P1。这样以防错漏 ，低优先级的标成高的没关系 ，但高优先级的标低了会出现麻烦。这时 候的预估往往不准确 ，但没关系 ，等后面第二步再说。 比如这样 ： 二. 讨论 / 设计阶段 隔一段时间 ，我们会开需求讨论会 ，整理需求池 ，也就是记录所 获取到需求的表单。 我们会详细讨论每个需求的情况 ，确认几个事项 ： 1. 需求的优先级 之前的判断是粗估 ，这里的判断就要精细了。一般需求的重要程度很难量化 ，尤其来源复杂的情 况下。营销部门着急要我们配合做活动 ，不做就少赚好多钱 ，业务部门着急要我们配合做一套自动 化结账工具 ，做了能节省很多成本… 时抉择很痛苦。 这里还是用最常用的判断方法 ，紧急重要四象限法则 （请自行百度 「四象限法则」 ）。重要程度大 致按这种排序 ： 不做会造成严重的问题和恶劣的影响的 做了会产生巨大好处和极佳效果的 跟重要合作对象或投资人 关的 跟核心用户利益 关的 跟大部分用户权益 关的 跟效率或成本 关的 跟用户体验 关的 紧急程度按这个排序 ： 不做错误会持续发生 ，造成严重影响 在一定时间内可控 ，但长期会 糟糕的影响 做了立刻能解决很多问题、产生正面的影响 做了在一段时间后可以 良好的效果 大家把能考虑到的因素想全 ，会标上 P1 – P4 的优先级。 2. 方案的方向 需求 不同的解决办法 ，我们会讨论清楚到底用哪种解决。比如我们发现 刷单现象 ，可以事前 提醒 ，告知用户目前地理位置或订单信息 嫌疑 ；可以事中限制 ，必须到达指定地点、拍摄当地照 片等等操作来限制用户 ；可以事后惩戒 ，提供给客服或者业务部门疑似刷单的名单和证据 ，罚款或 者封号。这几项到底做哪个 ？还是做其中哪几个 ？优劣在哪 ？需要好好讨论。 时会 大概的方向 ，再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内 ，暂且不提 。 3. 指定负责人 我之前经历过两种需求分配制度。一种是每个人负责的需求范围 清晰的边界 ，那需求对应哪个 模块 ，就直接分配即可 ；另一种是团队作战 ，每次指定或者认领 ，