听谷歌设计师Riceman访谈有感
今早听到一篇博客：S2E12 | 谷歌设计师和他的苹果最佳播客 | 黄季业 Riceman从零道一，是一位设计师讲述自己的工作履历与在设计中产生的一些思考，联想到自己刚刚做完的一个项目，还是蛮有感触的。来不及吃完午饭，随便扒了两口，就回到实验室，想做个记录。
可能是自己没有做过这种想法方面内容的输出，坐到位置上大脑一片空白。这也让我更加坚定我需要这么一个机会把我汲取的内容做一个输出了。想了半天，想到三点：
- 设计是一个多方博弈的过程
- 对用户的定义与取舍决定了产品的生命
- 终身仁慈独裁者（BDFL）的管理模式
设计是一个多方博弈的过程
Riceman在博客中提到，设计是一个多方博弈的过程。怎么理解这句话 ？把自己代入一个TikTok的设计师/产品经理。
为了给用户带来绝佳的短视频浏览体验，那么必然需要削减广告投放的数量与时长。但是这么干老板肯定不愿意了，老板一看，广告投少了谁给你发工资啊？出于资本家的角度，并不care你使用什么方式留存用户，反正就是要创造最大利润，最大利益。对于设计师自己，做了这么多的产品，在TikTok中肯定想要融入自己的一些设计理念。比如30秒的广告尽可能少投放，5秒的广告适度投放。或者比如Youtube，可以允许用户在5秒后自由选择关闭或继续观看广告。
所以，设计一个产品其实需要站在三个维度思考问题。对用户：这个产品怎么才能吸引我；对老板：这个产品怎么才能给我赚到更多的钱；对设计师自己：这个产品如何才能体现出我的设计理念。这么看，产品经理和设计师似乎比研发同学压力要大很多。
Riceman的这个观点挺有意思的，在听到这里的时候我很迅速地就想起来了我前阵子刚做完的一个华为云的项目：Multi-View Visualization Method for Cloud network。翻译过来是：云网络场景下的多视图协同可视化方法。很酷的名字，感兴趣的朋友可以到我的仓库中看看。个人觉得是我一个比较拿得出手的项目，集成了数据分析、链路探索与多视图协同多个板块，也算是我做的第一个图析平台了。但是，既然我能po到github仓库上，说明我的这种方案肯定最终没有被落地到华为云的网络大脑的系统中上线使用。还挺难过的，因为我觉得各方面都蛮好。其实我们设计了两套方案，出于一些业务的考虑，客户选择了另外一套。
为什么我想起了这个项目？很简单，当时我其实也在做博弈。对于华为云的这个项目，我算是个小leader吧，和客户沟通，把控进度，和客户做汇报都是我来负责。那么自然而然地，我承担起了leader、项目经理、研发多重任务。因为网络大脑这个项目比较青涩，公司那边的需求比较明确，就是想要一种直观地可视化方式，布局简洁美观，故障设备的分布一目了然。但其实这需求又不是那么明确，如何展示？如何定义直观？如何布局？都是不知道的。准确点说，公司是给了我们一个想要达成的目标，并且为这个目标的实现过程添加了一些约束（业务知识，比如设备的层级关系，分Region、AZ、POD展示等），其余我们自由发挥。
一听到自由发挥那我高兴了啊，我不就是这个设计师吗？公司就是客户，我的老板就是我的导师。客户想要简洁高效，我的导师想要客户满意（因为合同已经签了，金额已经确定了，客户满意了才能收到钱），那我呢？因为是第一次做大项目，还蛮激动的，我既想要客户能够满意，我的导师能够满意，还想要这个交互系统技术上不要搞得那么难，毕竟我不想压力那么大。
于是，经过了大约十余次次的沟通，我逐步引导客户往多视图协同上走，一切进展地非常顺利。但是…
好巧不巧，网络大脑部门负责人换了，原来的负责人描述不清楚他们的需求，所以我们提什么方案他都答应。换了个新的负责人，是从研发线晋升上来的，比较熟悉业务，给我们推翻了先前的方案，说是：“这种几何割裂的层级分割方式虽然在几何上很美，但是却不是我们运维人员想要的结构”。后来经过一番了解才发现，他们居然想要的是：树形结构～！
对我们来说，这简直是灾难，我们努力了半年的结果居然不是他们想要的。但是这个问题后续还是得到了妥善的解决，自然而然地，我们提出的早先方案就没有被接受。我觉得丢弃了有些太可惜了，就好好写了个README传上了我的仓库。在这场博弈中，我可能没有完全站在用户的角度考虑问题，或许是我不该引导他们接受我们设计的方案，而应该引导他们说出他们心中最理想的方案。这是我做的不好的地方，但是给用户种草这个思路也是一种方式，我觉得这点我做的还是OK的。
产品的生命 & 终身仁慈独裁者（BDFL）的管理模式
这两点其实是最近在给G6提PR的时候，扫了一眼G6的issue list。发现有一些用再提增加xxxxx功能的请求，联想到的一个话题。博客中有提到：如果做产品的时候一直只关注提出负面反馈的用户，那么产品最终也会走向失败。这其中其实存在一定的幸存者偏差，假设有100个人使用了产品，有10个人不满意，有5个人反馈了为什么不满意。那么如果一直照着用户的反馈意见修改产品，反而可能会让产品越来越糟糕。在先前听 antfu讲开源手册的时候就了解到，并不是每一个给社区提的PR都会被接收的，这种时候就需要尊重并且理解社区的决定，有时候并不是这个想法不好，可能只是不满足社区发展的方向。
终身仁慈独裁者（BDFL）是我前两天在一个访谈尤雨溪的节目中了解到的一个词，通常是指社区中对于一个项目拥有最高决策权的人，负责拍板社区的重大或有争议的决策。
国内开源模式
感觉国内的开源产品很容易走向自身业务主导的道路，做出来的产品很可能只match自己公司的业务，而并不能做成一个面向社区的开源产品。不过Umi.js似乎是一个成功的典例，Umi是云谦 sorrycc老师的作品，一个React极速开发框架。对于内部的业务，基于Umi封装了Bigfish，专门在业务层做输出。前阵子刷到偏右老师的知乎那些年的体验科技部，了解到Umi和Bigfish之前居然是竞争关系，你死我活，后来联手做了这么一种开源模式，一个主外一个主内，感觉还是挺有意思的。