产品效率五个标准

合集下载
相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一、熟练使用生产力工具

什么是生产力工具?简单来说,就是专门帮助用户更快、更高效完成工作的软件,比如文字编辑、图片处理、视频剪辑等等。作为产品经理,也有一堆工作中常用的软件需要掌握。

PRD输出:最常用的就是word,在mac平台对应则是page,还有一些人会用OmniOutliner等文字处理软件,同时mou等markdowm工具也深受推崇;

原型设计:产品必备Axure,更轻便灵活的mockplus,同时还有深受好评的sketch能够快速产生高保真原型;

流程图:微软老牌软件Office Visio ,还有mac平台上功能强大的OmniGraffle,还有ProcessOn等在线制图平台也十几受欢迎;

思维整理:常见的有mindmanager、xmind等,还有mac平台非常美观的mindnode;

软件的很多高级功能我们或许很少用到,但是对于那些常用的操作一定要熟练掌握,因为只有这样我们才能将精力专注于产品设计等核心工作,而不是浪费在工具的调试。同时也要注意工具是用来帮助我们更好的思考和表达,不要一味追求酷炫的表现形式,也不要局限于形式。

另外,我们也要明白软件的强大并不是在于功能丰富,而是它在既定的设计逻辑下支持多样的使用场景。所以当我们判读一个软件是否足够优秀,是否得心应手时,要先找到自己清晰的使用逻辑和场景,然后持之以恒的用下去,才会逐渐发现这些生产力工具对我们工作效率带来的提升。

二、学会提炼通用的模块或内容

产品经理是一个创意型的工作岗位,所以那些重复性的机型动作基本上大部分都是在降低我们的工作效率,在工作中,我们要学会将那些通用的模块提炼出来,从而可以通过不断快速的复用来提高工作效率。

我们最常用到的就是各种模板,比如RPD的Word模板,统一确定好文档包含的各项内容,以及各级标题等样式,这样在我们下次写文档时直接填充主干内容即可;再比如Xmind思维导图或Visio流程图等,设计出一套或多套自己喜欢的风格样式,以后每次需要时直接套用即可。这样做不仅仅提高自己的效率,当团队成员相互之间磨合完成之后,也会降低理解成本和沟通成本。

还有原型设计软件中非常好用的母版/组件功能(axure中称为母版,sketch 中称为组件),将多个地方经常会用到的模块提炼成组件,不仅仅在创建时能直接复用节省了很多工作量,尤其在涉及修改的时候,你会发现只要修改一处,全局同步调整完成,那种快速带来的痛快感非常明显。我之前的一篇文章如何用Axure快速制作APP交互原型就是利用了母版的功能。

除此之外,在产品设计上也经常会有很多通用的功能点。如果在每个运用到的地方都赘述一遍必定是个繁琐的过程,只要某个功能点被应用了3次及以上,我们都可以将其剥离出来,对这个功能单独阐述,凡是应用到此功能的地方,一句话引述过去即可。比如不同页面选择商品的逻辑是相通的,所有banner位置跳转配置逻辑是相通的,不同活动的启用停用管理是相通的......其实不仅仅是在产品设计上,在开发实现上也是类似的思路,这些功能点都是以全局形式实现出来的。

三、体会深入思考的重要性

一个效率低下的常规表象就是处在不断的返工修改中,造成这个局面的原因,

一部分可能是外界不可抗因素所引起,比如业务方临时需求变更,但同样也有大部分情况是由于自己没有思考清楚就草率的开始了下一步骤。没有思考的足够透彻,就冒然做事,很容易出现方向不对、细节疏忽等异常情况,这些都会导致效率变低。

产品新人最常见的一个坏习惯就是整理好需求之后马上开始写文档画原型,其实在需求和原型之间还存在一堵墙,我们只有通过深入的思考将这堵墙拆解之后,才能顺利的过渡到到写文档的阶段,否者就很容易出现反复修改的过程。当我们想清楚之后,再去产出文档或原型,你会发现是水到渠成的一件事情,效率自然就会提高,并且质量也会有所保障。这个思考的过程可以称为设计规划,包含“组织信息架构”和“设定任务流程”两个步骤,具体可参考之前的一篇文章产品设计:需求和原型中间隔着一堵墙。

在产品经理的实际工作中,经常会有很多问题冒出来需要处理解决,同样的问题,有的人能很快找到有效的解决方案,而有些人可能花很久却摸不到眉目,这也就体现出了效率的高低。在我之前的一篇文章产品经理在解决问题时是否有套路可言?,也着重强调了将问题思考透彻的重要性,当我们拿到一个问题后,先不要急着从问题表象出发来寻找解决方案,这样很可能治标不治本,当我们通过思考探寻到问题的本质逻辑后,再结合业务背景才能高效准确的寻找到最理想的解决方案。

无独有偶,在前些天的项目周会上,开发leader也表达了同样的观点,他强调真正写代码的时间其实很短,要多花时间在思考上,把需求理解清楚,把开发逻辑思考透彻,然后在开始写代码,效率和质量都会有所提高。

四、对不同认知类型的工作分层处理

心理学家发现,当从任务A转换到任务B后,执行任务B的绩效明显要比非任务转换条件下执行B的绩效差,这个差异称为“转换损耗”。形成原因主要有两种,一是任务A留下来的认知习惯对任务B造成的干扰;二是做B的时候需要对B进行认知重构。同时还有个重要的事实不容忽视:在非常投入的和忘我的思考时被打断,损失非常大;相反,如果只是在机械性动作,频繁被中断也会有太大影响。

在《精进》一书中,采铜提出了一般任务分解的“三明治模型”。中间的部分称为“核心思考区”,这个部分需要集中精力、非常专注地进行思考,要尽量用可保证的相对完整的时间来处理,减少被中断的可能,才能高效地将其破解;余下的就是一些支持性的、补充性的工作(即“支持性思考区间”和“操作性动作区间”),这部分相对来说则是可以“允许中断”的。

在《精进》一书中同样提出了要学会对不同认知类型的工作分层处理。什么是认知类型呢?指的是我们头脑加工信息的不同方式,比如处理语言文字时是一种类型,处理视觉图片是一种类型。当不同认知类型进行切换时,人需要重新进行调整,这样任务的转换损耗会比较大。

比如对这篇文章来说,大家看到的顺序是从上到下,可是在我创造的过程,可能会分成这样几个步骤

1、通过思维导图MindNode梳理出主要想表达的观点和文章结构;

2、然后再通过文字处理软件Ulysses填充每个章节内容的细节描述;

3、接下来利用Sketch或PS等软件处理文章需要用到的图片素材;

4、最终再从文章全局角度来调整排版布局等样式细节;

同样在写文档或画原型图时,我们也可以尝试将任务分解并找到核心思考区

相关文档
最新文档