我是怎样在美团点评做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收到的影响最小，尤其是我们这种经历公司合并，业务变动频繁的团队。当然，能够坚持留下来并且并推动团队走向完善，首先，你得有一颗积极向上、充满信心、乐观并且拥抱变化的心。
我是怎样在美团点评做App需求迭代的相关推荐
- 工具化、产品化、运营化—「美团点评」运维的故事
本次分享嘉宾是美团点评运维中心高级总监钟红军,他向我们详细介绍了美团点评近3年来在大规模运维的理念和实践方面的探索,尤其是在运维自动化和数据运营方面的工作和效果-- 钟红军 / 美团点评运维中心高级总 ...
- 美团点评金融平台Web前端技术体系
背景 随着美团点评金融业务的高速发展,前端研发数量从 2015 年的 1 个人,扩张到了现在横跨北上两地 8 个事业部的将近 150 人.业务新,团队新,前端领域框架技术又层出不穷,各个业务的研发团队 ...
- 转载《美团点评金融平台Web前端技术体系》
复制代码 作者:禹霖 原文地址: tech.meituan.com/2018/03/16/- 背景 随着美团点评金融业务的高速发展,前端研发数量从 2015 年的 1 个人,扩张到了现在横跨北上两地 ...
- 5000字干货原创 | APP版本迭代如何避免踩坑？
这是我之前好友总结整理的APP版本迭代流程与规范,主要涉及到版本迭代过程中的规范流程以及涉及到版本各个角色的职责分工等内容. 为了避免和团队成员撕逼扯皮,可以按照如下规范流程和团队成员宣导,落实 ...
- 在美团点评当工程师的第一年总结
伴随着公司的推送,在2017年7月12日,我迎来了在美团点评的第一年.在公司的第一年,遇到了一些困难,学习到了很多知识,得到了很多人的帮助.文字是有生命力的,总结一下自己过去的正式工作的第一年,给自己 ...
- 【个人思考系列】在美团点评当工程师的第一年总结
伴随着公司的推送,在2017年7月12日,我迎来了在公司中的第一年. 在公司的第一年,遇到了一些困难,学习到了很多知识,得到了很多人的帮助. 文字是可以传承下去的,总结一下自己过去的正式工作的第一年, ...
- 【个人思考系列】美团点评 Java 后端新人第一年总结面试经验 | 掘金技术征文...
image.png 伴随着公司的推送,在2017年7月12日,我迎来了在公司中的第一年. 在公司的第一年,遇到了一些困难,学习到了很多知识,得到了很多人的帮助. 文字是可以传承下去的,总结一下自己过去 ...
- 美团点评基于 Flink 的实时数仓平台实践
摘要:数据仓库的建设是"数据智能"必不可少的一环,也是大规模数据应用中必然面临的挑战,而 Flink 实时数仓在数据链路中扮演着极为重要的角色.本文中,美团点评高级技术专家鲁昊为大 ...
- 美团点评效果广告实验配置平台的设计与实现
广告系统中,一个好的实验平台可以令算法.工程.业务的迭代更多.更快.更好.本文详细介绍了美团点评效果广告引擎团队结合自身业务实际,在广告实验配置平台上的实践.目前该平台已经在搜索广告中全面上线,支持线 ...
最新文章
- [转自scott]ASP.NET MVC框架 (第二部分): URL路径选择
- Visual Studio 2013开发 mini-filter driver step by step (4) - 获取文件名
- Jquery操作Cookie取值错误的解决方法
- Glide 这样用，更省内存！！！
- ORA-00257 错误解决
- java 写jsp_Java开发之JSP指令
- linux namespace 工具,Linux Namespace : 简介
- Java基础入门笔记-多态
- vscode编辑器 装JavaScript Standard Style 遇到不检测代码问题
- 2020-11-17 一道有趣的求极限问题
- xp系统 护眼模式
- 代码整洁 vs 代码肮脏
- python123汉诺塔实践_python汉诺塔问题
- 雄迈H.265 DVR程序功能升级简介
- 华为p4支持鸿蒙功能吗_华为鸿蒙系统支持机型介绍
- 大数定律与蒙特卡罗法
- 第7章第36节：六图排版：三张图片一组并列排版 [PowerPoint精美幻灯片实战教程]
- HMM隐马尔科夫时间序列预测 Markov马尔科夫时间序列预测（Matlab）
- 青少年编程教育平台后台—登录注册（代码编写）
- 33220a 编程C语言,基于AT89C51单片机的数字式波形发生器(非常完整).doc