APP项目工作流程详解！
做任何事情之前，首先要考虑用户的需求，商业价值，以及背后的技术难度。只有用户有需求，你的产品才会被别人使用；只有其商业价值确立，才能给企业带来利润。毕竟企业最基本的目标是盈利。只有整体技术评估可行，整个项目才能实施。现在大家都在追求“快”的互联网创业，比如两个月融资，4月用户突破百万，3年后在纳斯达克上市。然而这就是大家看到别人创业成功的样子。我不知道做任何事情的前提是你要知道自己在做什么。诚然，你不能排除自己很勇敢很幸运地随便做了什么，但那只是个案，不值得深究。
在项目的执行过程中，我们经常会陷入一堆人在一起，讨论的气氛兴高采烈的局面。a说这个地方的按钮不行，B说这个地方应该像别人的app一样做，C说你们都不对。应该是这个模块而不是这个。经常参加这种讨论，会极其耗费时间和体力，一次就要几个小时，但是一旦会议结束，我发现什么都没有出来。大多数情况下，一定是产品定位有问题。执行人必须清楚产品是用来做什么的，给谁用的，才能正常讨论具体细节。如果我们热血沸腾地讨论了很久，踢鼻子踢脸，发现没有结果，会上的讨论就误入歧途了。我们不妨回归本质，想想自己的产品定位是什么。
产品定义:产品定位包含两大内容，一是产品定义，二是需求定义。产品定义中要分析的内容包括产品的用户、主要功能和产品特性。
比如你现在想开一个移动招聘APP，作为产品经理首先应该做什么？中国每年都有庞大的就业人口和各种行业，所以你要想好你的产品打算服务什么样的人群。如果你想服务所有行业的人，那是不可能的。首先，一个小公司很难整合这么多行业的招聘信息。另外，每个行业的人对互联网的接受度也不是那么高。
通过数据分析和研究发现，现在国家鼓励创业，创业高峰期必然会产生大量的人力需求。尤其是几乎可以说创业与互联网无关，从事互联网的人对APP的接受程度很高，至少愿意尝试。所以你把互联网行业的从业者当成了你产品的用户。
当你分析其他招聘app时，发现这些app存在很多问题。例如，我只想在北京的Xi二七找一份工作，但目前许多app都没有筛选。虽然可以海选，但是得到的反馈很少；企业信息太少，看不懂；在投递成立之前，作为求职者，我想知道这家公司的老板是谁；现在互联网时代，电子简历完全可以。为什么招聘人员每次招聘都需要自己打印简历？求职者打印简历不是很方便，因为随时会变，求职者很不方便。所以你要做这个APP，它的特别之处是:
1，位置支持企业位置分类；
2.招聘人员要经常给求职者反馈；
3.取消纸质简历。主要功能是招聘。
现在我们把这个APP命名为飞鸽招聘。
需求定义:需求定义的分析包括目标用户、使用场景、用户目标三个方面。会使用你产品的目标用户是什么样的人；主要功能是指你的产品是用来做什么的，工具是社交还是其他；你的产品和市场上的其他产品有什么不同？这是产品特性。
刚才已经明确了app的适用人群、主要功能和产品特点。市面上的一些招聘app是给想跳槽的猎头用的。你的app的目标用户是谁？基于特色功能分析和用户痛点，产品的目标用户是想在特定地点找工作的人，比如已经在北京后沙峪落户，想去望京工作的人。当你刚搬到回龙观时，当你面临跳槽时，你可能会倾向于在Xi二七找工作。
以上是所有产品定位的内容。这些完成后，接下来就是竞争产品分析和用户调查。这一方面是对我们需求的一定验证，另一方面也是我们直接接触用户的机会，看看用户有什么需求。
前期需求筛选是一件很辛苦的事情。如果产品经理是老板本人，他的头脑是清楚的。如果不容易陷入海量的需求中，讨论之后他就会误入歧途。经过讨论，似乎所有的功能都需要。这个函数很有用，必须添加。那个功能太好玩了，用户一定很有趣。这种说法总是完全主观的，往往当时听起来很有道理，事后却经不起推敲。所以我们需要时刻把握产品的定位和优先级，千万不要盲目的在这个地方做出很多无畏的牺牲和挣扎(少一些欠考虑，拍脑袋，不加思考的决策)。
需求记录表:
在前期需求的筛选过程中，会有很多这样或那样的需求，有些是我们不能马上判断出来说好的。这些想法可能会成为我们未来产品迭代的灵感点，也会给产品的开发带来更广阔的思路。做好管理，尊重大家的想法，记录下任何模糊之处，对会议的推进和进展都有很大的帮助。
市场需求文档和业务需求文档一般在大公司会比较成熟。在小公司，大部分都是老板自己决定。老板不一定会做这样那样的文档，但是他自己肯定会做一个基本的了解，或者他对某个行业非常了解。这两份文件既不是多余的，也不是累赘的。在项目开始之前，花一些时间深入了解行业和用户是非常必要的。具体的文档细节这里就不细说了，网上有很多文档可以参考。
作为一个不是技术出身的人，这里不再写了。尊重开发者，和开发搞好关系，对产品的推广会很有帮助。
在上一篇文章中，我已经告诉了你项目开始前应该做的三块1和要求；2.商业；3.技术。这些准备工作梳理好之后，接下来就是实施了。实现过程不像以前那么宏观，但是你需要足够的细心和耐心。
需求生成后，产品人员就可以制作需求文档，对后续的交互设计(创业公司往往由产品经理担任)和UI设计起到关键作用。当然，在生成需求文档的过程中，如果有专职的交互设计，最好在需求阶段就和产品人员讨论需求文档的细节，有助于交互设计师了解整体需求，也有助于他原型化和编写交互说明。
需求文档一般包括以下几个方面:
背景描述:你为什么发起这个项目？你为用户解决什么问题？会有多值钱？大致是对项目开始前所做功课的总结，一定要简洁明了。
用户画像:对用户特征的虚拟描述，以明确用户的情况。
项目时间规划:什么时候出样机？真正的设计稿什么时候出来？什么时候进入开发？考试什么时候开始？什么时候开始向App Store提交？这些都需要说清楚，否则如果没有时间概念，一切都拖拖拉拉，没有紧迫感。
信息结构图:APP的内容组织结构。下面举个例子，简单给出微信的基本架构。
任务流程图:对于APP内的大功能，梳理用户从头到尾的全过程，把各种可能都考虑进去。不然以后发展遇到问题问你，你还得重新考虑。更可怕的是，开发没问你就直接开发了，结果不是你想要的。以一个简单的登录为例:
要求:明确每次操作的条件和结果。如果你能用语言表达清楚，那就用语言。如果说不清楚，最好用图片。可能有人会说，这个时候没有线框，怎么解释？这并不矛盾。早期的需求文档是用来交互的(还是那句话，创业公司的产品可能是交互的)，交互设计师会根据你的功能结构和流程梳理，设计出线框和高保真原型。
数据嵌入点:把以后要查看的数据列一个清单，比如这个按钮的点击率，这个页面的打开率等等。这时候就需要多和运营沟通，把需要埋的地方整理出来。这对产品上线后的数据分析很有帮助，数据也可以辅助产品功能的迭代。
需求梳理好之后，接下来就是线框、页面流程、高保真原型、交互讲解的设计和输出。高保真样机看具体情况。有些公司有要求，有些没有。
尽量把每一页的视觉效果表达的简单明了。最好不要加互动，也不要弄得五颜六色，最好是黑灰色的。每种情况都是一页，每种情况都用一页来表达。一方面，你会更清楚整个APP的界面数量，设计会更清楚自己想要什么。不然加入了交互，就不知道怎么设计了。你得解释很久。
类似于之前的信息结构图和页面流程图，用各个页面来连接，在视觉上让各个链接的连接和跳转更加清晰。
对交互的要求会更高。要完整展现各种功能之间的交互，尽量在视觉上还原真实产品的外观。(关于Axure，可以学习孙吴的课程，很不错。很多人觉得太罗嗦，但是你仔细看还是会得到很多货的。)
个人认为交互描述和高保真原型是有重叠的。如果做的高保真，大部分交互动作基本都能显示出来。但是有些地方的交互效果是软件解决不了的，这时候你就需要用交互来解释了。
如果不想解释文字和图片，就用纸模拟。不要小看这种方式。
下面是一些交互标注的工具:mac电脑是草图；windows下有snagit，Circle Point，FScapture，viso也可以标记。
一般情况下，交互设计师把线框交给设计师，设计师就可以开始工作了。在这个过程中，交互也要和设计沟通。毕竟UI会有自己的专业性，她会有自己的设计意见，这很正常。
设计已经产生，交互工作已经完成。是时候交给项目经理去执行了。目前这个地位只有在非常大的公司才有，一般都是由产品经理直接担任。这里需要提醒的是，在实施之前，要先建立各种相关规范。例如:
以下都是我的亲身经历。做好这些，对以后安装包的管理有很大的帮助。当时我们搭建了一个开发者环境。这种环境下的APK和API文件只能在局域网中使用。在这种环境下，我们可以在不影响已经上线的应用的情况下，随意折腾测试。
开发人员环境中打包的安装包的图标和命名应该与在线环境中的应用程序区分开来。以后继续测试就不会因为各种版本而手忙脚乱了。
4.2.1开发版:纯为自用或产品使用而开发，其他无关人员一般不会接触到该版本。网络环境:仅用于特定的网络环境(需要技术人员搭建环境)。
4.2.2公测版:经过产品和测试人员的详细测试，基本没有bug，可以拿出来给公司的人使用，也是上线前的稳定性测试。网络环境:只能在特定环境下使用(搭建环境需要技术)。
4.2.3商店版本:向市场提交APK和API文件。经过开发版和公测版的全面测试，消除了所有不稳定的bug。此时，打包的商店版本仍然需要测试人员的最终检查。最后，必须保证将要启动的APK和API文件是测试人员的最终检查。否则如果开发改变了，测试人员和产品人员都不会被告知，等推出后再做改变就来不及了。
前期要明确好版本号的管理，否则后期产品上线后，bug会得到改善，或者添加新功能后老版本会不会受到影响。这个时候，好的版本号管理就会发挥很大的作用。一方面可以随时找出之前上线过的apk和API文件，另一方面面对不断修改打包的文件也不会迷惑自己。
以下为个人观点，如哪位大牛有好办法分享一下。版本号永远是唯一的，依次迭代递进。不要为了上线的时候好看而故意干扰版本号。严禁搞多套版本号。
测试说明:
在UI、交互、产品的开发阶段，需要多和技术人员沟通。最好把大功能细分成小功能模块，每做好一个部分就通知相关人员检查，避免最后出现太多问题和太多修改动作。UI负责盯着开发是否按照自己的设计实现，交互负责关注交互效果是否符合你的标准，产品负责关注每个功能是否正确实现。
测试用例:一个好的测试用例能够有效地推动测试过程。一个好的测试用例就是尽可能清晰地用人类的语言描述需要测试的各种情况，这取决于你的写作能力。测试用例写好后会交给测试人员进行测试，这也是他们判断APP是否达标的标准。
Bug管理工具:bugtags、bugclose等。市面上有很多，大部分都是免费的。即使收费也不要在乎钱少。借助于bug管理工具，可以有效提高测试人员和技术人员的合作效率。
之前给大家介绍过两个部分，项目开始前和项目执行过程中。项目上线后，作为产品有几个方面需要关注，一是APP数据，二是用户反馈，三是需求提取。
新用户:第一次启动应用程序的用户；
新独立用户:所有应用程序的新用户总数(重复数据删除)
活跃用户:当天启动一次的用户为活跃用户，包括新用户和老用户；
活动独立用户:同一天应用的活动用户总数(重复数据删除)
Mau :MAU的月活跃用户数:MAU(月活跃用户)。
Dau:Dau的日活跃用户数(日活跃用户)。常用来反映网站、互联网应用或网络游戏的运行情况。
用户留存率:在互联网行业，在一定时间内开始使用该应用，并在一定时间后继续使用该应用的用户被视为留存用户。这些用户占当时新增用户的比例就是留存率，每隔1单位时间(如日、周、月)就会统计一次。
用户留存率40-20-10法则:如果你想让游戏和应用的DAU超过100万，日留存率要大于40%，周留存率和月留存率分别要大于20%和10%。
次日留存率:(当日新增用户中第二天仍活跃的用户数1)/首日新增用户总数；
第二天留存率:(首日新增用户中，第二天仍有活跃用户)/首日新增用户总数；
第7天留存率:(首日新增用户中，第7天仍有活跃用户)/首日新增用户总数；
30日留存率:(首日新增用户中，30日仍有活跃用户)/首日新增用户总数。
另一个是APP的埋数据。这个功能的点击率是多少？有多少人开启并使用过这个功能？有多少人在经常使用这个功能？等等，这些被埋没的数据要时时关注。结合数据变化反思功能设计的问题，从而优化产品。
产品上线后，用户的反馈和评论对产品人员来说是特别珍贵的资料。这一方面是你真实用户的直观感受，另一方面表达了他们的直接需求。那么，如何处理用户的意见就显得尤为重要。用户给我们反馈什么我们就做什么，这肯定是不行的。很多时候用户表达的只是表面现象，要学会挖掘用户背后需求的本质。多研究世界上革命性的产品，多了解人。
当我们看到观点满天飞的时候，我们应该学会思考，而不是全盘接受和照搬。
这是我们的目标吗？想想我们的目标用户是谁。
使用场景是否有效？还是这只是非常个人化的场景需求？
用户目标是否正确？我们的APP是用来满足用户需求的吗？
产品定位是否正确？如果做这个功能，还符合我们产品的定位吗？
想做这个功能，自己的项目资源能满足吗？如果你需要所有的资源来做这件事，你必须再次谨慎。
也许用户的意见是一个圆，但是分析之后，很有可能需求是一个三角形。
“如果我第一次问消费者他们想要什么，他们会告诉我，‘一匹更快的马！’"
这是亨利·福特的一句经典名言，现在我们又在《乔布斯传》中看到了。
100多年前，福特公司的创始人亨利·福特先生四处询问顾客:“你需要哪种更好的交通工具？”几乎所有人的答案都是:“我想要一匹更快的马。”很多人听到这个回答，马上跑到马场选马配种，满足客户的需求。但是福特先生没有马上跑到马场，而是继续问。
福特:你为什么需要一匹更快的马？
顾客:“因为它能跑得更快！”"
福特:你为什么需要跑得更快？
顾客:“因为我可以更早到达目的地。”
福特:“那么，你想要一匹更快的马的真正意图是什么？”
客户:“用更短的时间更快的到达目的地！”
所以福特没有跑到马场，而是选择制造汽车来满足客户的需求。
顾客需求有两种类型:显性需求和隐性需求。我们通过市场调研了解到的，往往是一些“我想要一匹更快的马”之类的显性需求。客户的显性需求并不是客户的真实需求。企业需要根据收集到的显性需求信息进行深度挖掘和捕捉，从而了解客户的隐性需求是什么，进而分析出客户的真实需求是什么(比如在更短的时间内，更快的到达目的地)。这是一个需求分析的过程。
乔布斯说:“我们的任务是理解还没有落在纸上的东西。”其实就是对用户隐性需求的深度挖掘。
原文:/a/20160309/291676 . html。