前人挖坑，后人填坑

最近半路接了一个别人的需求，产品方案早出完了，设计稿也已经出完了，部分前端页面也开发完了。这种情况下，更换产品人员或者更换产品方案，不仅返工量较大，而且也不太好和设计、开发人员交代…

奈何老大说产品方案有问题(确实有问题)，我怎么着也得把这个坑填了。最终改了改方案，砍了砍需求，跪了跪设计和开发大佬，总算是把这个需求给满足了。在整个方案调整的过程中，产生了一点碎碎念，暂时就先记录一下。

本文会先将整个产品案例阐述一遍，最后是由此引发的一点点思考。

我们公司的产品是一个音频平台，平台内主要有普通听众、主播、赞助商这几个角色。平台的内容为PGC+UGC的形式，凡是上传内容的用户，我们统一称为主播。

我半路接手的这个需求是为了给直播主播一个周数据的汇总，一方面便于主播了解当周的收益、互动等数据信息，另一方面也好让主播根据数据反馈来优化改进。

之前的产品方案包括这几部分，分别是本周数据、Top3的榜单数据、阶梯分成数据、当月开播数据。

方案的信息层级有些问题，而且有些数据服务端没有办法取到，在这样一个背景下，上司让我对这个方案进行一些调整…

在整个需求中，涉及到了两个角色，一个是主播，另一个是我们自己。所以首先需要解决这两个问题，一个是主播关注的是什么信息，另一个是我们想让主播看到什么信息。

作为一个主播，我更关注的很可能是我上周的一些数据信息，比如收益是多少，新增粉丝的数量是多少，粉丝与我的互动情况是怎样的等等…

当时和需求相关方沟通的时候，发现运营小伙伴有这样的需求，他们希望将主播当月的开播天数、开播时长和阶梯分成这些数据加入到周报里去。因为这些数据是和收益分成直接相关的，他们希望能够以此刺激主播完成当月的任务。

以上，从我们的角度来看，我们希望这个周报能传递给主播有用的数据信息，而且还能够让主播知道当前处于阶梯分成中的哪个阶段，距离下一阶段还差多少，进而刺激主播完成当月的直播任务。

相关干系人的需求和背景了解清楚之后，就是结合现有方案进行方案调整了，个人觉得现有方案最主要的问题是信息层级比较混乱。

首先这是一个周报，统计维度是按照周划分的，之前的方案是将上周的数据和月数据混在了一起，而月数据还不是按照自然月进行统计的，是按照结算月(当月20日-下月19日)进行计算的。

这样就会很容易让人产生困惑，不是周报么，为什么还有月数据的统计。所以我将数据信息进行了合并和分类，优先展示本周相关的信息，最后是月统计的信息。

其次是之前的产品方案有一些数据服务端取不到，需要做一些调整。因为数据指标主要是围绕着主播和听众展开的，所以我就按照收听和互动这两个维度进行了梳理。

收听主要包括收听人数、收听时长、收听场次等，互动主要包括评论、打赏、分享等…当时首先确定下来的是打赏这个指标，至于第二个指标选择什么，一直没确定下来。

因为这里面还隐含了另外一个角色，那就是管理员，主播一般都会有辅助自己管理直播间的管理员，而管理员的互动、收听数据一定是最高的。

中间想了好几个数据指标，都觉得不太恰当，而且对于主播的价值也不大，实现起来的成本还是有一些的，所以我果断决定把这个Top3的榜单数据砍掉了…

方案改好之后，我就去找我的上司确认产品方案去了，当时他问了我一个问题，这个问题我之前也考虑到了，也想到了对应的解决方案，不过他对解决方案不太满意。

这个问题就是周报中的周数据是按照自然周展示的，而阶梯分成的数据是按照结算月来计算的，这样造成的结果就是前面的数据和后面的数据可能会不一致。可能当周的数据较少，结算月的数据较多，也可能当周的数据较多，结算月的数据较少(本周数据跨了结算月)…

我最开始的解决方案是首先将两者从层级上进行了区分，先展示本周的数据，再展示结算月相关的数据。其次是考虑在结算月的数据上加上文字说明或者Tip弹窗的形式进行提示说明。

