app开发
角色
PM（策划）→交互→视觉→开发→测试（QA）
策划阶段
我们需要形成一份策划案，通常由我们的投资方或者说管理层对产品或者说项目进行拍板，之后PM需要对产品或者项目进行分析，策划以及评估，形成书面的文档，通常或者一份pdf格式的文档或者是一份word文档，之后我们开一个会议，将和项目相关的人员全部请来，就这一份产品或者是这个项目进行评审，评审之后我们要开始着手去启动项目，相关人员需要做准备，负责交互模型的人员需要根据PM的策划案或者项目启动书去准备APP的交互稿，通常就是我们所说的产品原型图，当然有时原型图也是PM需要做的，当然UE或者UX这部分设计关键还是要关注到用户体验，有的企业会有独立的人去做，大部分企业的这部分工作是PM兼职完成的，这和一家企业对开发的分工有关。
UI
我们的UI当然要尝试去提出自己的视觉方案了
测试
准备基础用例
后端
准备和开发人员协商数据格式和数据内容，为书写接口文档而准备
开发
关键是技术预研，对于关键性的技术或者说三方SDK进行调试和研究
交互阶段
通常我个人是会用Axure去设计App的原型，当然有的人可能会觉着用Justinmind设计App的原因会更加专业，我通常会用MockingBot去设计App的产品原型，关键是这个软件能够帮我节约时间，能够直接导出一个原型的apk，还有就是能够提供常用的素材，节省我去网上找素材的时间，在这个阶段交互人员需要拿出一份交互稿，当然可能是一个url地址，需要描述清楚所有的交互需求，交互流程以及交互特效，搭建一个产品或者说App的基础模型出来，此时不需要太过注重控件的美感，只需要描述清楚控件所具备的交互功能就可以了，也就是搭建一个App的功能骨架，当然不仅仅是原型的设计，还有就相关的流程附上流程图，相关的思路附上思维导图，还有相关的互动逻辑最好也能用图形展示出来，尽量不要使用过多的文字去描述，这样能够更加直观，更容易被被人所理解，当然我们和项目相关的人员进行沟通才是最重要的，我们总说产品开发中最大的成本就是信息的不对称，PM在整个产品或者说项目的开发中必须保证每一个环节，每一个相关人员之间信息的对称性，这种对称性不仅仅是指发一个文档给每一个人告知一下项目的进度，而是要保证每一个相关人员的项目理解保持相对的一致性，这样才能保障团队协作的效率，避免浪费太多时间在沟通还未到位的工作上，当然可能一个配合默契的团队不需要做太多的沟通工作，我们设定的是一个刚组建的开发团队，对于有必要和其它人沟通或者解释一下的交互设计我们有必要和相关人员进行讨论，而不是直接交上去一份交互设计稿就完事了，这样可能会给后期的开发工作带来不便。
完稿之后的评审
评审的主要内容：
1.这个交互稿是否符合我们的策划需求
2.UI将自己设定的视觉方案进行嵌套，确定一下是否适应，以及确定其它相关的设计事宜
3.根据交互稿书写我们的用例
4.前后端开始搭建框架了，前后端接口协议确定，模块划分和分工
5.实现困难的交互方式和技术预研
6.当然作为一个项目经理或者说程序员当然也要关注项目的开发周期，我们需要根据交互设计稿去预设产品的开发周期，当然对于不可控的开发模块进行风险监控，假设不能明确一个开发时间，这个项目就不能做了。
视觉阶段
通俗地来讲就是我们在开发中经常使用的效果图，不同于交互稿的时视觉稿最终决定了产品的模样，而交互稿只能决定我们的产品轮廓，对于我们的程序员而言当然需要在理解和搭建产品轮廓的基础上去填充我们的视觉效果，这部分的工作主要是由我们的UI完成，UI这个工作在实际开发中不是一步到位的，准确地来讲应该是一款App产品在实际的开发中不可能一次定稿，可能会有调整和变动，可能还会有频繁的需求变动，这是我们程序不太情愿发生的事情，这就需要考验一个PM的能力和需求方的意愿了,UI完成设计稿之后通常也要进行一次视觉评审（我们也可以理解为小组会议），之所以要进行评审主要是就一部分细节达成一致性的意见，毕竟是不同的人在做事，每一个人关注点的和所做的事情不同，比方说Android开发中对dp和px单位的转换，当然现在我们可以直接使用px，程序员可以引入一个依赖包解决这个问题，当然这也要UI与我们的开发人员协商好，对于UI来讲可能需要设计交互特效中一部分素材文档，针对特效实现所需要的素材也需要再交互稿在评审时和交互设计人员以及相关人员沟通好，实现方式不同可能对于素材的要求也不同，所以UI可能会被各种切图需求所包围，所以在确定视觉稿之前还是要提前做一点沟通上的工作，要相关人员明确设计需求，确定视觉设计稿之后可能也要喊上大家一起进行评审，策划首先要认可视觉设计稿，假设需要修改，就要马上修改，之后对比一下交互稿，评定一下UI素材能够支撑起全部的交互效果，效果图可能还需要让我们的移动开发人员进行一下评定，开发人员对于效果不太明白的地方可以及时沟通一下。
UI和视觉设计
其实UI就是企业中的切图人员，只要基础素材足够，一个UI人员的效率是极高的，无非是切出不同尺寸，不同风格以及不同分辨率的组图，对于我们这种移动开发人员来讲，现在转换工具太多，我们基本上能够完成大部分图片的转换工作，对于UI来讲Adobe企业的产产品至少要精通PS，当然AI和AE能够精通也是极好的，其它的辅助插件此处就不讲了，还有矢量图的操作软件比方说CoreDraw软件，也被一部分人经常使用，我们通常不说UI是设计师，而说UI就是个切图的人，原因是我们的UI所做的大部分工作就是对素材进行各种拼接，修改和特效上的制作，而不是真正地进行原创性的绘图工作，其实这对于UI来讲也是一道坎，过这道坎必须有着好的美术功底，就如同我们程序员想要进行数据结构的设计和优化就必须有着算法功底，这对于我们程序员来讲也一道坎，其实我觉着UI更多需要承担App的设计工作，比方说配色方案，以及品牌设计，以及对app的主题进行设计，可能在日常的工作中UI会去做这方面的事情，可是企业却未能有重视这方面的工作，这让UI的地位下降了好多。
开发，测试阶段
其实前面我们一直忘了说，我们需要一套集成的项目开发系统，当然好多企业用了禅道的项目管理系统，当然我们也有好多其它的选择，对于我们开发人员来讲我们还需要关注到代码仓库的问题，通常我们也会将其托管到github上，有实力的企业也可以托管到自己的服务器上，我们通常会使用git进行版本管理，svn可能已经过时了，当然对于有的企业来讲也是一个选择之一，对于我而言我认为开发需要分模块，模块之间需要解耦，让分模块之前需要统一网络框架，代码规范以及工具类，当然在分模块时我们必须注意模块之间的解耦，不能建立太强的耦合性，否则两个模块之间的代码可能会造成太多的冲突，这是我们进行模块合并时经常会碰到的问题，也是最令人头疼的事情，所以在分模块时，我们就要重视这个问题，避免在之后的代码合并中造成重大的损失，老手应该规避这方面的问题，特别是开发团队中存在太多新手时，初版的app只要按照产品原型和效果图去做就可以了，对于我们而言我们不过是用原生的代码去重构一个在不同系统中运行的产品模型，开发中我们需要将代码上传给我们的测试进行测试，测试根据之前建立的测试用例对我们的代码进行测试，当然有的测试也会手动进行测试，所以说测试基本上和开发是同步进行的，开发写出来的代码和功能必须要经过测试的检验才行，这时我们也需要一个bug管理软件，当然在项目管理软件也会有这种功能，可是有的bug管理软件更加专业，用于测试将测试出来的bug提交给我们的开发人员进行修复，对bug进行描述和记录，开发人员其实对于效果图可能还会跟UI进行沟通，也会针对bug和测试有所沟通，当然实际开发过程中我们和测试沟通的机会基本为零，我开发和PM交流的次数可能会更多，PM是出策划的人，必须监督开发人员严格按照自己的策划去开发App，当然还会改需求，这对于开发人员来讲十分可怕。
关于后端
此时后端当然要拿出接口文档给我们前端的开发人员了，否则我们前端的开发人员是无法进行开发的，假设碰到了这种情况，我们需要将此事和领导说明一下，否则领导还以为你一直在拖时间，一定要汇报上去，曾经有个同事就被后端人员拖了好长的时间，结果这个项目最后流产了，老板也将后端的人员全部开除了。
关于测试
一个不能给App测试出bug的测试不是一个好测试，当然这不是绝对的，可是假设你未能测试出bug，App上线出了一个简单的bug，你这无疑是引火上身，所以测试通常要细心，所以就适合我们的女孩去做这项工作，现在有好多自动化测试的工具，而不用我们写太多的测试用例了，当然手动写的用例还是必须的，这也许能够帮助我们测试出业务逻辑上的漏洞，对于App而言我们可能还需要进行手动的点击测试，Android中的monkey测试还是不太靠谱的，在不同的设备上进行测试，对控件的效果，大小，样式以及互动功能进行各种变态的测试，当然资深的测试还会对网络访问的安全进行测试，特别是特别是涉及隐私的用户数据和用户行为相关的数据，还有就是网络框架本身的安全隐患。
关于我
一个Android开发工程师，励志成为一个不写代码的程序员，有时一杯咖啡，一次沟通能够给你的是一种方向，而有时仅仅是重复性地工作，我不太关注自媒体，尽管在互联网企业和这部分的人有所接触，可是猿天然地抗拒运营们油嘴滑舌的姿态，有时也只能被金钱（企业文化）所驱使，还请我们要尊重马斯洛的需求理论，作为一个程序员，任何一个角落，任何一杯咖啡，全部能成为我们设计程序的地点，关键在于我们的思维能够跟上别人的需求设定。
上线阶段
可以说上线我们必然要和公司的推广和运营打交道了，千万不要自以为是地去上线我们的App，这根本不是开发人员的事情，运营狗做的事情是不同的，比方说你能设计各种各样的衣服，可是卖动这件衣服的套路不是我们设计师能够掌控的，推广中涉及关键词的搜索，以及各种各样的推广手段，针对不同渠道的推广方案，当然对于iOS开发工程师来讲此时所需要做的事情只是等待苹果官方的审核，对于我们Android可能是打包各种渠道包，或者是通过Gradle打包各种变种包，总之一个打包工程师已经上线，当然我们可能会进行最为重要的一次测试，就是上线测试，我们可能也会用一下蒲公英内测服务，如何用大批量的手机进行App测试，可能就要花点钱了，我们的后台能够收集到App崩溃的日志，不要以为上线我们的工作就做完了，产品出来之后，我们要面对企业中各个部门的评价，也要面对上线之后用户和推广人员的反馈，对，迭代更新的重任来了，修复简易bug不影响用户体验可能还会用到热修复的技术，迭代更新不过是重复上述的流程，不再赘述。
声明
有时间可以加一下我的微信，仅限于技术沟通。
二维码
网友评论