移动产品团队迭代运作概论

2017-05-05 11:13:00

移动产品团队的运作强调高质量、零风险、高速度交付；结合这些年来参与的团队运作经验，特别是之前带领团队进行敏捷运作试点的经验，写了这篇概述性文章。

1 快速迭代

版本快速迭代运作流程参考了SCRUM敏捷运作模型，但是更重落地、而不重形式。目前我们App采用Hybrid混合架构，以一个月一个原生版本为正常迭代节奏，月中最多可夹杂一个h5热更新版本。

2 需求分析前置下的版本周期规划

版本规划周期为四周，实际执行周期为六周，需求分析前置两周，在上一版本Uat阶段即开始需求分析工作，与开发测试并行运作。

在前置两周内，需求分析、预研开发、系统测试三者并行运作，具体而言是将需求分析的时间节点较版本开始时间点前置两个星期：第一个星期做业务需求分析与原型开发（产品）、核心需求技术可行性预研（主程），最终交付版本需求原型与交付范围确认、技术方案预研报告；第二个星期根据原型做需求评审、UI设计稿开发（UI设计师）、核心需求底层实现开发（主程）、后台服务设计与开发（后台开发人员）。

版本正式启动后立即开始功能开发（开发）、测试用例开发（测试），即便UI设计稿还未开发完成，也先按原型稿来开发，到ST测试后期再分批次做视觉还原。

关键评审节点：

Pre第一周：需求开发（包括原型开发）、核心需求技术可行性预研，星期五依托原型稿进行需求评审与需求交付范围确认；

Pre第二周： UI设计稿开发、核心需求基础开发、后台接口服务设计，星期五进行UI设计稿评审，技术方案评审与宣讲（包括后台接口服务设计，如果有的话）；

Cur第一周：主要进行功能开发、用例开发，星期一产品做需求宣讲，最好能结合UI设计稿（如果没有就用原型稿）；星期五进行测试用例评审；

Cur第二周，主要是完成功能、Bug修复、ST测试，星期五产品经理开始介入ST测试、UI设计师开始准备做第一期视觉还原；

Cur第三周，主要是完成ST测试、开始UAT测试，星期三进行UAT验收评审、后台服务做发布准备；

Cur第四周，主要完成UAT测试，版本上线发布，星期三进行版本上线评审，包括版本需求验收、上线发布材料评审、后台服务发布验收；星期五完成app上线发布审批，待后续上线后进行试运行验收；

3需求承诺与交付承诺

在敏捷迭代项目中，承诺是一个非常重要的词汇，通常主要包括需求范围承诺与交付质量承诺，上文提到，纳入版本交付范围的需求，必须是零风险、高质量的需求，需求范围一旦确定，在当前版本执行周期内，原则上决不允许再有需求变更事件发生，如果有，也只能做需求替换，而不是需求追加。

敏捷项目之所以能快节奏持续迭代，一大重要原因就是认可团队开发能力有限这一基本原则，成员相对固定的团队，在产品架构、技术能力等因素没有显著提升的情况下，开发团队的产出是有限而且可评估的。也基于此论断，在一个迭代周期内，需求交付量也必然是有限的，如果中途增加需求，其结果必然是增加版本交付风险、延长版本交付周期。

而在基于“需求分析前置”的敏捷迭代运作方式下，各个版本就像坦克履带一样是环环相扣的，一环延期必然导致环环延期，最终结果就是版本迭代节奏被彻底打乱、版本稳定性遭到致命性破坏。这种结果在之前我呆过以及现在的团队中均是有血淋淋的事实的。

      版本持续稳定高质量迭代除了需求稳定之外，最重要的还是要有高质量的交付。一旦承诺交付的需求，开发就应当高质量高效率地完成并保证最终成功上线。当然开发质量的提升是一个非常复杂的命题，既与开发人员能力直接相关，也与产品系统架构休戚相关；既跟需求交付质量间接相关，也跟测试质量正向相关。但是，并不能因为事情难做，就放弃努力。总体而言，系统架构足够优秀，就能极大提升功能开发效率、减少初级开发人员犯错几率；普通开发人员能力提升既能带来开发效率的提升也能带来代码质量的提升，最终还是能提升后续功能开发效率与功能稳定性；需求交付质量的提高，既能减少需求沟通成本与时间，也能尽早发掘异常分支场景，避免重大功能场景遗漏；测试用例质量的提升，能直接保证功能场景的覆盖程度；自动化测试的落地，是大幅提升原有功能回归验证的效率与正确度。

3 每日站会

每日站会发生在每天上午开工之前，主要是为了跟进团队成员每日开发测试工作进展、协调各成员资源与问题，时间控制在5~10分钟，每人3~5句话，重点简述昨日进度、今日计划、出现的问题，具体问题处理留到会后单独沟通，每日站会会贯穿整个版本开发周期，即从版本开发启动开始直至版本上线结束。

