APP就是代码开发完了去推广。如果你觉得这是笑话，那我同样觉得你是个笑话。
发出第一篇文章的链接之后就出去吃饭，回来发现浏览量并没多少，而在正常情况下如果推出一项新业务，需要实时观测用户对产品或模块的反应，以避免内侧过程中尚未发现的问题影响大量客户。那么完整的项目开发流程是怎样的呢？
产品需求分析
知己知彼百战不殆，然而小公司最喜欢做的是全盘复制，笔者曾在某小型 P2P金融公司 待过，团队讨论的大体结构是--这家APP的这个功能不错--我们以后可以用到--那家APP的结构不错--我们可以沿用--我们公司有他们家没有的功能--这也是要加上的。这类讨论方式简直是对具有专业素质的设计和开发的侮辱，但的确有很多公司使用这种方式。还有甚者是直接弃之不顾的，开发成啥样就是啥样，完全没有实质性建议。这两种都是万万不可的。
为何？如果只是抄袭，你的产品永远跟在人家后面；如果你还加入了自家特色，它就更变成了大杂烩。邯郸学步的后果是突然间某天你发现人家完全以数据支撑的业务上线了你却无能为力，黔驴技穷的你坚信自家特色是救命稻草，那么终究只是费时费力而已。那么放任自流如 Facebook 或 Google 的工程师文化主导呢？首先人家在各个模块也有专人负责，其次人家强调的“FB的事就是你的事”在国内大多充斥着只会一种技术的员工的公司里，完全行不通。
怎么做？不管是初始版本还是后续迭代，每个产品阶段，只以1个核心功能附加3~7个辅助点进行设计，摒弃当前所有不重要的需求，专注是你唯一要做的事。辅助点意味着操作层级深或优先级低的环节，可利用更为分散的精力去实现。
市场趋势分析
你所要介入的市场是增量市场还是存量市场？这就好比你是往东还是往西。往西是保守派的存量市场，针对现有同类产品，它们所呈现的形式对市场已经构成的影响有多大，如何避免同质化并且拿下尚未挖掘的需求是重中之重。往东是激进派的增量市场，如何促进用户活跃，避免负面情绪，是第一步要做的，然后才是营造消费环境。
基于运营数据分析的功能改进
-
基于流程的漏斗模型
例如大量用户在注册页就直接退出，那肯定是你的验证码延迟太高或者流程太繁琐，要么就是程序崩了。这种方式的特点在于观察用户使用习惯，针对层级较多的模块，其每一层级的到达率尤为重要。 -
基于特定模块的节点覆盖分析
一份表单没有提交，是哪一步令用户疑惑不前？节点的点击率可以帮你分析，最先(后)点击的条目是什么，最多(少)点击的条目是什么，流失量最大的条目是什么。 -
如何构建数据分析框架
在前一篇文章中提到 growingIO，就是一家数据分析公司，国内同类型公司并不少，但距离随心所欲的达成你想分析的数据这个目标，还有些路要走。
结合以上的分析模型，辅以客户端上传的崩溃日志(尤其安卓版本 APP)，此时团队就可以对此进行补救，包括代码优化，功能重构，以及文案的再设计。
产品设计
-
MVP模型
MVP 全称最小化可行性产品，此处的产品并非特指最终版本，它是一个可交互与演进的架构，但其中所涉及到的功能点和模块保持不变，否则请一切推倒重来。 -
交互 & 原型设计
一般由PM整理项目结构后，交由交互设计进行线框图的编排，然后 UI 设计负责低保真原型图，项目相关成员集体讨论当前结构的可行性，包括运营活动的可嵌入性，后续2~3个版本迭代的结构健壮性，结构完整性与用户接受能力等等。最后再进行高保真原型的绘制，通用工具有 Axure 或者 Sketch，后者为 Mac 系统专用，插件丰富。关于可交互原型的设计，在各个环境中的重要性并不统一，
产品开发
-
团队协同
包括工期预估，以及架构优先 & 模块化优先的并行策略，保证 UI 与B/C端开发，服务器接口与B/C端开发的协同，首先要有充足的人员，才能尽量少的出现空档期，并提高疑难问题的解决效率。 -
敏捷开发
BDD, 以需求为主导地位的开发模型，测试中经常用到，这种方式的特点是不再基于全局设计而是面向全局整合。这样直接效果是周期快，遇到问题直接处理。团队成就感也很明显，不再是漫无目的的抽象活动。如果遇到临时大改需求的奇葩，也能从容应对(貌似这才是重点)。
总结
产品本身接触较多，然而在实践过程中，每个阶段都会有很多可能无法归类的坑。比如无法协调第三方依赖带来的无法绕过的坎，原本的项目周期就会一拖再拖导致领导干预，项目结构直接被打乱。或者过早的为将来而设计，笔者曾被告知“大家都说底下要4个TAB栏，你就加上吧”，幸好没过多久公司就倒了。
且行且珍惜。
网友评论