【app开发】手机APP的研发和设计流程
2017-12-26 10:40:31大局观
产品的研发流程分为四个步骤：产品定义——交互设计——开发——测试。这四个步骤也分别对应研发中的四个角色：产品经理——设计师——开发工程师——测试工程师。
产品定义阶段的目标就是确定用户场景，定义产品的功能和范围。
而设计师需要根据这些用户场景和功能范围进行交互设计。
之后开发工程师将会根据产品经理和设计师的方案进行写代码，把这个方案实现成可用的产品。
之后的再由测试工程师进行产品测试，以保证产品达到了产品经理和设计师的这个要求。
步骤细分：
一、产品定义
从用户需求初步定义产品功能
1、关于需求
在这里要谈论的主要是用户需求和产品需求。
1.1用户需求和产品需求
首先必须要搞清的是用户需求不等同于产品需求。
用户需求，简单来说是用户希望同构使用某一款产品来实现和满足某种需要。如安全、娱乐、沟通、交友等。用户需求是用户对某类产品真实需要的反应。
而产品需求，是某一类产品或服务能够满足用户需要的集合。也就是说，用户需求并不完全传递到产品需求当中去。而产品需求的获取渠道也不仅仅是用户需求。
1.2获取产品需求的方式
(1)用户需求：用户需求是产品需求的核心来源。但并不是所有的用户需求都能转化为产品需求。用户需求需要子可行性和必要性验证上，才可以转化为产品需求。
(2)相关利益合作伙伴：开发商、咨询机构、制造商等等。他们通过对市场的研究分析和对运营所积累的产品需求，是设计分析产品需求很好的参考。
(3)竞品分析：对竞争对手主要产品进行对标研究，分析其产品的成败关键和发展趋势，了解市场对类似产品的反馈。
(4)标杆市场：标杆市场是国内外在同类产品上运营比较成功的热门行业，通过对标杆市场中知名企业所运营的相近产品的功能进行剖析。可以了解国际与国内在该类产品上的先进做法。
(5)企业内部产品研讨会、员工体验及内部专家评估。
1.3用户需求的提取与挖掘的方式
了解用户需求的有效方式是用户研究，这是用户中心设计流程的第一步。其主要研究方式是：用户访谈、用户观察、问卷调研、焦点小组、眼动实验等等。并对由此得到的信息与数据进行处理和分析。从中提取制作出初步的用户需求文档。
显然这些需求是不够的。这些需求仅仅是用户在现有需求上的反馈。此外，设计师可以利用在用户研究阶段所生成的人物角色(人物画像)这个工具，并放置到具体场景中，从而挖掘用户可能的潜在需求。
(1)通过用户研究直接获取
用户研究阶段可能会出现各式各样的问卷及数据列表。这些数据的收集活动并不难，所需要付出的只是耐心和时间。
为了更多更好的获取初步用户的需求，用户研究员需要在问卷调查的问卷设计 、用户访谈、焦点小组等的脚本设计中，明确哪些问题或者选项是为需求而设置的，以便后续阶段的整理。
(2)在场景中运用人物角色进行挖掘。
人物角色的来源、概念及功能：人物角色不是真实的人，但它是基于我们观察到的那些真实的人的行为和动机，并且在整个设计过程中代表真实的人，是在人种学调查收集到的世纪用户行为数据的基础上形成的综合模型。在研究阶段我们观察用户的行为模式，在建模阶段将其模式化，最后生成人物角色。
也就是说人物角色源自于用户研究。研究人员通过用户研究，通过一定的标准将众多的用户进行细分，从而得到不同的细分用户群组。
细分的用户群组经过一定的评估、调整，从而确定细分角色群组。角色群组经过一定的润色。诸如为每个角色群组赋予具有代表性的照片、名称、职业、性格等鲜明的人物属性，从而形成不同的人物角色。
人物角色通常因其重要程度及特定定义为：首要人物角色、次要人物角色、不重要的人物角色、排斥的人物角色。
通过建立人物角色，从而将用户研究结果以一种简单直观但又非常有效的方式使设计团队成员(决策人员、产品经理、交互设计师、视觉设计师)等对大家所面对的客户群形成一致的了解。
场景的概念与作用：用户角色是死的，静态的东西，只有将其放到一定的场景中去，才会鲜活起来，与产品产生交互。
场景是人物角色与产品进行交互的“理想化”情景。它讲述的是每个人物角色如何与产品进行交互的故事。每个人物角色都将对应一个场景，甚至更多，以求覆盖用户使用场景的各种情形。
在场景中使用人物角色进行需求的挖掘:针对每个人物角色，设计合理的场景，然后集合相关的工作人员(不仅仅是交互和视觉设计师)一起进行头脑风暴。再此阶段每个人要有深度的同理心，并在每个关节点将所能想到的可能性完全说出来，记录下来，此时的气氛也是不加约束和不带批判的。
在此以时间为轴“生活中的一天”为例，来针对手机浏览器产品利用人物角色来进行需求挖掘。譬如：
早晨起来，刚起床：会看天气预报、日历中可能涉及的功能：天气查询、日历。
吃早餐的时候：可能会看新闻、邮件以及自己的博客。这样就会设计到新闻、微博以及邮箱。
以及交通途中：上午办公室：中午午餐：下午办公室：下班前：下班途中：餐厅里：家中：被窝里等等各种状态下来挖掘可能用到的功能。
每个人物角色通过一个或多个场景的挖掘，要对其所涉及到的功能进行罗列，并根据其在每个人物角色的重要性定义每个功能的权重，并建立excel档。
1.4用户需求提升为产品需求，由此得出产品功能需求列表
以上得出的用户需求，并不能直接转入产品需求，需要经过一定的评估和帅选考察其可行性和必要性。
可行性：目前的技术和企业资源是否有能力，是否能在现行的情况下，与进度时间表等现实条件下开发出完全满足用户需求的产品。
必要性：用户的这些需求是否有需要满足，满足这些需求企业需要付出的代价，以及是否有足够的企业效益来支撑市场的运营。
经过上述验证，并结合前面所叙述的相关利益合作伙伴、竞品分析、标杆市场及企业内部研讨会等所得到的用户需求，从而得到完整的用户需求列表。
在此所有的产品需求都转化为产品功能。工作人员可以将之前用户研究阶段收集的功能需求合并到后来利用任务角色在场景下挖掘的需求列表中。他们本质上也相应对应着不同的人物角色。
在这里，角色的权重(可以根据首要人物角色、次要人物角色、不重要人物角色等分成3点量表或者5点量表)与对应的任务的权重的乘积，就是功能总的重要程度。
二、交互设计流程
(一)交互设计三段式
草图——低保真原型——高保真原型
草图：就是使用纸和笔去手绘这个界面草图，以便快速的和产品经理以及其他同事进行讨论，在进行想法具体化。
我们看到的这张图实际上他画的相当规整，它已经是一个完整的产品架构图。但是我们工作中的话可能只是信手拈来，草草的画上几笔，这些都没关系，草图强调的就是能快速地将想法具体化，然后和其他同事进行讨论。
低保真原型图：就是在草图的基础上，通过计算机的帮助，由简单的线框和文字去绘制这个界面。当然，低保真原型不能只是简单的看，还要进行一些简单的交互操作。用白话来讲就是动态，可以简单地进行体验一下这个设计，尽可能的发现一些问题。去进行一定的修改。
我们看到的这张图实际上他画的相当规整，它已经是一个完整的产品架构图。但是我们工作中的话可能只是信手拈来，草草的画上几笔，这些都没关系，草图强调的就是能快速地将想法具体化，然后和其他同事进行讨论。
低保真原型图：就是在草图的基础上，通过计算机的帮助，由简单的线框和文字去绘制这个界面。当然，低保真原型不能只是简单的看，还要进行一些简单的交互操作。用白话来讲就是动态，可以简单地进行体验一下这个设计，尽可能的发现一些问题。去进行一定的修改。
高保真原型图：就是先在这个线框图的基础上进行视觉设计，在将这个视觉设计稿呢制作成可进行交互操作的原型。这个效果很可能都能和最后的那个产品相差无几，甚至你可以在你的手机上进行模拟的操作。
高保真原型呢一般用于交付给开发与测试那边。开发人员将按照高保真原型进行开发。测试人员将以高保真原型为基准，对开发人员交付的产品进行测试。
所以大家可以看到，在设计流程中，设计师首先要通过草图与产品经理以及其他同事进行讨论，以确定产品的设计方向。之后再做一个低保真原型来进行打磨设计。在之后会制作高保真原型来交付给开发和测试人员。
所以设计师的整个这个设计工作都是一个和其他角色进行沟通的一个过程。而我们刚才提到的设计的三个步骤也是围绕沟通而展开的。
(二)为什么要画原型
减少修改成本，便于沟通讨论
画原型最大的目的呢，是为了减少后期修改成本，用一个低成本的原型去体验去讨论，去修改，尽量避免开发好了再去修改。第二呢，一个可交互的原型更方便和其他人去进行沟通和讨论，所谓一图胜千文。所以图片比文字的沟通效果要好很多。那么，如果说是原型，或者可以交互的原型，它的沟通效果就要比图片要好很多。
所以，需要强调的是，原型只不过是一个设计工具，设计的思想才是真正的核心所在。所以，在学好工具的基础上，应该多花时间在设计思路的学习上。
三、开发
接下来就到了程序员编写程序的三个步骤了。(关于开发，在这里不做详述)
1、app软件开发大功能模块代码编写
2、app软件开发大概的界面模块编写
3、把大概的界面和功能连接后，app软件开发的大致demo就出来了
4、demo自己试用和体验几遍后，根据情况修改
5、没有大错误后，0.9版本可以尝试寻找beta用户
6、根据测试用户的反馈，重复 前三个步骤
四、测试
测试工程师，一般就是从用户角度出发，检测开发工程师做的东西是不是符合产品的需求，或是用户体检好不好?不要求有太专业的知识，但是要细心，对产品敏感。所以有很多不是计算机专业的人员照样可以做测试工程师，因为我们的产品需要不同的人来说嘛。
也有比较专业的白盒或是灰盒测试，这就要求测试人员会些儿编程技术了，但是要求不太高，不必会某种语言的高级编程，普通应用或是代码段能看懂就行。问题要考虑全面，细致，有原则，不能跟着开发和产品走，这是测试人员的要求。
(一)软件测试的测试流程有：
制定测试计划——编辑测试用例——执行测试用例——发现并提交BUG——开发组修正BUG——对已修正BUG进行返测——修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活.
(二)规范的测试流程
需求分析：需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。
需求评审：这里会叫上所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求
开发人员编写排期：开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。
测试计划排期：测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。
编写测试用例：根据详细的需求分档，开始进行用例的编写。
用例评审：在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。
然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。
提交基线：开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。
(三)具体测试流程：
开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。
测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
测试通过：经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。
验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。
流程分析：这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。
那么这个流程是不是完美的呢?不，这个项目流程太强化各种文档。我们来看测试的工作内容，测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。其实，我们真用于测试的时间是非常少的，在一周的时间，也许只有一天或不到一天的时间是在进行测试的。测试人员只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。
当然，我这里会省略与测试主流程无关的东西，真正的测试工作中琐事很多。
(四)敏捷测试流程
前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了;开发开发完成之后给测试，然后开发人员也不忙了。
测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的(这里只对单一项目)。
开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。
敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
1、下面是我理解中的敏捷测试流程图：
第一阶段：通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢?会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。
流程分析：在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
2、对测试问题的处理
上面的图更能清晰看出对问题的处理过程。
第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。
