大厂的产品经理是怎样进行产品迭代的-技术圈


作者：SherlFang  个人网站：iamsherl.com  （转载已取得作者授权）

这篇文章也是对我自己这几年产品做事方式的一个流程总结吧……
先说一下背景，大厂和小厂都呆过。呆过野蛮生长的传统集团的互联网部门，呆过上市的中型二线互联网公司，呆过 APPLE STORE 行业APP 排名第一的产品公司，现在呆在全球一万多员工的超级独角兽公司。
其实各个产品公司的迭代流程都大同小异，因为规范起来，迭代流程就是那一套。目前觉得差异比较大的就是使用的工具和具体管理的方式，这个也是很想跟大家一起讨论的，看看有没有更加高效的方式或工具。
这篇文章大概会从以下几个方面分开讲述，不排除我写着写着会修改大纲的可能：
一，需求收集
二，需求整理
三，优先级划分 及 需求交付（直白地说就是怎么写 PRD 文档）
四，需求评审 及 产品评审
五，需求变动（针对由于其他特殊问题导致的需求变动，产品经理该如何做到“不背锅”）
六，工具（滴答清单、为知笔记、confluence、JIRA、Axure）
如果感兴趣的话，还有……
七，如何更高效地跟交互、UI 设计、开发、测试 沟通和交流（这部分貌似没人感兴趣我就不写了……）
下面开始，是正文。
〇，流程图
先看一下大概的流程图，每个环节再具体解释

