一个手机APP项目的RD规模可大可小，但离不开以下几个成员:产品经理、ui设计师、前端开发、后端开发、测试等。如何合理安排项目成员的工作，保证项目的顺利进行？一个清晰合理的项目RD过程控制是非常重要的。
手机APP项目RD过程控制图
一般来说，项目研发过程分为三个阶段。
第一阶段:需求规划。
需求阶段在产品经理内部讨论需求:讨论下一个版本需求的重点是什么，要做什么功能，怎么做。通过反复研究、讨论，输出互动方案。确认需求的可行性:产品输出交互方案后，找相应的开发讨论需求方案是否可行。在这个讨论阶段，产品和开发的思维模式不同，往往会产生新的火花和惊喜；但是讨论不好控制，不然会演变成产品和程序员的战争，呵呵。UI:设计师让产品的交互方案更加生动美观，但并不是所有漂亮的设计稿都能实现。在这个过程中，产品经理需要协调设计师和前端人员的沟通，制定设计规范。同时保证设计稿的质量和稿的进度。需求演示:在产品经理完善交互方案和实现逻辑，并将上一版本的bug和其他优化需求整合成一份完整的版本需求文档后，邀请项目全体成员进行演示。演示的目的是让项目成员知道新版本需求的重点是什么，要做哪些功能，为什么(强调)；简单介绍一下怎么做，说明一下交互方案或者设计稿，给大家一个整体印象，让大家知道版本功能的意义。
第二阶段:需求研发。
根据产品评审结果发送项目启动邮件。RD:在需求RD过程中，跟踪产品的RD进度，与开发保持沟通，确保正确理解需求，及时解决RD过程中发现的新问题。测试用例:产品、测试和开发共同确认测试用例的版本，并同步RD过程中变更的需求和细节。测试:产品验收、功能模块开发输出、经验回归文档输出；根据测试用例验证需求的逻辑，提出bug并优化开发。内网环境测试通过后，测试继续验证预发布环境和正式环境。
第三阶段:版本发布。
客服培训:在测试验证过程中，版本发布前，产品会提前对新版本进行客服培训。发布:后端开发、运维人员对外网环境发布代码，前端输出外网官方包。产品将正式上传至各大安卓市场或ios -appstore进行审核。升级:当所有安卓渠道包更新完毕，或者appsore通过审核，新版本没有发现问题时，后端开发运营人员会打开升级配置，发送升级通知。运营报告:版本发布尚未完成。新版本发布后，运营商收集用户反馈，监控和分析数据。评估新版本功能的效果和影响，验证新版本功能，输出开发和优化版本需求的建议。
从上面的APP项目研发过程来看，每个版本的RD都要经历以上三个阶段，12个环节。理论上是完整的流水线，但如何保证流程的顺利进行？如何让项目成员的工作效率最大化？这很考验产品经理/项目经理的版本规划能力。当然，项目成员之间的默契和沟通也很重要。
从笔者的实践经验来看，为了保证流水线的顺畅，理想情况下，产品需求文档应该比前端开发早两个版本，设计比前端开发早一个版本，后端开发比前端开发早半个版本。也就是在当前项目启动的同时，产品经理已经在调查和讨论下一个版本的需求；设计并开始下一个版本的手稿；在当前项目中期，后端已经完成了当前版本的需求，开始准备下一个版本的需求预研究。
app版本规划
版本规划由产品经理根据需求优先级和开发进度预估确定，即每个版本要做什么，重点是什么，研发时间，上线时间等。一般来说，一个项目的每一个发布都应该有它的意义和主要功能。
第一版app比较长:app需要匹配开发环境，确定app的技术框架，开发各种基础系统等。对于这样一个长期版本的RD，产品经理和技术人员应该分阶段进行开发需求，并在评估需求时设定里程碑(尽量不超过三个)。在每个里程碑上(最长不超过一周)，产品经理需要确认完成状态，发现问题及时调整RD计划，控制项目风险，确保项目如期完成。
一般情况下，不建议频繁发布次要版本，因为每个版本发布都需要测试、打包、投放市场、更新配置和更新提醒等。频繁发布小版本导致测试和运营的重复性工作增加，造成资源浪费；用户看频繁的升级提醒也很烦。另外，建议外网运营客户端版本不超过4个。老版本的维护成本还是比较高的。比如在做新功能的时候，要考虑新版本和旧版本的兼容性，要升级更新与各种后台数据接口的兼容性。后续每个版本至少要有一个重要功能，版本的开发周期控制在2 -3周内。这种优势一方面是保证项目成员有良好的发展节奏，最大化RD效率；另一方面保证每个版本对于用户体验都有新的东西，以及满足各大市场申请上线的要求，获得免费推广资源(ps:一般上线活动可以获得几千到几万的免费用户，相当有吸引力)。当然，如果各大功能上线，为了保证上线版本的稳定性，RD周期可以延长到一个月，也可以进行灰度发布。尽量避免安排一个研发周期超过一个月的版本，或者将长版本设置为几个里程碑验收。经验表明，漫长的RD周期往往会导致RD技术人员分心，工作拖沓，积极性下降。
特殊情况下，出现紧急bug和漏洞时，建议紧急发布一个bugfix版本。
