如何打造一款商业级APP

前言

技术服务于业务，而业务又大可分为三类：需求、问题、和解决方案。脱离业务的技术不复存在，不断迭代的技术手段也是为了解决业务的痛点，让业务更加顺畅，那么一款可以满足需求，解决问题的应用与技术的结合，就是商业级应用的必要条件，这也是开发者的价值所在，如果一个开发者没有参与过生命周期较长的产品，可能无法看到一个商业级的APP应该长成啥样，也并不清楚如何打造一款成熟的应用

经历

自2015年1月至今从事Android研发的工作7个年头，大致分了三个阶段, 第一阶段：就是在做业务，做各种各样的业务。第二阶段：解决一些异常问题，遇到足够多的问题，追溯根因，查源码 第三阶段：规律制定流程（开发规范、协作方式、设计模式）才有所心得，渐渐的觉得，程序员其实是一个很具有创造力的工作，脑海中浮现出各种实现方案和通信模式的调度来布局应用，不由的生出自豪感；

这篇文章从几个方面来介绍，产品设计，UI设计，版本计划，架构设计，测试介入 各个阶段协作共同打造优质产品---- <流程规范>

产品

乔布斯说过让用户思考的产品一定不是一个好的产品。大家也经常提到什么是产品思维，这是一个很大的问题，我的理解是更接近用户的思考，经常思考一个东西好不好，好在哪里或者坏在哪里

产品经理负责对产品的设计，结合用户需求对产品进行创新，关注运维数据，指导着UI设计师对产品建设高品质的用户体验，对产品长期发展战略提出建设性意见，种种迹象都表明产品经理左右着产品的走向，似乎产品经理应该具备对产品的绝对控制权。在移动互联网圈内，似乎流传着产品经理和程序员之间的爱恨情仇，导致这一现象的根本原因是：产品需求在频繁的变更，需求改了一版又一版，那么这个锅应该是产品经理背吗？我认为这是产品控制权出现了问题。

结论就是：责任或许不应该在产品身上，而是在拥有”产品控制权“的其他角色上，这个控制权是掌握在不同人手中的，导致了往往产品经理也不能左右其产品走向

在一个相对规范的团队中，产品经理的方案和需求一般不会直接走到开发手中，它需要经过严谨的审核，如果实施的瓶颈都在开发阶段，而不是在需求和设计阶段，势必会耗尽更多的开发资源，导致延期和线上问题暴增的，随之而来的恶心循环，相比之下如果进行了严谨的审核，会极大的降低风险的发生，既是后面有更好的方案，也不会随意立即更改，如果是因为产品水平问题反复的修改需求方案，责任也是出在拥有产品控制权人的手里，或者是审核机制没有设定好

当然也有很多种情况，比如一些小型公司和创业型公司，产品经理是可以和开发进行直接沟通，如果相对称职的产品经理也会遵循，用户体验，技术和需求的平衡点，同样在这里也提前强点一点就是开发的水准，至少具备移动架构师的资质，强强联合的搭配，促使产品稳定和极好的性能用户体验。

UX 视觉

一款APP的应用的成败和它是否能获得用户的的支持有必然的联系，而获得用户的支持又与它的美观程度息息相关，美观度越高恰恰更能吸引用户，用户对APP的青睐就会越多，提升美观度似乎对提升APP的成功率越高，这就是UI设计师的价值所在

相信有不少的朋友听过这么一句话，Android应该和IOS保持一致，我的意见是Android最好不要去刻意强调和iOS的用户体验保持一致，原因是 Android 用户和 iOS 用户对 app 具有不同的心智模型，Android的机型众多，同一套UI尺寸是不能满足与所有机型的，而针对特别的机型给出不同UI调整显得至关重要，充分考虑到用户，才会加分

在实际的项目中，设计师提供的UI,需要对项目组进行UX宣讲，详细的讲解页面交互结构和用户操作流程，对开发同学交付的应用进行UX对比，字号，间距等一些列 是否达到预期效果 。融入到实际项目中，产品集体责任感。

 版本计划