关键时间节点：

Cur第一周：产品、UI、开发、测试参与站会，重点协调UI资源、核心需求的开发资源分配；

Cur第二、三周：产品、开发、测试参与，重点协调技术疑难、测试bug处理；

Cur第四周：产品、UI、开发、测试，重点协调视觉还原资源、上线工作安排；

4 UAT验收

UAT验收标准：Bug数量总体收敛，1级bug为0，bug总数不超过10个，已做过一轮视觉还原；

UAT期间重点处理页面效果优化，尽量少产生功能类bug；

5 生产问题处理规范

生产问题特指分流到产品手中的生成环境用户问题，总体分两类处理：

1、紧急问题，紧急处理，开发临时开分支版本修复并上线，尽量通过发布h5包来热修复；

2、一般问题，统一转需求，纳入后续版本处理（非当前开发中版本）；

6 技术架构演进

技术架构演进总体要比当前业务版本提前至少一个版本，技术任务的形成依托于中长期产品功能规划，也即是年度核心需求实现的技术储备任务、未来两至三个版本内核心需求实现的高耗时技术预研类任务。技术预研任务的目的是为了确保核心需求在版本实施过程中能做到零风险交付，将技术攻关工作提前完成，确保核心需求实现时的零风险高效交付。

前期预研、方案设计评审、框架代码开发均独立于当前迭代版本，开分支进行独立开发，在方案开发完成后，作为需求支持项纳入该需求对应版本实施。

上文需求前置一节中也有提到主程预研工作，特此说明一下，主程预研任务也是技术架构演进任务的一部分，只是相对风险更低、周期更短，一般是一至两个星期以内可以确保交付完成的任务，此类任务遵循快速立项、快速交付、快速结项的原则运作。而此节所指的技术任务更多的还是大型、高难度、高耗时、高收益的产品架构级别任务，要么不动，一动就牵动全身。

结合目前产品组项目管理方案——禅道，做了如下具体运作规划：

技术架构演进相关的项目主要有三类：技术任务池；技术预研阶段项目；开发实施阶段项目；

6.1 App架构改进优化任务池项目

这个项目做类似产品需求池作用，所有技术改进类任务先统一纳入这个任务池中，编排优先级，并关联产品需求。对于最高优先级（优先级为1）的任务，统一纳入下一期项目“App架构优化期”中启动研究或开发。

关键节点：

1、方案优先级编排：一般采用邮件评审确认的方式，原则上一个工作日给出评审意见，否则按默认优先级执行；

2、方案评审：方案确认后，有主要预研人员组织技术团队、核心产品经理进行方案评审；

3、方案转需求：方案预研人员与产品经理协商，选择合适版本以关联需求的形式转入版本需求进行实施并上线。

6.2 预研阶段项目

高优先级的任务会定期排入新的分期项目，先由核心技术人员进行技术可行性预研，预研阶段要求形成方案预研文档，并在技术核心团队中组织技术方案评审，评审通过后再开始基础框架代码的封装开发，基础开发完成后才转入下一阶段全面实施阶段。而对于主程预研类任务，因为影响范围相对较小，经过预研阶段就可以直接关闭项目，结合当前版本需求进行开发实施即可。

6.3 开发实施阶段项目

在基础开发工作完成后，方案主导人员结合方案预研文档对团队内普通开发人员进行技术宣讲（即技能培训），宣讲完成后分配全面实施任务给普通开发人员进行全产品级别的统一整改开发，开发完成后，结合所关联的产品需求纳入对应版本测试并发布上线。

7 需求分析

在移动产品团队中，产品经理是一个非常关键的角色，除了产品功能设计与规划，还有一项核心技能即是需求分析，需求分析能力的强弱直接决定了功能开发效率与返工率、测试用例开发质量、测试质量，最终决定版本交付质量。

虽然现如今项目运作方式变了，但是软件开发周期中的事情并没有减少，只是做了角色重新分配，传统项目式运作方式中除了项目经理，还有需求分析师这一角色，而在敏捷迭代运作方式中，这一角色其实是由产品经理承担的，所以不客气的说，不是把你摆上产品经理的位置，你就真是产品经理，只有真正具备了产品经理的相关能力，你才能称得上真正的产品经理，而不仅仅是所谓的“产品狗”。

7.1 需求分析技巧

需求分析是一类非常专业的IT技能，笔者三年前写了两篇文档，之前是放在CSDN上的，现也收录进简书专辑中，内容的整理格式是基于以前传统瀑布式项目运作流程，但分析过程其实不论哪种项目运作方式其实都是一样的，只是交付成果不同，原来是《需求分析报告》与《需求规格说明书》，现在是需求原型图与需求补充说明文档，仅供参考：

谈谈需求（上）

谈谈需求(下)