论熔断机制的下线,最失败的功能规则设计

有时候我在做程序设计的时候,单位领导总是要在产品中加一些附加的、令人不解的、乱七八糟的附加功能,我都认为是失败的,为什么决策者对此乐此不彼,我们来谈一谈最近比较热门的熔断机制吧。



1月7日晚,沪深两所以及中金所联合发布通知表示将暂停实施熔断机制。“经中国证监会同意,上交所、深交所及中金所决定于1月8日起暂停实施指数熔断相关规定”。至此,熔断机制仅运行四天,然而在熔断机制实施的4个交易日内,就有4次触及熔断,1月4日与1月7日两日提前休市,而1月7日仅在开盘半小时内就两次触熔致全天休市。


在以沪深300指数为主体熔断机制下,权重股所反映出来的市场价格并不能及时反映交易者的交易意愿,权重下跌非权重疯张、千股齐跌权重拉升等情况常常出现,指数与个股的不对称容易导致价格扭曲和有效性下降,而价格扭曲会带来价格波动,价格波动不会降低市场波动而是会加剧市场波动。从2016年“开门绿”的行情我们也可以看出,熔断机制不仅没有降低市场波动,反而令市场更加恐慌。


我国股票市场的涨跌停板制度规定,当个股价格涨跌幅度触及10%时(ST股票为5%),交易继续进行,但报价限制在10%之内。事实上也可以看出,涨跌停板的叫法不是很科学,因为交易并未“停”,更正确的叫法是“价格限制”。10%的涨跌停限制已经能够控制当日涨幅,为什么还要画蛇添足设计出多余的熔断机制?【这背后定有乾坤。】


从这件事情出发,我们在接下来的功能设计当中逐渐归纳出了一点最重要的设计原则及经验:


*任何新的主意和想法都需要首先进行验证!!!


我们曾经有一个重新设计浏览器插件的主意,它最终失败的很惨。

浏览器插件是整个Buffer产品的一个重要组成部分,它可以帮助用户直接将Web页面上的内容添加到自己的“buffer”当中并分享到社交平台,整体体验非常棒。

所以很自然的,我们会将注意力放在浏览器插件上,希望尽可能的对其进行改进,实现一些更酷的点子。不过在改进的过程中,我们似乎又捡起了过去的一些坏习惯,犯了一些本该避免的错误。当时的步骤是这样的:

  1. 我们识别出Buffer的浏览器插件中存在的一些问题,头脑风暴了想要改进的地方。
  2. 接下来,我们花费了大量的时间与资源,重新设计并开发了全功能的新版本插件。
  3. 完工之后的测试当中,我们发现新版本插件给用户带来了极大的困惑。
  4. 最终我们决定放弃这个版本的插件。

可以说,正是这次失利让我们将“尽早验证每一个假设”的原则深深的印在了脑海里,成为了今后的一种习惯。

我们管理层和决策者们是不是要在规则发布以前做几次小范围的测试或验证,而不是不计后果一股脑的投放下去呢?

如今,我们要改进产品或是要实现一些新功能时,会通过以下步骤进行:

  1. 识别已有问题,确定需要改进或新增的点。
  2. 与现有用户进行沟通,了解他们是否在使用过程中也遇到了这些问题。
  3. 想法得到初步验证后,快速制作线框稿或低保真可交互原型。
  4. 再次与用户进行沟通,向他们展示原型,观察他们的交互行为。
  5. 重复这样的过程,直到最终确定设计方案。
  6. 持续追踪各种指标,保持与用户的沟通,验证新版产品的表现。

后话:这次熔断机制的推出和加速下线会不会是政府行为?有人说是为千亿养老金入市做好铺垫工作,我只能说“呵呵,让我们拭目以待吧“。







你可能感兴趣的:(浏览器插件,熔断机制,最失败的功能,测试或验证)