config.o:文件无法辨识_如何看待“无法实现”的需求？

01

日更挑战：DAY15

产品经理和研发之间，有两种关系：一种是“战友”，一种是“敌人”。 这是可以选择的，而且选择权 在产品经理手中。

也就是说，我们可以选择与开发成为“敌人”，或者，选择与研发成为“战友”。

这取决于我们对一些特殊事件的看法。

比如，“这个功能实现不了”。

当研发告诉你，某个需求无法实现时，你会怎么看？

02

我的一 位读 者朋友曾经和我讨论过一个事件：

他们是做内容社区的，在内容上的运营非常出色，用户活跃度很高。

产品上线收费功能以后，为了增加用户的付费率，产品总监准备向某些潜在付费用户定向推送一些活动通知。

其中一类潜在用户，是“连续使用7天”的用户。

当他们第8天登录产品时，会自动触发活动弹窗，引导他们参与到付费业务当中。

我的朋友，是这项需求的执行人，落地执行时遇到了一些困难。

研发团队一致认为“这项需求无法实现”，并且，研发主管也有相同的看法。

如果是你，你会怎么办？

我的朋友将研发的判断告诉了产品总监，站在他的立场来看：

既然研发主管都说实现不了，那么这个需求就是无法实现的需求了。

而对于无法实现的需求，完成不了，也是没办法的事。

然而，这项需求，最后却实现了。

产品总监先是组织了开发团队进行需求评审，通过询问的方式，详细了解大家认为无法实现的原因。

最后，针对这些原因给出了一套解决方案。

这套解决方案的核心，就是对“连续使用7天的用户”进行“标记”。

系统会在每天凌晨01:00，进行离线计算。

以昨日有登录行为的用户为对象，统计他们的用户ID，在上一日是否有登录行为。

如果有，就继续向再上一日进行统计，如果没有，就停止统计。

循环7次，就能判断出一位用户在最近的7天里，是否连续使用了产品。

对这些连续使用7天的用户，赋予一个有效期为24小时的状态标记。

系统就有了一个简单的“是和否”的判断条件。

这样，就能够做到针对“连续使用了7天的用户”进行定向活动弹窗的需求。

开发团队认为该需求无法实现的原因，是因为系统本身并不知道用户的连续使用天数。

尽管我们可以在用户登录时，查询该用户过去7天的使用行为。

但这样会导致登录行为本身变得迟钝，也会产生服务器算能的浪费。

而产品总监所提出的解决方案：一方面赋予了用户临时标签，使得系统可以判断用户是否符合弹窗的条件；

另一方面，也通过离线计算的方式，将算能的使用至于凌晨1点。

此时，服务器大量的算能都处于空闲状态。

至此，一个原本“无法实现”的需求，最后，还是成功实现了。

这段经历，让我的朋友沉默了很久。

同样的需求，不同的态度，最后成就了两种不同的结果。

根本原因，还是我们的态度。

当开发团队告诉我们“需求无法实现”时，我们应该如何对待这样的回应。

03

条件满足时，所有的事情都可以做。当必要条件缺少时，原本可以做的事情，也变成了无法做的事情。

需求的实现，也是如此。

“无法实现”与“可以实现”是需求对于开发者呈现出来的两种特殊状态。

是否满足必要条件，则是需求处于何种状态的判断条件。

我们所说的“需求无法实现”，就是指某个需求的实现，缺少相对应的必要条件。

当缺少的条件，被补充上时，“无法实现”的需求，也会变成“可以实现”的需求。

如同，缺少墨水的打印机，无法打印文件，补充墨水以后，就可以正常打印一样。

根据缺少的条件类型，也可以将“无法实现”划分成多种类型。

比如，缺少时间，缺少资源，缺少逻辑，缺少业务等等。

朋友所经历的“无法实现”，就属于“缺少标记”的类型。

“标记”，是做逻辑判断时常用的字段，其核心意义是进行条件辨识。

通过“标记”，我们可以对用户是否符合条件进行辨识。

复杂一点，还可以辨识出用户符合哪种条件，并为不同的条件设计不同的响应策略。

缺少标记时，系统就无法对用户进行辨识了，对应的需求，也就无法实现了。

基本上，数据库里的所有字段都可以作为“标记”来使用。

而“标记”的缺失，往往也意味着数据库缺少了对应的字段。

比如，向男性用户推荐胡须刀，向女性用户推荐口红，就需要将用户的性别字段，作为标记来使用，以此来对用户进行辨识。

缺少标记所导致的“无法实现”，就需要在数据库里补充对应的新字段，或者采用其他的字段作为“标记”。

“针对连续登录7天的用户，触发活动弹窗”，这项需求无法实现的原因，就是因为缺少标记。

数据库里没有字段存储用户的连续登录天数。

因此系统无法对用户进行辨识，无法知道用户是否符合活动弹窗的触发条件。

产品总监的底层思想，简单来讲：就是对缺少的必要条件，进行了补充。

使得系统能够对用户进行 辨识，能够判断出用户是否符合触发条件。

04

我们可以选择与开发做“战友”，也可以选择与开发做“敌人”。

如果，我们将开发所说的“无法实现”，理解成事情的“结论”。

将会采取的措施，无外乎是“争执”和“强压”。

从结果上来看，大概率也只有两种结果：

第一种，开发同事熬夜加班。

自己独立思考“缺失条件”的补充方案，对产品经理不抱有一丝期望。

第二种，即使熬夜加班，耗费了许多时间，也仍然没能找到“缺失条件”的补充方案。

既承担了压力，也付出了辛苦，还被老板和领导责罚，心里对产品经理充满了不信任和怨恨。

不论是哪一种结果，都意味着我们和开发成为了“敌人”。

如果，我们将开发所说的“无法实现”，理解成事情的一种状态，就会采取另一种措施了。

我们可以与开发一起探讨：

缺少了哪一个必要条件；

也可以和开发一起思考补充方案；

还可以对彼此提出的补充方案进行完善和修改。

最重要的是，我们站在产品的角度。

可以从需求和产品设计上，对缺失的条件进行补充，这是开发同事所不具备的优势。

无论我们最后是否找到了补充方案。

这样的选择，以及这样的过程，都会意味着我们和开发建立起了彼此的信任。

也意味着，我们和开发成为了“战友”。

那么，你想和开发之间，建立“战友”关系，还是建立“敌人”关系呢？

选择权，一直在你手中。

我是枯叶，与你分享我对产品的认知。

明天，11:50，不见不散！