产品线定位

不断的接触到公司的新产品,同时也给公司新的产品制定规划线路。对新产品线的定位,已经涉及到公司的整体发展、公司效益、目标群体定位等多方面。产品经理在给产品线定位时考虑的是全方面位的,需要老板、技术、产品、市场等负责,多条产品线之间的协调,除了资源的协调,市场协作、技术配合、产品人员的努力一个也落不下,产品线定位不是产品经理一个人的事,是共同协作的结果。

产品线的定位分为五个部分:

1、产品线对公司的影响
产品靠什么盈利?产品市场机会如何?与公司其它产品的联系又如何……一系列的问题,都是产品经理需要思考的,对于产品线的规划,以及对公司其它产品线的影响与结合,如何做到合理的资源调配,以及跨产品线的服务。做到产品线之间的协调以及产品独立性影响 ,对公司利润产生点深远规划,如果无盈利的产品或许对公司来说存在性已经变的太微小了。
2、产品线对用户的价值
产品线对于用户来说获得哪些好处?降低成本?提高效率?更好的用户体验?更漂亮的产品……产品线最终是要走向市场,面对用户,需要得到用户的肯定与质疑声。产品线对于用户的价值一定是可以帮助用户解决问题,得到一定的帮助,或比市场上的其它产品更有吸引力,能提高效率,这将是用户选择该产品的关键所在。
3、产品差异性–竞争对手分析
市场上有多少竞争者?产品的进入门槛有多高?超越的时间多长?产品新亮点挖掘,新产品用户接受程度,多少用户会选择放弃竞争对手产品……对竞争对手产品的分析会成为在规划产品线时考虑的重点之一,对于新产品的进入,用户有多少接受程度源于对竞争对手产品的期望,当有新的产品可以替代同时更好的使用,差异性将主导新产品线的“性格”。
4、产品利润模式
为什么要使用我们的产品?为什么必须使用我们的产品?如何让更多的用户使用我们的产品?利润模式很多时候会给弱化掉,但存在着一个道理,当你有足够的用户时,你还会觉得赚钱难吗?把以可盈利性形式获取的当前价值与竞争差异和产品规划 关联起来。
5、产品定期规划
一期?二期?三期?……产品是否能够持续发展来源于对产品长期的规划,很多时候产品在上线后得到用户的反馈后才知道产品的规划,但产品经理得知道自己的产品长期规划 ,不一定做的很远的规划 ,但得知道下一期将是如何规划的,一期未实现的,二期如何续接,功能如何拓展都将影响产品整体规划。预测产品线的主要优先级,并简要指出一直没什么吸引力的领域。产品只会越来越简单,让用户更快的上手,这也是产品的发展方向。

产品线的定位最需要的理清产品思路,对于产品的整个生命周期有个概念规划图,但同样需要一系列的数据做支撑,当没有数据和用户时,产品经理对于市场的信息捕捉显得更加重要,更多的时候我喜欢称作为触觉,比别人更快一步的感应,而这种触觉除了多看更应该有慎密的逻辑思维,一种活跃的逻辑思维,这将是我做为产品经理将在自己的规划中学习的重点。

产品线定位更多的体现在MRD中,通过市场调查分析得出产品线定位,根据产品线定位再进行产品需求确定和分析,产品线定位在很多公司是由公司的老板主导了,当产品经理有机会自己定位产品线时,希望可以更加全面的考虑产品的定位以及站在公司的角度确定产品的发展线路。

PS:如果产品线没定位好,我宁愿扼杀摇篮中。哪怕它是一个很好的点子,宁愿重新规划可行性路线。产品经理是暴君还是伪娘就留给其他人去评价吧!

产品过程

产品从无到有,从一个想法到雏形到上线的产品,都有个过程。不论是产品、运营、开发、测试等都有自己的职责和工作。很多公司都希望将自己的产品流程化,正规化,希望按照一定的流程走下去,想的是哪天哪个职位出现空缺了,直接找个合适的人可以顶替。同时也为以后的产品工作或项目进程都提供一个模版。特别是对于中小型公司来说,当没有UED,当没有产品相关流程时,产品是否能够按时完成,能否高质量的完成,成为很多产品经理和BOSS担忧的事情。