一，需求收集
其实不同类型的产品，需求来源会不太一样。这里会尽量列出所有可能的来源。
用户反馈：产品中包含『用户反馈』页面，用户通过『用户反馈』入口，直接反馈过来的一手信息。
用户研究：通过用户调研、用户访谈、用户拜访、可用性测试等方法获得的用户一手信息。
客服团队：通过客服团队收集并反馈的二手信息。
市场/商务/BD团队：通过市场/商务/BD团队接触用户时，获得的用户需求。
内部成员需求：测试团队、开发团队、运营团队，针对产品提出的需求。
战略型需求：来自竞品的竞争压力产生的需求，团队制定的产品发展方向下的需求。
其他需求：老板需求。（牛逼的产品经理可以忽略这一项……）
其实看似需求来源很多，再综合一下，分析出来就是两种：1，外部需求；2，内部需求。
针对于外部需求，又分为『一手信息』获得的需求和『二手信息』获得的需求。『一手信息』就是产品经理直接从用户方获得的需求信息，是未中途经人加工过的。经过其他职能岗（如客服、市场、商务等）转述给产品经理的信息称为『二手信息』，这类需求相对而言质量没有『一手信息』高，需要产品经理再进行处理和分析。建议产品经理都找到方式直接跟用户进行沟通，而不是要假借他人之耳去听取需求。
内部需求，就是我们非常熟悉的了，经常会从不同小组或者部门的同事那里获得新的需求内容，一般这些功能是针对于产品功能的可用性或者优化的。再就是根据产品战略制定的需求内容。
这两部分需求其实获取起来没那么难，外部需求就是，想尽一切方法去接触用户、然后跟用户沟通。内部需求就是，多跟同事们沟通，没事儿多聊聊，问问看他们对于产品的看法。战略型的需求内容就不说了，这个涉及到不同公司的管理方式，说出来又是长篇大论的东西，甚至免不了要吐槽……
二，需求整理
如果需求收集做的比较到位，到手的需求是多且杂的，基本是千奇百怪什么都有。这种情况下，要做的流程图上已经比较详细的说明了。
1，只保留有效需求
剔除那些看上去很明显不合理的需求。这个步骤需要依赖产品经理自身的经验和对自己产品的了解程度。
『对自己的产品很了解』，这一条看上去简单但挺难做到的，需要的不仅仅是产品经理自身的能力，还需要行业的经验、在公司呆的时间足够长。只有满足这些条件后，产品经理才能够很高效准确地做到『只保留有效需求』。
2，需求分类
有效需求进一步分类就是：需讨论的需求、需开发的需求、已有功能支持的需求
需讨论的需求：对于是否需要做不是很确定，需要跟相关人员讨论。
需开发的需求：需求强烈、跟当前规划一致、对短期目标/长期目标有助力、……
已有功能支持的需求：这个是需要反思的，一般出现这种情况说明要么是功能的可见性做的有问题，要么是引导做的有问题，要么是功能不太符合用户的认知模型。有一些需求是合理的要求就需要进行功能的优化，甚至重新确定方案。
其中，确定开发的需求就能顺利的进入到需求池了。需求池字面上来讲就是管理需求的大池子，我觉得这形容词挺形象的。在这个大池子里，你需要对需求进行优先级的维护，方案的制定、补充、完善。现在我是通过 JIRA + confluence 来进行管理和维护的，JIRA 和 confluence 简直是神器好么，配合起来用简直无敌。这个之后会在【六，工具】篇中进行具体的介绍。
3，标签
当需求过多的时候，也可以给需求打上标签。如果说按照迭代排期来进行需求分类是基于时间线的纵向管理的话，打标签则是横向管理。可以让你更清晰的看到现在的需求在每一个模块所占的比例和待做的内容。
现在比较常用的标签大概是这几类，当然最好是根据自己的公司和产品的情况进行分类，我这里只是提供一个思路：
基础体验类：体验上有问题了，这个一般是需要修改交互或者 UI，要求比较高的公司/产品可能还存在响应速度、流畅性等方面的优化
运营支持类：运营活动支持
功能优化类：产品流程上存在一些问题，导致转化率、响应率等指标过低
新需求类：嗯……就是新需求
数据分析类：埋点需求啊，或者一些公司有大数据部之类的部门还会存在，报表需求啊
技术架构类：这个类别其实产品经理比较少管，属于架构师负责的内容，之所以写在这里是因为有一些对特殊的模块，技术架构的修改会影响到很多功能的开发进度和产品设计。产品经理对于这些需求的掌握是有助于产品规划的。（简单解释一下啥是特殊模块：比如，移动办公软件的『签到』功能，用 户量大且存在 上下班的流量高峰期；由于是基础功能、对于稳定性要求更高，一发生异常状况基本就是要罚钱的…；存在各种情况，比如什么类型的考勤、进没进圈、连没连网、打没打上等等，产品逻辑很负责；做过定位的人都知道，定位的技术手段太多，而且还有漂移、偏差矫正等，所以技术逻辑也复杂）
三，优先级划分 及 需求交付
这两步其实占据了很多产品经理的很大一部分工作量和思考时间吧……
1，优先级划分
哈哈，其实关于这个模块，我之前写过一些 文章/回答 也有讲怎么进行优先级划分。然后一直有跟大家推荐过一本书 Jeff Patton 的《用户故事地图》，我从中受益很多，也希望这本书能帮助到大家的工作。
需求的类型在这里可以大致分为3种：1，新功能；2，迭代优化；3，bug fix（这里的 bug 可能是开发代码 bug、可能是产品流程 bug）
针对1和2如何确定优先级呢？首先需要搞清楚以下内容：
产品的长期/中期规划是怎样的
当前的 sprint 对于长期/中期规划的意义是什么，是为了达到什么目标
达到目的的 MVP 需要哪些功能
对于3如何确定优先级呢？首先需要搞清楚以下内容：
有没有触碰高压线
fix 后能带来什么
不 fix 能导致什么
比如我现在的公司，『安全』就是高压线，如果发现什么问题对于『安全』因素有影响，哪怕可能性不是那么大，优先级都是 P0。
再多说一句，我个人对于产品经理好坏的判断标准，其中有两个维度就是：
对于『情报』的收集和分析能力
下决定的能力
产品经理必须要能够很快速的收集到关于当前问题的尽可能多的『情报』，因为你所有的判断都是需要依靠这些情报的。
优柔寡断的产品经理，是我最忌讳的，不愿意深交。产品经理需要你能够基于当前的所有信息，尽量快、准地做出判断，并且你需要为你的判断承担相应的责任。
2，需求交付
应该有很多人期待这个部分？看到好多文章都是在教产品经理如何写需求文档。我这边就不细说了？列个大纲，大家看看有没有帮助吧，如果需要细说，请在评论区留言，我再根据留言补充一下内容……
目前，我们这边的最完整的需求内容包括：
迭代记录：版本号、修改时间、改了啥、为啥改、修改人（谁知道需求中途会不会换人呢，前面的人挖了个坑，也好去追责啊对不对？）
人员职能（非必须）：产品、交互、UI、前端、后端、客户端（iOS Android） 分别是哪些小伙伴。大公司必备，特别是我们这种组织架构完全看不到的公司……
需求类型：不清楚的同学翻翻前面的标签哈
需求背景：你不说清楚这个，开发和设计心里绝对会怀疑做这个需求的意义。部分产品经理是不是觉得开发和设计的小伙伴不怎么配合你的工作啊？仔细想一下，自己在这部分的『忽悠』是不是不够到位…
需求目标
专业术语和缩写解释（非必须）
功能列表：这个就是一张大表了，需要包含 功能点名称、所在模块、使用场景描述、风险点（风险一定要提前暴露，引起大家的注意，大家能一起想办法规避）、备注（这个你就爱写啥写啥，觉得啥重要写啥）
流程图 及 逻辑图：这个不用多说吧……
文案：呵……如果你的 APP 包含有3种及以上的语言，你不写个文档保存试试……而且有文档的话，比较利于 APP 在文案上的一致性
合作内容（非必须）：你是跟哪个部门合作了啊，对接人是谁啊，用了他们的哪些接口啊
数据埋点（非必须）：哪些关键埋点是需要开发小伙伴帮你埋的呀，埋点名称、埋点内容，都需要写清楚
 公司的协作情况和产品需求的情况不同，可能需要写的内容也会不同。大家看着用咯。
