产品研发概览

在企业的生产实践中，产品研发往往处于组织中的关键的环节。好的产品研发流程能够有效提升团队工作效率、把控产品质量。

由于产品类型和组织架构的不同，产品研发的具体流程在不同公司间会存在差异，但大体会分为产品需求创建、产品设计、产品评审、技术评审、项目排期、开发上线、项目复盘几个核心阶段。

飞书项目的产品研发理念

飞书项目是字节跳动旗下一款面向大型产研团队的项目管理工具，基于飞书项目孕育的土壤——抖音的产品研发落地实践，飞书项目也沉淀打造了一系列强大的功能模块，来承载组织的项目管理理念。

1. 最好的流程会顺其自然融入工作

飞书项目认为产研项目管理工作本身就是流程的执行。最好的流程是顺其自然的融入工作，而不是靠项目经理的角色去催促项目进度。和其他项目管理产品相比，飞书项目最大的不同，就是流程。飞书项目希望辅助产研团队将完整的产品研发流程沉淀到系统中，让流程自然发生。

用Workflow完成关键流程管控

1. 重视关键流程节点的把控

除去对整个流程管理、项目管理足够的重视，飞书项目也很重视整个产品研发流程中关键节点的把控。在产研实践中，当有需求/项目是跨业务线联动、或者存在资源冲突需要多方协作时，飞书项目可以自动引入“综合评审”节点，用飞书项目的投票功能完成决策。

用投票完成关键节点的决策把控

1. 信息透明

在传统的产研工作中，每个角色会更多地沉浸于自己的工作，但飞书项目鼓励大家更多了解上下游信息，关注项目全貌。飞书项目与飞书消息高度集成。当一个项目发起时可以自动建群，加入关键角色成员。新成员被拉入时能够看到项目全部内容。项目的进度变化能够通过卡片推送到群内，在移动端也可以快速打开项目查看。

一键拉群 需求相关人高效沟通 群消息沉淀 秒懂上下文

1. 重视数据的价值

除了沉淀项目管理过程中的需求，飞书项目还提供数据完整沉淀之后的复盘能力，呈现为不同的视图。核心的需求和能力到底花多少时间才能面向客户、研发团队的吞吐速度、管理问题带来的阻塞，都可以通过飞书项目的度量能力实时分析发现问题。度量模块也是高配置的，每个客户可以根据团队情况定制指标。

用度量驱动正向反馈

1. 流程自动化，让工作发生在该发生的地方

飞书项目希望每一个产研流程中的角色都能够有最高的效率、最专注的投入。飞书项目能够快速对接代码托管平台，通过发送系统外信号，通知飞书项目，自动流转节点。这样的能力在系统中天然支持，可以有效减少低效沟通。

提升效率-自动化完成信息的流转

飞书项目产品研发全流程实践

通过流程标准化、定制化能力和不同的功能模块，产研团队可以在飞书项目中实现从产品需求立项到功能上线的全流程跟踪管理。

需求创建

在飞书项目中创建需求，并通过飞书项目不同的视图关注特定需求。

需求对齐

通过飞书项目固定每周开需求评审会，讨论BACKLOG里的待处理需求。

• 分析讨论需求的用户场景、大致的解决方案以及业务收益；
• 相关节点完成后，系统会通过机器人自动向飞书中发送通知，告知相关人员项目进展。

产品设计

撰写产品需求文档：产品设计阶段，负责需求的项目经理会根据需求评审会上讨论的目标进行产品方案设计，方案完成后，产品经理会将飞书文档的链接贴到飞书项目「需求文档」字段里，点击「完成节点」按钮进入下一步。

产品评审

固定时间统一进行产品评审：如果评审通过，相关人员需要填写评审纪要，然后完成节点进入到下一个流程；如果评审不通过，通过自动化配置，产品节点自动「回滚」，重新回到产品设计节点进行修改。

自动发送评审预告：对于需要进入评审的需求，在评审开始前自动往群内推送评审预告。

UI/UE设计、翻译文案、安全合规评估

流程裁剪：飞书项目支持根据实际落地需要，进行流程的节点裁剪。

对接多方业务系统形成流程闭环：飞书项目的开放能力支持与第三方的平台的联动，例如在合规评审节点，第三方平台的评估结果会自动回传到飞书项目流程中，无需再次人工操作填单。

技术评审

搭车制评估产品需求文档：PM召集技术负责人一起，对已进入评审环节的需求进行评估，评审遵循搭车制，即根据当前研发人力情况按照需求优先级确定哪些可以进入评审。在此过程中，技术Owner 也会撰写相应的技术文档，技术负责人则会最终判断是否需要引入QA测试。

自动发送评审预告：对于需要进入评审的需求，会在评审开始前，通过飞书项目的自动化能力，自动向飞书项目的相关群组推送评审预告。

估分排期

各研发小组根据团队安排进行排期：研发流程的第一步是各个研发小组对需求进行估分和排期。飞书项目支持使用子任务对大节点进行分拆。同时可以通过人员甘特图查看全部人员的排期情况。

开发阶段

开发--测试--验收--合码--上线：开发环节可实现在飞书项目中自动集成，在代码平台完成提交、合入等操作，节点会自动流转。通过这种方式，研发不用花时间在沟通与管理流程上，专注写代码就好，也可以查看上下游进展。开发完成会进入测试节点，测试过程中遇到的问题可以在飞书项目中分拆子任务，或直接飞书沟通。之后会进入验收及合码环节。

代码提交

• MR提交：RD提交MR，在创建页「关联需求」下拉列表中，选择通过评审的需求，以实现工单关联。
• 开发节点自动流转：通过系统外信号驱动开发节点自动流转完成，节点详情中自动展示关联的MR链接及进度状态。

代码合入

• MR合入：MR 所有Reviwers角色从飞书项目对应需求的QA角色自动同步，无需手动填写，点击OK准入后，MR 变为Merged状态。
• 上车节点自动流转：MR 合入后，需求上车节点即可自动流转完成。

封板上线

• 封板发车：根据项目流程设置定点自动封板，已合入MR随之被合入发布分支中。
• 发车节点自动流转：MR 所合入的版本封板后，需求封板后节点即可自动流转完成。

效益分析

在飞书项目中可以从两个角度来评估一个需求的长期效益：需求实现的数据表现和需求开发过程中核心人的主观评价。评估需求实现最常用的是 AB 实验，通过设计实验可以获得一些直观的用户数据作为需求的反馈，来评价需求实现的好坏；除了明确的收益数据信息以外，也会通过一些流程进程中内部参与人员的评估反馈，判断团队是否可以长期的稳定持续发展。

这两大评估理念目前都作为核心模块内置在了飞书项目中。

需求实验客观数据表现：通过AB实验定量分析，飞书项目可以与AB实验平台打通，数据自动同步。

核心参与人主观评价：核心参与人通过飞书项目评估相关字段的主观评价，找到影响产品/项目路径的关键需求，及单个需求是否符合预期值，方便对特殊需求快速筛选定位。

需求的上线并不代表着产研流程的结束，既有的流程也不是一成不变的，通过每一次的复盘和分析，产研团队才能在飞书项目中，不断推动产品研发流程的规范落地和持续优化。