大厂的产品经理是怎样进行产品迭代的
作者：SherlFang 个人网站：iamsherl.com （转载已取得作者授权） 这篇文章也是对我自己这几年产品做事方式的一个流程总结吧…… 先说一下背景，大厂和小厂都呆过。呆过野蛮生长的传统集团的互联网部门，呆过上市的中型二线互联网公司，呆过 APPLE STORE 行业APP 排名第一的产品公司，现在呆在全球一万多员工的超级独角兽公司。 其实各个产品公司的迭代流程都大同小异，因为规范起来，迭代流程就是那一套。目前觉得差异比较大的就是使用的工具和具体管理的方式，这个也是很想跟大家一起讨论的，看看有没有更加高效的方式或工具。 这篇文章大概会从以下几个方面分开讲述，不排除我写着写着会修改大纲的可能： 一，需求收集 二，需求整理 三，优先级划分 及 需求交付（直白地说就是怎么写 PRD 文档） 四，需求评审 及 产品评审 五，需求变动（针对由于其他特殊问题导致的需求变动，产品经理该如何做到“不背锅”） 六，工具（滴答清单、为知笔记、confluence、JIRA、Axure） 如果感兴趣的话，还有…… 七，如何更高效地跟交互、UI 设计、开发、测试 沟通和交流（这部分貌似没人感兴趣我就不写了……） 下面开始，是正文。 〇，流程图
先看一下大概的流程图，每个环节再具体解释 一，需求收集
其实不同类型的产品，需求来源会不太一样。这里会尽量列出所有可能的来源。 用户反馈：产品中包含『用户反馈』页面，用户通过『用户反馈』入口，直接反馈过来的一手信息。 用户研究：通过用户调研、用户访谈、用户拜访、可用性测试等方法获得的用户一手信息。 客服团队：通过客服团队收集并反馈的二手信息。 市场/商务/BD团队：通过市场/商务/BD团队接触用户时，获得的用户需求。 内部成员需求：测试团队、开发团队、运营团队，针对产品提出的需求。 战略型需求：来自竞品的竞争压力产生的需求，团队制定的产品发展方向下的需求。 其他需求：老板需求。（牛逼的产品经理可以忽略这一项……） 其实看似需求来源很多，再综合一下，分析出来就是两种：1，外部需求；2，内部需求。 针对于外部需求，又分为『一手信息』获得的需求和『二手信息』获得的需求。『一手信息』就是产品经理直接从用户方获得的需求信息，是未中途经人加工过的。经过其他职能岗（如客服、市场、商务等）转述给产品经理的信息称为『二手信息』，这类需求相对而言质量没有『一手信息』高，需要产品经理再进行处理和分析。建议产品经理都找到方式直接跟用户进行沟通，而不是要假借他人之耳去听取需求。 内部需求，就是我们非常熟悉的了，经常会从不同小组或者部门的同事那里获得新的需求内容，一般这些功能是针对于产品功能的可用性或者优化的。再就是根据产品战略制定的需求内容。 这两部分需求其实获取起来没那么难，外部需求就是，想尽一切方法去接触用户、然后跟用户沟通。内部需求就是，多跟同事们沟通，没事儿多聊聊，问问看他们对于产品的看法。战略型的需求内容就不说了，这个涉及到不同公司的管理方式，说出来又是长篇大论的东西，甚至免不了要吐槽…… 二，需求整理
如果需求收集做的比较到位，到手的需求是多且杂的，基本是千奇百怪什么都有。这种情况下，要做的流程图上已经比较详细的说明了。 1，只保留有效需求
剔除那些看上去很明显不合理的需求。这个步骤需要依赖产品经理自身的经验和对自己产品的了解程度。 『对自己的产品很了解』，这一条看上去简单但挺难做到的，需要的不仅仅是产品经理自身的能力，还需要行业的经验、在公司呆的时间足够长。只有满足这些条件后，产品经理才能够很高效准确地做到『只保留有效需求』。 2，需求分类
有效需求进一步分类就是：需讨论的需求、需开发的需求、已有功能支持的需求
需讨论的需求：对于是否需要做不是很确定，需要跟相关人员讨论。 需开发的需求：需求强烈、跟当前规划一致、对短期目标/长期目标有助力、…… 已有功能支持的需求：这个是需要反思的，一般出现这种情况说明要么是功能的可见性做的有问题，要么是引导做的有问题，要么是功能不太符合用户的认知模型。有一些需求是合理的要求就需要进行功能的优化，甚至重新确定方案。
3，标签
基础体验类：体验上有问题了，这个一般是需要修改交互或者 UI，要求比较高的公司/产品可能还存在响应速度、流畅性等方面的优化 运营支持类：运营活动支持 功能优化类：产品流程上存在一些问题，导致转化率、响应率等指标过低 新需求类：嗯……就是新需求 数据分析类：埋点需求啊，或者一些公司有大数据部之类的部门还会存在，报表需求啊 技术架构类：这个类别其实产品经理比较少管，属于架构师负责的内容，之所以写在这里是因为有一些对特殊的模块，技术架构的修改会影响到很多功能的开发进度和产品设计。产品经理对于这些需求的掌握是有助于产品规划的。（简单解释一下啥是特殊模块：比如，移动办公软件的『签到』功能，用 户量大且存在 上下班的流量高峰期；由于是基础功能、对于稳定性要求更高，一发生异常状况基本就是要罚钱的…；存在各种情况，比如什么类型的考勤、进没进圈、连没连网、打没打上等等，产品逻辑很负责；做过定位的人都知道，定位的技术手段太多，而且还有漂移、偏差矫正等，所以技术逻辑也复杂）
三，优先级划分 及 需求交付
1，优先级划分
产品的长期/中期规划是怎样的 当前的 sprint 对于长期/中期规划的意义是什么，是为了达到什么目标 达到目的的 MVP 需要哪些功能
有没有触碰高压线 fix 后能带来什么 不 fix 能导致什么
对于『情报』的收集和分析能力 下决定的能力
2，需求交付
迭代记录：版本号、修改时间、改了啥、为啥改、修改人（谁知道需求中途会不会换人呢，前面的人挖了个坑，也好去追责啊对不对？） 人员职能（非必须）：产品、交互、UI、前端、后端、客户端（iOS Android） 分别是哪些小伙伴。大公司必备，特别是我们这种组织架构完全看不到的公司…… 需求类型：不清楚的同学翻翻前面的标签哈 需求背景：你不说清楚这个，开发和设计心里绝对会怀疑做这个需求的意义。部分产品经理是不是觉得开发和设计的小伙伴不怎么配合你的工作啊？仔细想一下，自己在这部分的『忽悠』是不是不够到位… 需求目标 专业术语和缩写解释（非必须） 功能列表：这个就是一张大表了，需要包含 功能点名称、所在模块、使用场景描述、风险点（风险一定要提前暴露，引起大家的注意，大家能一起想办法规避）、备注（这个你就爱写啥写啥，觉得啥重要写啥） 流程图 及 逻辑图：这个不用多说吧…… 文案：呵……如果你的 APP 包含有3种及以上的语言，你不写个文档保存试试……而且有文档的话，比较利于 APP 在文案上的一致性 合作内容（非必须）：你是跟哪个部门合作了啊，对接人是谁啊，用了他们的哪些接口啊 数据埋点（非必须）：哪些关键埋点是需要开发小伙伴帮你埋的呀，埋点名称、埋点内容，都需要写清楚
四，需求评审 及 产品评审
1，需求评审
大型需求：需求功能多，一个人设计可能会考虑不周全，需要人帮忙补充完善，让产品设计尽量全面 方案不太确定的需求：产品经理对于方案有疑问，比如 不知道现在设计的方案在开发上是否可行、设计上是否可行、业务上是否可行；需要相关模块更有经验的人一起做决策 与其他部门 / 模块耦合较深：涉及其他部门 / 模块的业务，需要跟两方一起进行沟通商议 敏感需求：恩……这个只能说是自行体会了……不是每个公司每个产品都会有敏感需求，而且敏感的点可能也会不一样，可能是跟政府相关（比如 微博/抖音/快手/头条 等面临的整改要求）、可能是跟国家政策相关（比如 金融类产品？）、甚至是跟国外的政策相关（哈哈 比如我现在的公司…）、有的可能只是跟公司内部相关（比如，有些公司老板说的需求某种程度上也算敏感需求，哪怕是改个 icon 大家也要一起脑暴……）
开场白：简单说明组织这次讨论 / 会议的原因 需求背景：恩，这个一般情况下是需要说的，如果参会人员全部对于背景都非常了解了，也可以不说 需求目的：你做这个方案，是为了达到什么目的 需求内容：开始讲方案咯 抛出问题：具体描述组织这次会议的原因，及需要他人哪些支持
2，产品评审
PRD：主要是，需求列表、流程图、逻辑图。当然，如果逻辑比较简单的话，交互稿就够了 交互稿：必备 视觉稿：这个要是来不及的话，有多少看多少
开场白：简单说明组织这次讨论 / 会议的原因 需求背景：绝大多数情况下，大部分开发是第一次听到这个需求，说明背景很有必要 需求目的：你做这个方案，是为了达到什么目的 需求内容：开始讲方案咯 确定方案：定下最终方案咯 确定协作：确定各个协作方做啥 给个 deadline：让各方给个 deadline 咯，要不怎么催进度
五，需求变动
六，工具
滴答清单——日常工作梳理、管理、记录 为知笔记——个人知识库维护 confluence——产品文档、工作文档维护 JIRA——项目内容记录、追踪、迭代维护 Axure——PRD 工具 ZEN——脑图工具
1，滴答清单
2，为知笔记
3，confluence 和 JIRA
比如，有树形目录管理，对于结构复杂的迭代型文档是必须的功能了。 文档内还 可以@团队成员，并邮件通知到 ta。 文档内还可以直接链接到其他文档，被链接文档标题修改后，链接文字自动同步修改，省去了同步维护的时间。 权限管理也很强大，可以精确到某个子页面是否允许读或编辑。 跟邮箱绑定后，当你关注的文档有了修改还能通过邮件通知到你具体修改了哪些部分。 更关键的是，直接跟 JIRA 打通，链接到 JIRA 的某个单，当前单的状态也能够直接同步到 confluence 上。
七，最后再多啰嗦几句
点击“阅读原文”
查看更多干货
评论