但是这样还是解决不了两者的结算周期不一致导致的问题，既可能会导致主播的困惑，又可能会增加主播咨询客服的频次…

最后和上司达成的共识就是把这个阶梯分成的数据砍掉，不在周报中展现，单独放置一个独立入口进行展现。

其实我的内心是非常拒绝把这个本月数据砍掉的，原因有很多，比如：

• 我答应了运营小伙伴这个功能会上线；

• 设计花了很多时间和精力来做这件事情；

• H5开发的动效都已经开发完成了；

• 我自己也在这个方案上投入了很多时间和精力…

人真是一种奇怪的生物，总觉得自己的想法或者方案总是要优于别人的，总是会想当然的认为别人的和我们的想法一样，一旦在一件事情上投入时间和精力之后，就会不自觉的高估这件事情的期望值…

最终我还是从投入产出比的角度否决了保留结算月数据的想法，因为做这件事情的成本会比较高，还会延伸出一系列的后续问题，而它的价值并没有那么大，即使投入了这么多的沉没成本，最后还是咬着牙把这个功能点砍掉了…

另外我还把另外一个需求给砍掉了，当时的产品方案里面是精确计算到上周是XX年的第XX周，比如2018年第35周的周报。

当时服务端找我确定详细的计算规则的时候，我直接把这个需求砍掉了，理由是不符合用户心理认知而且价值不大，仔细想想你什么时候说过上周是今年的第XX周这种话…

整个事情的始末用一句话说明就是，产品方案加入了很多功能点，经过一番沟(si)通(bi)之后把无关的功能点全部都砍掉了。

最终，产品方案由开始的3个页面，砍到了只剩下1个页面。开发小哥很满意…

改产品方案本身就是一个很痛苦的过程，而且这个产品方案还不是自己做的，改完之后还要和其他相关方沟通说明，还要避免队友产生厌恶情绪，想想也是头大。除了沟通协调这些事情，我还想说一点产品相关的感受。

产品经理(或者其他能决定产品走向的人)可能什么功能都想要，什么功能都去做，也可能会被动的接受很多相关方的需求，但是请一定记住这两个字——克制。

克制不仅仅意味着做与不做的问题，还意味着什么时候做，在哪个版本做，投入多少资源去做，而克制的本质，其实在于决策。

做加法是一件很容易的事情，随随便便就能够往上叠加功能，但是加了之后呢？有没有价值，有没有达到预期价值，投入的成本是多少，投入产出比是否划算呢？加了之后是否还面临着下线的风险？下线之后的坑会有多大？

在主播周报这个需求里面，之前的产品方案有本周数据、排行榜数据、月结算数据和阶梯分成这4个功能点，可以说是尽可能给用户展示了更多的信息，但最后的方案却只保留了本周数据…

如果是我自己出一个全新的方案，第一个版本我会倾向于出一个MVP的版本，即只包含最基础的功能或者再加上一个可称之为卖点的东西，其他都会放在后续的版本迭代中，最好不要在1.0版本做2.0版本应该做的事情。

理由很简单，我们所有的想法都是建立在猜想的基础上，做的越多也就越容易出错，首先需要验证猜想是正确的，然后才是基于此的一些优化迭代，上线仅仅只是一个开始，是验证想法的第一步。

但是我在接到别人的方案的时候，就掉到这个坑里了，没有跳出方案本身，而是受限于方案，只在方案的基础上进行了修改。即使事后看起来那么显而易见的一件事情，之前我却都没有想到…

有时候面对一件还没想清楚的事情，我们可能会先动手做了，然后再看反馈，而有些时候面对这样一件还没想清楚的事情，我们可能会选择先不处理，等想清楚了再说。

具体什么时候是先做再看，什么时候是先想清楚再做，目前我还没有形成一套判断的标准。或者说，目前我还没有拆解复杂系统的能力…

不禁想起来之前我的第一位产品Mentor问过我的一个问题，你的产品观是什么？

我已经忘记了当时我是怎么回答的了…现在看来，是时候开始思考产品哲学这个事情了。

以上，就是本文的主要内容，欢迎斧正、指点、拍砖…