weekly-summary-20210131
别跟傻子玩
否则你也会变成傻子。
起因是昨晚听了 WZB 的管理分享，然后我意识到，其实绝大部分开发组长都是没啥管理意识的，包括我自己，也是属于有一些意识但是并没有完整的策略模型，很多事情也是了解但是没去做。这就是典型的一个傻子和一堆傻子一起玩，那么这个傻子不可能变成聪明人。
只有多去跟聪明人玩，才能让自己变聪明。
别自己瞎搞，让专业的人来做专业的事情
我不可能 cover 住所有事情，因此我只需要建好团队，把人招好就行了。
特别是产品，搞个靠谱的产品，我跟在后面搞好开发即可。
没有想法是因为书读得太少
别人的想法，只要能够吸收转化，就能变成自己的想法。
别人的想法知道得多了，才能构建自己的思考体系。
Leader 第一要素：干净
能做到干净，本身就意味着很多事情了。
五分钟策略：沉下心，很多感觉不愿意做的事情也是可以做下去的
有了开头，入了门，剩下的就只是坚持了。
可视化建设、基建、前端提效、宣讲也是一样的。
这些东西应该都还没上升到拼智商的程度，只要持之以恒，成功的概率就很大。
人不够的情况下，就应该做减法
类似：如果我只能招一个人，招什么岗位、招什么样的人？
如果我只能做一件事，做什么事收益最大？
做 10 个好的宣传，可能比做 10 个好的功能效果更好
当然前提是你必须得有一些好的东西可以让你去宣传。
精准推送造成的信息茧房现象
精准推送所造成的信息茧房现象就像游戏沉迷一样，是不可避免的。
工作中也需要生活气氛
工作中也需要有一些生活
互动、交流；工友&朋友
我们需要在忙碌的工作中，有共同的目标、有生活的氛围，有朋友，合作共赢
否则无法长期下去的
焦虑的本质：求而不得
个人当前能力与际遇，和你想要的东西不符，就会焦虑。
凡事皆有方法论
学习他人的方法论，从无到有，先学习，后超越。
个人的能力视野，局限性很大，全部靠自己不可能走得远。
你工作多年的顿悟，竟是别人的习以为常。
比如：
问题分析：七步成诗
报告展示：金字塔原理
团队管理：组织行为的杨三角
产品包装：FAB 法则
辅导下属：GROW 模型
思考问题：黄金思维圈
写简历：STAR 原则
讲故事：SCQA 原则
描述目标：SMART 原则
能承担后果的尝试，都值得一试
如果开始最坏的结果会是什么呢？我们能不能承受呢？梦想和现实，我们到底该怎么办呢？
点燃你的是什么
至于为什么选择《戴森球计划》，一是因为喜欢，二还是因为喜欢。每一次我们设计游戏时，我们都会问自己，这个点子都点燃你吗？你自己喜欢吗？你足够喜欢吗？过了今天你依旧会喜欢吗？只有经过不断的反问和推敲，你依旧坚持它是最棒的，那这个点子才是最棒的。因为，在我们的理解中，设计出的东西如果没办法点燃你，那肯定也没办法点燃玩家，只有你足够用心，足够爱了，你才会把这份爱，这份用心传达给玩家，他们是能感受得到的。
–《戴森球计划》制作人
敏捷开发的技巧
As a (xxx), I can do (xxx) in order to (xxx).
As a (角色), I can do (职责) in order to (目的).
As a developer of data visualization, I can take the design of the program and user interface in order to make the product more powerful.
可视化(开发)体系建设笔记
可以参考这个，我也学习构建下：
https://github.com/fouber/blog/issues/2
当然，首先我得知道优秀的可视化(开发)体系是什么样的。
四个知道这个理念模型真是太有用了。
经典语录
我只想知道将来我会死在什么地方，这样我就永远不去那儿了。
一帆风顺 VS. 乘风破浪
现在的我遇到了一些风浪，是被浪击翻，还是乘风破浪，都是看我自己。
颓废过一天也是一天，奋斗过一天也是一天，何不选择后者？
周鸿祎：你在公司工作，可以看做是创业第一阶段
看了周鸿祎的访谈视频有感。
问题：我没有几个数据可视化案例
一个很严重的问题：我没有几个数据可视化实战案例
这里的实战指的是通过可视化去帮助具体人员解决具体问题
也就是我缺乏数据可视化的刻意练习，练习题都没做过，没有系统学习过
语音技术的兴起是数据可视化的一个好机会
因为数据可视化的目的虽然是降低理解成本、传递更多有效信息，但是它的方是讲故事，而讲故事就肯定需要语音。
前端效能
如何理解高效两个字？
郑超推荐的文章：https://martinfowler.com/articles/developer-effectiveness.html
结合这个文章分析我们目前的开发现状：
1、工具不是不够，是太多，且相互割裂，不好用
就比如 CI、CD，有多个工具，是不同组的同事开发的，只是勉强能用，根本谈不上好用。文档也不友好。
2、专注时间太少
3、缺乏快速排查线上问题的工具
4、外部依赖(接口)导致项目受阻
In the example illustrating a low effective environment, everything takes longer than it should.
我们能不能搞个开发流程的“最多跑一次”？比如：
查文档最多问一次
发布最多点一次
查线上问题最多看一次
想要高效，就得给开发构建良好的工作环境，人性化服务好开发人员；这算是曲线救国，也能给大家带来更好的体验。
Who cares about the experience of developing ?
Whereas in the organization that provides a highly effective environment, there is a feeling of momentum; everything is easy and efficient, and developers encounter little friction.
Small Inefficiencies
isolated islands of information
The Positive Flywheel
DevOps Culture
The four key metrics (lead time, deployment frequency, MTTR and change fail percentage) are great measures of DevOps performance.
MTTR：Mean Time To Repair，平均故障修复时间
Fast and Simple
Feedback loop
反馈闭环
Backstage
所有信息的正门：