结合自己的产品经验,同时在不同的公司的经历,将产品流程规划分为8个阶段:立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、磨合阶段、运营阶段、总结阶段。

1、立项阶段
体现产品经理核心功能的阶段,对于产品需求确定,核心功能提炼。产品提出讨论,输出MRD,与技术、业务、资源的可用性,同时确定产品参与人员,沟通是产品经理的一项职能,如何将所有的参与人员集合一起共事,如何更有效的沟通,明确各自的职责。更希望将产品聚焦于可以满足80%用户需求的解决方案,而非20%的用户需求。
2、设计阶段
设计阶段的首要任务就是将产品周期确认,周期是产品经理需与各部门人员配合确定的。产品、交互、UI、视觉、开发、测试等人员在设计阶段更多的是个溶合过程,信息的溶合,目的的明确,同时对于各自工作的明确。产品经理在做出PRD后更多的是与其他人员中的交流与沟通,同时文档的迭代,这个阶段是让所有的人员知道这个产品的核心及功能,交互根据文档出高保真原型,UI根据文档找到产品的表现形式,开发知道产品的核心力体现在哪,技术难题以及实现方式等,测试除了了解产品外对于产品的测试重点及难点掌握。运营则知道这个产品亮点及产品特征等,“好产品是运营出来的”,越早让运营介入产品只有好处。
3、开发阶段
“工欲善其事,必先利其器”。从服务器的部署开始,到最后的代码存档迭代,都将是开发人员做为主导的阶段,同时对于产品开发周期的确定。产品经理更多的协助开发了解产品功能,测试需配合开发做单元测试、压力测试等。运营则是更多的是配合内容数据的提供。
4、测试阶段
当产品经历过初审,接下来的工作就交给了测试,黑盒、白盒测试,以及三轮产品测试。第一轮测试发现产品bug,第二轮测试围绕着bug、以及优化展开,经过第三轮测试过后产品已经归类为较稳定版本。在三轮测试中测试人员需时刻保持着沟通协作,与技术、产品、UI等,这是个磨合的过程,同时也是质量把关过程。
5、上线阶段
这也是beta阶段,这也是开启产品市场的阶段。但在上线前需对产品的代码、系统接口监控、系统维护方案、数据清理等,上线评估阶段需经过市场、产品、运营、开发、测试等对于上线做出整体评估后才能正式上线运营。同时对于上线后的跟踪,日志分析、服务器监控等,同时从日志分析出做出产品调整同时产品运营计划表制定。
6、磨合阶段
经过上线阶段的数据分析,以及数据日志的分析,程序等调整,对于产品做出优化,对于用户常见的问题及反馈做出调整,这阶段更多的是产品与用户的磨合,做到更好的用户体验。
7、运营阶段
软文?广告?产品上线后的工作都将是围绕着用户展开的,如何让用户第一时间用上产品,如何让用户知道产品,如何抓住用户……提供优秀的用户体验,让用户喜欢上产品,爱上产品,离不开产品,这是运营的能力,同时也是运营人员对产品的信任,同时应证一句话“好产品是运营出来的”。为用户提供产品帮助,软件产品更多的是产品使用说明书,而web更多的是FAQ,减少用户“为什么”。
8、总结阶段
学会总结,学会分析,学会批评,产品上线后需要对产品做出个阶段的总结,不论是产品上的,还是人员相互配合上的,有摩擦,有不同的见解在产品过程中是常见的,但出发点一定是围绕着产品,提出意见,产品二期改进及规划,这都可以做为总结阶段讨论的重点,以及如何加强沟通协作,如何做好产品运营。


产品流程并不是一尘不变的,同时对于不同的产品,会有不同的要求。这样的流程同样适用于做项目,对于很多公司没有UED等组织时,如何高效、快捷的做出产品或完成项目,减少不必要的工作,成为流程简化与规范的基础。8个阶段的相关人员都有相关的侧重点,或许期间还有不同的人员介入,比如市场,比如BOSS,任何一个过程都有可能受到影响 ,这时候需要的是配合、需要的是协作。成功的产品会遇到很多的困难与阻碍,但相信自己的产品只是满足80%用户需求的解决方案,别想100%的压力,没有人会为这100%买单的。

