HI大家,其实我当PD没多久,所以我就用了这个标题:“PD成长记”,我所要讲的是一个有关效率和文档的故事。
我2014年11月8日真正成为PD接到第一个项目是这个日子。接到的第一个项目就是“Y项目”,一个通过日常任务与抽奖体系增加用户黏性的项目。当时从需求kick-off到开发kick-off用了将近一个月,开发也用了将近一个月。
虽然这个项目的结果是好的,从数据上看它让用户黏性提高了10倍左右。项目在时间管理方面也并没有到达失控的境地。但冥冥中,我总感觉在需求确认和开发上耗去的时间仍然还有优化余地,就去采访了两位开发人员,他们是这么说的。
某后端架构师:“还是照着测试的case写比较好。”
某客户端工程师:“你们产品写的文档都是乱的,现在都是靠case文档撑起来的。”
在那以后我就一直在反思,如何写好prd来提升效率。因为我认为“prd是pd自己的产品,读者是用户。”读者这里指的就是你要完成这个产品所要接触到的所有人。一个pd连自己的产品都做不好,也很难带着开发做出征服用户的产品。所以在之后的时间里,我不停的与开发沟通,争取在需求正确的基础上,写出可读性较高的prd。
通过一些沟通与调整,我的prd格式为以下:
文档属性、解决问题、术语概念、应用范围、产品原型、应用场景、兼容问题、竞品分析。
文档属性我一般会讲述整个文档的概略:pd是谁,交互、设计是谁,后端、前端、客户端开发是谁,测试是谁。
解决问题就是当CEO问你在做什么时,用“解决问题”中的三句话告诉他你在做什么。也可以用另一个角度告诫自己,在撰写文档的时候,不要忘记初心,别要忘记为什么而出发。
术语概念非常重要,是用来定义一些在你接下来的文档里,需要引用的一些专有名词,提高读者的阅读效率。
应用范围是描写一下该产品什么是要做的,为什么要这么做,以及什么是不要做的,千万别去碰。
产品原型我会分两部分来阐述,第一部分是产品DEMO,就是用户能直接看到的界面,也方便开发人员快速理解。第二部分则是产品架构和流程,这就有些许麻烦。架构方面我们需要一点架构师的思维:抽象画、通用化、模块化地描述产品。而流程方面,我们必须梳理业务逻辑来串联你的故事:要让开发和测试明白你要做什么、复杂流程简单化,此处我推荐的软件是MindNode,也是思维导图软件家族里,美观方面我认为唯一能过得去的软件。
应用场景描述的,则是一些场景下的user case。需要注意的是,一般好产品的共性,总是拥有简单且学习成本较低的用户体验,而需要的往往也是复杂而庞大的后台支撑。所以这里的“user”不应该只仅限于用户,对公司里的运营、BI、开发人员描写user case也是非常重要的一部分。
兼容问题的说明,在移动客户端作用尤为明显,但并非所有产品都需要做,但这部分做的细致,将给予开发与测试人员更好的推进体验。
最后则是竞品分析,其实这往往是pd在做一个产品规划的时候第一件要做的事情,只是当文档已经完成,这一部分就显得不那么重要了,放在这个位置,也只是方便大家随时查看而已。
有些产品逻辑可能确实还是比较简单的,视具体情况可以进行简化。但是我们必须保证,在完成这个文档的撰写以后,必须对读者是友好的,且严谨的。
至于如何高效地进行文档管理和维护呢?以前我也是直接把文档传到服务器上就了事了,但对于开发和测试来说,这是一件麻烦的事。对于pd来说,我们这里有四个工具可供文档维护。
工作流我这边就暂且不说了,对于项目推进来说是神器,但是对于prd文档维护来说,可能效果就不那么明显了。
第二个是我们的邮箱,对大家没有看错,其实邮箱如果大家善加利用,也是一个小工作流。只是现在的状况非常的凄惨,我刚才看了一下,一天的时间里我收到的邮件有27封,其中真正有用的只有两封,其余25封是什么呢?都是一些垃圾邮件,公司里总有一拨人,为了证明他们是在工作的,随便写一封一句话邮件也要抄送好几十无关人员,但是真正的实事他们往往干得最少,因为心思都花在这上面了。所以我在这呼吁大家,随便写一封邮件就抄送好几十人这种行为是不好的,净化我们邮箱,让他回归他应在的位置。
第三个是我们的Axure RP。因为Axure这款软件的产品定位缘故,我非常不建议将整个prd用这个软件写,然后直接扔到服务器里了事。我的做法是:只做交互DEMO的时候使用,让设计师同学能够更加快速的明白你的意思。在设计师同学将设计稿做出来以后,代替DEMO放在RP里,让前端同学更易理解。而真正的逻辑问题,我的建议是交给word,并把word放在XWIKI里。
第四个就是XWIKI了,也是目前我认为最适合文档维护的地方,在XWIKI里,我会分为4个部分存放,第一就是正文,正文是读者进来第一眼就要看到的地方,我会在这里写最重要的文档属性和解决问题。而附件我首先会上传pdf格式的prd,在保证严谨性的同时,也兼顾了美观,只是自己会有点麻烦,每次修改后都得转一下格式。第二我会放rp格式的交互稿,但是到后面我也不太放了,直接在pdf里写好链接,让读者点击跳转至服务器上看,这样在读者体验上也许会更好。第四我放的则是将设计师给出的设计稿切玩图打包好,放在附件中,随时供前端和客户端同学查看。
这一切的优化,都是为了我们的效率,为了我们能够又好又快地使产品尽快产出结果。
所以做完这些优化后,我的结果是:
2015年3月20日到2015年4月3日,5个工作日就完成了复杂程度和所调用的开发资源均是“Y项目”两倍的“X项目”的全部需求确认并完成评审,并在开发那边反响也非常不错,排期完成后立即开始了开发。文档易读性也被开发主管称赞。
也许我的方法并非最优,只是我个人的一点小经验,供大家参考,在接下来的日子,我将继续在提高效率方面进行思考。
网友评论