1. 为啥有方法论或者定律？

最开始的时候大家都是遇到事情然后想办法来解决问题，那么结果会有这么几个

1. 问题没有得到解决；
2. 问题得到了解决，但是解决问题的不是那么的好
3. 问题得到了完美的解决。
   前者是失败，后两者是成功，总会有人分别总结失败与成功的经验，这样社会中就会有一些沉淀。久而久之，有些人会对成功的经验进行抽象，总结出其中共通的部分，那么这就是方法论或者定律，不过定律是更广泛的方法论。

2. 为啥要有方法论或者定律

吾生有涯而学海无涯，有涯的生命更需要追求成功率和效率。方法论或者定律就是提高工作效率和成功率的窍门。

3. 定律

3.1 二八定律

如果需要找出这世界普适的一条定律，那么我认为是二八定律。20%的XX带来80%的XX。典型的马太效应，强者俞强弱者愈弱。

3.2 熵增定律

封闭的系统，如果没有外力的作用，那么必然从有序走向无序。混乱是趋势，逆熵是需要自律的。

3.3 墨菲定律

担心发生的一定会发生。提醒我们一定要想周全。

3.4 彼得原理

雇员总会处于其不胜任的位置上

3.5 帕金森定律

大企业病，企业倾向越来越臃肿，人浮于事

3.6 晕轮效应

看喜欢的人啥都是优点，看不喜欢的人哪里都是缺点。

3.7 破窗效应

窗户如果破了一块玻璃，如果不及时修补，那么很快所有窗户都会被打破

3.8 首因效应

第一印象很重要，后续要改变需要花很大的功夫

3.9 电梯法则

一个事情需要在上电梯或者下电梯的这段时间能够讲解清楚，否则这个事情就是没有理解清楚

4. 常用的方法论

4.1 5W2H

设问的方式，5W2H可以将事情考虑的非常的全面
WHO:谁做
WHEN:什么时候
WHAT:是什么
WHY:为什么
WHERE:哪里
HOW:怎么做
HOW MUCH:程度

4.2 四象限法则

事情按照重要程度和紧急程度可以分为4个象限
重要紧急：救火的角色，会疲累
重要不紧急：最应该做的事情，而且需要规划好
不重要不紧急：交给别人做
不重要紧急：授权别人做

4.3 金字塔思维

4.4 六顶思考帽子

4.5 SMART法则

《持续交付2.0》中提到，对团队日常工作进行学习与反思有两种常见的方式，一种是定期回顾，另外一种是事件复盘。事件复盘非常的重要，是打造完整闭环中关键的一环。

1. 什么是复盘

复盘，本身是围棋中的一个术语，是指棋手在下完一盘棋后，要在棋盘上重新摆一遍，看看哪里下的好，哪里下的不好。下的好的要继承，下的不好的，要再重新摆的过程中探究怎么样落子才更好。引申到日常的工作中，就是来剖析下某个事情干的过程中有哪些做的地方，哪些做的不好的地方（更侧重在不好的地方），为后续的工作沉淀经验，愈来愈靠近正反馈循环，也即是成功的范式。

下周就要放假了，春节临近啦~老规矩，放假前都需要对系统进行一次全面地梳理与走查，具体的细节如下：

每个人都有自己的领导，也会接触到形形色色的领导，自己也会想着成为领导，那么怎么才能算是好的领导力呢？

1. 做对用户有价值的事情

一切以用户价值为依归、客户第一、用户为本，这些都算是对这个价值观的相互注解。什么是用户价值？谁来判断具备用户价值？都是我们需要认知思考和反复权衡的。

一个产品或者服务只有具备为用户解决一个问题、为用户更好的解决一个问题、满足了用户的某个需求才能具备用户价值，但是在实现这三个目标的过程中，我们所做的全部都给用户提供了价值吗？

每一个产品不是功能的堆砌，产品像人一样，他/她背后是有价值观的。抽奖、裂变、push、复杂的活动、忽悠用户、打扰用户这些日常很常见的手段真的很好吗？

少即是多，想想真是具备至理但却难以践行的法则，不断的招人开发新的功能、设计新的玩法，自己产品核心的价值都做好了吗？时间是有限的，人力也是有限的，为什么不在最具核心价值的地方好好打磨呢？

第一章

VUCA，volatility(易变性)、uncertainty(不确定性)、complexity(复杂性)、ambiguity(模糊性)，源于军事用语，911后概念才被确定，该词用来描述混乱的和快速变化的商业环境。面对复杂易变的商业环境，那么在进行软件实践的时候就会遇到很多难题，问题从此就展开了。

前几天，看网上说IPV4的地址已经分配完了，IPV6的时代开始了。其实工信部早就开始推各个大公司进行IPV6改造了，不过进度不尽如人意。说到IPV4就不能不提IP转换服务了，IP转换服务是指根据用户的IP获取用户的国籍、省份、城市、运营商等信息的服务。可以被使用到诸如用户画像、版权控制、流量调度、路径加速等领域。

收录一些好的技术网站！

我们活动存储都用的是redis，落地用mysql，这样就会面对一个问题：如何清理过期活动用过的key。同事搞个一个脚本：每天去扫码有无过期的活动，如果有就去slave redis实例中用scan扫描出活动所有的相关key，然后挨个清理。有一天redis发生了主备切换，这个脚本就去主redis上扫描去了，引起了告警。这种scan方式不是很好，我们在想是不是搞成一个日志服务，将这些key都记录下来，等到活动结束后直接看这些日志文件，对照着日志文件清理就行了，但是不去重的记录每个redis key的话，每天的数据量会很多，所以就有了如何去重的思考。