谈谈大型互联网产品流程

七月和产品 2023-07-28 03:18:43

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

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

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

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

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

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

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

一、BRD阶段

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

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

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

二、产品规划

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

有几个点需要注意：

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

三、需求设计

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

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

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

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

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