附上整理的产品流程表:[download id=”9″]

如何写PRD

PRD是每个产品人员最经常看到的文档,还是有很多产品的朋友问我PRD怎么写,如何才能表达清楚意思。其实PRD并没有规定的格式,每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。

PRD(Product Requirement Document,产品需求文档),这对于任何一个产品经理来说都不会陌生的一个文档,一个PRD是衡量一个产品经理整体思维的标准,一个PRD可以看出一个产品经理在某个领域的专业性,同时也可以反应出一个产品经理的整体产品思维。

产品经理的整体思维体现在:
1、提炼核心需求
2、思考满足核心需求的方式
3、评估方式优劣选定方案
4、思考功能概要
5、思考支撑功能和关联功能
6、细化设计功能
7、子功能(功能间迭代)

PRD其实就是将以上的思维整体走向写出来,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老板……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述。

网上已经有太多互联网公司的PRD文档,淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范,适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例,讲解一下PRD的主要内容。

1、文件命名(编号)
文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页
一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。

3、目录
不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

5、概述
概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险。
名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。
产品roadmap:产品分期目标,阶段描述,以及时间点的确定,产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,二期才会继续去完善剩下的30%,同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标,而是更多的通过维护来保持产品的更新和迭代。
产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,不当使用的风险等等。风险级别为高中低。

6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级。
目标客户即为产品的最终用户,确定产品的最终使用者。
需求描述是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。
优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案。你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,永远没有过时的idea,只有最适合时机的idea。所以可以写出几个可选方案,或许是你下期产品改版一个方向。

8、效益成本分析
产品经理是个全才,在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本。
效益预测是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,最好能包含现在和过去的效益数据。如网站的PV值,软件的使用数都是效益预测数据。
产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求,包括人力成本,软硬件支出等。很大时候这份成本需要由项目经理来协助,需要有什么样的人才加入产品中需与人力协助。
非产品技术中心支持成本,产品不是只有产品组完成的,同样需要其它部门的配合与协助。比如:需要客服部投入多少的资源用于该产品的服务,需要运营部投入多少的资源运营该产品。

9、功能需求
功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求。
功能总览一般包括二个部分,一个是流程图,一个是功能表。流程图是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化,同时将列出产品的功能点。
功能详情,这是所有的产品功能的描述和规划。包括以下内容:
简要说明:告诉此功能主要干什么的。
业务规则:每上产品在使用时都有自己的规则,而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则,包括一些细节,如排版形式、日期显示方式全定好,这样方便其它人员的沟通和理解。
界面原型:产品经理在这时做的原型界面只是显示的框架,别细化,这样会给交互和UI造成错觉。只需做一个简单的界面即可,更多的时候只是个框架图。
执行者:产品使用者。
前置条件:具体的操作。
后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,所以对于建议在PRD中的前置条件和后置条件结果合起来。
主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求
很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求
都说产品经理是全才,在这点上得到彻底的体现。很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分:产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能,还不如说是沟通,如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

13、上、下线需求
上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要。

……

写PRD并不是产品经理的全部工作,但却是不可少的一部分,很大程度上反应了产品经理的思维和产品核心功能把握上,同时对产品经理沟通、协调、规划等都得到了一定的验证,但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

附上一份网上弄来的PRD,可以参考一下。[download id=”8″]

手机原型设计工具–PPT篇

PPT,一种演示文稿图形程序,是Power Point 简称。Visio做原型还是比较多的,至少我看过迅雷的人用Visio画原型 的产品经理还是变多的,用PPT来做原型的并不多,但还是有存在的,其实最早看到用PPT做原型还是从朋友那看到的,所以好奇之下做过一些PPT原型,当然不建议做网站的PPT,但做手机原型还是蛮不错的。
很多产品经理用PPT来做MRD,因为在展示效果上确实比WORD好看很多,而越来越多的PPT模版的使用,让MRD写的漂亮的同时,也让原型设计做的更漂亮了。

