公司往往有不同的工作安排。有些公司流程比较精细化，而像笔者目前这家公司，则偏向以结果为导向，具体内容自行安排。于是有了这篇文章，来总结自己的部分工作流程。

当前公司里，产品经理在产品上线前的工作流程分为五个阶段：

1. 立项：什么事？
2. 需求：做哪些？
3. 设计：怎么做？
4. 开发：做到哪步了？
5. 验收：做成什么样？

一、立项

公司流程：由高层发起会议，给各部门负责人讲解项目起因、市场情况和商业目标，由各方负责人进行评估和讨论。

由于部门原因，笔者往往当天或者前一天才得知会议，对项目本身处于一脸蒙的情况，只能在会议期间整理基本信息。高层之间的信息讨论往往较为散乱，因此会按照下图所示的分类进行逐个整理。

立项会议结束后，领导基本会留下一句“熟悉下项目，或者相关产品”后，直至具体任务下达前，会有一段2天左右的空白期。这段期间笔者会根据之前整理的会议信息进行“桌面研究”——在网上寻找项目相关内容。

桌面研究

在“桌面研究”中，尤其针对2B的产品，往往有以下三个难点：

1. 信息量多且杂，全面收集极为困难；搜索渠道是否足够、信息是否有用以及信息是否准确；
2. 信息提炼和整合费时费力：大量的信息堆积起来，需要筛选、提炼和归纳整合；
3. 2B的产品很难接触到，往往需要提交信息进行申请，等待产品所属公司经过一系列的审核（查看访问ip、天眼查公司信息以及电话沟通）。即使拿到试用账号后，里面的功能也都是阉割版。

因此可以尝试按照以下流程进行：

（1）明确目的

• 将“立项会议信息整理”细化成若干个问题，即可作为目的。例如：项目涉及哪些业务？业务的目前发展情况？业务涉及的企业机构构成如何？
• 类似的项目解决方案有哪些？项目的落地场景是什么？有哪些公司参与进来，怎么推行的？
• 市面上有哪些相关产品？面对的用户群体是哪些？相关公司重点宣传了他们产品的哪些功能及解决了哪些业务需求？产品如何收费的？

（2）确定渠道

常用的信息渠道有：

• 研报渠道：艾瑞、易观、发现报告以及一些垂直行业论坛网站；
• 媒体渠道：常见的媒体新闻网站、搜狗微信搜索（搜索订阅号的相关文章）；
• 官方渠道：官方网站、微信公众号；
• 其他来源：百度、谷歌和天眼查（里面的竞品信息）等。

（3）信息挖掘

根据自己对项目及业务的熟悉程度，基于上述渠道逐个查询并记录相关内容；

（4）筛选整理

对于所挖掘的信息，按照最初的目的进行划分整理到文档里。有时间或者精力的话，可以对信息分门别类进行提炼（这步如果没时间做，会留至竞品分析时进行）。

（5）输出文档

无论领导有没有要求，都需要做成简略的PPT或者pdf报告文档，给领导查阅。有必要的话，说明自己对项目的理解，这一步的目的在于：

• 所整理的信息内容是否正确；
• 对项目的理解是否和领导保持一致；
• 收集领导的建议和想法。

和领导沟通后，即可适当修改，作为自己进行后续工作的一个参考基准，并进入“需求”环节。

二、需求

公司流程：公司开始安排产品经理和其他同事完成用户调研、竞品分析和搭建需求池。

用户调研

首先说一下用户调研，公司产品基本为银行机构人员服务，因此用户调研往往以登门拜访为主。由于各家机构的地理位置不一样，所以由和客户打交道较多的市场人员在1-2周内分别拜访不同的机构。作为产品经理，一方面需要准备完整的调研方案，另一方面要和市场人员沟通，让他们知道“项目要做什么”以及“调研方案写的是什么”。

关于调研方案，笔者常用的格式如下：

调研方案评审通过后，立刻召开会议，根据需要讲解的内容，结合具体场景给相关同事讲解，最后由领导推动调研的完成。而在同事调研的过程中，笔者则需要进行竞品分析。关于B端产品的竞品分析，难度较大，原因在上述的“桌面分析”里提到。除了“桌面分析”里的渠道外，笔者其他的方法有：

1. 自己申请或者利用公司其他资源来获得相关产品的试用账号体验“阉割版”；
2. 查找相关的使用手册或者操作视频。有些官网就可以找到，有些则需要去公众号或者论坛等平台，查看官方号发布的相关文章。

至于竞品分析怎么写，这里不再赘述，网上相关文章很多。需要强调的一点是，竞品分析一定是抱着某些问题来分析，并最终得到了有效的解答以支撑后续的产品设计，例如：需求验证、业务流程梳理、寻找市场方向或者功能交互设计。

需求池

在完成对调研结果和竞品的分析后，可分析整理出初步的需求，常见的需求来源如下所示：

需求池可用excel初步整理，笔者格式如下：

优先级：一般用于衡量需求的开发优先程度，常见的方式是用类似kano法等方法来定性分级，也可以基于不同维度来定量分析。这里介绍一下2种定量分析的方法可供参考：

（1）笔者公司产品以用户需求为导向，在基础版上会根据不同机构要求进行定制开发，因此需求优先级会根据带来的收益情况分级，例如影响因素有：客户需求数、客户重要性、客户付费情况以及开发成本。

