在需求分析阶段,即上图所述 ”需求明确“之前的阶段
产品经理PM召集需要项目相关人员,开需求讨论会、讲解原型
相关人员需要以此了理解产品的需求,提出质疑:这是什么功能,怎么做,为啥这么做,大概包含如下几个方面:
注意:该阶段之所有会要求其他人员也参与进来,主要是为了想要在项目开始的早期就让相关人员都了解项目的全貌、提供建议,有利于部门间协同,减少不必要的内耗。
相关人员分头行动:评审-》分头开发-》合并&联调
这部分工作主要忙活的是产品经理PM、UE、UI。
如果PM不画原型草图,就会出现: 交互搞不懂产品,UI搞不懂交互,技术搞不懂UI背后的l逻辑,领导看不到产品经理PM的思路… 通常在你们公司有专们的交互设计师UE的情况下,PM会偷懒不画草图,光靠一张嘴白活,还不一定能够 白活明白,这样就会导致UE对需求不清晰,他不知道怎么干活,加上PM随时随地乱入交互,UE会更加懵圈,他也不知道还要不要干不干活(产品乱入交互) 所以个人建议,为了防止Garbage in and garbage out,PM一定不要偷懒,应该坚持画产品原型图的草图(拿着汇报工作也方便,对不?),并且不厌其烦地与UE碰头讨论。总之PM是整个项目的发起者,你偷懒,后面的人全懵逼,程序员想掐死你都是有原因的。
PM应该整理思维脑图,头脑风暴之后,优化思维脑图,然后出草图,你可以用Axure或者visio甚至腾讯出的UI disigner或者最近比较流行的Fluid UI(APP设计工具)来画草图,也可以称之为低保真原型图,在这个低保真原型图中,你需要要一一罗列功能点,交互细节大可不必提及,完成后主动找交互设计师进行沟通交流,要耐心的将各个功能点向交互设计师描述清楚。
PM应该先跟交互设计师在纸上、白板上充分讨论交流,让他明白产品和功能以及用户需求,接着讨论大概的交互怎么做,交互设计师下去用工具(推荐sketch,没有集是设计师就自己画也挺快的)做像素级的线稿,PM准备背后的ᵱ求、流程、逻辑、期间再碰N次。
交互设计师了解到某些功能点之后,会根据自己专业能力的感知,来进行高保真原型设计,然后交互设计师做好线稿图、高保真原型,PM应主动与交互设计师沟通,看看是否有需要修改的地方,两个人需要在灵ṯ魂层面达到二合一的境界,对功能的理解一定不能有出入,一些功能细节,PM应该把关,某些交互细节,应该提出自己的意见,换位思考,理解交互的设计含义。耐心与责任心在这个时候显得尤为重要。统一方案后,就可以提交UI进行设计了。
完成上述环节后,三个人都可以开工了,UI设计师可以拿这个去做界面设计,PM和交互设计师可以分头做原型了。
因为sketch做图又快又美还是像素级,三人同时参考避免最终成果有偏差。所以PM拿去套进axure,页面配上功能说明、规则逻辑、流程图等,生成产品经理版交互原型,用来汇报领导、沟通协调、需求评审 与讲解、与技术进行项目开发计划评审评估工期等。
他继续把线稿图用axure做完全部交互细节设计,期间与PM反复沟通确认,最后生成交互设计原型。差不多个时候开发计划出来的时候,交互设计原型已经完工了,UI主界面也差不多了,技术可以直接 开搞不耽误!
最重要的就是每个环节的人都对要做的东西认知基本一致,因为前期的反复讨论和沟通,以及相差不远的线稿图做各自工作的参考依据。
之后就是前端工程师的静态页面设计,程序员的技术实现,测试了。整个过程中,PM的沟通能力得到了最大程度的提现。所有的这些,都基于你对产品的热情程度,因为只有热情,才能让你持续不断的保持上 文提到的那些能力。
1、产品经理PM=》原型图(草图),侧重:产品的核心
梳理出所有的产品功能以及流程逻辑,比如使用axure的站点地图这种树状分支的表达要清晰完整。 每个功能页面,上需要哪些功能和数据需要呈献,要表达出来。 一定要在最短的时间内制作出人能看懂的原型,反复讨论,反复修改,留给设计师足够的时间。一定不要 纠结画的好不好看,这一点也不重要,快速是第一位的。甚至功能好不好用可能都不重要,表现出来我们有什么,可以做什么就够了。
2、交互设计师UE=》原型图(细图),侧重:用户的使用感受,人性化,让用户爽,不要反人类
拿到产品经理的原型,协助细化功能点,考虑交互逻辑是否成立。对整个产品的交互逻辑要表现清楚,比 如提交数据按钮要呈现加载状态,创建新数据表单,在哪个地方使用弹窗,哪个地方使用页面,空白数据页面使用表情还是添加新数据引导呢?给UI设计师提供UI设计思路。
3、视觉设计师UI=》PSD,侧重:使用界要漂亮
PS:UE与UI非常关键,尤其是在手机app和网站开发中,UE是主观的,UI是客观的
PM原型草图
UE原型图
UI设计图
测试QA人员编写测试用例
** 前端人员拿到UI
设计图,先自我解析需求,画出思维导图,流程图
在未拿到UI给定的PSD时,可以先理清我们的需求**
项目经理(通常由部门内有丰富项目开发经验的RD担任)组织部门内小型需求/项目相关讨论会,完善文档,整理有疑问的地方,与产品、设计等其他人进行反复确认 (发送邮件or其他通讯工具)
文档是程序开发的灵魂,除了设计的相关文档外,在正式进入开发流程前,还需要要架构师或项目目经理出的需求分析文档,公司如果有专门的需求分析师岗位肯定是需求人员写,如果没有,最好是项目经理来写,因为一方面他对业务很了解,另外一方面也可以借此梳理业务流程 需求文档是对整个项目的历史背景,系统开发软硬件要求,或版本信息,等等。 需求分析文档如https://www.cnblogs.com/linhaifeng/articles/13623153.html 另外一个是由服务端工程师提供的接口文档,这里边包括一些请求类型,传参的数目与键名,还有服务端 返回的参数名约定等等的,这些文档是开发中的灵魂,也是以后测试回溯的标准或依据。
之后项目经理独立or协同部门内人员
更进一步的,many-to-many实际上就是两个one-to-many。 对于核心业务部分尚不能明确表与表关系的,能一对多就不要一对一,能多对多就不要一对多。 这样开发的复杂度会增加,却消除了后面可能的修改扩展的隐患。 对于非核心业务也不能明确关系的,可根据实际情况,综合考量开发实现的烦琐程度及未来的可变性再做决定。 “刻削之道,鼻莫如大,目莫如小。鼻大可小,小不可大也;目小可大,大不可小也。举事亦然。为其后可复者也,则事寡败矣。”说的就是这个道理。
前后端各自开发,然后合并&联调
先开发手动自测
然后提测---测试人员测试,一旦测试出bug,需要开发人员修复bug,开发人员在修复bug期间
关于测试:
软件测试从测试方式上分为黑盒测试和白盒测试,从测试范围上可分为单元测试、集成测试、系统测试、验收测试 。黑盒测试、白盒测试、单元测试是开发人员分在不同的开发阶段要做的事情;黑盒测试、集成测试、系统测试是测试人员在测试周期内级层做的工作;验收测试一般是在用户方做的工作。
上线准备
技术创新(对现有的技术领域以及具体项目实现方法进行优化)
项目开发周期:https://www.cnblogs.com/linhaifeng/articles/13623594.html
项目版本号
项目版本号简洁
版本发布周期: