PRD.png

成为产品经理之前觉得自己特别牛逼；成为产品经理的时候觉得自己贼拉牛逼，经理的Title，官瘾一发作谁与争锋啊，🙅脸；成为产品经理之后，汪汪汪。🐶

这里说下我也是个半路出家的银，关于我是如何成（wu）功（ru）转（qi）行（tu）的会再另外叨逼叨的。至于为啥现在还是半吊子，我记得一个前辈跟我说，“当你懂得分享的时候，说明你成功了”，之前一直觉得自己笨写不出啥，现在，来来来，鸡蛋白菜招呼过来，老娘从100斤到120斤了啥都能承受了。（这句话信息量有点大，知识点有木有）

如果你想做产品或者已经是半条腿搭里面了，就跟我一起走走看，也许走着走着就散了，也许走着走着就走出门道儿了。

为什么写产品需求文档这里不再赘述，作为产品经理，相关文档、原型简直就是你的脸，虽然我长得惨不忍睹，但是文档绝对要让他们一看就想舔屏。（当然，刚开始的时候，也就5、6个程序猿水土不服吐了）

重点在下面👇

开发哥哥其实才是外贸协会的，注重颜值和身段儿，看到漂亮妹子真的会舔屏的人看到你一堆博大精深的汉字，一定是抗拒的。所以，给他们看的，一定图文并茂。至于用什么写，全凭自己心思，不过要考虑是不是全员都可以使用的，比如你用pages，就一定想着转成PDF格式，这样全部的人都可以看。

文档.png

不叨叨了，上骨头架子。

文档标题

简单明了，否则以后做归档或者开发过程中有人来找你讨（si）论（bi）找文档核实找不到。打脸，piapiapia。

修订历史

一个清晰的修订历史可以让协同人员和开发者更好的下手。

A-增加 M-修改 D-删除

目录

很多文档编辑软件都可以根据内容自动生成目录，这里不做赘述，只想说一点，如果文档页数比较多，页码一定要支持点击跳转。

需求概述

发号施令的时候到啦，恩应该是跪着的时候到了，委屈脸。

目的

一般开发哥哥不会看，但是作为一个产品，要用充满改变世界的气质去写你为啥要做这个需求。

新增/修改功能列表

项目进行过程中，免不了要有需求的增、改，不要觉得这样是对自己的否定，这是对整个项目团队和产品负责。记得，开发过程中，商（si）量（bi）完，一定要把更改和结论落实到文档里，并同步给相关人员，否则，大家只会“渐行渐远渐无书”。

优先级P0>P1

用户角色

一个产品，会有很多人去使用，也会并发很多使用需求，产生使用场景，目标用户和使用者的功能权限清晰定位，是整个项目逻辑清晰的基础。

用户角色.png

名词解释

会有很多因为业务或产品经理自己对产品的定位而产生的名词，这个时候，作为造词者，你有义务解释清楚，否则开发过程中，大家不清楚要么按照自己的理解做，要么全部过来问你，有的忙。

名词解释.png

功能结构

向世人展示你精妙绝伦的逻辑，xmind脑图就是一个特别好的利器，果粉可以使用OmniGraffle，也是颜值居高的产品，我脑图、流程图都用它搞定。以后争取出个使用技巧给大家。

功能结构图会让无论项目中的开发人员还是砸钱的老板，胸中有数，知道你要折腾啥，有时候你会看到有人也用它画大饼。

xmind.png

操作流程

流程图可以清晰的展示业务流程和操作流程等相关的使用逻辑。开发哥哥喜欢逻辑清晰的汪，有它支撑你的需求，相信我你不会被打倒的。

OmniGraffle.png

功能详述

功能名称

功能概述

按照模块或者按照业务需求来讲各个功能展开描述，这里注意不要写800字作文，更不要写论文！有文学功底的同学请克制自己。只需要写清楚功能点和如何实现就好。

详细描述

这里要详情写清楚各种状态会触发的事件和边界情况。例如，字段、状态说明、交互说明；输入、处理、输出、补充说明等规则；不要只告诉开发哥哥你要一个苹果，要说清楚你要什么品种，什么颜色，什么size，否则，我不保证他给你一个大西瓜。

原型/效果图

高颜值的东西来了，对，就是你画的原型或者效果图，当然，有的公司不要求产品原型是高保真的，但这并不代表你可以随便画！

原型或效果图上最好写清楚交互说明，这个可以跟交互设计师一起来定，请相信设计师的能力，这也影响着设计师的设计图效果。做产品要懂得接力而行，不要晒比呵呵的啥都一个人做，自己审美不行还非得花一星期画个高保真的，结果局限设计师。

上几个图大家自行感受，对我就是那个画高保真的晒比。请原谅我放大的高保真图，没办法的虚荣心。

手绘原型.png

手绘原型图绝壁是最文艺的输出，并且在一定程度上能快速还原大脑中的产品构思，适合脑暴或者初期的产品建设。现在也有很多软件可以将手绘图转变成图片。

线框原型图.png

其实线框图才是设计师最喜欢的原型图，逻辑清晰简单，不局限，当然如果你有交互想法可以跟设计师沟通。并且利于你自己对产品规范性的把握。

高保真原型图.png

真正高保真的原型图是有全部的交互效果的，不过也是最花时间的，看个人能力，我觉得有时间可以学习起来，但不建议新狗狗们直接耍这样的大刀，我不会说我耍过，设计师也绝对没有嫌弃我。😭

非功能性需求

性能需求

做的产品多了或者学过一些的狗狗们应该知道并且学会去定义产品的大致响应时间，最大并发数，全局定位，状态的维持与恢复等边界值，这时候你就真的是有点牛逼了。

监控需求

在这个KPI横行的时代，我们做产品的必须要扛起这个重任，做的产品一定要用数据说话，数据的统计和分析，是产品进一步迭代和发展的有力发声，在产品文档输出前，要确定好埋点事件，产品上线了要做好数据统计（PV、点击、登录等）和数据管理（下载、缓存位置、收藏、清空等逻辑处理）

兼容性需求

如果是做PC端，会对浏览器进行兼容，例如IE8、chrome等，做客户端的当然是各大家的手机型号，不过，也并不是一味的进行兼容，要结合产品的使用者，也就是我们的上帝。

产品需求文档只是我们这些产品狗傍身的一项技能，写好它，我们工作效率会提高很多，本狗也是分享一些拙见，还望各位前、后辈多多斧正，啦啦啦啦啦啦……