四，需求评审 及 产品评审
不是所有的需求都需要进行需求评审的，只有一些相对『难搞』的需求才会进行需求评审。这个是需要靠产品经理自己进行把控的。
1，需求评审
（1）什么需求需要需求评审
大型需求：需求功能多，一个人设计可能会考虑不周全，需要人帮忙补充完善，让产品设计尽量全面
方案不太确定的需求：产品经理对于方案有疑问，比如 不知道现在设计的方案在开发上是否可行、设计上是否可行、业务上是否可行；需要相关模块更有经验的人一起做决策
与其他部门 / 模块耦合较深：涉及其他部门 / 模块的业务，需要跟两方一起进行沟通商议
敏感需求：恩……这个只能说是自行体会了……不是每个公司每个产品都会有敏感需求，而且敏感的点可能也会不一样，可能是跟政府相关（比如 微博/抖音/快手/头条 等面临的整改要求）、可能是跟国家政策相关（比如 金融类产品？）、甚至是跟国外的政策相关（哈哈 比如我现在的公司…）、有的可能只是跟公司内部相关（比如，有些公司老板说的需求某种程度上也算敏感需求，哪怕是改个 icon 大家也要一起脑暴……）
（2）目的
确认需求的必要性；粗略地确认方案的可靠性 和 可行性。
（3）参与人
产品经理，主力开发，主力设计，其他和需求相关的、具有话语权的人
（4）准备内容
原型稿 / 着急的话，草稿也可以 / 牛逼的话，方案装脑子里，白板现画也可以
总之，需要有一个相对全面的方案。不需要对细节进行描述，但各种情况需要考虑到。
（5）会议内容
产品经理可能会需要说到这些内容：
开场白：简单说明组织这次讨论 / 会议的原因
需求背景：恩，这个一般情况下是需要说的，如果参会人员全部对于背景都非常了解了，也可以不说
需求目的：你做这个方案，是为了达到什么目的
需求内容：开始讲方案咯
抛出问题：具体描述组织这次会议的原因，及需要他人哪些支持
接下来就是，各种讨论咯……
2，产品评审
（1）什么需求需要进行产品评审
都需要，大需求大说，小需求小说。
（2）目的
让需求涉及到的所有成员，都能够全面的了解到这个需求的方案、流程、细节，并完全确定最终方案；开发的同事需要对需求进行评估，给出排期和工时；确定后续各方的工作内容；预知的风险点也需要暴露。
（3）参与人
产品经理，各执行开发，各执行设计，需求方（运营？业务方？等等），需求涉及到的协作方等。有些公司可能还会需要 leader 参会，这个就是看各个公司内部的协作方式咯……
（4）准备内容
PRD：主要是，需求列表、流程图、逻辑图。当然，如果逻辑比较简单的话，交互稿就够了
交互稿：必备
视觉稿：这个要是来不及的话，有多少看多少
（5）会议内容
产品经理可能会需要说到这些内容：
开场白：简单说明组织这次讨论 / 会议的原因
需求背景：绝大多数情况下，大部分开发是第一次听到这个需求，说明背景很有必要
需求目的：你做这个方案，是为了达到什么目的
需求内容：开始讲方案咯
确定方案：定下最终方案咯
确定协作：确定各个协作方做啥
给个 deadline：让各方给个 deadline 咯，要不怎么催进度
五，需求变动
如果是由于自己考虑不周到导致的需求变动，那就只能自己想办法了，请开发兄弟们多吃顿饭，反思一下为什么会导致这个问题，然后让自己下次不再犯错。
但是，如果说你是作为服务方，需要对接多个公司内部的『甲方』，当需求方频繁的变更需求，又该怎么处理呢？
其实，说出来的话，方法挺简单的。
1，产品评审通过后，不再允许修改方案；
2，如果需求方需要再修改方案，很简单：填张表，邮件发送给产品经理，抄送开发 leader 及各部门领导。
表内容需要包括：需求变更功能点，需求变更原因，需要重新开发的人力（几人天），需求变更人。
六，工具
总结一下我自己比较常用的工具：
滴答清单——日常工作梳理、管理、记录
为知笔记——个人知识库维护
confluence——产品文档、工作文档维护
JIRA——项目内容记录、追踪、迭代维护
Axure——PRD 工具
ZEN——脑图工具
1，滴答清单
滴答清单是我现在正在使用的，类似的 GTD 工具还有奇妙清单、todoist、Microsoft to-do、等，选择自己习惯的就好。
GTD 工具，能够归纳现在手头待做的事情，按顺序安排好你之后一周每一天的工作内容。
当工作内容太多了之后，就很容易就不知道做什么。每天花3分钟，排好今天需要工作的内容，工作效率就会高很多。并且，给任务设置好提醒时间，你也不容易漏掉重要的事情。

