在新公司也有近一个月了，基础的流程也都跑过一遍了，包括需求评审、方案评审、设计、开发、测试、上线等环节，也产生了一些零散的想法，其中有一些是关于工作流程优化方面的。

刚好本周的时候我们业务线开了两次比较重要的会议，其中一个就是涉及到工作流程优化的，本文就结合我们内部最后达成的一些共识，简单的写一下个人关于需求到开发上线整个流程的一些想法。

背景和目的

先简单的说下整个事件的背景，我所在的部门是公司今年新开的业务线，公司比较重视，给予了各种资源上的扶持，同时目标也是比较明确和比较高的。

之前的团队协作形式是属于跨部门合作型的，按照产品团队、运营团队、技术团队这种职能型的维度来划分的，有需求之后就采用项目制的形式临时组队，即A产品+B运营+C技术+D设计，项目完成之后，团队解散，后续再重组。

随着业务的发展，团队开始重新搭建，成员开始逐渐稳定起来，这样就出现了团队成员部门线和职能线交叉的情况，两边的工作还可能会冲突，所以团队协作效率并不是最高效的。

现在的情况是产品方案、设计稿的排期通常都会比较紧张，开发资源的利用效率未能达到最大化，各环节之间的衔接不是特别紧密，容易断链，会出现一段时间内开发资源紧张，另一段时间内开发资源却又闲置着的情况。

为了解决以上的这些问题，我们产品团队的几个小伙伴和Team Leader一起重新梳理了内部的工作流程，希望能够提高整体的协作效率，达到每2周发布一个版本的迭代速度。

理想中的流程是用户研究》需求分析》竞品分析》产品设计》UI设计》开发》测试》发布上线》数据分析》优化迭代，然而实际上前2-3个步骤很有可能是没有的…很有可能是XX产品有了，所以我们也要有，或者说XX觉得要有个XX功能，于是乎…你们懂的。

下面就会议上讨论的流程简单的说明一下，算是属于比较通用和常规的流程，另外文末会放置在其他地方看到的几个产品研发流程，仅供参考，可以对比着来看。

需求流程

这个流程如果去细分的话，又会分为需求收集、需求过滤、需求挖掘、需求评审等环节，每个单独的子流程就是一门很大的学问，故本文不再展开。宽泛的说的话，需求流程就是指开发正式介入之前的流程，包含需求阶段、原型阶段、设计阶段等…

本文中提到的需求流程为后者，即正式进入开发之前的流程。此外，不同公司针对需求阶段的划分标准也是不同的，没有一个严格的区分标准，所以不同团队之前的划分也会有些不同。

针对需求阶段，我们的Team leader给我们提了以下几个要求：

• 产品路线图要提前1个季度规划好；

• 月初明确当月需要上线的功能；

• 没想不清楚的需求不做；

• 拿不准的方案做灰度；

• 上线前有预期，上线后有对比。

其中需求可能来源于用户、竞品、团队、数据等，在明确了需求之后是需求的过滤和优先级排序（公众号Tab的【用户研究】里面的文章有详细写过，不再赘述），最后才是方案的产出。

需求阶段的主要产出物为产品方案、设计稿，其中产品方案可能包括流程图、原型图、PRD文档等，我个人的习惯是先手绘原型，初步的方案定下来之后（包括需求方确认、技术可行性确认），再用软件画出来。

这样做的好处一方面是将思考和绘制的流程分开了，在特定的阶段只做特定的事，效率会更高一些，另一方面是能够尽早将方案进行确认，避免自己产生了理解偏差，导致在需求的道路上越走越远。

排期流程

目前在公司内部，排期是一个非常尴尬的事情，因为我们内部客户端和服务端的排期是分开的，所以就会出现服务端排期排上了，客户端没排上，或者客户端排期排上了，服务端没排上的尴尬局面。还有可能是是客户端开发完了，服务端没开发完，或者服务端开发完了，客户端没有开发完…

有了团队独立的开发资源之后，就无需再担心这个事情了，提前和开发确认好方案可行性，之后再约个特定的时间一起过需求就好。我们确定下来的形式是服务端先行，即优先进行服务端的排期，然后根据服务端的排期情况再来进行客户端的排期。

作为一个非技术出生的产品汪，技术排期的时候就会比较尴尬，因为本身不懂技术，所以不清楚需求实现的难易程度和所需工作量，而有的程序员也确实不是很好沟通。那怎么办？先打成一片再说吧，不停的请吃饭、请吃饭、请吃饭…

