在星巴克的碎碎念

碎碎念

1. 我觉得招聘应该把质量放在第一位，如果迫于招聘KPI的压力，或者目前业务发展现状招不来牛人，可以有一些妥协，但是依然需要秉持 质量 > 数量。因为会发现牛人的工作效率远高于水平一般的人。并且长期来看，团队之间的高下，很大程度归因于团队成员水平的高低，人是团队乃至公司的核心资产。

2. 什么样的团队是一个好的团队？记录下我目前的所见所闻。

   1. 扁平化。上下级经常oneone。因为程序员本身不善言辞，上级主动一点，下级会心存感激。有利于上下目标等信息对齐，减少上下级的信息壁垒。
   2. 有分享，成长驱动。基本上大家都会有成长诉求，大家成长的阻力也不太一样，组织如果考虑到个人的诉求，个人能感受到组织的温暖和价值，进而正循环的给予组织更大的贡献，这种正循环感觉很美妙。但是总有一些因素阻碍这个目标的达成， 比如业务需求时间紧、害怕分享、觉得自己太low，没东西分享，其实一旦拆解好到底是哪些影响因素在作祟，对策是可以有的，比如 业务需求紧？是效率低还是真的任务多？任务多是需求不合理？还是方案设计繁琐？如果是效率低？组织还不去有针对性的提升员工水平，效率会越来越低，员工还觉得自己啥也没学到，负反馈从此走的让人发笑。有时候会发现大家说我要分享xxx，每次听到这句话就有点虚，我就知道一定会不了了之，其实如果是我的风格，我直接在任务管理平台上建立个task来跟踪同学这个事情了，因为不这样做，“只说不做拖延症“的社会规律就会起作用了，这样做是一个小技巧，毕竟最难开始的是第一步。
   3. 责任到人、成长到人，前者要求个人有主R的事情和意识，只有大家对所说所做的事情是有所担当的时候，这个同学的“所说所做”才有意义，否则很难是发自心底的。成长到人是说，大家主R的事情是能给大家带来成长的，主R的事情也是大家选择的，事情的收益和责任也是和同学们对齐的～，这样在接下来的工作中，大家更容易奔着目标做事，少了信息不一致的理解偏差和抱怨。
   4. 领导层一定好。 领导的意志是团队意志的导向，并且，团队成员水平差，对个人的影响甚至都小于管理层的影响，因为无论何种团队，成员都有三六九等，比较、竞争无论去哪儿都少不了的，其实可以扯到这样一个问题——新业务部门的P7和核心业务P7，title出来都一样，为啥非常努力在核心部门晋升7呢？
   5. “非大锅饭”——如何分饼将决定了饼能够做多大。这个可以思考政府的思路，虽说组织和国家都想让成员共同富裕，但是共同富裕的概念其实是含糊的，如何定义都是问题，所以任何时候都是有特别富有的人，大部分都是脱离温饱线的以及中产，政府最重要的其实是拿捏好这种比例的权衡以及提供一种公平，这种公平的体现比如“高考”、“打破职业歧视”等，人们的评价维度标签，如“富有”、“美貌”、“豪车”、“名校”等等，好像只有“名校”这种标签是大家可以相对公平的去争取的，高考的设立赋予了每个人这种争取，这样给了底层的人阶级跃迁的机会自由。“又不是没给你富有的机会？谁让你没考上清华？”。这种财富的不均衡事实上有助于促进大家的积极进取，为社会、为家庭谋福利，进而国家利益最大化。团队里也应该这样，大锅饭其实是对优秀者的侮辱，对庸人的保护，当大家看到原来组织容错率这么高的时候，那干嘛不悠哉起来，反正淘汰不了。
   6. 总结一下就是核心关注 管理层靠谱 + 业务天花板高，团队牛不牛逼是结果而已，决定的是个人实力在互联网全局的位置，但问题是大部分人考虑好局部的牛逼就可以了，还不够大家撑到35岁？ 。蛋糕能做大，还能公平的分蛋糕，这是最棒的情况了。而现实可能是这样那样的问题，我相信各个组织都有自己做不到优秀团队的理由和困难，不过吧，不重要，我倒是挺好奇并乐于去察觉这些因素到底是什么。

3. 我发现一些程序员，把源码研究的深的不行，其实很多时候我觉得并没有想明白到底有什么意义，可能只是觉得我懂xx细节，我就是牛逼？我18年面去哪儿网的时候，面试官就教育过我，其实要带着目标或问题去看，比如我要借鉴他如何设计的？为什么他的实现会导致我们现在的线程不安全？思路比如何做的本身更重要些。

4. 做事情要有一套方法，没有也要沉淀出一套，前者体现出人的规划、掌控能力，一步步来会让人觉得有可操作性、可落地的、可衡量的。方法、思路、计划可以和大家沟通，大家去监督这套方法，也不至于让接下来的动作思路跑偏。做事毕竟要闭环，事后总结沉淀传播。

某次复盘的问题记录：

目标： 找到团队中存在的问题

1. 为什么没有快速发现？ 本质是什么？如何快速发现响应问题？
2. 谁来验收？用机器？ diff工具？
3. 缺乏项目文档，缺乏开发方案与需求，需求要理解透彻
4. 人在迭代的同时，也要组织规范迭代、工具迭代，来backup人的无限可能性
5. 主R可以去维护业务文档
6. 只方法论会说，却不践行，所以评价一个人要看是否知行合一
7. 测试资源不足
8. 找不到拍板关闭灰度的人，因为没能评估影响面？
9. 任何小的事情，按照100分的标准做，挖的深一点，也会做的五脏俱全。
10. 很多时候大家都在说 我们要怎么怎么做，却忽略了这样做能落地么？落地能有效么？大家为自己说的负责么也？不负责或者不能让别人负责就是瞎说
11. code review 应该做什么
12. 线上问题 第一时间关闭灰度
13. 因为职级上层压力，不敢在大群及时回复问题提出方
14. 要有定期回滚演练
15. 领导信息中心，没有其他人能快速决策
16. 主人翁意识，哪怕是小事情，别人的事情也要注意跟进，推动
17. 关注问题怎么思考的，出发点
18. Case是不是方案设计本身的问题
19. 什么样的配置适合配置在mcc配置里
20. 业务逻辑的backup
21. 存在战术上的勤奋掩盖战略上的懒惰，有些人忙碌奔波，事实上跑偏了