产品新人写PRD应该避免的坑.pdfVIP

产品新人写PRD应该避免的坑 产品入行半年了 ，大大小小的坑遇到不少 ，这些血泪经验是最 贵的财富 ，一直告诫自己 ，要常 总结、常反思 ，希望n年之后 ，再看到今天写下的这些东西 ，能有更多的感悟。今天主要说的 是PRD中遇到的那些大大小小的坑 ，不一定适用全部情况 ，欢迎各位纠错 ，欢迎各前辈指导 ！ 最近半年 ， 最主要的工作就是写PRD ，PRD的重要性不言而喻。 在产品的整个开发流程中 ，PRD的作用有以下几个方面 ： PRD指导其他部门进行工作的准备工作 测试根据PRD写测试用例 ；开发经理根据PRD写开发文档 ；UI根据PRD和原型设计。 PRD承担字典的工作 测试人员可能更多的是根据测试用例工作 ，而开发看的更多的是开发文档。但当大家发现某个细节 在测试用例或者开发文档描述不清楚或者难以理解时 ，就会翻出PRD查找相关内容。PRD在这个时 候是承担了一个字典的功能。 PRD是打架必备。 测试和开发的天然属性决定了他们之间微妙的关系 ，很多时候bug的定义是似是而非的 ，很多时候 涉及到用户体验的问题 ，而用户体验有带有很大的个人主观性 ，此时矛盾就出现了。当测试和开发 就某个问题争论的面红耳赤 ，几乎要干架时 ，最后一句压场的话就是“别瞎bb ，看PRD ！” ，此时要 是PRD上有关于此问题的详细描述 ，那开发要么找产品经理改需求 ，要么只能自己改代码了。要 是PRD上没有相关内容 ，那开发就可以傲娇的说“需求就是这么写的 ，你要改 ，先去找产品改 文档 ！”。所以一般来说 ，测试是希望PRD写的越详细越好 ，这样他们的bug才提的有理有据 ，而开 发希望提出的需求能够逻辑严密 ，但不太希望产品经理将所有的细节都规定死 ，毕竟产品对于技术 的了解并不深。所以产品要注意把握好度 ，这点我自己还在不断的思考之中。 貌似现在也有很多公司不需要产品人员写PRD ，但我觉得PRD应该是产品人的必备技能 ，他可以不 要求你写 ，但你不能不会。作为一个新手 ，特别是一个没有技术基础的新手 ，写PRD时 ，是一个很 好的梳理思维的过程。 刚开始写PRD的时候 ，不知道有些功能可以整合在一起说明 ，每次都罗里吧嗦的全部重新说一遍。 比如 ，分享功能 ，应用里很多地方都涉及到了 ，每一次涉及分享 ，我都会把分享的机制从头到尾说 一遍 ，其实这就很啰嗦 ，文档的文字本来就够多了。所以 ，建议将一些在软件里反复涉及的功能提 炼出来统一说明 ，当后续涉及到的时候 ，简单阐述一下就行 ，不用再重头说一遍。 我的经验是 ，对控件及一些通用的机制进行统一说明 ，会使文档简洁省力一点。 在文档的一开始 ，最好有一个单独的模块说明应用内使用的控件 ，说明这些控件的类型以及每个控 件对应的操作方式 ，在这个模块统一说明之后 ，在其他模块涉及此控件时 ，只要简单阐述一下 就o k了。 下面列举了一些常用的控件。 模块一、控件说明 输入框 若输入框有默认提示 ，点击输入框 ，弹出软键盘。 当输入框内不为空(空格除外)时 ，默认显示消失。 软键盘的弹出及 去机制 当输入框内必须输入的为数字时 ，弹出数字软键盘。其余时候 ，弹出文字软键盘。 当在软键盘以外区域 ，点击或者向下滑动时 ，软键盘退去。 小黑块提示 显示*秒 ，然后自动消失。 选择弹框 弹框上有操作按钮。 点击弹框以外的区域 ，弹框消失。 手机返回键(安卓) 点击手机上返回键 ，返回上一层 ，并弹出相应提示。 Ho me键 按ho me键 ，程序改为后台运行 ，再次打开软件时 ，则回到按ho me键时的页面。 在文档的一开始 ，最好有一个单独的模块说明应用内使用的控件 ，说明这些控件的类型以及每个控 件对应的操作方式 ，在这个模块统一说明之后 ，在其他模块涉及此控件时 ，只要简单阐述一下 就o k了。下面列举了一些常用的控件。 同样 ，很多通用的机制也能整合在一起 ，比如加载机制、缓存机制、网络判断、中断机制等 ， 以下 是我自己整理的几个通用的功能。 模块二、通用功能 ： 缓存机制 每一步操作、每一个页面切换之后 ，都要想得到的数据需要缓存么 ？缓存到哪里 ？清理缓存的时机 是什么? 网络判断 一般当涉及到下载或其他很耗费流量的操作时 ，会进行2/3G网络还是w if i网络的判断 ，当判断出 是非w if i状态时 ，会进行提醒。 其他需要向后台请求数据时 ，只进行简单的网络状况是否良好的判断 ，当网络状况不良时进行 提示。 中断机制 除退出登录外 ，要考虑出现什么情况会导致用户中断操作。中断操作会有什么影响 ，比如是否要