客户端产品：如何高效稳定地迭代开发
客户端产品相较PC、移动web而言，更重、更繁琐，需要综合考虑的因素多。因此有一个系统、全面的项目管理流程是很有必要的。特别是用户量到达一定级别之后，产品和项目会变得愈加复杂，如果项目管理跟不上，就会导致开发效率下降，产品方案实际落地与预期偏差大、沟通复杂且困难，团队内部矛盾加深等问题。一个客户端产品如果想高效而稳定的进行迭代和版本开发，科学的项目管理方法至关重要。接下来的文章就本人的经历和思考提供一些解决方案，以供参考。
既然是项目管理，当然就得按一定方法将项目从起始到结束的整个流程切分为一个个的节点，然后根据各个节点的情况来提炼共性并输出指导方法论。就像打游戏一样，哪一关的boss应该如何打？以下提供一种思路做参考。将客户端产品项目的产品需求调研、收集及策划定为项目开始，版本稳定上线设为结束，这就是一个完整的流程，中间的环节及顺序见下图：
狼蚁网站SEO优化，我们仔细分析每一个节点需要处理的事情和一些需要注意的事项。
策划：
作为一个项目管理者，在这个阶段需要做的就是明确各个需求方的需求，从大的角度（整个APP）去审视各个需求方的方案是否存在短视的行为。比如：是否遵循了端的设计交互、设计规范（后文会补充说明），是否有可以合并实现以降低开发成本的交叉区域，是否有现阶段做不合适的需求等。
从细节展开来讲就是先了解清楚各个需求方的需求、优先级和产品预期；然后经过全盘的思考后，给出意见和输出结论。
例：
需求方A想在这一版本中卖会员，方式是走自己的交易系统进行结算；
需求方B希望在这一版中卖虚拟道具，方式是使用自己产品的虚拟货币体系M币来进行结算。
当前的情况是客户端上没有接入任何交易体系。在这个case的背景下，作为端的项目管理者就要思考：既然大家都有支付的需求，是否值得做（接入）一套支付体系来整体承接。比如接入货币体系M币，所有的支付需求都走M币结算，用户仅需购买M币就可在这个产品上兑换所有的付费服务。
在这个环节，这种例子不胜枚举，大家可以举一反三去处理实际遇到的问题。总的思路就是眼界要宽一些，能重复利用的尽量重复利用，能协调到一块的就尽量协调，以节约开发成本。关键点是让产品从用户的角度看不会感觉明显割裂，体验是完整的。
举个反例：如果单纯的满足上例A、B方的需求并上线，某用户C需要购买A、B方的东西，他充值M币之后用来购买B方提供的虚拟道具；剩下的M币想买A方提供的会员，却发现无法用M币支付。此时，体验就是割裂的，不完整的，用户会迷失。这种情况非常严重，大家一定要重视，竭力避免。
交互、视觉：
和交互、视觉同学打交道，要注意自己的沟通和阐述方式。注重输出需求本身而不是浮于形式，这个很关键。比如：告诉设计师你要做这件事的初衷以及期望达到的产品目的（例：通过附近的人来为陌生人创造场景，提供沉淀关系的机会），而不是直接告诉他照着狼蚁网络推广（陌陌）抄。
有很多公司PM本身就兼任交互设计师，那么在这种情况下在产品设计过程中建议多跟视觉同学沟通，保持信息通畅。原型设计过程中尽量别带干扰因素（上色、限制死元素尺寸等）。
沟通过程中一定要以目标为导向，不要沉溺于形式。比如：某一个地方两种设计方式都能达到目标，且效果评估相近，设计师赞同A，产品赞同B，这种时候可适当妥协。
设计方案过程中产品一定要有逻辑、有体系的去检查各个页面的细节，尽量减少后期返工的可能性（问题前置一定比后置要好）。
例：设计好方案后将其拆解为几个大方向，分别去检查case是否健全，有无遗漏情况，狼蚁网站SEO优化分享一个检查表，大家可以根据参照这个思路去进行产品设计的检查。
做设计的时候一定要去考虑细节，不然后期可能因为一个很小的点（致命）而导致大返工。
例：
假如我来设计网易新闻中新闻tab下头条tag中的新闻卡片。例图如下：
我会从UI、交互、缓存、异常这几个关键点入手对产品方案做细节梳理，梳理脑图（case）如下：
上述脑图（case）只是举例，大家可以按照自己的实际情况及偏好借鉴这个思路去做变形或延展。但是在做产品设计时一定要考虑，不然后期可能会因为不确定性因素造成delay甚至是大返工。在跟需求提出方对方案时，最好也按很细的角度，思维去检查。
很多产品同学认为case是QA同学负责的，自己不用在意，其实这种思路非常错误和不负责。试问如果产品考虑得不够细致和全面，那最后产品还是会被QA同学不停的追问。那么你的整个工作节奏肯定会被打断，每天被琐事缠身，工作效率下降。对于QA同学而言，写case的时间也会成倍增加。
评审：
评审是产品全流程中的分水岭，理论上讲评审过后则需求冻结（不能再改了）。作为项目管理者，在这个阶段一定要确定好游戏规则并严格执行，在各方心中建立信任度。评审过程越激烈越好，大家充分的提出自己的想法和观点，以及自己预判的一些风险点，在评审中一定要尽量暴露问题（问题前置）。如果需求评审会一团和气，那一般情况下后期开发、验收过程中都会存在大量撕逼、扯皮、delay的情况。
个人提供一种规则思路：