优先级 = （需求数*重要性*付费情况）/开发成本”

其中需求数为真实数量，重要性通过“客户分级”量化（关于客户分级，先埋个坑，日后再填），付费情况根据需求客户的实际付费情况量化，开发成本用总天数量化。

（2）只从功能本身进行考虑时，影响因素有：符合迭代目标程度、客户数量、体验提高、性能优化、开发成本； 根据阶段目标赋予每个正面因素不同的权重，例如50%、20%、15%、15%；对单个需求，进行不同因素的评分（1-10）

优先级 = （迭代目标分*50% + 客户数量分*20% + 性能优化分*15% + 体验提高分*15%）/开发成本。

• 需求类别：界面、功能以及数据等
• 需求描述：一句话描述需求
• 场景描述：一句话描述需求的来源场景
• 需求来源：见需求来源图

需求池里一些地方可以留空，等待评审后确认和填写。

输出需求池后，即可进行评审，和相关领导同事逐个确认，基于风险、难点和资源等方面讨论，完善表格内容，并确定下来。理论上这一步的时候即可封闭需求池（想的很美好，实际上，开发过程中甚至开发结束时都存在甲方临时改需求的情况），进入下一阶段“设计”。

三、设计

公司流程：项目负责人要求产品经理输出prd文档及原型图。

到了这一环节，需要根据需求池，整理产品信息结构和业务流程，输出原型图和Prd文档。

原型图

笔者常输出高保真原型图，因为可以在企业机构演示、给高层领导讲解和给内部同事描述上起到试错的作用，作为早期的可行性验证，进而优化。如果不进行这一步，很有可能导致最终方案偏离用户实际需求（关于这点，笔者在某个项目里被坑惨了，埋个坑，之后复盘项目时填上），一旦偏离，后续弥补代价极高。

PRD 文档

关于PRD文档，是用于给设计师、工程师及测试对照实现的重要文档，包括但不限于：

• 修订历史：记录版本变更，便于追溯修改与管理；
• 信息结构图：用于梳理产品每个模块的功能架构，使用脑图完成；
• 业务流程图：用于梳理每个业务的闭环、输入及输出，可用流程图或者泳道图完成；
• 功能描述与逻辑：描述功能作用和内在运行逻辑；
• 功能边界条件：描述功能的各类边界情况，进行条件约束；
• 数据埋点：描述埋点触发、事件名称和ID；
• 功能交互：描述交互逻辑；
• 性能要求：平台系统的各类功能性能预期。

Prd文档是整个项目开发过程中的参考文档，因此需要详细记录更迭情况，并且通知到所有人。会进行不断的更新迭代，需要由产品经理严格把控，避免出现多个岗位对需求认知不一致的情况。

四、开发

公司流程：协同UI、开发、测试同事推动项目产品的展开。

在进入开发阶段后，产品经理主要负责开发工作的协同与产品的迭代规划。

工作协同

具体的协同内容有：

• 配合UI完成页面设计和功能交互，产品经理以辅助评审为主，相信设计师的专业性；
• 解答来自开发同事的各类问题，配合Prd文档并结合业务场景，让开发们知道你想要什么；
• 配合测试同事输出测试用例。

协同期间，会接到来自各个岗位的问题。不要指望各类会议和Prd文档能够让同事们的思维和自己保持一致，因为岗位的不同，对于业务和功能逻辑的理解也会不同，甚至他们会发现一些笔者没注意的问题。

产品经理需要随时及时的解答各方疑惑，并跟进各个需求。同时，可以建立一份Q&A表，避免同事们的反复提问。如果该过程中发现任何细节问题，需要及时与各负责人沟通，如果影响到项目的排期更需要告知项目经理。

版本规划

由于某些产品会保持小版本的快速迭代，因此产品经理需要在上一批优先级高的需求进入开发周期后开始考虑下一个小版本的迭代内容，而需求来源于需求池里没有划入本次开发的各类需求。

五、验收

公司流程：测试人员根据测试用例测试完毕后，由产品经理验收。

验收标准即产品正常使用无严重的bug问题，各类功能按照需求文档实现。完成验收后，产品经理则需要制作产品使用手册、操作视频以及宣传视频，同时给内部员工进行产品培训，让市场和运营同事学习使用产品。

如果对于培训材料没有严格的要求，可以像笔者一样，使用手册用word找模板写，最后输出pdf版。视频先用excel写视频脚本，之后用Ae制作，Au录音，Pr剪辑。

最后对各类资料归档，如果是外部项目，把产品和资料交付甲方并进行培训。如果是内部项目则交付运营市场团队。

结语

上述的流程会因为公司的不同而有所差异，但最重要的一点“沟通”是不变的：

• 和外部需求方沟通，保证项目的方向和需求方的要求一致；
• 和内部各职能的负责人沟通，保证项目的协调统一，共同推进；
• 和领导层沟通，让领导知道项目的进度情况、所遇问题和解决情况；

而每个阶段的输出文档作为沟通的材料，不用拘泥于形式，保证效率和理解即可。也欢迎大佬们指出本文的不足之处，提出自己的见解。

本文由 @jojo_saw 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议