再有就是，可以根据项目或产品进行工作内容的整理，可以很清楚的知道，每个项目当前是什么进度，后续需要做什么。当你能够在视觉上区分各个项目/ 产品后，你的大脑里对于各个任务之间的关系和逻辑也就会更加清晰了。

再有就是，不知道大家的公司有没有需要写周报或者日报。是不是有时候不知道写什么？那是因为你从来没很好的记录你今天到底做了些什么。有了 GTD 工具，也很容易进行工作总结，能够很清晰的知道你这周做了些啥。回顾的时候，也会有成就感，感觉这周没白过。
2，为知笔记
这个没啥好说的了……笔记类的工具都差不多，关键是要找到合适自己的记录方式，并要坚持去维护。其实我身边有很多朋友做的比我好太多了。我就贴张图吧，大家看看就得。关键还是要自己去试去做。

3，confluence 和 JIRA
confluence 和 JIRA 是 Atlassian 这家公司出品的两个软件系统。
confluence 就是一个团队协作的文档管理软件，可以用于整理团队项目相关的所有文件内容。
类似于现在的在线文档协作平台，石墨啊、腾讯文档啊，N 个人可以同时对文档进行编辑。但是 confluence 的功能更加强大。
比如，有树形目录管理，对于结构复杂的迭代型文档是必须的功能了。
文档内还 可以@团队成员，并邮件通知到 ta。
文档内还可以直接链接到其他文档，被链接文档标题修改后，链接文字自动同步修改，省去了同步维护的时间。
权限管理也很强大，可以精确到某个子页面是否允许读或编辑。
跟邮箱绑定后，当你关注的文档有了修改还能通过邮件通知到你具体修改了哪些部分。
更关键的是，直接跟 JIRA 打通，链接到 JIRA 的某个单，当前单的状态也能够直接同步到 confluence 上。
这些都是非常实用并且能提高效率的功能。

JIRA 是一个需求管理、开发管理、项目管理的平台。功能强大到可怕，随你怎么用。目前我还没发现我想做但是它做不了的。
由于这个截图太难打马赛克了，所以我直接从网上下载了一些图，也能够说明 JIRA 的强大。

直接可以通过 Epic 来管理项目，每个 Epic 还能看到每个 Sprint 的迭代。基本每个迭代需要完成的内容都能一眼都看清楚。

还能根据自己团队的迭代方式建立迭代阶段，比如常见的是：需求池——交互设计——视觉设计——开发分配——开发中——测试——回归。有些团队可能在开发阶段会再进行一些细分，这个根据团队来就好。

还能很好的进行版本管理，哪些版本现在处于什么状态、共有多少个需求/bug、完成了多少、还剩多少，都能一眼看清楚。
Axure 和 ZEN 我就不说啦~ 都是大家都非常了解的软件了。
七，最后再多啰嗦几句
如果你问我现在的迭代啊、管理啊、是不是完全按照上面说的内容来的，我肯定要说：当然不是啊……有一些项目还是没有按照这个方式走的……
每个团队和产品所处的状态都不一样，以上的方法不是一定都要按照这些东西做或者说这些方法就是最好的。
比如，当团队一共就一个产品经理、一个设计、两个开发，并且坐的很近回头就能看到的情况，用这些方式效率可能就会太低了。像小团队协作，如果大家都是靠谱的人，每天一个10分钟内的站会基本就能摆脱 jira 的需求了。产品经理文档也不需要写这么复杂，需求点说清楚、关键时间点标清楚就够了。
之所以写这些是希望，如果你在团队协作或者迭代方面存在一些问题或者疑惑的时候，这篇文章能够给到你一些参考。
希望每个产品经理都能够跟团队配合的好好地、不要吵架，能很顺畅的一起把产品越做越好~
最后，谢谢大家的支持！（鞠躬~）