梳理做一个做技术leader的经验集。虽然title是总监，但其实一线的事儿也做，管理的事儿也做。
自己梳理好的经验很重要，毕竟别人的经验是别人的，看到很多写高并发，写虚拟机，写各种中间件的，有时候看了一遍觉得好厉害，但看懂的不多。其中既有自己水平问题，也有作者写法的问题。非技术类文章人人都能看，品控就能做很好。技术类文章门槛超高，可能来评审的编辑也不知道咋提要求。所以技术类内容写得好还是挺难的。至今为止觉得最好的技术书是《代码大全》，写的深入浅出。这本书的内容消化起来毫无难度，而且全都实践完，就能超过非常多人。
过去一年半的时间。成为了一个技术合伙人，方方面面和技术相关的事儿都会以自己为收口。事儿很杂，但也确实因而接触了非常广的内容。自顶向下的总结，大概有以下这些。
第一类是商业类问题。其实就是咱这业务的商业模式到底通不通，比方说我们本来只是做数据通道，但通道人家觉得不完整，所以要做个完整解决方案，但完整解方尽管对方需要，可我方又需要额外投入很多技术成本，这就是一个商业角度的考虑了。其实不就是收益和成本嘛，是的呀，商业本身也不难理解，但也不简单。其中行动力和资源也很重要。我们知道有PEST分析法，包括Policy、Economic、Social、Technological。对于技术人来说，能从这些角度去思考就很好了，其中的PES，理解起来真并不比T容易，没个几年积累也是做不到的，但幸运的是那是老板的事儿。但不幸运的是老板有可能是缺少批判性思维的，技术出身的人在这方面就比较好，所以咱虽然想不出来，但评判他人的PES是很容易的。这就又需要老板是个悦纳他人意见的人，否则，这事儿基本就不成了。
第二类是管理问题。商业问题搞不好，就不用想搞好管理了。大家都不傻，半年挣不到钱是在做准备，一年还挣不到就不知道是啥了，大家不可能心齐。但这归于商业类了，我们假设商业模式是通的。
管理的第一个任务是做事。
做事首要是定好团队目标，有目标才可前进，目标要有一些挑战，也得够得到，还得可证伪，对，比可量化更重要的是可证伪。做事儿的第二个点是找解方，这时候就像搞明白中间件一样，把各个成员的工具性的职能搞明白，需求、前端、后端、测试都咋合作才能达成目标，这就是解方。做事儿的第三点是要让大家有凝聚力。凝聚这个就难了，心是最复杂的。首先大家都是有希望的，公司的盈利模式是清楚的。其次大家觉得业务是有意义的，我们在做一件对社会有益的事儿，那意义感之下动力就绝对不同。再就是这事儿是能做成的，如果哪个老板说我们今天要做个永动机，那还做个屁啊，大家转型做夸夸企业，拍老板马屁就好了。
管理的第二个任务是成长。我们要像个教练，让成员都有成长。这样团队才能日渐强大。那工具就是知识沉淀的方法，比如文档记录、复盘等等。所以我们要让团队有这样的能力。
管理的第三个任务是风控。我们有很多的风险，比如员工会不会离职，那业务咋办，这就需要总监自己在关键时刻能顶上去。
第三类是技术问题。其实这很根本。到一定level其实是找到架构师来解决这些技术问题。但自己一定要懂。对于小公司来说，这个架构师不就是自己嘛。
技术问题其实是分两大类的。
第一类依然可被称为业务问题，那需要我们对业务有足够的理解。软件开发的根本任务是处理复杂的概念结构，所以就有设计模式，有领域模型等等各种思想。这些可以让我们开发的时候更容易做到高内聚低耦合，从而可以应对各种业务逻辑的变化。
第二类是性能问题。当高并发时，会有很多新问题。单机服务器可能只能支持qps50，当qps达到5000时，咋办？这也并不是靠简单扩容能解决的，一扩容就成了分布式了，分布式是有一些跟随而来的问题的。横着分，竖着分，也是不一样的。此外还要根据场景选择缓存，异步，我们要依靠这些工具来让系统更高效地运作。
这两类问题大部分独立，又有相当部分的交叉。为什么说独立，因为性能问题，既然抽象除了微服务、缓存、队列，其实这些都是足够通用的。但所有这些工具都是解决业务问题，业务问题解决的是商业问题。商业问题就是你为哪类人解决了哪类问题。所以，没有单纯的技术问题。
后续的文章会从商业、管理、技术角度陆续来梳理。有具体的问题和解方。从而建立一套至少自己能有用的技术leader的方法论。
网友评论