产品管理流程思考：互联网产品流程的碎片化

产品管理流程思考：互联网产品流程的碎片化，【无流程】是一个现实问题，或者说是一种趋势。请记住：在那之前，你还有团队、公司…

什么使得一款产品从0到1？

不同人而言，有不一样的理解和笃定。如是说来，兴致万分，十分有趣。人们通常是先相信某种东西，而后再去找证据来证实自己的观点。

有人觉得，技术水平是一款产品的基础条件；

有人相信，资金能力是一款产品的必要前提；

有人坚持，沟通技巧是一款产品的实现助力；

有人认为，人是一款产品的核心要素；

很多人，很多认为…

显然，我是无法反驳上诉的任何一条观点的，难道说技术、资金、沟通、人对软件毫无裨益？然而，是否有维系全部产品要素的纽带存在？

我相信，一定是存在的并且为大多数人所知。做产品以来，一直有人问我，你觉得对产品而言，最重要的是什么？坦白讲，我的内心是抗拒的，产品本身就是一个复杂的综合体不仅得益于源于一个复杂的过程，不论如何回答都无法达到一个平衡。

一、定义产品流程

产品管理流程（Product Design Process）简称PDP，特别不喜欢使用【项目管理】这个词，平时的工作中我很少提及，因为我觉得项目管理倾向于专注项目本身，过分强调关键节点，轮廓很清晰。愚认为产品管理是完全覆盖项目的管理的，并且用于项目管理所不具备的优良特质，产品管理是一个价值导向、有温度的过程，不是锱铢必较，不是须臾推诿，不是闭门造车…

1、瀑布模型

经典的软件工程提倡采用线性的工作流方式，应用范围最广、最有名气的莫过于——瀑布模型（waterfall model ），又被成为经典生命周期（classic life cycle）。

瀑布模型提出的是一个系统的、顺序的的软件开发方法，从用户的需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

是不是是曾相识？好像在哪见过？是的，该方法到目前未知，还有很多公司在遵循，暂且忽略一些弊端，该模型真的是经典之最，没有之一。

由于现实的压迫，实际的项目很少严格遵循瀑布模型的顺序，因而后期对该模型做了不少改变，比如V模型、增量模型、原型开发模型。一些比较前卫的互联网公司，大多采用了【增量过程模型】持续交付，各个公司依据自己公司的实际情况可能存在细节上的差异，但总体的思想是别无二致的。

2、SCRUM

现代软件又提出了一个用于开发和维持复杂产品的框架 ——SCRUM，是一个增量的、迭代的开发过程。SCRUM的五个价值观：

承诺 – 愿意对目标做出承诺专注– 把你的心思和能力都用到你承诺的工作上去开放– Scrum 把项目中的一切开放给每个人看尊重– 每个人都有他独特的背景和经验勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

如果你对SCRUM有所了解，其实就能知道SCRUM的两个重要观点：敏捷开发、XP编程，让其看起来更像是一个偏向于软件开发的概念。

我认为，事实上确实是如此的，将开发人员前置需求、过程化是一个很有先见的做法。

当然，现实终究是相对比较骨感的，对人员素质和团队结构的要求都近乎严苛，而现在公司的人员简直就是流水般顺滑，因而采用SCRUM的产品管理理念的团队知之甚少。

二、回顾经典产品流程

古语有云：不以规矩，不成方圆。如果说没有一个相对范式的产品流程，那么0到1的产品过程必然是不可言喻的，而其中的关系人更是苦不堪言、无意言表。或许这正是大多数产品死在路上的重要原因，大多数技术人员对产品人员印象很差的最初来源。

下述流程是一个经典的【瀑布模型+增量模型】的复合流程，其有两个关键要点：一是流程的线性，二是执行的交叉。之前我已经在《产品经理必修课之产品设计流程[完整版]》一文中做了详细说明，下面将概述关键要点，不再赘述：

1、顶层设计需求分析：沟通、理解情境研究：需求调研的过程，包括：用户研究、调研，竞品分析等；需求管理：项目管理技巧；2、概要设计需求建模功能建模流程设计原型设计：很多产品经理只对这个感兴趣，并且占据了TA们的大多数工作时间；信息架构：信息架构（IA）是设计信息的组织结构；视觉设计：UI协同完成；3、技术追踪项目追踪：产品实现进程的管控，确保产品的按时按量上线；产品验收：不论理念还是业务逻辑设计上都是需要产品去把控的；4、回归迭代实现偏差：技术实施过程中，必然有些需求因为现实的局限性被耽搁或者简化实现，那么上线后第一时间需要给出小幅优化的迭代完成之前研发阶段的历史遗留问题；反馈迭代：问题反馈通道建设对于一款新产品迭代优化初期显得尤为重要，对产品快速增量式迭代及改善用户体验的重要都是不可估量的；

