编辑导语：由于每个互联网产品都有着一定的差异，所以每个团队的产品流程其实都大不相同，也没有一个完全的标准，但是大致上的研发流程还是有相似之处；本文作者分享了关于大型互联网产品流程，我们一起来看一下。

最近因为工作需要特意整理了产品的流程，其中基本覆盖了互联网产品的主要节点，由于这个偏通用型，所以并不能说这个就一定适用不同类型或者不同阶段的产品；尤其对于创业型或者敏捷型团队，其推进的流程是相对简单的。

这儿需要特意强调：不要迷恋流程！不要迷恋流程！不要迷恋流程！

当团队需要靠流程来约束的时候，团队战斗力和自驱力已经受损了，流程往往是一种多个角色妥协的结果，而且流程使用不好，对于团队杀伤力极大。

既然聊到流程，就多说几句个人的观点。

• 流程只是一个“约束”，是希望尽量让大家协同效率变高；但是不应该让团队成员用流程来反向约束或者挑战关联角色，不应该成为一种“制衡”或者“甩锅”的工具。
• 流程在使用中如果发现不对，当有“甩锅”的苗头，需要尽快调整。
• 业务在不同阶段、团队成员能力构成不同，产品流程可能差别很大。
• 如果大家的精力都在focus流程，那这个项目团队势必已经走偏了，可以预判业务没有“增长”。

如下流程将大部分关节节点都有体现，其中并不是强制约束，可能不同阶段的团队在部分节点上的处理方式会有不同。

我们来详细聊下这些节点：

一、BRD阶段

核心点就是“需求来源”，不同公司情况差别很大，很多产品的需求其实来自于老板，经常甩一句“xxx老板的需求”，这种需求基本上也就不存在BRD的说法了，需要对接需求的同学能相对清晰的理解需求。

大家往往容易忽视这个阶段的重要性，因为这个阶段其实需要收集到比较关键的信息，比如需求背景、价值、上线时间预期等，这些都是接下来会直接影响项目排期的。

大部分公司项目资源都是有限的，所以往往都会涉及到优先级的PK；如果前期收集的信息相对完整，在中间决策的时候，就不需要再往前回推找人确认这些信息。

二、产品规划

这个话题很大，需要通过单独的topic来聊。

有几个点需要注意：

• 产品规划体现的是对于需求输入和产品长期走向和资源现状的综合判断，是一种综合能力的体现。
• 产品规划的大忌就是看似很漂亮很牛逼，但是不接地气，落不了地。
• 规划是一种动态的行为，需要根据产品推进阶段和资源情况，以及市场环境变化或者组织结构的变化，而及时调整。

三、需求设计

即我们常说的需求文档输出——能否输出高质量的需求文档，也是体现产品经理能力的地方；需求文档的核心在于让开发和测试理解需求，通过这个文档可以按照产品经理的要求交付功能。

个人的风格更加倾向实用主义，也就是用相对清晰简洁的方式高效率的把文档输出，这个要基于对于开发、测试的理解能力的判断，以及相互的配合默契程度的把握。

首先确保大方向和逻辑不要跑偏，关键细节需要尽量完整，但并不一定是每个地方都需要特别精细特别完整。完整的背后就是时间和精力的投入。

产品交互和流程建立一些基础的规范，可以大大提升效率，这个需要日常的积累，构建规范，构建默契。

关于需求文档模板或者规范，这个还是很有必要的，至少可以减少产品内部或者研发对于需求文档理解的成本；但是这个模板不要太复杂，别规定的太细，可以先从粗后细；比如刚开始只需要明确需要包括：需求背景和目标、关键名词解释、核心流程图、用户量预期等（用户量预期，这个对于研发比较关键，他们会根据这个指标或者节奏来制定合理的技术方案）。

四、需求内部评审

这个阶段很有必要，尤其是一个初创或者还不是特别成熟的团队，通过资深的产品来review下需求设计，会避免后面很多问题；往往很多较为初级的产品经理容易受经验的限制造成设计的方案考虑不够完整，容易出现逻辑漏洞，或者方案扩展性不强。

但是如果配合默契的团队，并不需要单独有这个步骤，一般都会潜在的“导师制”，也就是初级的产品经理一般会在设计方案的时候会先和自己的“导师”先沟通对齐方案，然后再写文档，避免后续修改返工。

五、提测后的走查

只要产研配合顺畅，这个阶段一般是不需要的。

将这个节点列出来，只是在有些比较重要的产品功能或者逻辑比较复杂的功能，产品最好还是提前介入会好一些；这样可以及时发现问题，避免到后期因为人力或者工期或者沟通问题造成项目延期。

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

题图来自Unsplash，基于 CC0 协议