最近团队在赶一个重点项目，公司投入了很大的产品研发资源，但在产品移交后开发时间过半的这个时间节点，依然会存在对某个核心功能点的逻辑存在重大分歧的问题。产品没定义清楚？在某个9千多字的PRD里的某个模块说明里，的确提了一句，那么就是需求评审的锅咯，这么重要的点，评审的时候怎么没想到呢？本着解决问题为出发点，我认真思考了一下如何才能避免类似问题的再次发生，毕竟评审是自己参加的，就当写一个POSTMORTEM吧。
1、Bounded Context
先介绍一下背景，此项目为一个新业务当然也涉及到老系统的改造，产品为此在分工上做了一些划分，每条线都有负责的产品，每人负责输出自己的PRD，最终串起了整个业务。
在需求评审的时候，发现了这么一个现象，前端产品PRD里某个展示逻辑，依赖的是后端产品定义的库存调拨逻辑，由于端比较多，不同端的产品经理的风格也不一样，有的比较详细的叙述了一下这个逻辑，有的通过一句话“由后端提供“让应用端开发不用关心这个逻辑的细节。到了后端产品的PRD里，这个逻辑又被定义了一下，由于这个逻辑涉及到的系统较多，在相应的后台系统里，这个点又被负责这个系统的产品经理提到了。
所以这个贯穿整个项目的核心逻辑，打乱了当前产品的分工边界，似乎所有人都得说一遍这个，否则我的PRD就是不完整的？类似的功能并不少，这个问题普遍存在。
2、Zoom In & Zoom Out
Zoom In指的是聚焦某个功能，Zoom Out是切换全局的能力，在这个项目中，可能是项目比较大的关系，真正辐射全局的PRD好像没有，除了有些独立的系统产品定义相对完整（对外部的影响好像提的也不多），其他的PRD都是一个模块。
3、Readable PRD
PRD作为产品和研发之间的交流载体，其重要性自然不言而喻。有的产品的确很认真，花了大力气写了PRD，其中甚至设计了数据模型，接口的入参出参都详细的定义了，工程师照着这个文档一行一行写代码就可以了？这个文档让我在评审的时候放空了，因为字真的有点多。所以怎样的PRD会比较受研发同学的欢迎呢，我简单总结了几点：
1、要解决什么问题。讲清楚要解决的用户或业务场景，别一上来直接列需求。
2、分层。先综述一遍你要的表现层，包括涉及到的页面展现，跳转流程，交互逻辑。然后描述具体的业务逻辑，这里包括流程图，功能模块。最后列出所有要实现的功能点，需要和现有的系统的对比，哪些是改动点，哪些是新功能。
3、抽象。重复的功能抽象出来，定义成一个统一的逻辑，和开发的思维一致，能很大的提升效率。
4、统一语言。整个文档的名词统一命名，类似开发定义变量，别一开始叫库位后面叫货架，这样很容易理解错误。
5、简化。不用太关心研发如何实现，毕竟我们不是对日外包，详尽的文档有好处，但个人比较偏向简洁，突出重点结构清晰的文档。
6、格式。文档格式尽量考虑在线可阅读的格式，避免出现网盘下载，zip包之类的文档。
以上为一个研发对产品文档可读性的一些想法。
4、技术和项目的管理
说了这么多，那研发这边就没问题了么？其实也不是，研发的问题也很多，特别是团队越来越大，即使不断在建立流程比如设计评审、Code Review、自动化测试，依然有很多错误在重复发生，似乎高素质的人才是解决问题的唯一办法，针对良莠不齐的人员，一个标准的详细的PRD好像也是可以提升质量的，这些可以专项讨论，毕竟这篇重点关注的是这次PRD问题引发的思考。
5、END
2019年了，决定重新启动Blog，锻炼一下写的能力。新年的目标也很少，聚焦几件事情就够了。
网友评论