PPT画原型优点:
1、普及度高。相信PPT的普及度比Visio还更高,在装MS-office时三套件WORD、Excel、PPT,所以基本上每个电脑上都有了PPT。做产品演讲时最多用到的还是PPT,所以对一个产品经理来说PPT永远没有被淘汰的一天。
2、界面展示效果好,带来视觉冲击。比起Axure,Visio能做的原型,PPT自身定义就昌演示文稿图形程序,展示的效果确实更好,全屏的演示,在做评审时,展示的效果很能让评审的人满意(切身经验)。使用数十个新增的 SmartArt 布局可以创建多种类型的图表,例如组织系统图、列表和图片图表。将文字转换为令人印象深刻的可以更好的说明您的想法的直观内容。这点上比其它设计软件强的不仅仅是一二点了。
3、母版使用——丰富的组件库和拓展组件库。画图表?SmartArt?当Office2010的到来更加美化了PPT原型设计,母版的使用让组件库的使用得到了进一步的升华。这点上和Axure上一样,母版的效果二者在使用上同样等效。做一个手机原型后,就可以直接做成母版使用了。
4、同步协作。这是2010版的PPT具有的功能,您可以同时与不同位置的其他人合作同一个演示文稿。当您访问文件时,可以看到谁在与您合著演示文稿,并在保存演示文稿时看到他们所作的更改。对于企业和组 织,与 Office Communicator 集合可以查看作者的联机状态,并可以与没有离开应用程序的人轻松启动会话。这一点等同于Axure的SVN功能。
5、展示多样性。这也是在2010版中得到实现,将演示文稿发布到 Web,从计算机或 Smartphone 联机访问、查看和编辑,使用PPT您可以按照计划在多个位置和设备完成这些操作。Microsoft PowerPoint Web 应用程序,将 Office 体验扩展到 Web 并享受全屏、高质量复制的演示文稿。当您离开办公室、家时,创建然后联机存储演示文稿,并通过 PowerPoint Web 应用程序编辑工作。
……

PPT画原型缺点:
1、使用成本高。如果做展示我觉得非常不错,但是成本确实太高了,做一个PPT原型要花费的时间是Axure的三倍,而且是在熟悉的基本上。
2、流程表现能力差。如果用PPT做原型对于整个流程演示效果不太好,PPT可以画流程图,但流程表现出来的原型对于UI、开发等人员的理解上会产生一定的误差。
3、交互能力差。PPT和Visio一样没有交互,表现的只是界面效果,无法实现高保真原型,交互能力对于MS-office家族的成员都是一个致命的“痛”。
4、页面承载能力差,需大量文字辅助。交互能力差,就倒导了需要用大量的文字来辅助。这个缺点在Visio中同样存在,但PPT比Visio差的是界面,PPT界面有限,造成了对于文字输及表现方式也有限,承载能力就相对较弱了。
5、弹性差。PPT的弹性差表现在与PRD的连接上,以及与UI、开发等配合上。弹性对于原型设计上占有很重要的一部分,因为产品经理涉及到的软件性越多,对于其它人员的成本将增大。
……

PPT做手机原型的很少,毕竟不是很多人愿意加大成本去做PPT原型,但PPT最大的好处是在出PRD前,MRD与低保真原型一起出时一起用PPT,其实PRD里的原型界面也可以用PPT做(但会占据你比较长的时间),其它的工作就交给交互设计师去做吧。

PPT定义为演示文稿程序,所以用它来做手机原型演示效果确实更好,但我并不建议做手机设计的设计师用PPT做原型设计,因为消耗的时间确实太高了。但有感兴趣的可以学学看,试玩一下。顺便推荐一下Office2010,确实好用,感谢微软给我寄的试用版本。

PPT做手机原型确实是个苦力活,有人问我为什么一直用些难操作的原型设计软件,其实多一种手机原型设计方式并不是坏事,多的是一种对产品的认识途径罢了。今天下午的时候我在一个群里看到有交互设计师说用PPT做原型,其实蛮佩服他们的,我是只个好玩的人,所以才会花些时间去做PPT原型,同时在外企学的一些PPT技巧和模板觉得还有用就做试着做了一些。送一个PPT做的iPhone原型(iPhone的Icon也可以做的哦,仔细看附件吧)。

