|
昨天登录「公众号」的后台，系统提示我被「邀请体验图文标签功能」，一小段描述外加一个示意图，如下： 2020年以来，我收到5个微信公众平台的灰度测试申请，除了最新的「图文标签功能」，还有「个人认证」、「视频原创」、「页面模板」、「付费阅读」。 这让我想起传统的产品，虽然用户量没有那么大，但其实也可以从这个过程中学习下产品节奏。 1、灰度测试 我理解的「灰度测试」，是产品发布新版本或新功能前，提前选定一部分用户试用下产品新功能点。然后根据这部分客户试用产品的情况，选择是否对所有用户放开或者根据客户反馈将功能点改进后再发布。这个过程中，可能不同的用户群，灰度的版本也不一样，平台方根据这些不同用户、不同版本的灰度结果，综合来调整最终的产品方案。 作为互联网从业者，可能对「灰度测试」、「A/B测试」比较熟悉。但我认为这种工作模式和方式，对传统产品其实也非常有用。 传统产品的开发和应用，我形容为「一竿子扎到底」，制定好了目标然后基本上就是封闭开发，测试，最终产品发行。出了问题，一堆人开会讨论，然后又重复上述过程。 其实可以借鉴互联网公司的一些做法，「灰度测试」的目的是验证方案对用户的影响，在这个过程中，用户需求是核心。但用户需求的收集和分析又是传统行业非常难以做好的一点，这就导致产品不停地改进、甚至推翻重来。 而「灰度发布流程」则是关注过程，可以用下面一张图来表示： 「灰度测试」其实更关注用户和需求，但传统行业如何来实现是一个难题。互联网公司有产品经理和运营人员，他们来负责产品灰度的节奏和客户端信息的采集。但在传统行业，这两个岗位基本上更偏向于市场和售后。 一个可行的办法是由工程师去做这件事，根据规划的要求，分节点完成了模块功能点后，和产品及项目经理沟通，先选一个点或部分点来验证自己的程序和功能，自己去采集和分析数据，并通过业务或者售后积极地和用户做沟通。得到反馈后，再调整，直到完成一个比较好的版本。 2、做事的灰度 产品的「灰度」说的是针对某一个功能点，先小范围投放，如果没有问题则逐步扩大范围，如果有问题则进行改进后再投放。 我觉得在团队管理、公司内制度发布等方面，其实也可以借鉴这种方法。 团队管理中，很多事情并不是非黑即白、非此即彼，一个做法到底好不好，可以先小范围试一下，如果大家都觉得好就可以大力推行，如果大家执行起来有各种问题，则可以不用太机械和僵化地推行。否则，最终的效果不好不说，下一次很可能会推翻重来。 任正非曾经写过《管理的灰度》，他提到：
我看到很多公司制度发布，常规的做法就是一刀切。比如处罚措施、人力招聘。其实可以适当地在前期进行一些「灰度测试」。定好目标和策略后，先在小范围内试一试，然后针对问题再快速地进行改进。 很多时候，一句「制度就是这么要求的」很可能就堵死了各种尝试的可能，所以我们很容易看到很多僵化的流程。 |
|
|
