‍ 产品经理“客户说这个功能必须有。”‍ 开发“什么时候要”‍ 产品经理“越快越好。”‍ 开发“具体怎么做”‍ 产品经理“客户说了做成这样就行。”‍ 开发“……”三个月后。功能终于上线。客户看了一眼 “嗯……好像不是我想要的。”开发“”产品经理“”项目经理“”这类场景相信不少做产品、研发和项目管理的人都不陌生。很多企业的问题并不是没有需求而是需求太多、太乱、太碎而且从“客户说了什么”到“最后交付了什么”中间缺了一整套管理逻辑。所以真正成熟的产品团队不只是会“收需求”更重要的是能够发现需求 → 分析需求 → 判断价值 → 排定优先级 → 转化为产品要求 → 分解到项目 → 落实到任务 → 验证结果 → 持续反馈这才是完整的需求管理。01 需求是产品的“源头”产品需求分析有一句非常形象的话 “需求是产品的根源”。为什么这么说因为产品就像一条河。 如果河流源头的水是干净的后面的河流才有可能清澈。 但如果源头一开始就被污染了…… 那后面再怎么过滤可能都只能 一边加班一边打补丁。所以需求管理真正难的地方并不是 “我们有没有收集需求”而是“我们收集到的到底是不是有价值的需求”02 客户说“我要一个功能”不代表他真的需要这个功能这是需求分析里非常经典的问题。比如 客户说“我要一个防水的树脂材料电脑包。”很多人听到这里马上开始记录需求电脑包采用防水树脂材料。然后研发开始研究用什么材料材料多厚成本多少怎么生产怎么测试忙了一圈之后才发现…… 客户真正想解决的问题可能根本不是“树脂材料”。 而是下雨的时候电脑不要被淋湿。进一步分析 客户可能真正关心的是防水耐磨防潮使用寿命保护电脑也就是说客户说出来的可能只是解决方案真正需要分析的是背后的问题。所以产品经理不能只负责 “客户说什么我就记什么。”真正优秀的需求分析往往需要多问几层为什么为什么需要这个功能现在遇到了什么问题这个问题出现在哪里谁最需要解决如果不解决会产生什么影响问着问着需求就开始从“功能”变成“问题”。03 真正的需求分析很多时候不是“说”而是“听”需求采集的时候有一个非常重要的能力“听”。不是 客户说一句。产品经理记一句。 客户再说一句。产品经理再记一句。 最后得到一份几十页的《客户需求汇总表》。这不叫需求分析。 这叫电子版记事本。真正的需求访谈更重要的是问听确认理解继续追问获取具体场景关注客户期望发现不同客户之间的冲突尤其要注意客户说的“方案”不一定就是需求本身。04 需求不是越多越好而是要“收集 → 整理 → 分析 → 排优先级”很多企业都会遇到一个非常现实的问题 需求越来越多。微信群里有需求。邮件里有需求。Excel里有需求。会议纪要里有需求。销售那里还有一堆需求。老板突然又来一句“这个功能客户特别需要优先做。”于是产品经理的电脑里出现了 客户需求.xlsx 客户需求‑new.xlsx 客户需求‑new2.xlsx 客户需求‑最终版.xlsx 客户需求‑最终版真的最终.xlsx 真正成熟的需求管理需要把这些零散信息统一起来。基本过程可以理解为需求收集 → 需求解释 → 需求整理 → 需求分类 → 需求权重分析 → 需求优先级 → 产品需求 → 项目实施05 ⭐ 不是所有需求都值得马上做假设现在产品团队收到500条需求。是不是意味着500条全部做当然不是。否则产品经理最后可能会变成“需求搬运工。”真正重要的是判断需求价值。需求分析中经常会涉及不同的方法例如KANOBSAAHPSWOT竞争分析需求权重分析其中比较容易理解的就是把需求分成不同层次。基本需求没有它客户会觉得“这产品怎么用” 例如登录基础权限数据保存基本功能期望需求做得越好客户越满意。 例如操作速度使用体验查询效率页面交互兴奋需求客户原本没想到。但是有了之后“哎这个不错” 例如智能提醒自动分析自动推荐自动生成报表06 ✂️ 真正成熟的产品经理还要知道“什么不做”产品经理最难的一件事情有时候不是“决定做什么” 而是“决定什么不做”。因为资源永远有限人有限时间有限预算有限开发资源有限测试资源有限如果什么需求都答应客户“这个能不能加”产品“可以。”销售“这个客户也需要。”产品“可以。”老板“这个功能也挺重要。”产品“可以。”最后开发“你们到底准备让我活到哪一天” 所以需求管理必须考虑减少什么增加什么强化什么消除什么07 需求分析不能停在一份PRD里很多企业的需求管理到这里就结束了 产品经理写PRD。然后发给研发。研发打开文档。看了半天。然后问“这个需求到底什么时候做”产品“这个版本。”研发“哪个版本”产品“就是那个版本。”研发“……” 问题就在这里需求文档只是开始不是结束。一个完整的需求需要继续往下走市场需求 → 产品需求 → 设计需求 → 开发任务 → 测试用例 → 测试结果 → 最终交付08 这时候项目管理软件就开始有用了说到这里就出现了一个很现实的问题如果公司只有几个项目、十几个人也许Excel还能勉强撑住。但当企业开始出现项目越来越多产品越来越多客户越来越多研发人员越来越多需求越来越多版本越来越多Excel就开始逐渐变成 Excel 需求表 Excel 项目计划 Excel 人员表 Excel 进度表 Excel Bug表 Excel 汇总表……最后大家每天做的事情变成“你把最新版发我一下。”“哪个是最新版”“就是昨天那个最新版。”“昨天有三个最新版……” 09 让需求真正进入项目执行这也是项目管理软件真正有价值的地方。以 Eywe 项目管理系统 为例。 它并不是简单地把Excel换成网页。 更重要的是把需求、项目、计划、任务、人员、进度、执行、验收这些原本分散的信息连接起来。易为项目管理软件一款免费、高效、轻量易用的项目管理工具。在线演示http://www.cseywe.com:90开源仓库https://gitee.com/eywe-butler/eywe安装包下载https://pan.baidu.com/s/1qdGPmofQsVBVQr8kMI2-4g?pwdEY0110 最关键的不是“有任务”而是需求和任务真正连接起来需求管理最怕出现一种情况 产品经理“这个需求已经分析完了。” 项目经理“项目已经立项了。” 研发“任务已经分了。” 测试“测试已经开始了。”然后突然有人问 “等等我们做的这个任务到底对应哪个需求”全场安静。 所以真正有效的项目管理需要建立这种关系需求 → 产品规划 → 项目 → 计划 → 任务 → 负责人 → 进度 → 测试/验收 → 交付这样一来管理者看到的不再只是“项目现在完成80%。”而是可以继续追问这80%完成的是哪些需求哪些需求还没开始哪些需求已经完成哪些任务延期了是谁负责为什么延期这才是真正有价值的项目数据。11 对企业来说需求管理做好之后改变的不只是产品经理很多人以为“需求管理 产品经理的事情”。其实不是。 它影响的是整个企业协作过程。‍对管理层可以更清楚地看到公司到底在做什么项目为什么做进度怎么样哪些项目存在风险‍对产品经理不用每天在微信群、Excel、邮件、会议纪要之间来回翻找。 需求可以更加集中管理。‍对研发团队知道为什么做这个任务这个任务属于哪个项目谁负责什么时候完成对测试团队可以更容易理解这个功能对应什么需求应该验证什么最终结果是什么对整个企业最重要的变化是 大家开始围绕同一套信息协作。而不是产品看Excel。研发看群消息。项目经理看甘特图。老板看PPT。最后大家一起“信息不一致。”12 ⚠️ 当然软件不是“万能药”这里也必须说一句比较现实的话 项目管理软件并不能自动解决所有问题。如果企业本身需求没有分析优先级没有确定责任人不明确项目计划不清晰执行过程不跟踪验收标准不明确那么换多少软件都一样。因为工具解决的是管理效率问题而不是替企业替代管理。真正有效的需求管理需要方法 流程 工具 人四个一起配合。13 最后把整个需求管理过程串起来回到最开始的问题 客户说“我想要一个功能。”真正成熟的团队不会马上回答“好的安排开发。”而是会继续问为什么需要 → 解决什么问题 → 谁需要 → 价值有多大→ 优先级是多少 → 应该怎么设计 → 属于哪个项目 → 怎么拆成任务→ 谁负责 → 什么时候完成 → 怎么验收 → 最终有没有解决客户的问题这才是真正完整的需求管理闭环。