作者：巨人电商

如何开发手机App系统软件，App开发的流程是如何的

POST TIME:2021-08-20

分析永远是分析，模板永远是模板。分析不能落地，就是0，模板永远只是个框架，走不出来就是死胡同。抽空会不断更新文章，目前计划写两篇，其一为产品迭代流程，其二为从0-5的产品流程。

互联网是个神奇的大网，大数据开发和软件定制也是一种模式，这里提供最详细的报价，如果你真的想做，可以来这里，这个手技的开始数字是壹伍扒中间的是壹壹叁叁最后的是驷柒驷驷，按照顺序组合起来就可以找到，我想说的是，除非你想做或者了解这方面的内容，如果只是凑热闹的话，就不要来了。

产品迭代流程：

一、需求

5、需求获取

2、需求分析

5、需求管理

二、竞品分析

三、原型

四、Prd文档

五、需求评审(包括修改需求)

六、对接UI，对接开发

七、需求验收

八、上线，跟进数据

回到正题，如何主导产品线的迭代。个人习惯，一图流。

一、需求

产品以解决用户核心问题为目的。这里的一个关键词，用户核心问题。可以理解为需求，虽然两者有区别，但是这样画上一个≈号，没什么不妥。

我们遇到了产品迭代第一步需求的第一个阶段：需求获取

获取需求的方式，也就是需求的来源：

5、商业需求-来自于商业化团队，或者老板、合作商，外包团队多见于甲方;

2、用户反馈-来自于各大应用商店的用户评论或应用自带的用户反馈，也可以是客服团队的用户反馈，问卷调查等;

5、团队其他部门-来自包括但不限于测试、运营、开发、产品等团队;

4、自身挖掘-产品线负责人体验自身产品、对比竞品、数据分析来得出的需求点。

身为产品经理在这个阶段要做什么?简单的收集和整理，就足够了。

随后是产品迭代第一步需求的第二个阶段：需求分析

顾名思义，不是所有的需求都是真正的需求，这就需要产品经理掌握需求分析的技能。首先是筛选，讲一些明显与产品定位背离的需求过滤。还有一部分需要过滤的需求，即不合理的需求或小众化场景的需求。综上可以统称为伪需求，如何辨别真伪需求是一个永恒的话题，作为一个初出茅庐的产品经理，以理解自己的产品为基础，若不能很好的判断。个人建议请教前辈，或了解这个产品的人，领导、同事，都是你可以咨询请教的对象，但是也要注意方式，不是拿着一堆需求，听他讲，哪些哪些是伪需求。一定是你先进行尝试，然后再拿有疑问的去请教。不耻下问，才能进步，这也是一种学习的方式，而且是很好的学习方式。第一步筛选过后，剩下的基本就是真需求了，我们已经完成了“做还是不做”这个问题，这时候又会面临一个问题“什么时候做”，网上有许多具体的方法，比如四象限分析法，kano原型等等，这里就不一一赘述了，还是那句话，作为一个初入产品的年轻人，要学会不耻下问，不要指望一下子就会把一件事做的很好。

最后是产品迭代第一步get需求的第三个阶段：需求管理

学会如何管理好需求，对产品经理接下去的产品迭代有很大的帮助。创建一个自己的需求池，并保持不断更新，从中发现产品迭代的方向。这里贴一个自己的产品需求池，放不了太多，大家谅解一下。表内包括了需求的收集和整理，也包括了需求的分析，还有需求的状态和时间等记录。

二、竞品分析

当你从得到下个版本的需求以后，身为产品经理的你需要做什么。当然是对需要的功能进行设计规划啦，这时就少不了做竞品分析。注意，初入门的产品经理，一般都会被分配到一个小功能的优化和迭代，所以像产品培训班的对整个产品做所谓的深入分析，一般没什么X用，很少见有应届生或刚转行的产品能负责从0-5的，况且从0-5，也不需要如此大费周折的长篇大论。

那么在真实工作中，我们需要的一份正确做法的竞品分析，应该是什么样的呢?

5.明确竞品分析的目的;解决一个实际的问题，比如要做购物车的商品分享功能，想看看同行都怎么做?

2.选择好竞品分析的对象选择细分行业的前二/三即可;比如对于淘宝公司来说：天猫，京东，就是不错的选择;

5.对比目标状态的截屏，放到一起;横向放置不同产品同一功能的截屏，纵向放置当前功能页面的不同状态;

4.在页面合适的位置可以使截屏右侧叙述优缺点，和自己的思考与总结;

5.通过对比分析，得出自己的观点，我们应该怎么搞?

三、原型

原型是产品经理很关键的一个输出物，个人不推荐用墨刀或者mockplus等原型工具，还是喜欢用axure，当然更推荐有条件的同学使用sketch。我想讲述的并不是如何使用这些工具，我想讲述的，是一个产品新人，如何去产出原型。流程来到这里，你已经做足了功课，完成了竞品分析，now，就是把需求落地的第一步，产出一个demo，也就是原型设计稿。这里引申出两个问题：

你是否已经完美的完成了竞品分析，明确需求的规划和设计?

