Being Agile! 当评PRD的时候我们聊什么？-京东云开发者社区

------------

#### 主编说：
文章里有句话特别提神：“需求评审时，做一个没得感情的杀手”；需求评审是一个几方对齐的过程；大家要扩大共识，把“你知道，我不知道；你不知道，我也不知道“的信息孤岛消除到最小。所以，我们在评审的时候应统一站位，即客户视角；并基于调研、基于逻辑、基于数据；而不是，“领导说”、“业务说”……。文中还提到了对边界问题的思考，也是同理，要跳出“XX决定脑袋“迷局，以技术和客户的视角去站位、思考。

------------

#### 引言
文章照搬村上的《当我谈跑步时我谈些什么》的命名形式来命名，只是显得文艺一点吸引大家的兴趣。并不能表示文章的质量多高~~~

此文的内容是我们在日常评审prd做的一些总结，一些必须要思考的点，也可以说是checklist。当然这些注意的点是慢慢积累出来的，在后面的工作中有了新的想法还是得补充进来，一定不是一层不变的。

当然，有的点在执行的时候会在研发与产品之间，研发与业务之间出现产生分歧和对峙。排除需求理解没对齐和更好的建议之外，大多数研发是对，因为研发更了解（自以为是）用户。但是最后大多数还是听了业务方的，因为他们也以为自己更了解用户。这些微妙的东西看大家如何处理了，暂时没有固定法则。

这些也不一定完全适合其他的团队，毕竟每个团队的文化、风格不一样。建议大家定制下自己团队的内容。希望我们在评审prd的时候，都是一个没得感情的“杀手”。
#### 需求合理性
##### 业务方想要做什么，为什么？现场需要什么、现场真正用起来会怎么样
这一条应该大家都去想，围绕用户体验思考。这里有个争论点，业务方和我们究竟谁是最了解现场（用户）的人。也许是我们更了解现场。所以我们对业务方的每个需求都要提出可行性质疑，现场会真正用吗？需求有没有经过调研？能不能给现场提升工作效率？如果不能回答好这几个疑问，建议拒绝不能拒绝考虑升级处理。

- **需求变更（处理好加减法）**
**这一条主要场景是对原有需求做改动。需求的每次变更都会有副作用，有的可以接受有的却是大问题，这就看我们能否仔细评估。也可以这样理解这一条，是对功能做了加法还是做了减法。**
① 如果是做了加法警惕体验问题，有些功能是高频次使用，比一个功能，如果多加一个数据框或者拦截可想而知对体验和效率影响有多大。
② 如果做了减法，就是原有的功能减少了使用场景，那些使用这些场景的用户怎么办，如果考虑不周经常是上线了又回滚。
  **反例：**
① 有个打印功能，只是对“原单号”输入框内容做了长度范围减小限制，前期也对历史数据进行了分析。但是等上线一周后现场才反馈问题，后面不得已回滚。
② 三无功能改造。有个来自“上面的要求”，要火急火燎的改造三无功能。这个功能本身不在我们这边，只是把菜单挂在系统里。我们对功能和使用的用户都不了解。业务小哥也对此功能不懂。研发根据需求起早贪黑改造上线后，现场不认了。原先支持的场景不支持了，使用习惯也变了。后面一直在救火、填补原有的功能。

- **系统边界**
 需求内容里哪些不应该放在我们系统，业务域是否清晰。是不是对方不好沟通才放在我们系统里做得，或者之前有类似得我们系统做过，这些说法都不合理。或者说我们多做一些是不是更好一些，对方多做一些会不会更好？

##### 简单点？说话的方式简单点？
 需求里经常出现这类词语“逻辑跟XXX一样”，“原先逻辑不变”。这是偷懒的写法。一方面：并不是每个人都了解原来的逻辑，另一方面，不确保你认为的原来的逻辑和我认为的原来的逻辑是否一致。我们也在这上面踩过多次坑。

#### 需求如何做
##### 聚合、复用、可扩展
这一条比较抽象，只是提醒我们往这方面思考。想一想我们之前是不是有过类似的功能可以整合使用，如果是新的场景要考虑以后如何扩展和复用。
##### 最小MVP
这一条是敏捷开发的核心，好处不必多说。我们在评审的时候是必须check的点。
##### 直觉会犯错
心理学上有个词叫“易得性直觉”，就是说人们总是喜欢偏向于自己熟悉或者容易提取的信息来对某事进行决策。在评审需求的时候大家都会遇到模糊或者暂时未知的地方。这里还是要警惕，这些模糊和未知的地方不要太乐观，需要跟别人确认的地方及时确认，需要跟业务沟通的地方再次沟通。涉及到研发实现复杂度，研发要充分评估研发周期，不要被“这个需求很简单”这句话干扰到，要不后面填坑的是自己。
##### 其他部门兄弟准备好了吗
需求依赖别的部门的服务，或者是项目由整体节奏的排期。要跟对方对齐。要不自己提前做了开发，后面无法进行下一步联调、测试、上线等事项、研发人只能搁置次需求，多少天后再次拿起来基本就不记得细节了，而且研发资源这么紧张，反而用在了刀刀把上。
##### 运维成本&运维闭环
有些需求上线后用户使用的时候会有很多问号，这些问号需要产研花精力去解答，这种运维事项积累越多，我们在日常的工作中就会陷入值班解答中不能自拔。产生的原因如下：
- 新功能现场不知道如何使用。
- 可能是使用过程中遇到了阻碍后，不知道怎么办。
- 着急完成的功能，由于开发环节、测试环节、uat环节没有把控好，出现各种细节缺陷。
- 。。。

第一个最基本的解决方法是业务方对现场进行培训和收集反馈。虽然是最基本的要求，也并不是所有的业务方都能做到。第二条体验上的细节，比如我们产品有个提示：“该订单没有重量或体积不能组板”。现场看到后不知道如何进行下一步工作。提示换成：“该订单没有重量或体积不能组板，请使用平台打印称重”。这样更友好一些。第三条还是要多注重软件质量。
##### 逆向场景怎么办
系统常会对某些单子做拦截，在发货的时候不让现场直接操作，需要做一些其他的工作后才能操作。但是逆向单的拦截逻辑和正向单往往不一样。我们也是必须要check的点。此条有局限性。
##### 什么时候才算完？
起早贪黑做好的产品&功能，上线后使用率低？我认为需求上线后，是另一个开始：业务、产品、研发要跟踪现场的反馈，积极收集反馈。有条件的做调研。形成良性循环，慢慢打磨产品，好产品要经过几个迭代才能成形，并不是一蹴而就。
#### 结语
已上内容都是我们评审比较侧重的点，还有别的方面没有一一列出。欢迎大家提建议。 初心是做更好的产品、更好的用户体验，这也是更大的课题。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：快递技术部 徐迷根