在一个项目中，流程管理是最基础且有效的管理手段。通过审时度势的看待资源现状，从而确立最优化项目流程方法。在规避无用流程的同时，又能以宏观角度去把控整个项目运转效率。
在项目流程相对固化的今天，如何优化流程去辅助项目进行这一议题，成为了越来越多产品人考虑的关键所在。
流程管理是项目环节中所用到的一种管理方法，需要在项目开展前确定、在项目过程中遵守、在项目结束后优化。它的核心原则为：
遵循因地制宜，选择适合项目推动的流程；切勿本末倒置，流程管理只是项目落地的工具
为了梳理清楚流程管理的整体思维框架，便于宏观对其进行了解，于是汇总了相关的知识脉络，如下图所示：
前言
一般情况下，在我们日常工作中，会常见两种流程管理方法。除此以外，也还会出现依托于这两种之上的变形方法。但归根结底，只要使用的流程适合团队项目的开展，那么它就是好的流程。不是所有方法都能与项目情况所契合，所以这需要一个产品经理具有洞察本质并且善于变通的能力
不管项目流程如何进行，都无法降低需求评审的存在价值。这是一个让产品经理爱恨交织的会议：爱在可以舌战群雄实现自我价值，恨在如果思考不充分会演变成一场撕逼大战。但无论如何都可以确定的是，需求评审在一个项目中扮演至关重要的角色
1.流程分类
项目流程的种类有很多，但大致上分为两类：日常型和复杂型
1、复杂型
所谓复杂型项目流程，指的是项目从需求环节到开发周期直至上线，所经历的流程如下所示：
立项会议 → 需求评审 → 设计评审 → 测试评审 → 上线
在上述流程中，主要是通过4个评审会议去完成需求向功能的转变。其目的是通过多轮评审沟通，确保需求到功能的转化与预想一致
1.1 立项会议
顾名思义，立项会议的召开就标志着一个项目的成立。作为项目流程的第一步，它的作用主要是为了给各方领导讲解项目内容，让他们给把把关，顺带争取资源。在此过程中，最好可以鼓舞人心，点燃成员激情。需要介绍的内容为以下6个方面：
项目背景（用户需求场景）
项目意义、目的
需求内容
项目计划（项目整体规划）
项目节点（里程碑、上线等各个节点时间）
沟通计划（如何沟通，比如周例会、早会等）
在介绍完以后，我们还需要给本次项目确定一个有意义的“名字”，这样会让团队成员更有代入感和凝聚力
1.2 需求评审
这部分内容是整个项目的重中之重，所以会在后文中详细剖析
1.3 设计评审
设计评审主要是站在开发的角度，去评审功能如何实现等问题，把开发设计具象化。虽然大多数情况下，听不懂他们讲的实现原理都是些什么，但是可以借助设计评审去验证需求实现是否与目标一致
此举的目的是保证需求实现无歧义，以防开发过后才发现好多内容与预想大相径庭、更有甚者背道而驰。同时，可以在评审过程中，进一步完善需求评审时遗漏的瑕疵
在设计评审过后，就正式进入了开发阶段。后端开发人员会敲代码写接口，前端开发人员会根据已有的UI切图标注信息，去搭建页面的可视化显示内容
1.4 测试评审
最后一步主要是由测试人员讲解测试用例，在此环节，你就会惊叹于测试人员看待问题的全面性。他们可能会列出所有你没考虑过的细节问题、异常情况、边界状况等等。其实和设计评审也有异曲同工之妙，再次核实需求实现的是否与预想一致
在测试环节，常用的方法有：压力测试、性能测试、冒烟测试等。有这些检测方法为我们保驾护航，使得我们提供给用户的产品一定是安全可信赖的
测试流程一般为：开发完毕后先自测，测完没问题后会把代码从开发环境提交到测试环境。在测试环境中可以更直观的发现问题所在，测试人员不断的发现BUG并提交给相对应的开发人员去解决，这可能会是一个相对漫长的过程
当然，如果没有严重问题且时间紧急的情况下，也允许带着小问题上线。因为好多问题都是无关痛痒的边缘内容，而且相较延期可能错过的机会，BUG的存在就相对无足轻重了
2、日常型
相较复杂型流程而言，日常型更注重的是快速迭代、化繁为简的工作流程。事实上，流程只是辅助完成工作的方向标，所以面对日常敏捷型迭代或者开发，可能就不会用到上面那种厚重繁琐的流程了
这种流程的缺点就是可能开发完成后才发现问
