PM输出效率,是否可以改进?

作者: 闲云囧人 | 来源:发表于2017-02-18 08:39 被阅读277次

做PM头两年,基本靠四板斧:

* MindManager,做脑图,理清功能结构;

* Visio,做逻辑流程图,理清逻辑顺序;

* Axure,做交互原型,把构思的产品用相框图和简单的交互效果活灵活现地展示出来;

* Word,形成最终需求/规格文档,交付开发的最主要依据。

后来在某东家就职的时候老大提到如何提高PM输出效率的问题,联想到之前Y思远兄曾经在鸟厂游戏做过的类似努力,觉得是个可以考虑的思路方向。

在上面的过程中,脑图和逻辑图基本是为原型与PRD服务的,不算最终PM输出的必要产物,因此效率全看PM整理思路的过程中需不需要,没有可实际优化的地方。

但原型和PRD,是要做出来和其他团队成员沟通用的,所以提高输出效率的事情,自然最好是在上面做文章:合二为一。

方法一:把原型并入PRD,最后输出PRD。

这实际是我从做PM开始就一直在做的方式,具体是把交互原型完成后,通过截图贴到PRD里,用图文形式阐明设计方案。

这个方案,有两个缺点:

1、太多的截图,会导致PRD文档过长,如果再没有做目录的习惯,很容易阅读疲劳;

2、由于交互原型的最终的呈现形式是静态的截图,真正动态的交互功能主要借助文字描述,时常会出现无法完整表达设计意图的情况,最终还是需要附上能动态交互的原型文档。

方案二:把PRD并入原型,最后只输出一个原型文档。

这即是Y思远兄曾经尝试过的方式,也是这次讨论会上被提及的一种方案,做法是在交互原型的旁边做注释,这样的优势确实比较明显:

1、在文档中,交互是动态的,加上旁边的功能阐述注释,更容易理解;

2、看文档的人,他看注释的阅读流和操作流是一致的,并且由于内容基本都被限制在一屏内,不用总是来回用滚轮翻页定位,阅读不会有太大困难;

3、借助于原型文档自动生成的,左侧的页面结构树,在设计页面较多的时候,也能够快速进行跳转地位,不易发生因为设计方案太长有部分内容被忽略掉的情况。

不过,目前的情况是,方案二貌似很少见到实际使用的先例,毕竟这等于是消灭掉了言PM必谈PRD的情况,是否容易被行业习惯所接受,是个问题。

即便是今日,也有不少同仁在为这个问题忧心,前一阵子还有位PM童鞋因为开发哥非要他输出需求list、PRD、交互、注释4份以上独立文档而找我诉苦,开始怀疑自己做了一枚实际是文秘的假PM。

为了不让这样的好点子就此消失,于是也记录下来,希望有朝一日有助于各位PM同仁的工作。

相关文章

网友评论

  • 文本:一直在用方案二,节省更多的沟通时间和文档时间
  • JustRockIt:我们现在就是采取的原型图+需求说明的文档结构,效率还是蛮高的,技术都是喜欢看图的,没有技术乐意花那么多时间看一份连产品自己都不乐意看的文档。
  • call_me晓铎:几十甚至上百页的prd自己都懒得看,而且耗时。现在中小公司大都是敏捷开发,prd的形式完全可以通过原型展现,写好说明注释交互展示逻辑,开发绝对是喜欢这种形式的
  • Pehd:新手请教应该如何画脑图和流程图:joy:
    闲云囧人:@Pehd 那其实可以先临摹一下网上现有的文档找下感觉~
    Pehd:@闲云囧人 我知道这些,只是不知道画的对不对,最近开始在项目进行之前画脑图和流程图,这样对于后面的开发比较好
    闲云囧人:@Pehd 我觉得简单可以这样理解,脑图是把功能仔细拆分,流程图是把逻辑仔细拆分
  • Hobby_:@有音色融入 原型配说明文档的形式势必会引来开发的不满的(老子写了2周的代码,你就这玩意搪塞我?他是不会考虑到你前期和需求方的各种PK的),这个时候我觉得我的一位leader的做法就很棒:充分发挥需求评审会,前期聊需求的可实现性和实现方式、立项会聊产品的方向让技术认可你,后期聊实现的的细节,最后再来一个确认开发周期的会(此时应配上下午茶,和假输的王者荣耀一局,哈哈哈)。每次会议的与会人员也不同的,最后最后玩的,千万别觉得会多了…他会让你省去无数的麻烦,项目速度会飞起来的…

    一句话,让技术了解你的产品一切细节,他才会觉得你是认真想过的…让技术认同你的产品,他才有能动去做得更好…
    Hobby_:@闲云囧人 而且这几个会都是在项目准备期的会议,不是项目进度的会议…
    Hobby_:不不不,都是小会,比如立项就是产品经理和涉及到的几个leader,确定高效并得出结果,会议怎么能当成绩效呢…
    闲云囧人:@Codeee 这比较难以认同,因为这不小心就会走偏,我就经历过把会议当项目进度和业绩的公司,效率低得发指

本文标题:PM输出效率,是否可以改进?

本文链接:https://www.haomeiwen.com/subject/zcerwttx.html