跳到正文
首页文章需求传了三手,“只在这种情况下”丢在了哪一手

需求传了三手,“只在这种情况下”丢在了哪一手

做贪杯熊商家平台时,商家填的资料要一路传到用户侧。最容易在传递里掉条件的就两类:活动优惠的适用时段和商品范围,套餐的使用条件和核销规则。丢掉的从来不是字段,是字段之间的关系。

需求沟通跨团队协作产品思考
需求传了三手,“只在这种情况下”丢在了哪一手 封面图

做贪杯熊商家平台,商家维护的资料要一路同步到用户侧,中间要经过不止一个人的手。我想多问一个比“大家有没有理解需求”更细的问题:同一个需求从一个人交到另一个人手里,哪些条件最容易被省掉?

需求未必因为谁说错一句话才变样。有时候,每个人都把自己收到的东西整理得更清楚,最后却已经不是最初要解决的那个问题了。

最容易掉的两类

最容易在传递里掉条件的就两类:活动优惠的适用时段和商品范围,套餐的使用条件和核销规则。

举个假设例子:有一个商家活动配置需求,某项优惠只在指定时段、针对部分商品生效。把它写成“支持活动时间和优惠商品配置”,功能名字没错,但“两个条件必须同时成立”这层关系,就不够醒目了。做配置页的人可以把时间和商品分别做成字段,做展示的人也可以把优惠标签摆出来。两边都有交付,用户却可能只看见优惠,没看见自己不适用的条件。

丢掉的不是某个字段,是字段之间的关系。这比少写一行说明更难察觉。字段有无很容易核对,关系却需要把配置、展示和实际使用连起来看。页面上有时间,不等于优惠标签出现时一定带着时间;有商品范围,不等于用户能分清哪些商品不在范围内。

这也是我不愿只用功能列表判断需求是否传完整的原因。列表擅长回答这一版做什么,不擅长保存为什么只做到这里。商家希望自己调整活动,可能是为了减少常规修改的等待,不意味着任何规则都该开放。传递以后只剩下“商家自助配置”,下一位接手的人就可能合理地继续扩展选项。那不一定是理解能力的问题,也可能是原来的范围没有一起交过去。

真丢过的一次

真丢过的一次,丢的是套餐的使用条件。

那条需求从商家开始,经过运营、产品,到研发,正好是这几手。商家把套餐和它的使用条件交给运营,运营整理进资料,我写进需求,研发做出来。每一手都有交付,上线以后,是用户反馈过来,才知道使用条件没有跟着套餐一起到用户面前。

回头找丢在哪一手,找不到一个明确的人。每一手都觉得自己把套餐传下去了,使用条件好像也在。大概是从套餐成立的前提,慢慢变成了附在后面的一行说明,再往后,就没人把它当成必须和套餐一起出现的东西。

这件事以后,我在需求里多写一样东西:边界情形。不只写套餐怎么展示,也写不满足使用条件的时候,用户会看到什么。

“已确认”是谁确认的

还有一类条件,是某个角色能够成立的判断,换个人就不能直接用。“资料已经确认”尤其让我停一下。是商家确认内容无误,运营确认资料齐全,还是平台确认符合展示要求?这些确认各有用途,不能相互顶替。商家确认了活动价格,不能顺带证明用户侧已经展示了完整的使用限制。需求里只留下一个“已确认”的状态,后面的人很难知道还需要自己确认什么。

当然,不可能把每个人知道的背景都抄进每一份文档。商家经营的细节、运营的全部沟通过程、研发讨论过的每种实现,都带过去反而让关键要求更难找。我更想保留的是那些会改变方案的条件:少了哪一句,下一位就可能作出不同决定?活动的适用范围值得紧贴着优惠展示写,至于活动文案曾经讨论过几种措辞,不需要占同样的位置。

原话和整理后的意思也不能只留一个。只留原话,接手的人要重新猜;只留结论,又看不到中间做了哪些解释。可以让两者离得近一点,尤其是尚未确认的解释。“希望更快修改资料”是诉求,“允许所有修改立即生效”已经是方案。两句之间还隔着内容风险和检查方式,不能在整理时把这段选择悄悄省掉。

传递中的变化也不都该阻止。研发可能发现一个状态不够表达,设计可能发现限制说明放在原位置很难被看到。这些新信息本来就该改变方案。我在意的是,改变以后大家是否知道原来的哪项前提被调整了。如果只是各自在自己负责的部分补得更合理,最后合起来,仍可能有一条条件没人负责。

沿着这个活动继续想,展示空间确实放不下所有说明,就得讨论哪些限制必须在用户作决定之前出现,哪些可以展开查看。没有一种排版天然正确,也不能简单要求所有文字都同样显眼。关键是不能把空间不足直接处理成删条件,更不能让“点开详情就有”自动等于已经告知。

拿一个边界情形核对

我也不想因此把需求沟通变成反复复述。每交一次都要求别人原样讲一遍,工作会很重,而且复述正确不等于能用。相比再问一次“理解了吗”,拿一个边界情形来讨论更有意义:活动时间到了但商品不符合,用户会看见什么?答案一不同,大家讨论的就是同一处缺口,而不是谁听得不认真。

这类核对不需要写很长。一个适用条件、一种不适用的情形,加上尚未确认的地方,有时比一页“各端保持一致”有用。它也能让后续的修改有依据。以后决定扩大活动范围,可以明确知道改的是哪条规则,不用重新从一个模糊的功能名字开始猜。

那次丢掉的使用条件,如果上线前有人问一句,不满足条件的时候用户会看到什么,大概就能被发现。

资料从商家手里到用户面前,本来就要经过不同人的处理。现在我更关心的不是尽量减少所有转述,而是让必要的转述有迹可循。尤其那些“只对谁”“在什么时候”“还要经过哪一步”的话,读起来像补充说明,却可能正是下一位作决定时最需要的部分。

问问 KANG AI

想了解我什么?