有很多小伙伴问到润壤一个问题，就是APP产品如何管理？APP产品的管理很困难吗？事实的确是这样的，APP管理相对于PC端产品而言确实比较困难，因为APP产品更繁琐，需要综合考虑的因素也多。科学的项目管理很重要，那么如何科学全面的管理好APP产品呢？今天，润壤就给大家讲一讲项目管理者如何科学全面的管理好APP产品的方法。
首先，我们从项目管理的起始到结束这整个流程来切分节点，这样我们的思路就会很清晰了：
下面，我们仔细分析每一个节点需要处理的事情和一些需要注意的事项。
策划：
作为一个项目管理者，在这个阶段需要做的就是明确各个需求方的需求，从大的角度(整个APP)去审视各个需求方的方案是否存在短视的行为。比如：是否遵循了端的设计交互、设计规范(后文会补充说明)，是否有可以合并实现以降低开发成本的交叉区域，是否有现阶段做不合适的需求等。
从细节展开来讲就是先了解清楚各个需求方的需求、优先级和产品预期，然后经过全盘的思考后，给出意见和输出结论。总的思路就是眼界要宽一些，能重复利用的尽量重复利用，能协调到一块的就尽量协调，以节约开发成本。关键点是让产品从用户的角度看不会感觉明显割裂，体验是完整的。
交互、视觉：
和交互、视觉同学打交道，要注意自己的沟通和阐述方式，注重输出需求本身而不是浮于形式，这个很关键。比如，告诉设计师你要做这件事的初衷以及期望达到的产品目的而不是直接告诉他照着抄。
有很多公司PM本身就兼任交互设计师，那么在这种情况下在产品设计过程中建议多跟视觉同学沟通，保持信息通畅，原型设计过程中尽量别带干扰因素(上色、限制死元素尺寸等)。
沟通过程中一定要以目标为导向，不要沉溺于形式。比如：某一个地方两种设计方式都能达到目标，且效果评估相近，设计师赞同A，产品赞同B，这种时候可适当妥协。
设计方案过程中产品一定要有逻辑、有体系的去检查各个页面的细节，尽量减少后期返工的可能性(问题前置一定比后置要好)。
做设计的时候一定要去考虑细节，不然后期可能因为一个很小的点(致命)而导致大返工。
最好从UI、交互、缓存、异常这几个关键点入手对产品方案做细节梳理。
评审：
评审是产品全流程中的分水岭，理论上讲评审过后则需求冻结(不能再改了)。作为项目管理者，在这个阶段一定要确定好游戏规则并严格执行，在各方心中建立信任度。评审过程越激烈越好，大家充分的提出自己的想法和观点，以及自己预判的一些风险点，在评审中一定要尽量暴露问题(问题前置)。如果需求评审会一团和气，那一般情况下后期开发、验收过程中都会存在大量撕逼、扯皮、delay的情况。
提供一种规则思路：
1.项目管理者收集汇总各方的PRD及feature list，统一交付给评审参与者。有两点较为重要：
1)文档写清楚版本号，方便多次修改、调整后各方都还能明明白白;
2)文档做好留档工作，日后追查线上功能时，有据可依。
方向是指需求提出方，模块是指属于APP哪个部分，页面就是功能所在的页面，需求点是需求的提纲和概述，优先级是指紧急程度，负责人是跟进这个需求的PM(有问题就找他了解、协助推进)。有了feature list后可以保证版本需求很繁琐时不出现遗漏，减少了很多后期的风险，也方便开发人员快速找到需求的接口人，提高沟通效率。所以作为项目负责人有必要让各需求方按照统一的方式提交feature list。
2.评审开两次，第一次小范围(负责各需求的PM、项目管理者、UI负责人、RD负责人、QA负责人)评审和讨论，第二次全体(所有置身于项目中的人)评审和讨论;
3.第二次评审结束，开发和测试就此版本需求情况进行排期，输出每个需求的开始及结束时间节点以及最后完成版本开发(封版)的时间节点；
4.第二次评审出结论后，即是产品、开发对此次项目达成共识。对产品而言意味着需求不能再改(增)。当然了，如果砍需求，我相信开发们会很乐意(所以PM同学在这之前一定要仔细考虑清楚需求和边界情况);对开发而言需要则是要对输出的完成时间点、功能实现负责。后期存在delay，需求无法实现的情况都是需要开发同学背锅的(所以开发同学评审时一定要了解透彻，认为不靠谱的地方一定要在这个环节提出并解决)。
这个环节的重点是在于不保留的提出问题，明确划分好权责，把之前阶段所有不透明、不明确的因素全部解决好。
跟进：
这个阶段的重点在于按照之前的协议卡好时间节点来开展相关工作。项目管理者在这个阶段需要双眼盯好时间点，一切为时间服务。项目管理者在此阶段是需求提出方和开发方的接口人，
要积极帮助双方推动事情，解决问题，关键的时候需要能站出来拍板并承担责任。很多有明显交叉的地方(不属于此版本中任意一个需求方，但是又必须要做)需要项目管理者来进行处理。
验收：
此环节对经验的要求很高，大家平日一定要多积累，见多就识广了。拿在手上体验一会就知道哪里有问题，哪里要返工。个人的经验也说说，大家可以自行判断和参考：
1.验收要有科学的方法：拿着feature list保证不会漏看，根据PM和QA同学写的脑图(case)验收每一种情况是否都符合预期。最后按照用户可能的使用路径做无规则体验。
2.验收分为分个验收和总验收两种情况。在跟进环节时，每做好一个需求就拉上相应的PM进行验收，确认每个分块没问题。最后组织一次大的整体验收，多邀请一些角色(运营、交互、UI设计师、用研同学、销售同学等)，从不同角度来体验和验收。
3.验收时发现有问题一定要及时跟进并解决。如果是由于PM特别是项目管理者自身失误导致的问题，一定不要推卸责任，勇敢的担下来并寻求弥补方案。人都会犯错，关键是把结果达成。但是如果出现的是重大问题…那一定是工作没做到位，回去慢慢反思吧。
灰度：
灰度主要有两个用途：
1.就产品方案进行A/B test，基于测试结果来判断使用哪种方案;
2.投放给APP小规模的用户，观测crash(闪退)率以及用户对于版本新功能(改变)的态度来决定是否做出改变等。
需要注意的坑：用户反馈的不一定就是对的，一定要有自己的判断力，实在拿不准就去联系这些用户问清楚场景和他们吐槽的问题。
灰度的具体实施方法：
Android的话有很多应用商店，可以选择其中一两个作为灰度渠道，发出新版的包，然后再收集用户的反馈意见。比如在百度手机助手、应用宝发布灰度包。
iOS的话可以在一些越狱渠道放灰度包进行测试，同时可以使用官方的testflight测试(大致几百到一千用户可以提前体验未上架App Store的包并进行反馈)
上线：
灰度一两周后，确定该解决的问题都OK了，没有重大的问题或者是大量的集中反馈就可以正式发布啦(如果灰度时还有很多问题，比如crash率很高，那建议修复后再次进行灰度，确保不出问题)。
循环节奏：
如果你的产品稳扎稳打，节奏较慢，那么在上述流程走完之后，进入下一次大循环即可。
如果你需要敏捷开发、快速迭代，那么下一个版本的完整流程应该从当前版本中间时就启动，在此其实非常简单，当前版本进入灰度时，下一个版本的流程刚好走到评审即可，整体的环节不变。正常的版本迭代，进入灰度之后开发的时间相对会充裕起来，任务基本是解当前版本需求的bug，空出来的时间可以开始下个版本需求的调研工作。
好了，润壤已经从策划-交互-视觉-评审-跟进-验收-灰度-上线这几个方面一一跟大家讲解了项目管理者如何科学全面地管理好客户端产品的方法，大家是不是get新技能了？