PPT手机附件:[download id=”5″]

打造成功的产品团队

来到这家创业型的公司8个月了,产品部从无到有,从辅助的部门到成为公司的主导力量,经历过很多曲路,从最初的产品团队二个人,到现在的一个成熟的产品团队,虽然没有纯粹的交互设计师,但我们很好的利用自身的优势互补,解决了在缺少交互设计师下的一些难题。一个产品的优秀与否与公司的产品团队有着密切的关系,成功打造一个产品团队对于一个以产品估算 为主导的公司显得格外的重要,一个强悍的产品团队需要面对的不仅仅是老板、市场、技术,而是面对着成千上万的产品直接使用用户。产品部现在越来越成为一个公司的主导部门,越来越多的公司凭借着优秀的产品团队成功的打造成为一流的公司。

结合在这家公司的产品团队的工作,介绍一下产品人员在产品从无到有过程中的一些工作。

1、需求输入

执行者:市场部门

辅助:产品经理

工作内容:根据客户和市场需要,整理出客户的原始需求,包括产品定位,客户信息,项目信息,需求矩阵,规模和预期成本,预期工期,演示原型(可选),以及市场部门建议等。

输出文档:原始需求文档,MRD对应部分(可选)。

原始需求文档:需求矩阵。

2、需求收集

执行者:市场部门、产品经理。

工作内容:以客户为最终导向(偏项目)进行需求的细化收集,形成需求矩阵表。

输出文档:需求矩阵细化。

注:该步骤和需求整理可以合并。

3、需求整理

执行者:产品经理

辅助:市场部门

工作内容:将收集的需求进行整理,完成需求文档并进行需求冻结,根据需求矩阵进行功能设计,出具低保真原型,功能列表,MRD或产品需求规格说明书。该阶段提交需求确认单给市场部门和客户进行签字确认。

输出文档:需求矩阵,低保真原型,功能列表,MRD,需求确认单。

4、需求讲解

执行者:产品经理

辅助:UED团队

工作内容:通过需求整理阶段的输出物向开发、测试、UI等进行讲解,使产品相关人员对产 品的需求有一个清晰的理解。在需求材料明确、完善的情况下需要如此,毕竟从文字到思想要丢失太多,在需求材料不明确、不完善的情况下更要进行讲解和沟通。

输出文档:线框图

注:需求讲解可以分为两步执行,产品和研发,产品的需求讲解主要针对UI和交互,研发的需求讲解主要面向研发人员,步骤在视觉设计之后。

5、细化设计

执行者:产品经理,交互设计师

工作内容:将线框原型进行细化,设计交互框架,并生成高保真原型。

输出文档:高保原型(AXURE),交互文档(可选),PRD。

6、视觉设计

执行者:UI设计师

辅助:产品经理,交互设计师,市场部门

工作内容:基于高保真原型进行产品UI设计,提交UI确认单(只包含最多三个主界面的风格演示效果图:启动页面、登录页面、九宫格或十六宫格)供市场部门和客户确认。切片输出,对高保真原型进行UI匹配。

输出文档:UI确认单,UI文件输出,UI切片文件输出,高保真原型(图片)。

7、产品开发

执行者:开发工程师

辅助:产品经理,交互设计师

工作内容:基于高保真原型进行产品开发,最基本的流程走通,先期可能只是一个DEMO,很多时候客户想先看到的是DEMO下的界面效果。对于一个产品,开发工程师需要完成整个的业务流。包括代码优化,界面效果优化等。

输出文档:一个正常可run的安装包

8、产品测试

执行者:测试工程师

工作内容:视觉问题当成Bug来管理(UI视觉得),并参考UI输出和PRD对整个软件进行性质的测试。整个产品测试,包括压力测试,功能测试,业务集成测试……多次回归测试。

输出文档:测试文档,Bugfree(辅助工具)

9、产品上线

10、产品完善