整理了一下以前写的文章，将一些我觉得仍有价值的迁到简书，或许对别人有用呢。
我17年大学入学后加入了某技术团队PM组，到现在也有一年多了，最近一段时间，我负责了一个项目从0到1的产品设计和落地跟进。
由于各种因素的影响，目前项目的结果还没有达到预期，但是在项目过程和复盘中也有一些收获，以此输出记录。
当然，这些是一个没有工作经历的大学生在校内做产品的一些思考，部分内容可能不适用于公司工作场景，前辈们有好的建议请不吝赐教。
一、写PRD不要自娱自乐
1. PRD不是写给自己看的
PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。
PRD不是写给产品经理自己看的，这是在初期非常重要的一个认知，不是说在百度上了解到了像上面这些PRD的主要使用对象这么简单。
说一个我经历的情况，我写完PRD后自己觉得很满意，该说的都说了，而且自觉说得很有道理，很清楚，但是交给开发等对象的时候，他们会吐槽说好复杂，看不懂，这时候我就火了，我辛辛苦苦写的这份PRD你竟然说看不懂，这是你自己的问题吧。
但是我又考虑了一下，这可能真的是产品经理的问题，理由有三：
- 我的脑子里有这个产品完整的样貌，所以我在写的时候会有代入感，这种错觉让内容带有跳跃性，就像教科书上编者知道答案，所以两三个等式就给出了结果，但是学生看得一脸懵逼；
- 人总是会习惯从自己的视角出发来看问题，但是每个人的知识框架是不同的；
- 写东西的时候人们会很容易不说人话。
那么我们应该怎么做呢？
2. 换位思考，视目标对象为用户
明确了目标和问题之后，产品经理需要考虑的是我的目标对象想要在这份PRD中获取哪些信息，如何让他们更好获取信息，以及为什么他们需要这样做来获取这些信息，换句话说，PRD其实就是你的产品，PRD的使用对象就是你的目标用户，那么你该如何考虑呢？
- 用户通过什么途径来查看PRD，哪个途径对他们来说最方便？
- 用户打开PRD到找到他们想要的信息的路径是怎么样的，如何优化他们找到信息的路径？
- 用户如何接受你想要传达的信息，哪种方式对他们来说最高效？
- 用户如何向其他人反馈他的看法和疑惑，怎么让反馈被更有效地接受？
考虑了用户使用PRD的完整流程之后，我们就可以开始进行全流程优化了。
- 对于第一个问题，使用Axure写PRD可以生成在线浏览的链接，不再受文档保存的限制。一开始我是用传统的word文档来写PRD，在听了他们的反馈之后，我开始学习用Axure重新写了一版，写对比PRD的工具的文章已经很多了，我不再赘述；
- 对于第二个问题，使用Axure写PRD可以自定义一些方便查看的交互，比如全局目录、在修改记录中添加一个可以直接跳转的按钮、可以在PRD和原型间直接跳转等，只要你考虑得足够细，可以让你的用户在获取信息时非常爽；
- 对于第三个问题，使用Axure写PRD可以让你非常方便的将内容通过思维导图等方式进行可视化。这一点个人认为非常重要，将你想要传达的信息转化为人们更容易理解的思维导图等结构图，可以极大地降低人们信息交流之间的摩擦，当我在用优化后的PRD跟程序员们讲项目的时候，他们很快就能了解他们要干的事情是什么；
- 对于第四个问题，使用Axure写PRD生成的Axshare链接提供评论功能，可以在你想要评论的地方生成一个定位标签，可以直接在评论栏中点击跳转查看。
二、5WHY法找出问题的根源
这个项目经历了项目延期、寻找外包、最小可行三个阶段，可以说踩了很多产品经理的坑，在项目过程中我也在不断思考并改进，但总感觉没抓到要点，学习了5WHY法思考框架后，才意识到这些问题其实可以从根源解决。以下是我在复盘时的使用5WHY法的思考过程：
为什么项目会延期？
因为程序员没有投入时间去做。
为什么他们没有投入时间去做？
理由如下：
1.程序员都是学生，在时间和优先级上会有冲突，他们选择优先完成自己的事情
为什么项目在他们那的优先级不高？
因为没有给他们明确的重视和压力（程序员们是另一个技术团队的，这个项目是团队老师分配给他们的任务） 。
为什么没有给他们明确的重视和紧迫的压力？
因为项目的直接受益者没有真正重视这个项目。
为什么项目的直接受益者没有真正重视这个项目？
因为项目的直接受益者不是直接发起人，也不是需求最痛的人，没有体会到项目的价值。
所以我应该做的是找团队老师，跟她讲明这个项目的意义和对她产生的价值。
于是我按照这个结论去执行，结果团队真的又平稳地动起来了，比原来催他们进度有效多了
2.程序员看到项目需要实现的功能比较多，觉得要花很多时间，没有干劲。
为什么他们觉得要花很多时间？
因为PRD看起来比较复杂
为什么PRD看起来比较复杂？
因为他们在PRD中看到的是项目的完整结果，而不是阶段性可以反馈的目标。所以我应该在开发过程中使用MVP的模式，让他们能得到阶段性的积极反馈 于是我重新设计了产品MVP的形态，尽管和完整版相差较大，不能够彻底实现原先的目的，但是仍仅仅围绕着我们的核心需求，并且程序员们也觉得轻松了。
因为在信息的呈现方式上太死板。 所以我应该让信息的呈现更加直观 在优化过程中我通过思维导图等形式让重要的信息可视化，让他们能够更容易接收。
三、MVP的作用不仅体现在成果，还体现在过程
1. MVP是一个积极反馈
在做这个项目时，我并没有采取MVP+快速迭代的方式，理由有三：
- 项目有非常明确的且固定的用户来源，并不需要投入市场检验产品；
- 项目涉及三个用户角色，只有三个角色所涉及功能都完善了，才能达到我们做这个项目的初衷；
- 项目安全性要求较高，在所有功能测试完全之前上线可能得不偿失。
那么我为什么又在复盘时改变了主意呢？因为我认为MVP不只是用来做产品验收的阶段指标，还可以给团队成员一个积极反馈。
人类的“文科生思维”决定了我们更喜欢得到及时反馈。而对于周期较长的项目开发来说，就是需要给自己一个能跑起来的东西，哪怕这个东西只是给自己看，甚至说为了能让它跑起来，会需要去多弄一些对于迭代来说冗余的东西，但我能换回来的是一个阶段性的积极反馈，这个正反馈循环能让团队成员越来越积极地去给这个东西添砖加瓦来实现下一阶段的目标。
2. MVP的正确含义
迭代是重复反馈过程的活动，其目的通常是为了接近并到达所需的目标或结果。每一次对过程的重复被称为一次“迭代”，而每一次迭代得到的结果会被用来作为下一次迭代的初始值。
根据维基百科的解释，其实图片上方的形式才是理论意义上的迭代，因为它每一次迭代的结果都可以直接用来作为下一次迭代的初始值，而MVP的模式还需要去付出一些额外的资源，最后得到的都是一辆车，上方这种成本才是最低的。
对于我做的这个项目，不需要考虑先发优势、产品验证等维度，MVP其实是一个用户最优的概念，而不是一个成本最优的概念，但是团队成员有三个局限：
开发者是学生，属于兼职参与做开发，时间和优先级上会有冲突；
当开发者看到要实现这么多功能时，好像做完遥遥无期，会产生畏难情绪；
看到产品展示成果的周期太长，做着做着会失去兴趣，消极推脱。
考虑到这三点，虽然采取MVP的开发模式会增加他们不必要的工作量，但是权衡比较，这部分工作量远小于积极反馈所获得的满足感，毕竟人不是完全理性的动物。
总结
在学校中做项目，能提升的主要还是作为界面产品经理的能力，几乎不可能养成商业产品经理的意识，界面产品经理和商业产品经理最大的区别是对“成本”概念的理解，而学校会给学生一种成本错觉，让人觉得人力成本、试错成本、技术成本等似乎不太重要。
我希望能够通过实习去体验真正的成本意识、资源调度以及复杂系统的协作机制，能打破自己的认知局限。