是否已经决定参照哪一款竞品或者已经有了自己的规划和设计?

有自信鉴定的回答是好事，但是往往事与愿违。因为，经历不足导致你还摸不透领导的想法，你还不知道需求到底想达到一个什么样子的效果。怎么办?如果在做竞品分析的时候没有和领导讨论过。那我想最好的方法，就是参照竞品，结合自己的产品，设计出多套原型稿，根据自己的思考和分析，推荐一套，并跟领导进行讨论，在过程中讲明各方案的优劣。如果在竞品分析时已经完成了和领导的沟通，也不要局限，至少产出两套原型方案，再和领导沟通。如图(比较粗糙。。突然找不到好点的了，将就下吧)：

再补充一点，许多产品经理在纠结做高保真还是低保真的问题上分歧很大，我对这个问题的看法是这样的，在所限时间内，根据任务轻重缓急，能画的高保真一点就高保真。我的许许多多迭代需求原型都是直接在原图上进行修改的，效果看上去会很直接。高保真原型也有利于UI进行视觉优化，可能有人要反驳我了，但站在UI的视角上，你给我一个很丑的原型，我连看都不想多看两眼。能画高保真，为什么不呢?对自己也是一种技能的提升，何乐不为。下图贴自己的低保真，0-5的项目，任务重的情况下我也会画低保真，但是效果上绝对不会做的很差劲

四、PRD文档

prd文档无疑是产品经理输出内容的重中之重了，上下游交付，全靠这份文档。这里小小diss一下pmcaff的高赞文，题目叫上下游都喜欢的XXX文档。大概是这个名字，我看了以后很不是滋味，因为这样的文章，包含的内容太多，任凭UI还是开发，不会有那么多时间，来看这种文档。

prd文档不是写完上交，就可以了。要保持实时更新，特别是版本的需求变更等情况，要及时的记录并更新，一是为了不背锅;二是为了等待下一位有缘人接盘的时候，需求出现偏差不知所措。

五、需求评审

在完成了原型和PRD文档以后，需求评审就到了终于要交付的时候了。你要做到的就是告诉上下游，项目组的所有人，这个版本我们要做什么，为什么要做这个，设计是怎么样的，预计上线时间等等。当然，这样直接讲，压力难免有些大，而且，你怎么保证你写的文档没有问题呢?so，我们来讲一讲需求评审的流程。

在确定方案并完成了初版的prd文档v5.0之后，与产品线领导5对5，或产品组内部，进行需求评审。指出不足和有问题需要修改的点。大概流程就是你先讲一遍，然后大家讨论，自己做记录，然后结束后抓紧时间讲prd文档进行完善。

然后的然后，在prd文档v5.5会有专家组(boss们)对prd文档进行专家评审，有问题则指出并修改，循环。没问题则选良辰吉日，交付项目组其他成员(一般为设计团队和开发团队)。

第三轮，prd文档v5.2，可以交付设计团队和开发团队了。无可避免的，会上大家会各自发表意见，会发生诸如，需求变更，需求延期等常见问题，身为产品经理的你，要记录并整理，参与讨论甚至主导讨论，多站在对方的立场看待问题，并试图说服别人或者被别人说服。同样，需要快速产出prd文档v5.5，确认无误后，交付设计和开发团队，进行下一阶段。这里顺带提一句，如果是Axure完成文档的小伙伴，建议在设计产出作品后，将prd文档中的图片进行替换，可能有人会说多此一举或者麻烦，但是好处是显而易见的，开发可以看得更明白更直接，问题会少很多。

至此，需求评审结束，prd文档经过一系列的修改，完成归档。

六、对接UI，对接开发

这个话题也是产品届经久不衰的话题了，不多做赘述，没有什么意义。个人的意见是，在设计团队，开发团队，测试团队，运营团队，任何人在这个版本，或者你负责的某个功能上有疑问的时候，你都要及时出现，说明并解决问题。保证进度正常。其实话语之间，都凝结为一句话，别人在加班，你也就老老实实待着吧，乖。

至于如何和大家沟通，这个全凭自己，谁都教不了你，一句话：不会沟通，难以胜任产品经理。

补充一点：进入开发以后，产品经理可以就下一轮的版本迭代计划进行筹备了，即开始接需求，然后就是循环往复了。

七、需求验收

需求验收不等同于测试，测试有专门的测试方法论和测试工具。产品的需求验收，指的是对自己负责的功能点进行验收，确认与设计稿是否一致，确认是否存在问题。这个流程非常重要，直接关系到了预想和实际的差距。这个阶段多发的状况，是在原先的基础上进行优化，这是很正常的，在不改变需求的情况下，更好的将需求落地。

同样，期间可以安排设计团队走查，保证UI稿的正确性。

同时，更新项目进度表，记录并整理开发时间，进入测试流程。下图贴一个自己的项目进度表吧，看起来更加直接一点。

八、上线，跟踪数据

一般APP上线流程：选择一个小渠道进行灰度测试，以防不测。在确保一系列的数据正常没有问题的情况下，再推广到所有渠道，并开放升级。

APP的一些重要数据：错误率、日活、新增、留存、新增事件点击等等。