产品管理|产品驱动的跨部门协作流程

#文前小絮#感觉产品经理并不像他人眼中的神，也不能改变世界，或者说能不被这个世界改变就已经很NB了。产品汪、产品坑、产品SB…这些关键词大概能映射出两层含义：

1、在互联网行业这行，对产品经理的评价确实不高，值得思考：是不是产品这个圈子太浮躁？还是产品人的内心更加浮躁？

2、产品人乐观的，自嘲是一种态度。这一点是值得肯定的，但究竟是客观现实的无赖？还是产品人内心的一丝隐忧呢？

产品驱动的跨部门工作流程

有些产品人希望/乐于“闭门造车”，而不是到处“斗争“。需求来源于用户，最终回归于用户，这一来一回可谓是千山万水、扑朔迷离。产品扮演者衔接供给上下游的中间角色，充当需求的引路人，牵涉到的人员/部门自然也显得有些纷繁杂乱。因此，（互联网）产品更加需要规范化、专业化的工作流程以确保上下游环节的畅通无阻、持续推进。

---

正文

产品工作横跨多个部门和工种，需要不同部门之间的工作交互，分工协作。产品管理过程大致分为：需求管理、产品设计、技术研发、测试上线、反馈迭代，以产品工作内容为核心的跨部门协作大致分析如下。

阶段一：需求管理

1、需求方提出需求，需要以特定的提交单提交；

诠释：

a. 需求方包括，市场部、运营部、客服部、产品部等公司各个部门人员；

b. 《产品需求提交表格》由产品部统一提供模板；

c. 需求提交形式——口头沟通+邮件；

2、产品需求由产品部门统一管控、分发；

诠释：

a. 产品部对各个部门提交的需求进行统一管控，记录需求进展情况；

b. 《产品需求管控表》由产品部统一制定；

c. 以周或月为维度，定期向需求方反馈需求进展情况；

d. 需求上线当天，必须以邮件的形式告知需求方上线详情；

3、各部门指定专门的需求对接人，负责需求的沟通和协调；

诠释：

a. 各部门指定专门的需求对接人，统一负责需求的沟通和协调；

b. 需求提交周期，建议以周为单位固定时间，固定次数提交；

4、需求澄清，组织需求方、产品、技术部门等相关部门需求评审；

诠释：

a. 以邮件的形式发起需求评审会议；

b. 需求方、产品、技术部等相关部门参与产品需求评审会议；

5、产品部门给出产品排期时间；（时间节点：产品设计）

诠释：

a. 需求评审完后，产品需要给出产品排期，即什么时候完成需求设计提交技术部门；

b. 需求评审完后，技术部门需要给出产品需求技术的初步评估技术的可行性建议；

产品驱动的跨部门工作流程

阶段二：产品设计

1、完成《产品原型设计》和《产品需求文档》的编写。产品部发起组织需求方、技术、UI、测试进行产品原型和产品需求文档评审；

诠释：

a. 产品以邮件的形式，发起《产品原型》和《产品需求文档》的评审会议；

b. 与会人员：需求方、技术、产品、运营等需求相关部门；

c. 技术评估需求的技术实现排期和计划表；

2、UI效果图完成，UI发起评审，进入技术开发前的最后一次公开评审；

诠释：

a. UI美工以邮件形式发起UI效果图评审；

b. 明确给出产品需求的技术排期时间；以邮件形式反馈；

c. 如果微调，则直接修改后进入技术阶段；如果大幅修改，则需要再进行二次评审；甚至多次评审，直至进入技术阶段；

阶段三：技术阶段

1、产品技术阶段，产品追踪解答技术遇到的疑问；任何涉及到产品需求变更的环节，必须在产品需求文档中做记录并且持续更新文档；

诠释：

a. 持续更新《产品需求文档》，做好需求文档的版本控制；

b. 记录需求变动历史，并及时更新文档；

2、持续追踪技术部门的开发进展，确保实现的持续性，关键节点的验证；

诠释：

a. 持续跟进技术部门的技术实现进程，阶段式以邮件反馈进度情况；

b. 阶段式验收，确保项目进入的持续推进；

阶段四：测试阶段

1、测试部门依据产品需求文档（PRD），完成测试用例的评审；发起必要的测试用例评审，产品部门必须参加，确保测试用例的全场景覆盖；

诠释：参与测试部门发起的测试用例评审；

2、测试过程中反馈问题的追踪，主要是正对问题数量及问题方面的总体情况追踪，确保问题的及时解决，测试部门必须反馈当天的测试情况反馈表；

诠释：持续跟进技术部门的技术实现进程，阶段式以邮件反馈进度情况；

3、测试通过，上线前必须完成产品验收，产品产出产品功能清单，逐一产品验收，主要关注有无得问题；验收通过后，才能上线；（产品验收）

诠释：如实核对产品最初设计与技术实现之间的差异！

阶段五：问题反馈

1、产品上线后，各个部门需要针对上线或者生产环境发现或者用户反馈问题，做及时的反馈；该反馈直接反馈到测试部门，设计产品设计的需求，按流程又各部门需求对接人提交产品部门；（问题反馈）

2、进入正常的产品环节循环执行；（产品进入周期性迭代循环过程）

---

行文小结

以上所述的部门协作流程体现了产品经理在整个流程之中所需要担当的职责和需要完成核心工作。以产品经理的工作为轴心，衍生出与各部门之间的交互。有朋友问我：这么复杂的流程实用吗？显然，再质疑流程的可行性和价值型。口头沟通确实是最简单和直接的手段，却也是最没有保障和最不可靠的做法。当然，我并不是想表达对他人不信任的意思，而秉承的恰恰是一种对彼此负责的态度。

不忘初心，方得始终。问题还要回到：为什么需要产品工作流程？做这样一件事情的初衷是什么？

1、 产品管理过程结构化、模块化，分阶段推动产品进程，易于管理；

2、 规避项目风险，时间、空间要素构成了项目实施过程的潜在风险；

很显然，产品流程并不是为了规范上下游的同仁，恰恰是约束产品设计环节本身，是为了规范产品经理的工作。仔细想来，规范自己本质上是为了不给别人添麻烦，而这恰恰又是职场上最宝贵的信条——尊重别人的最好方式就是不给别人添麻烦。

很喜欢自己说的这句话：规范不是目的，只是手段！只有流程才能缔造优秀的产品，而优秀产品背后也必然对应一个规范的流程！

---

原创声明：本文章的最终解释权归产品小王所有，如需转载，请注明文章出处！谢谢...