我是怎样在美团点评做App需求迭代的

一、一人一个团队时期

我加入大众点评的时候，我所在的事业部刚刚分拆出App的业务线，刚好我是这个事业部的第一个iOS开发。所以当时的情况是一个人一个团队，而且只在点评这一款App上开发，版本迭代的节奏基本上就是我自己的开发节奏，因为只有一个人，PM们对我充满了无尽的respect和dependency。那时候很累，我基本上很少晚上9点之前下班，周末很少双休，而所有的这一切都是自愿的，尽管没有调休没有加班工资，所以，虽然累，但自己还是乐在其中，尤其那种被PM、QA包围的感觉，满满的存在感。

二、第一次制定App开发流程规范

点评App的每个版本的计划，什么时候开始，什么时候结束提交App Store，没有规律可循。有时是个大版本，时间就长一点，我们业务就可以多做一些需求，赶上小版本时，没办法，砍需求吧。后来，随着业务不断的扩展，人数不断的变化和增加，而iOS团队和Android团队，也慢慢变大（3～5人）。之前我一直觉得新兴业务，业务变更很正常，要知道我在第一家公司时，有一半的需求做了就压根没上，所以我对PM大多持“放水”的态度。令人头痛的是，随着PM团队的变化，不同的PM，不同的需求风格，需求变更变得更加频繁与肆无忌惮。有时候需求评审时，PRD不再是我想要的样子，草草的文字描述或者简单的截图就想让RD干活；而后端团队对于APP的计划时间点也并不是那么敏感，接口进度常常会delay我们开发；因为这种环境下做出的产品，业务逻辑充满了模糊和不确定，下游的QA团队对我们的抱怨越来越强烈；在这种背景之下，我深深体会到，是时候需要将PM、RD、后端、QA、设计等团队拉到一起聊一聊了。经过各方的一番“激烈”争论，最终我们形成了一套针对我们业务的移动开发流程规范，明确了在什么时间点，各方该做什么事，具体如下：



 这个规范的最终形成，并不顺利，经过一次改版最终形成。其中针对PM的需求变成，我们还另外制定了一套需求变更流程规范，为了让这个需求变更规范发挥它的作用，特此让团队大老板拍板同意，最终执行。

三、美团App和点评App双平台作战

第一次制订出流程规范后，App的需求开始步入正轨，我们经过几个版本的迭代之后，生活的“幸福指数”不断攀升。然而，好景并不长，美团点评合并之后，业务的不断调整和变化，最终我们业务需要同时维护开发点评App和美团App，进行双平台作战，而且此时PM也换了一拨。要知道，美团App的移动迭代大流程以及版本计划，和点评完全独立，我们试图用之前点评的流程去同时开发双平台，发现不断产生迭代混乱，暴露了问题也越来越多：

（1）PM想做一个需求，点评和美团双平台都要做，PM该何时提需求？该怎么提？是点评提一次，美团再提一次？

（2）而且双平台同时迭代，开发一下子会开发很多需求，到QA介入环节，往往只有几天，测试资源显得十分紧缺；

（3）我们业务刚起步，PM收集需求时，需求本身也具有一定的模糊性和不确定性，有时是业务老大们拍板必须要尽快上线的，有时突然来自第三方必须跟最新的版本上线，而最新的版本需求评审已经过去了。意味着，我们需要给PM的需求留有一定的空间；

针对这个问题，我曾经尝试过，PM有需求就提给我，我把每个需求的所需要的资源明确后，再分给团队RD去开发，这样既简单，有高效，后来慢慢发现，我根本无法从众多的需求之中脱身，对应的android团队，QA团队也不赞成。经过不断的摸索，中间甚至还经历过双周迭代。后来，经过总结，我发现，眼下的问题到底在哪里？

（1）PM拿到需求时，往往自己也无法完全明确所有的条条框框，只有有一点是明确的，这个需求必须要上。而RD要开始开发一个需求时，也必须是明确的；很多团队RD常常对我抱怨，我们应该在需求评审时，不明确的需求统统毙掉到下个版本再评审。一线的RD是无法体会业务的压力的（我曾经带领团队开发一个美团项目，放下所有的流程规范，无条件上最新的版本），要知道美团的版本一个版本差不多一个月就过去了，像我们这种面向大众的业务，赶上暑假节假日，你这不是要PM命么？PM不跟你拿生命去战斗才怪。

（2）下游的QA团队他们，只希望留有足够的缓冲时间，让他们去测试，不要一下子在短时间过来大量的需求；

（3）一线开发的RD希望，到自己手上的需求是明确的，不能充满不确定性，模糊性，视觉后端等资源也要明确；

针对这些问题，我们干脆屏蔽掉点评和美团的各自的需求开发迭代节奏，不再遵循点评或者美团的流程，我们只需要关注App的提测和发布时间点即可。让PM有需求就每周提一次过来，如果评审通过（PRD明确），就加入需求池中，如果需求所需要的资源明确之后，我们直接从需求池中移除，分配给对应的RD去开发；这样，慢慢地再一次形成了新的一套开发节奏，我整理了如下：



自从需求按周迭代之后，PM固定每周一给我们提需求，给PM留下了“空间绝后”的灵活与方便。自此，我们和PM团队之间的延续很久的斗争，第一次降到了最低，这个迭代流程目前一直执行到现在，目前运转良好，直到现在。

四、总结

有人读完此文，也许会产生共鸣，很多人经历过“混乱”的团队。当然，这个过程并不易，中间有RD因不堪忍受选择了离开了团队。自此，我也意识到，流程规范的变动，尽量让一线RD收到的影响最小，尤其是我们这种经历公司合并，业务变动频繁的团队。当然，能够坚持留下来并且并推动团队走向完善，首先，你得有一颗积极向上、充满信心、乐观并且拥抱变化的心。