客户端开发流程图

跟进

策划

灰度灰度主要有两个用途：1、就产品方案进行A/B test，基于测试结果来判断使用哪种方案；2、投放给客户端小规模的用户，观测crash（闪退）率以及用户对于版本新功能（改变）的态度来决定是否做出改变等。需要注意的坑：用户反馈的不一定就是对的，一定要有自己的判断力，实在拿不准就去联系这些用户问清楚场景和他们吐槽的问题。比如：1）用户说的不一定是事实：用户反馈新版本字太小看不见；你一改，另外一拨用户马上又来反馈说字太大。2）好的不一定是对的：某个东西大家都觉得好。从理论上推导更简单、更顺畅，从视觉上更漂亮、更精致。上线以后用户狂喷…..原因是用户已经养成习惯了，你去挑战他的习惯，他当然要反抗。这一点，有个高人曾经给过指导：好钢用在刀刃上。做得烂的赶紧改，做得好的扩大优势，做得一般的千万别动它（要么你下定决心把它下线了，要么就等他烂透了再动）灰度的具体实施方法：Android的话有很多应用商店，可以选择其中一两个作为灰度渠道，发出新版的包，然后再收集用户的反馈意见。比如在百度手机助手、应用宝发布灰度包。iOS的话可以在一些越狱渠道放灰度包进行测试，同时可以使用官方的testflight测试（大致几百到一千用户可以提前体验未上架App Store的包并进行反馈）

上线

视觉

灰度

补充客户端规范产品大了以后涉及到多团队并行设计和开发，有一套大家共同遵循的客户端设计规范就显得尤为重要了，这是保障客户端用户拥有完整体验的必要手段。在此提供一种思路：项目管理者协调好交互和UI设计师，从文案、按钮、导航栏、文字样式及大小、询问弹窗、toast、icon使用规范（描边？实体？彩色？）、基础设置、手势操作等制定出一套详细的要求发给各个团队，各个团队在进行产品设计时，涉及到上述元素时只可在规则许可的范围内进行自由发挥（比如app主题色是蓝色，你不能搞个红色的东西出来吧？标题用XX号字，摘要用YY号字，你不能反过来吧？双击是点赞，你不能设计成删除吧？）这部分细节很多，只提供一个大体的思路，就不展开进行讲述了，大家把握好关键点：大的客户端一定有个圈，大家都得遵守规则，跳舞不能跳出这个圈。

评审

3、评审是产品全流程中的分水岭，理论上讲评审过后则需求冻结（不能再改了）。作为项目管理者，在这个阶段一定要确定好游戏规则并严格执行，在各方心中建立信任度。评审过程越激烈越好，大家充分的提出自己的想法和观点，以及自己预判的一些风险点，在评审中一定要尽量暴露问题（问题前置）。如果需求评审会一团和气，那一般情况下后期开发、验收过程中都会存在大量撕逼、扯皮、delay的情况。个人提供一种规则思路：项目管理者收集汇总各方的prd及feature list，统一交付给评审参与者。有两点较为重要：文档写清楚版本号，方便多次修改、调整后各方都还能明明白白；文档做好留档工作，日后追查线上功能时，有据可依。feature list我提供一点点想法：评审开两次，第一次小范围（负责各需求的PM、项目管理者、UI负责人、RD负责人、QA负责人）评审和讨论，第二次全体（所有置身于项目中的人）评审和讨论；第二次评审结束，开发和测试就此版本需求情况进行排期，输出每个需求的开始及结束时间节点以及最后完成版本开发（封版）的时间节点。第二次评审出结论后，即是产品、开发对此次项目达成共识。对产品而言意味着需求不能再改（增）。当然了，如果砍需求，我相信开发们会很乐意（所以PM同学在这之前一定要仔细考虑清楚需求和边界情况）；对开发而言需要则是要对输出的完成时间点、功能实现负责。后期存在delay，需求无法实现的情况都是需要开发同学背锅的（所以开发同学评审时一定要了解透彻，认为不靠谱的地方一定要在这个环节提出并解决）这个环节的重点是在于不保留的提出问题，明确划分好权责，把之前阶段所有不透明、不明确的因素全部解决好。

