最近的一两年时间，我算是做了半个Tech Leader吧（毕竟，我自评算不上做得好，就算半个吧），期间也有一些思考、总结，记录一下。
免责条款
- Leader的风格是很多样化的，同样的目标，不同的风格都可以实现，条条大路通罗马。
- 方法本身是需要不断学习和改进的，有些人可能觉得自己情商高就可以做leader，本身是很不负责任的。成长型思维、不断学习、科学的方法，比所谓的“天生适合”更重要。
- 仅仅限制在理想主义框架下的讨论，实际情况会有诸多无奈和权衡，可能我说的所有内容都是错误的。
- 不讨论一些厚黑的东西，Tech Leader而已，包工头都算不上，真的没必要。
- 都是自己的想法，所以，其实每句话前面都需要加上：“我觉得”这三个字。
Big picture
作为第一篇，先总结下鸟瞰视角的东西。
A. 1个重点
科学，科学，科学
所有的事情，都应该建立在科学的基础上。比如，
- 你的决策要有基础，有一个科学的过程、收集了支撑数据。（当然，直觉很重要，但是不代表可以100%靠直觉行事，其实我自己就是很喜欢用直觉的人）
- 做事的方法。摆明了会有问题方法，还要重复，就不明智；同时，历史上没成的方法，新的场景下说不定就可以。
- 减少人治的特性在里面。一个人的想法变化会很大，人治会造成很多不稳定的“意外”，容易让整个team变得很困惑。需要设计一个合适的体系，保持整个team的稳定方向，即使改变，也不会让所有人摸不着头脑。
- 有些人可能因为自己的情商稍高，感觉自己就可以依靠这一点做一个tl了，这是一种不负责任的做法。这一观点本身就不科学，一个tl需要学习更多领域的知识，不断引入一些先进的理念与方法。
- 对人员的分析与分配也要符合基本的科学原理，我觉得MBTI测试是足够应用在TL日常里面的（这个测试是不够准确和细化，但是日常工作也仅仅需要大概方向就可以了；要是换在几年前，我也会对这种测试嗤之以鼻，但是每个人性格倾向和思路都不同，需要一个有指导性的评估体系），组合好不同性格倾向的人会让整体磨合的更好。
B. 时间方向上的2看
1. 向历史看：处理好技术债务，梳理历史需求
只要是一个运行了一段的team，技术债是必然存在的。我可以想到的原因：
- 使用框架的历史版本，需要更新大版本
- 代码在不断的发布、赶工中引入了太多“坏味道”
- 历史中积累的需求，需要重新调整代码来更好、更加灵活的适应
- 现有的代码不能更好的映射新的知识体系
这些问题，看起来都可以不处理，不会对team的开发有任何影响，但是会逐渐的拖慢整个team的开发速度，渐渐的占据大量的人员精力在这些事情上。
用我自己的话来说，这会增加所有团队成员的心智负担。对于程序员来说，这是很可怕的一件事情。我们需要一个轻松、投入的心智进入高效编码的状态，这些心智负担会大幅度的降低编码效率，从我的经验来说，是存在拖慢10x速度可能性的。
对于这个世界上有没有10x的工程师，存在很大的争议。但是，这个世界上存在1/10x效率的组织，绝对没有任何争议。不让自己的团队陷入技术债的低效率泥沼中，是每个TL的责任。
2. 向未来看：规划好中远期目标（or 愿景）、资源分配
中远期目标相比前面向历史看的工作才是更加重要的方面。处理技术债、梳理历史需求，最终都是为了规划好中远期目标。一个团队有了愿景，才会对大家产生吸引力，更加方便集合所有成员的智慧。愿景，就是驱动力，掌握的好，就会让大家开开心心工作。愿景也是TL对整个团队的承诺，不能随便儿戏。
除了愿景，也需要接地气的一点东西，那就是怎样一步步去向着愿景出发（毕竟，100%实现愿景的难度太大，低愿景也吸引不到真正的人才）。合理安排人力、时间的投入，分配好优先级，同时还要处理好日常工作中的各项意外带来的影响。评估好大家的能力、心理状态，及时的调整。
对于如何区分愿景与画大饼，我觉得回答两个问题就可以：
- 有没有向历史看，踏实的处理好技术债？
- 有没有 亲自带领 大家向着愿景出发？
C. 3个支撑的目标
这三个不仅仅是针对自己个体，也针对自己的整个team。所以，需要自己带领着自己的team，向着这三个目标靠近，自己做不到，也不用指望team可以做得到。
1. 解决问题
这点不需要浪费口水。但是，更加重要的是解决问题的方式。能不能有更加科学的方法、从更加长远的角度上解决遇到的各种问题，尽量避免救火队长、补缺式的解决问题。
2. 共赢思维
说起来很容易，但是实际上对自己的视野和格局的要求是很高的，不能有“稀缺思维”。有些时候，放弃“小利”才能有更好的合作。 尤其是跨部门之间的合作，很重要的就是能够通过保持沟通和透明度来建立信任。其实只要能把事情做成，大家都是愿意主动合作的。比较忌讳的是藏着掖着，这个算是对信任比较有破坏性的。最忌讳的是背后做小动作，一旦被发现，会彻底丧失对方的信任，未来(愉快)合作的可能性也基本为零。
3. 保持效率
尽量避免降低效率的事情：冗长会议、重复工作、太多行政性事务的干扰（比如，避免多余的填单子）、影响大家心态的事情（比如，要稳定军心）、较差的工作环境（比如，为大家抢个好工位区）、尽量申请开发工具的预算。 最大化实际工作的时间，作为程序员，那就是努力增加大家的心流体验。毕竟，心流体验算是工作中的心理高潮，谁不愿意做一件事情可以高潮迭起？ 说到时间，可以鼓励大家做时间日志。我做过的时间日志的结论是，一天的 纯工作 时间4个小时，就已经是效率很高了，每个成员都能保证这个水平，前面的愿景也就有更高的概率实现了。也因此，我反对无效加班，第一，长期来看，拖累整个团队效率，长期加班后效率会降低的连朝九晚五都不如；第二，这是管理、决策无能后的表现，天天无效加班，都是啪啪啪打自己的脸；第三，一天四个小时的纯工作时间就够了，能保持住就已经谢天谢地了。
D. 4步流程
这是自己总结的通用流程。 虽然我希望系统化的整理这几步，可以有更多的指引选项，方便自己实践，不过目前并没有。
当然，《原则》里面的五步法似乎也更好一点。
- 情报
- 分析&决策
- 准备&执行
- 反馈
希望未来，我能够总结出更抽象的指引。
结语：
下一步会总结一些细节的指引，比如：指标、零散的指引要点