zen of 32

zen of 32

经济学、心理学、社会学、管理学、行为学、控制论、博弈论

流程

  • 制度管人,流程管事
  • 发布与人为失误是导致事故的最大根源
  • 人靠不住,靠机器,靠程序

工作

  • 条理清晰的描述问题是很重要的技能,大部分做的并不好
  • 闭环思维,事没有完,别老是开新”坑”
  • 凡事有交代,件件有着落,事事有回音
  • 说不,在某种情况下就是帮助他人成长。不是简单的附和,需要指出对方的问题
  • 基本的演讲和PPT能力要有,这个是通用能力,遵循STAR原则
  • 靠谱、帮助他人来产生对内的影响力
  • 分享、开源共建来产生对外的影响力
  • 限制太多,借口太多,会渐渐沦于平庸
  • 事情比想象的复杂,不当键盘侠。 严于律己,宽以待人
  • 做完不等于做好,平庸与卓越的区别
  • 需求的背后是用户价值,用户价值有高有低,有急有缓,所以需求有优先级。用户分几个部分,一个是真实的用户,一个是内部的工作人员,前者带来业务需求,后者带来运营需求与技术需求
  • PMF点以下的推广都意义不大,需要自来水,即用户带来用户,口碑赢得口碑
  • 四象限工作法,勿以战术上的勤奋掩盖战略上的懒惰

管理

  • 项目管理前紧后松、看板&晨会,信息对称&流动
  • 对人要宽松,对事要严格。左手屠刀、右手佛经
  • 做好人才梯队建设,每个级别有每个级别的要求,另外需要给每个人制定发展路线,不然会留不住人才
  • 人前表扬,人后批评,日常开展一对一对话
  • 做好人才激励,有的人看重物质激励,有的人看重精神激励
  • 没有绝对的公平,但是保持公开
  • 一团和气的团队氛围要注意是否大多数人在忍耐
  • 尽量让一切可度量、可管理、可追溯
  • 决策仅需要少数人,但是参与需要多数人
  • 当螺丝钉其实很枯燥,但是做航母的螺丝钉还是挺不错的的。如果传达的价值是局部的较小的价值,那么容易让人疲倦,如果赋予其更大的意义,那么价值就会不一样
  • 效率的损耗无处不在,所以需要降能提效
  • 领导可以关注细节,但是不能限于细节,领导有更高维度的事情要做

架构&技术

  • 好的架构是迭代出来的,但是初步设计也非常重要,不然会走弯路
  • 预则立,不预则废。技术也需要有自己的五年规划,也要有自己的愿景
  • 灾备、调度、有损,这些都基本要求,都是为了高可用
  • follow流行技术,为业务的发展助力
  • 不炫技,从业务的实际需求出发,技术不能领先业务太多,一点点就行,不能滞后于业务

机制

  • 自下而上和自上而下是事情推进的两种方式,前者产生创新,后者产生效率
  • 政出一门,力出一孔,简单清晰才能让人适从
  • 责任人机制,避免陷入公财悲剧
  • DO DT分离,职责需要分离,参考三权分立
  • 技术需要轮岗,人才需要备份
  • 鼓励创新,因为稀缺所以珍贵
  • 注意破窗效应,及时予以干预
  • 复盘是成长的灵丹妙药,精通复盘四法
  • 信息尽量对称,而且要及时同步
  • 优先让提出问题的人来解决问题,如果不能解决问题至少要求他提供解决办法

团队

  • 人人做好自己,那么团队的效率自然高,强调招聘优秀的程序员,并会识别团队中的”南郭先生”
  • 不要背着别人前行
  • 保持小团队,但是小团队也可以联合起来做大事情。为什么需要小团队?领导者管理的生理极限,沟通、竞争等限制

思维

  • 系统化思维,事物不是孤立的存在
  • 思考先于行动,思考清楚后行动要快。思辨胜于执行,但是执行力也要求高
  • 不做什么比做什么更重要,根据28定律,80%的工作都是无效的
  • 既要有科学精神,又要有人文关怀
  • 数据可以解决一定的问题,但是数据不会告诉你怎么做。张一鸣数据至上的产品观和张小龙古典主义的产品观皆可
  • 康威定律、屁股决定脑袋
  • 事物不是一成不变的,需要用发展的眼光看到前进中的问题
  • 生活就是平衡的艺术。大多数时候都是在权衡,在两者之间或者三者之间权衡。
  • 无处不在的28原则
  • 批判性思维充分讨论
  • 逆向思维