PD成长记--有关效率和文档的故事

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项目”的全部需求确认并完成评审，并在开发那边反响也非常不错，排期完成后立即开始了开发。文档易读性也被开发主管称赞。

也许我的方法并非最优，只是我个人的一点小经验，供大家参考，在接下来的日子，我将继续在提高效率方面进行思考。