交互

验收

2、注重输出需求本身而不是浮于形式，这个很关键。比如，告诉设计师你要做这件事的初衷以及期望达到的产品目的（例：通过附近的人来为陌生人创造场景，提供沉淀关系的机会），而不是直接告诉他照着微信（陌陌）抄。在产品设计过程中建议多跟视觉同学沟通，保持信息通畅，原型设计过程中尽量别带干扰因素（上色、限制死元素尺寸等）。沟通过程中一定要以目标为导向，不要沉溺于形式。比如：某一个地方两种设计方式都能达到目标，且效果评估相近，设计师赞同A，产品赞同B，这种时候可适当妥协。设计方案过程中产品一定要有逻辑、有体系的去检查各个页面的细节尽量减少后期返工的可能性（问题前置一定比后置要好）。例：设计好方案后将其拆解为几个大方向，分别去检查case是否健全，有无遗漏情况，下面分享一个检查表，大家可以根据参照这个思路去进行产品设计的检查。

验收此环节对经验的要求很高，大家平日一定要多积累，见多就识广了。Demo拿在手上体验一会就知道哪里有问题，哪里要返工。个人的经验也说说，大家可以自行判断和参考：1、验收要有科学的方法：拿着feature list保证不会漏看，根据PM和QA同学写的脑图（case）验收每一种情况是否都符合预期。最后按照用户可能的使用路径做无规则体验。2、验收分为分个验收和总验收两种情况。在跟进环节时，每做好一个需求就拉上相应的PM进行验收，确认每个分块没问题。最后组织一次大的整体验收，多邀请一些角色（运营、交互、UI设计师、用研同学、销售同学等），从不同角度来体验和验收3、验收时发现有问题一定要及时跟进并解决。如果是由于PM特别是项目管理者自身失误导致的问题，一定不要推卸责任，勇敢的担下来并寻求弥补方案。人都会犯错，关键是把结果达成。但是如果出现的是重大问题…那一定是工作没做到位，回去慢慢反思吧。

1、从大的角度（整个APP）去审视各个需求方的方案是否存在短视的行为。比如：是否遵循了端的设计交互、设计规范（后文会补充说明），是否有可以合并实现以降低开发成本的交叉区域，是否有现阶段做不合适的需求等。从细节展开来讲就是先了解清楚各个需求方的需求、优先级和产品预期，然后经过全盘的思考后，给出意见和输出结论。例：需求方A想在这一版本中卖会员，方式是走自己的交易系统进行结算；需求方B希望在这一版中卖虚拟道具，方式是使用自己产品的虚拟货币体系M币来进行结算。当前的情况是客户端上没有接入任何交易体系。在这个case的背景下，作为端的项目管理者就要思考：既然大家都有支付的需求，是否值得做（接入）一套支付体系来整体承接。比如接入货币体系M币，所有的支付需求都走M币结算，用户仅需购买M币就可在这个产品上兑换所有的付费服务。在这个环节，这种例子不胜枚举，大家可以举一反三去处理实际遇到的问题。总的思路就是眼界要宽一些，能重复利用的尽量重复利用，能协调到一块的就尽量协调，以节约开发成本。关键点是让产品从用户的角度看不会感觉明显割裂，体验是完整的。举个反例，如果单纯的满足上例A、B方的需求并上线，某用户C需要购买A、B方的东西，他充值M币之后用来购买B方提供的虚拟道具，剩下的M币想买A方提供的会员，却发现无法用M币支付。此时，体验就是割裂的，不完整的，用户会迷失，这种情况非常严重，大家一定要重视，竭力避免。