互联网产品经验小分享——PRD中那些踩过的坑系列（2020.7.25）

撰写PRD，是互联网产品经理最最最熟悉不过的事了，网上有很多大佬写过如何撰写PRD，在此我就不过多重复了，今天我想分享的是，我在实际应用场景中，撰写PRD踩过的那些坑。

 

一.需求描述模糊，没有给出准确的逻辑方案

这个场景是我在日常工作中感触最深的，我举一个我曾经犯过的错：有一次，我写PRD时，写过这么一句话“竞标单状态为「竞标中」、「已结束」时，不可导入数据”，当时有一个后端开发是临时加入的，她是负责这个状态模块的编码工作，然后没有跟前端沟通，直接就在后端写了一堆逻辑做限制校验，直到她过来跟我沟通状态逻辑问题时，我才发现她在这部分弄得过于复杂了，于是我马上找来前端，让前端做一个限制点击就解决了。

不难看出，这个场景会埋下很多雷，同时也增加开发的工作量，这个经历，让我意识到了很多问题：

1）如果开发之间协调性低，如何解决此类问题？

解决：

1.增加团队之间协调性，在需求评审和接口文档设计阶段，需要团队配合完成，不要单打独斗；

2.开发须撰写日报；项目经理（或产品经理）跟踪开发进度，撰写项目周报；每周举办一次15~30分钟左右的周会，汇报项目进度与所遇到的问题，与团队成员信息共享；

 

2）为什么直到编码阶段才暴露了这个问题？这个问题本应该在接口设计文档定义之前就应该发现的。

解决：

1.开发在定义接口文档时，作为产品经理，面对不善于沟通的开发时，我们可以鼓励他们沟通，甚至可以牵头碰面开讨论去定义设计文档等，保证左右开发同学信息同步，需求理解同步清楚；

 

3）产品经理在撰写PRD时，一定要考虑前后端协调的问题，比如是由谁来做限制？谁来打辅助？都要思考清楚，如果产品经理不确定，可以提前询问开发意见；

 

4）PRD的内容，一定要定义精确，不要出现“需求描述清楚，但没有写明具体的实施方案”这种细节上的错误，避免给自己和开发挖坑；

 

二.修订记录

规范一些的PRD，一定是会有修订记录的，我个人也喜欢在原型图上专门设置一页修订记录，方便开发找到。

正常情况下，开发过程中有需求或者是逻辑的变更，是很正常的事情，修订记录里会记录这些变更内容（产品负责记录），但是如果遇到项目紧急、人员变更等特殊情况，产品可能就会忘记更新修订记录（我曾经就忘记过嘿嘿），如果修订记录里的东西不够完整，就等同于给项目组挖坑，后果我就不多陈述了，但我想说的是“产品经理一定一定一定要及时更新【修订记录】”

 

三.名词定义通俗易懂，避免发生误导

举一个真实例子：我身边有个产品，他把岗位名称和操作身份，定义的很混乱，比方说推广专员，他就称呼为“执行者、执行员、推广员”等等好几个称呼，在PRD里也是很混乱，这就导致开发不清楚每个身份与岗位的对应关系、业务使用也不理解、后续新产品接管迭代也不理解等等问题。

再举一个例子，大家可以猜一下光看字面上，“维护积分订单”这个词的定义是什么？我想大部分人都会觉得这个词的意思可能是编辑迭代某个订单的意思，但实际上，我身边的某个产品将这个词定义为提交一个新订单，我当时就傻眼了。后面不出我所料，因为这个词的定义，这个产品被喷的很惨。

因此，产品经理在定义某个名词前，一定要考虑业务场景，确认需求方是否能够理解，不要出现难以理解或者是有歧义的词。

 

今天的分享就到这里，希望对你们有所帮助