虽然产品不懂技术，但是产品有一个非常大的优势就是全局视角，而程序员基本上都是负责其中的某一小块，这中间有着很大的信息不对称性。如果你能对绝大多数的业务都很熟悉的话，就有希望利用你的专业能力为自己加分了，一旦建立起信任之后，后续工作的展开就相对方便一些了 …

如果你的项目经验比较丰富的话，可以根据以往的项目经验来粗略的预估开发周期，比如一个表单填写的页面要多久，一个简单的增删查改需要多久等等。如果你经验不足的话，就先和某一个程序员走的近一些，在需求评审的时候拉上他一起帮忙评估下。

还有一种情况就是让技术的leader来进行工作量的预估，资源的协调，和后期具体的工期安排，然后自己跟进技术leader就OK。

实在没辙了，就拉上参与项目的几个程序员一起评估，先把某个功能模块的开发量作为1，达成共识后，让大家从1-10里面分别写一个数字作为另外一个功能模块的预估开发量，最后看众人的结果差异是否较大，然后根据结果再来进行后续的安排。

我一般都是让程序员自己估时间，然后定期去跟进，虽然有时候也会被队友坑，但毕竟是少数，人与人之间的信任还是存在的。

开发流程

开发流程主要涉及的就是项目管理这一块，一般而言，大多数的项目都会延期…延期的原因会有很多，比如难度预估不足、人员请假、某些资源没有按时到位等等。

而开发上报上来的进度也很有可能是不准的，所以不要对项目进度太过乐观，每一点点的不确定因素都将转化为项目的风险，最终导致项目无法按时上线，甚至是失败。

在开发流程中非常忌讳的另外一点就是需求变更，对开发影响可能会非常大，一方面会影响项目的进度，另一方面也会影响团队成员的士气。

所以我们要求需求要闭环，即需求一旦进入开发期之后，尽量不进行需求的变更，不是很紧急的调整放到下一个版本进行迭代，不然调整起来需求会没有尽头的。

关于开发跟进的制度，我们是以晨会+周会的形式。晨会是每天利用早上几分钟的时间进行站会，主要是说明昨天做了什么事情，今天打算做什么事情，当前有没有遇到什么问题，需要什么资源等。周会主要就是本周的总结和下周的一些待办事项…

一旦进入开发阶段，我们就会进行下一个版本的功能规划，在功能进入测试阶段之后，我们就会和开发过下一个版本的需求，一方面希望功能的开发能够持续交叉着进行，另一方面希望能够让开发了解之后的版本规划，大致清楚接下来什么时间点需要做一些什么事。

测试流程

测试阶段和开发阶段有一部分是并行的，首先是测试用例的编写，其次是用例的评审，之后是开发的用例自测，完成这些步骤后会提交给产品进行初步的验收，产品觉得主要的功能和逻辑没问题的话，才会进入测试阶段。

我们的测试主要包括UI测试和功能性测试，此外还有开发调整之后的回归测试，都通过之后，最后才是产品的验收测试。

发布流程

暂时没有接触到，和我们业务线没有关联，有单独的部门在负责…

优化迭代

这里就对应着需求阶段里的上线前有预期，上线后有对比，对比主要指的是数据上的对比。

方案类型大致可分为3类，分别是新增功能、功能优化、砍掉功能，这些改动都会反应在产品的数据上，比如功能的使用人数、使用次数、人均使用次数、使用时长、DAU百分比等等。

功能上线之前需要对功能的效果有一些初步的预期，然后再根据上线后的数据反馈来确定功能的调整是否合理，最后根据功能的数据效果再来确定后期的优化迭代方案。

以上就是我们内部会议上梳理的一些工作流程，本来是打算绘制一个流程图详细说明一下的，转念一想，说太详细了反而不太好。

最后

附3张之前在网上公开内容上看到的产品研发管理流程图，大家可以仔细研究一下，作者分别是Blues、苏杰、佚名…

这张是兰大在公开课上分享的他们内部的产品研发流程：

素材来源于互联网

这张是苏大在自己博客上贴出来的一张流程图：

素材来源于互联网

最后这张是在网上看到的一张流程图，已经忘记了出处是哪里的了：

素材来源于互联网

我在文章的引言部分说，我们本周开了两次重要的会议，一次是这个内部产品研发流程的重新梳理，还有一个重要会议是老大神秘兮兮的把我们拉到大会议室进行的，核心的主题只有一个，那就是：

我们开始996吧，不然OKR完不成了。

所以，在接下来的哪一天万一你们没有看到主页君更新文章，不要方，他可能最近班加的有点多，想偷懒了。那你们就要去留言督促他多写点干货出来了…

以上，就是本文的主要内容，欢迎斧正、指点、拍砖…