app项目开发-「app开发流程详解」

admin app开发文章 2019-08-21 18:27 0
 
 产品以解决用户核心问题为目的。这里的一个关键词,用户核心问题。可以理解为需求,虽然两者有区别,但是这样画上一个≈号,没什么不妥。我们遇到了产品迭代第一步需求的第一个阶段
 
 1:项目需求
 
 app项目开发之需求获取
 
 获取需求的方式,也就是需求的来源:
 1:商业需求-来自于商业化团队,或者老板、合作商,外包团队多见于甲方;
 2:用户反馈-来自于各大应用商店的用户评论或应用自带的用户反馈,也可以是客服团队的用户反馈,问卷调查等;
 3:团队其他部门-来自包括但不限于测试、运营、开发、产品等团队;
 4:自身挖掘-产品线负责人体验自身产品、对比竞品、数据分析来得出的需求点。
 身为产品经理在这个阶段要做什么?简单的收集和整理,就足够了。
 
 app项目开发之需求分析
 
 顾名思义,不是所有的需求都是真正的需求,这就需要产品经理掌握需求分析的技能。首先是筛选,讲一些明显与产品定位背离的需求过滤。还有一部分需要过滤的需求,即不合理的需求或小众化场景的需求。综上可以统称为伪需求,如何辨别真伪需求是一个永恒的话题,作为一个初出茅庐的产品经理,以理解自己的产品为基础,若不能很好的判断。个人建议请教前辈,或了解这个产品的人,领导、同事,都是你可以咨询请教的对象,但是也要注意方式,不是拿着一堆需求,听他讲,哪些哪些是伪需求。一定是你先进行尝试,然后再拿有疑问的去请教。不耻下问,才能进步,这也是一种学习的方式,而且是很好的学习方式。第一步筛选过后,剩下的基本就是真需求了,我们已经完成了“做还是不做”这个问题,这时候又会面临一个问题“什么时候做”,网上有许多具体的方法,比如四象限分析法,kano原型等等,这里就不一一赘述了,还是那句话,作为一个初入产品的年轻人,要学会不耻下问,不要指望一下子就会把一件事做的很好。
 
 

 
 app项目开发之需求管理
 
 学会如何管理好需求,对产品经理接下去的产品迭代有很大的帮助。创建一个自己的需求池,并保持不断更新,从中发现产品迭代的方向。这里贴一个自己的产品需求池,放不了太多,大家谅解一下。表内包括了需求的收集和整理,也包括了需求的分析,还有需求的状态和时间等记录。
 
 2:app项目开发之竞品分析
 
 当你从得到下个版本的需求以后,身为产品经理的你需要做什么。当然是对需要的功能进行设计规划啦,这时就少不了做竞品分析。注意,初入门的产品经理,一般都会被分配到一个小功能的优化和迭代,所以像产品培训班的对整个产品做所谓的深入分析,一般没什么X用,很少见有应届生或刚转行的产品能负责从0-1的,况且从0-1,也不需要如此大费周折的长篇大论。
 
 那么在真实工作中,我们需要的一份正确做法的竞品分析,应该是什么样的呢?
 
 1:明确竞品分析的目的;解决一个实际的问题,比如要做购物车的商品分享功能,想看看同行都怎么做?
 2:选择好竞品分析的对象选择细分行业的前二/三即可;比如对于淘宝公司来说:天猫,京东,就是不错的选择;
 3:对比目标状态的截屏,放到一起;横向放置不同产品同一功能的截屏,纵向放置当前功能页面的不同状态;
 4:在页面合适的位置可以使截屏右侧叙述优缺点,和自己的思考与总结;
 5:通过对比分析,得出自己的观点,我们应该怎么搞?
 
 3:app项目开发之原型
 
 原型是产品经理很关键的一个输出物,个人不推荐用墨刀或者mockplus等原型工具,还是喜欢用axure,当然更推荐有条件的同学使用sketch。我想讲述的并不是如何使用这些工具,我想讲述的,是一个产品新人,如何去产出原型。流程来到这里,你已经做足了功课,完成了竞品分析,now,就是把需求落地的第一步,产出一个demo,也就是原型设计稿。这里引申出两个问题:
 
 你是否已经完美的完成了竞品分析,明确需求的规划和设计?是否已经决定参照哪一款竞品或者已经有了自己的规划和设计?
 
 有自信鉴定的回答是好事,但是往往事与愿违。因为,经历不足导致你还摸不透领导的想法,你还不知道需求到底想达到一个什么样子的效果。怎么办?如果在做竞品分析的时候没有和领导讨论过。那我想最好的方法,就是参照竞品,结合自己的产品,设计出多套原型稿,根据自己的思考和分析,推荐一套,并跟领导进行讨论,在过程中讲明各方案的优劣。如果在竞品分析时已经完成了和领导的沟通,也不要局限,至少产出两套原型方案,再和领导沟通。如图(比较粗糙。。突然找不到好点的了,将就下吧):
 
 再补充一点,许多产品经理在纠结做高保真还是低保真的问题上分歧很大,我对这个问题的看法是这样的,在所限时间内,根据任务轻重缓急,能画的高保真一点就高保真。我的许许多多迭代需求原型都是直接在原图上进行修改的,效果看上去会很直接。高保真原型也有利于UI进行视觉优化,可能有人要反驳我了,但站在UI的视角上,你给我一个很丑的原型,我连看都不想多看两眼。能画高保真,为什么不呢?对自己也是一种技能的提升,何乐不为。下图贴自己的低保真,0-1的项目,任务重的情况下我也会画低保真,但是效果上绝对不会做的很差劲。
 
 4:app项目开发之PRD文档
 
 prd文档无疑是产品经理输出内容的重中之重了,上下游交付,全靠这份文档。这里小小diss一下pmcaff的高赞文,题目叫上下游都喜欢的XXX文档。大概是这个名字,我看了以后很不是滋味,因为这样的文章,包含的内容太多,任凭UI还是开发,不会有那么多时间,来看这种文档。
 
 prd文档不是写完上交,就可以了。要保持实时更新,特别是版本的需求变更等情况,要及时的记录并更新,一是为了 不背锅 ;二是为了等待下一位有缘人接盘的时候,需求出现偏差不知所措。
 
 5:app项目开发之需求评审
 
 APP开发公司指出在完成了原型和PRD文档以后,需求评审就到了终于要交付的时候了。你要做到的就是告诉上下游,项目组的所有人,这个版本我们要做什么,为什么要做这个,设计是怎么样的,预计上线时间等等。当然,这样直接讲,压力难免有些大,而且,你怎么保证你写的文档没有问题呢?so,我们来讲一讲需求评审的流程。
 
 在确定方案并完成了初版的prd文档v1.0之后,与产品线领导1对1,或产品组内部,进行需求评审。指出不足和有问题需要修改的点。大概流程就是你先讲一遍,然后大家讨论,自己做记录,然后结束后抓紧时间讲prd文档进行完善。
 
 然后的然后,在prd文档v1.1会有专家组(boss们)对prd文档进行专家评审,有问题则指出并修改,循环。没问题则选良辰吉日,交付项目组其他成员(一般为设计团队和开发团队)。
 
 第三轮,prd文档v1.2,可以交付设计团队和开发团队了。无可避免的,会上大家会各自发表意见,会发生诸如,需求变更,需求延期等常见问题,身为产品经理的你,要记录并整理,参与讨论甚至主导讨论,多站在对方的立场看待问题,并试图说服别人 或者被别人说服 。同样,需要快速产出prd文档v1.3,确认无误后,交付设计和开发团队,进行下一阶段。这里顺带提一句,如果是Axure完成文档的小伙伴,建议在设计产出作品后,将prd文档中的图片进行替换,可能有人会说多此一举或者麻烦,但是好处是显而易见的,开发可以看得更明白更直接,问题会少很多。
 
 至此,需求评审结束,prd文档经过一系列的修改,完成归档。
 
 
 
 6:app项目开发之对接UI & APP开发
 
 这个话题也是产品届经久不衰的话题了,不多做赘述,没有什么意义。个人的意见是,在设计团队,开发团队,测试团队,运营团队,任何人在这个版本,或者你负责的某个功能上有疑问的时候,你都要及时出现,说明并解决问题。保证进度正常。至于如何和大家沟通,这个全凭自己,谁都教不了你,一句话:不会沟通,难以胜任产品经理。
 
 补充一点:进入开发以后,产品经理可以就下一轮的版本迭代计划进行筹备了,即开始接需求,然后就是循环往复了。
 
 7:app项目开发之需求验收
 
 app开发公司批出:需求验收不等同于测试,测试有专门的测试方法论和测试工具。产品的需求验收,指的是对自己负责的功能点进行验收,确认与设计稿是否一致,确认是否存在问题。这个流程非常重要,直接关系到了预想和实际的差距。这个阶段多发的状况,是在原先的基础上进行优化,这是很正常的,在不改变需求的情况下,更好的将需求落地。同样,期间可以安排设计团队走查,保证UI稿的正确性。同时,更新项目进度表,记录并整理开发时间,进入测试流程。
 
 8:app项目开发之上线跟踪数据
 
 一般APP上线流程:选择一个小渠道进行灰度测试,以防不测。在确保一系列的数据正常没有问题的情况下,再推广到所有渠道,并开放升级。APP的一些重要数据:错误率、日活、新增、留存、新增事件点击等等。一般对于新版本,最关心的错误率和新增事件点击。所以会做一个简单的表格来做记录。
 
 完成每一轮的工作之后,都需要进行汇报,因为根据领导部门的要求,可能会要求加快项目进度或新增某些紧急需求,不要闷头干活两耳不闻窗外事。四通八达的产品经理,才是大家喜欢的产品经理。
 
 以上就是app项目开发-app定制流程详解全文,希望对大家有所帮助!

发表评论

评论列表(条)