对于移动互联网产品来说，迭代的速度就是生命，项目周期越长，项目的可控性就越差，如果太长，就会形成前期激情蓬勃，中期的消极，后期的突击赶工，一个月内是相对比较合理的，版本一旦制订原则上不允许更改的和延期，现实中几乎不太可能存在产品经理会把东西都调研清楚，或多或少的更改和变更需求，而负责制定版本计划的项目经理就需要积极的参与需求研讨和分析中去，尽可能的在前期避免变动，不要带入到项目中去，不明的需求制定预案，不会因为需求的变化而导致失败和版本的延期，综合评估出需求量、开发人力、测试人力等等，保证产出质量和项目进度

 架构设计

  在移动产品中架构设计相当于一栋楼的地基一样的重要。底层架构的稳定和极高的拓展性，可以  使得业务开发更加顺畅。所以架构设计之前必须要熟悉业务就是重中之重，根据不同的业务分类选用适当的设计模式来形成业务架构，根据业务架构做出应用架构，最终落地。

架构听起来也比较高大上，实际上也确实如此，业务经过抽象的架构设计之后，可能会给其他的开发同学带来难以理解的困惑，所以这就必须有详细设计，类图和流程图等等说明的输出，这样可以方面其他成员或者是新成员的上手，在架构层考虑更多的事项目可维护性，比单单实现具体的功能要重要很多，因为维护的阶段比开发的阶段更长，面对的压力也更大，而且由于各种各样的原因，所以架构也不是一成不变的，任何项目如果不是因为无业务增加，无用户量，等原因，底层业务设计从未变过，其结果也很明显，一定是一个失败的架构，一个成熟符合业务的架构一定是应该不断迭代中调整，不断的面向业务，面向接口，更为重要的是面向未来编程，考虑业务所能发展的轨迹做好准备。这样才能面对由不同的模块应用组成，所要处理协调各模块关系，保证整个系统的功能性能和稳定性，基于此来制定各个模块之间的接口暴露。

将所有问题定在设计层面，不带疑问到开发中，如果一个业务或功能没有在设计层面发现，而在产线上发现，可想而知这个成本有多大，严重的问题必然导致APP对用户的留存率，设计稿可以让其他同事在不必了解代码实现的基础之上，发现遗漏点。总结：设计是正确的，代码一定是正确的，代码所可能发生的问题绝对不会在整体流程上，最多是一些细节逻辑的处理，而在一关卡，往往在测试阶段就很容易发现和修改。

任何一款APP的初始阶段，都必经第一个阶段的发育期，那就是开发的速度和质量以及维护性，速度决定你能否支撑公司抢占市场，质量决定能不能站稳位置不被迅速踢走，在此目标的前提下大可不必过于关注设计，第一阶段可分类为  快：很容易做到的，一个普通的APP一两周即可完成，稳 ：这就需要量化评价，大量bug出现之后进行修复可以保证稳。 维护性：可以理解为清晰，在第一阶段往往很难做到，这里往往需要硬性条件 既代码审查，如果此项任务相当滞后，很多情况下，要等到需要实现扩展，甚至换人接手代码时，才知道代码不清晰。而解决这些问题通过架构手段是唯一途径。

 测试阶段

  测试是发布前的最后一道工序，它保证了软件的质量，主要工作是发现软件的 错误和用户体验，    给开发人员提供信息，以方便其为风险评估做相应的准备，重要的是它贯穿在整个软件开发的        过程中，保证整个软件开发的过程是高质量的。

  每个版本的测试都不简简单单的执行测试用例，测试明确这件事的背景和目标尤为重要，围绕目    标进行开展，目标不清楚的会导致场景漏测，而背景不清楚的就很难评估出影响覆盖面，了解        背景和目标输出的测试用例才会大程度的测试全面

  在项目开发过程中，测试成员有必要对提出的每个问题，要求开发人员给出问题原因和修复方        式，而提出的每个问题也应当表明清楚以下几点：问题描述、操作步骤、实际现象、预期结果、    日志、录屏或截图，信息提供的完整度方面开发定位解决，间接的保证进度。

  完整的测试方案应当具备：发布方案 和 监控方案 版本目标 改动范围 影响范围 产品需求用例 技  术性用例 和冒烟用例 ，在每个版本上线直接需固定好基础上线前的冒烟用例测试，每个模块的基   础操作，这里说明的并非版本内所新增的功能，而是整个应用层面的基础功能的冒烟

总结

一款相对成功的应用都不是一个人所能完成的，团队合作尤为重要。

项目迭代的每一步发生的问题都需要对问题精准的界定，找出备选方案，分析每种备选方案的风险和后果，同时建立起反馈跟进后续的行动。

建立并落实起一套完整的规范建制是一款商业级应用的开始