产品设计流程将整条产品线上的人员都串联起来，将产品过程“数据流”化，可谓气贯长虹、如梦般丝滑。产品流程将产品从各个原本独立的实施过程聚合成一个统一的变现行为。

三、反思产品流程

这几年的产品经历，确实是属于自己的幸运——远胜于毕业之初进入BAT的机会，如果说没有最初的时光，我想可能不会有今天的这篇文章，而我也不知道自己在哪做着什么？甚至，也就少了一个产品经理与你们淌这趟“浑水”了…

最早接触产品那会，对系统性流程性的概念没有太多意识，只是停留在概念上的印象。更加清楚地说，关注节点因为自己就处在一个节点上，并且属于内部节点，还不是外部链条关键环节。该阶段关注的点，还不是宏观的流程和协作，搞好自己的一亩三分地，仅此而已。内部的衔接，上下游的通畅是照进实际产品工作的最大限度。后期深入产品过程，逐步开始迫使我建立提点到线的产品过程，脑海中的概念越发的清晰可见。由于手头接触的产品工作，以及工作职责的增加，贯穿流程、跨部门的协作日益明显，不得不跳出眼前的局限，将目光投向其他貌似毫不相干的关联。规则约束彼此，推动事情的前进，如果没有彼此的契约精神，现实总是比你想象的难以承受，甚至直至崩溃…如今逃离产品禁锢，开始意识到本没有什么一层不变的产品流程，一个似乎更加贴近大多数人的意识想法。而我有一点与TA们不太一样，不喜欢吐槽，喜欢做一些尝试直至些许改变。之前建立的线性和增量式过程管理遭遇的滑铁卢，新的环境显得格格不入破碎了一地。俯下身，拾掇起来，因为我深信有些是不会变的，只是打开的方式和顺序出了差错。

产品驱动的团队，产品的需求范围由产品经理敲定，而一个技术驱动的团队，产品的需求版本完全依据技术的资源/能力进行削减，既定的产品规则被肢解，很是无可奈何，任花落去。就这样认命呢？这可不是一个产品人该秉持的态度，拾起来…

无流程的尴尬并不是产品经理面对的问题，大部分团队/公司都经历着同样的煎熬，想要流程却又碍于现实，没有流程又只能走向OUT。既有的产品流程又无法满足团队的期待，那么该做些什么？于我个人而言，是经历过这样的尴尬和阵痛的，试探性的调整了产品管理流程，终究得出一个新的尝试：碎片化的产品流程。

名词解释：碎片化，Fragmentation；去中心化，Decentralization

碎片化的产品流程提出了两个关键的理念：碎片化、去中心化，也是个人这几点对产品的概念从建立到打碎到重新建立的过程。

关键点一：碎片化

产品设计的遵循一定的范式，比如：需求管理、需求文档、原型设计、UI设计等等，无论跨入一个怎样的团队，与怎样的同事协作，这些要素都是相对不可或缺的，是产品经理最基本的输出。

然而，各自的表达方式存在明显的差异，这样的差异体现在时间和空间之上。

举个栗子，产品需求文档（PRD）的输出形式存在多样的形式，有专业的文档、有直接原型标注、甚至有直接以交流代替文档的…

因而，所属的产品流程需要被打碎，在恰当的时间、恰当的方式重新组合，甚至会做一些自适应的调整和优化，这就是所谓的碎片化。

关键点二：去中心化

传统环境下，一个公司/组织都是围绕一定的信仰/中心去运转的，互联网类的公司也无法幸免。大致分业务驱动、运营驱动、产品驱动、技术驱动，各种公司格局都是由公司所处的成长阶段决定的，而不同的格局也注定公司走向何方和做多远。

上述的经典的产品流程可以认为是产品驱动的格局下的顺序流程，很明显产品处于一个中心的位置，一切都围绕产品展开。

对于一个产品经理而言，这样的格局不可能一层不变，升职、跳槽都面临着角色的转变，因而打破中心化的概念，尝试多中心的理念，将不同产品碎片置于不同的场景之下，相信你会有不一样的收获。

行文小结

最后，我还是想问：为什么需要产品流程？本质上而言，产品流程是一套人为制定的规则。这套规则的存在并不是要求人们去严格的遵循和信奉，而是对过程的督促，最终的目的都是为了解决问题。

如果说，产品流程阻碍了问题的解决，请果断重构TA；

如果说，产品流程破坏了团队的节奏，请立刻改变TA；

如果说，产品流程影响了你的心情，请暂时忘记TA；

如果说…

或许正如所遇见的那样，【无流程】是一个现实问题，或者说是一种趋势。请记住：在那之前，你还有团队、公司…

我相信：不给别人添麻烦，是对别人最好的尊重！