从技术专家到管理者的思路转变（V1）

时间：2022-07-25 07:34:28

作为技术专家出身的管理者，是一种优势（你所做的很多决策可能比非技术出身的管理者更加具有可行性和性价比）、也是一种劣势（你可能会过于自恋自己的技术优势）。这取决于你在接下去的职业生涯中，如何取舍你的技术优势。

0、最重要的是，人尽其才、物尽其用，每个人都是独一无二的，对于每个人，你都要以独立方式看待和对待。从资本的角度来说，你已经从常规交易进入了杠杆交易的阶段，最大化利用杠杆、组合的威力是你成败的关键。

作为技术专家、架构师的你，你的职责是亲自负责各种技术难题、架构设计的解决与研究，这可能会让你一投入就花费半天甚至一两周时间专门研究一个主题，反复不断的测试与验证，在此期间，你甚至有权在此期间不处理任何能够兜底的非致命常规性决策，不去参加日常性的例会等等，遇到一些比较难以处理但是可能自己擅长的问题时，很多时候可能都很想亲自去处理，一个是效率最高、另外一个是自己心里足够有底。从整体的角度来说，这是最需要避免的。此时最重要的是，让整个团队像一辆汽车一样，高速前进时各部分很顺畅的协同，比如下雨的时候刮雨器是完全正常的，下坡时刹车是很灵的，确保机油不会少。leader自己最重要的是要知道整体/每个重要部分的运行情况、潜在问题、紧急问题，确保时刻都有一个关于运行情况的checklist或dashboard，对于各自问题，确保拥有或者培养或者协调到相应的人员，不到天塌下来前一刻，哪怕自己知道了，也一定通过指导的方式解决，不要直接插手解决，否则最终团队不见得起来，自己成为了具体问题的瓶颈。同时，对于有些方面，我们可能出于担心最后过于依赖于一两个人的风险，总想有些事情亲自的处理。这些方面是在初期最伤脑的，所以有些时候理论上x人可以完成的团队，会预备1.2x，水平较好的团队，可以提前安排一定比例的重要但不紧急的事项来缓冲。

而你自己，可能至多只能预留1/3的时间用于自己想做的事情，比如潜心开发核心功能或者新技术或者解决某个技术难点。甚至很可能你只能在工作外去做这些事情。

所以，每个人哪怕是实习生，都有其能够做好的事情，前提是将其放在合理的位置上。对于各种非人力资源、比如服务器等来说，如果不考核成本，尽可能多预留，如果考核成本，一定要确保没有闲置，实际上，每个公司都有大量开发、测试、QA等闲置的服务器。确保各项配置都是优化的，不会影响开发人员的效率。如果可以，申请最好的PC工作机、VPN或者公有云，确保各同学只要愿意测试或者学习或者研究都不用担心自己没有环境的问题。

0.1 投入产出比是关键，不纠结于具体什么技术。

说到投入产出比，最重要的是人力资本是最大的投入，所以让所有的人尽可能做能够产生现实价值的事情，尽量避免本末倒置。比如掌握了某个核心技术，但是这个技术如果就投入而言，产出并不明显，或者中短期内都无法产生价值，那是战略层考虑的，而不是你这个绩效单元应该考虑的事情。典型的比如，招聘了一些高级技术专家，然后研究了很长时间，最后的结论是可以提升10-15%的性能，除非是成千上万个实例部署，否则我相信收益是远远覆盖不了投入的。比如，以https://my.oschina.net/qcloudcommunity/blog/857662为例，除了一线互联网公司，其他公司去研究这个问题从现实角度来说就是找死。再比如，在我们公司的交易系统中，交易客户端是使用.NET开发的，一个开发人员说他想一次性把数据查询回去，然后在客户端让客户可以DIY的排序和各种汇总，但是研发总监的思维一直停留在2000年时代，不停地说服务端排序快、客户端处理会影响用户体验，而且实现麻烦。扯了半个小时后，笔者实在听不下去了，插了一句，几千几万是完全没有问题的，看同花顺、QQ客户端不都是大量缓存么，直接用个单机内存库比如sqlite就可以达到了，如今的pc性能你还当10年前呢？更何况，你都C/S客户端了，何不好好利用免费的分布式资源。还是看具体场景，不要总是以自己过时/可以完全掌握的经验来限定解决方案。

0.2 接地气的愿景。

任何时候，任何行业，任何应用，不管是公司内部还是外部，无论你的目标是什么，任何时候都存在着大量的现成和潜在竞争对手。尤其是在应用还在早期阶段，当我们去调研竞争对手的系统或者我们想整合、接入的系统时，我们会发现很多显而易见的特性上都已经存在甚至很完善了，从表面上和早期看来，我们似乎没有任何的增值价值产生，所以，作为管理者，作为重要的事，你需要在脚踏实地的前提下，站在更高的角度去分析现有格局，就跟城市规划一样，规划师会搭乘航拍机，从高空俯视的去全局观察，根据城市的地理、现有工、农、居住格局先将城市定位为旅游、科技、生活为主的定位，然后据此划分区域，制定五年计划，确定优先级。但是一定要考虑到计划不如变化，不要认为定下来就不会变化，通常会每年review一次，可能会将以旅游为主的定位，调整为旅游+科技双轨驱动，比如说杭州，但是在执行过程中，新的规划调整前，一定是朝着既定的宏观规划或者我们说愿景去努力实现。只站在微观的角度，具体的执行者一定会想如果KPI是科技驱动，有大量的城市已经甚至远超当前自己的实力，我们要赶超应该如何切入，核心重点往哪方面去，比如科技就可能是AI，云技术，企业服务，互联网，电商，外包等等，细分下去你会发现每个地区都有自己的着力点。

回到既定主题，作为管理者，你需要始终如一的贯彻和定期审视项目/系统的愿景，并一如既往的向团队成员贯彻该愿景，并在执行过程中定期review执行路径是否为愿景服务。只有团队成员真正理解了系统的根本目标，才会真正从心理上愿意去把他做好，而不是为了工作而工作。

0.3 理解政治。

无论是创业公司还是大公司，只要有一定的规模了，政治就存在了。没有一个团队能够脱离其他团队独立存在，大公司尤其如此，系统间的整合或者职责划分不仅仅是一个技术或者业务对接的问题，还涉及到关键的一个环节，团体间的政治博弈，政治博弈包括整合后预期失意方的安全感以及尤其导致的内心抗拒，团体负责人的权力（虽然没有公开，但是通常较大的团队比较小的团队更有底气）博弈等等。所以，作为管理者，理解政治，懂得学会政治博弈对于中期的职业生涯有着根本性的帮助，有太多的人在政治博弈中失意。更重要的是，为了保护你的团队以及最大化效率，你需要将外部的政治影响在这一层隔离，并尽可能早的解决上层政治层面的障碍，让你的团队顺畅的创造价值。

1、能接受的答案永远超过2个。

95%+的情况下，能够解决问题或者让客户满意的答案总是超过2个。比如就某些只需要一个实例的场景而言，可以使用单例模式，也可以使用静态方法，很多时候采用哪种其实都一样。再如是否使用分布式缓存，很多时候，并发量没有到非得使用分布式缓存的地步，绝大部分场景中基于sql的pk完全可以满足要求，这种情况下不要过于固执某种答案，尤其是自己擅长一些方案、不擅长另外一些方案时，除非明确可以证明其存在风险且无法避免。

当然，在某些情况下，比如在一些统计查询中，五六张几百万记录的表进行关联、然后group、分析函数各种统计时，一定是要坚持oracle/postgresql+hash join/parallel+pga，甚至各种固定执行计划的，如果执意要采用mysql或者在应用中比如java中计算的，还是要反对的。

所以，除非明确可以证明其存在风险且无法避免，记住任何时候大部分场景选择哪种方案并无本质性差别，因为业务远达不到会造成明显差别的体量。

2、容忍犯错一两次，只要可控，哪怕明知。

这种情况一般发生在新到一个环境或者一些老员工加入、或者接手、协助一些需要帮助的项目、或者某些PPT领导时，我们会发现有些方案看起来就像开着轿车去工地里运砖头，或者拿着榔头去拆几十层高的楼，但是经过沟通后，相关人员仍然坚持认为没有问题，一定要采用某种方案时。这个时候最好的方式并不是闹僵亦或是到处打小报告。只要范围可控，有时候甚至可以那生产环境在高峰期可能出现问题为代价，也是可以接受出现一两次小事故的。当相同的事故多次出现时，通常别人主动寻求解决，此时只要我们足够的诚心，不仅可以解决问题，建立威信，更重要的是，还能和当事人建立更为和谐的后续合作基础。作为领导，更应如此，方才体现大度。

3、所有的事都是你自己的事。

无论是作为程序员，架构师，技术经理还是项目经理，要想做好一件事，最重要的是记住Linus 谈软件开发管理经验 中说到的，所有的事情都是你自己的事，不要觉得别人有义务配合、协作、支持你完成你想做的事，总之上下游都得打点好，如果到了约定1/2的时间，已知无法完成了，那么如果你可以解决的话，那就自己解决吧，哪怕你是协助他解决的，你们的工作量比例是1/2。如果你觉得这不是你该做的事，那么问问自己想不想做这事（刨除公司付给你工资的因素，你今天的额外付出，明天会有家公司额外付给你的），如果想做，那就去做，至于最后成绩归谁，不要太在意，总有很多人看在眼里。

我相信很多人都有这样的切身体会，每次各种开会、反思会、三板斧的时候，所有的人跟打了鸡血一样，各种目标、各种规范、各种规章，三天过后，真到了要落实改进的时候了，总是能够找到各种理由，比如说现有的环境很稳定了，既然客户说没有问题，那就不要去动它了（人家支付宝还搞了好几次冒天下之大不韪改了让大家都不爽的风格呢、其他的各种就不要说了，但是也有些让我们想从此再也不想用这个应用，比如联通网上营业厅），都一年前的版本了，就是不愿意升级，从来也不考虑额外的维护成本、提升客户体验、产品化管理。再比如，我们产品有基础版、专业版、旗舰版的概念，其实可以说应用是完全相同的，只不过根据具体选项启用了不同的特性配置而已，有不知道多少次、不知道开发和运维跟我说，这两个系统是不一样的，为了统一的发布、交付，每次都是免不了各种口水仗。对于这些问题，有些时候作为非行政上的管理者，要求去推动真心比登天还难。

4、最小化重复的人工动作。

很多事情，很多公司的很多团队都在重复的劳动，低效的生产率、高昂的人力成本，作为管理者，你要意识到，在IT业，最贵的不是购买价格两倍的服务器、不是该买1.5w的mac还是五六千的dell、也不是该不该买个正规的IDE、给员工各种零食小吃，而是开发人员、测试、运维人员的成本，一个初级开发一年的工资成本就要10万了，作为一个优秀的管理者，你应该观察哪些事情是在重复又可以避免的。比如，每次升级总要人工更改一些配置文件，相同的问题新员工或者另外一个项目组的同事总是要问，定期录入证券指数，我们就要好好想想是否可以通过环境变量、域名方式避免第一个问题，是否建立在线共享支持库，花一个下午建立定时任务自动从一些资讯源下载等等。这就像如果你家门口放了一块大石头，你每次进出门都要绕走，我相信绝大部分人宁愿花一天时间也要把这个石头想办法搬走。在日常管理中，一样的道理。

很多人肯定会想，这不是应该开发的事情么，为什么自己作为leader如此悲剧，我只能说有太多的员工缺少责任心、上进心、学习主动性，说的不好听就是混日子。如果你在一个已经习惯了最小化重复劳动的团队，那么你是幸运的，事实上很多外界认为不错的公司存在着很多这些问题。

总之，记住不要为了扩大规模而扩大规模。

5、及时决策。先确定一种规范，哪怕后来证明是错的。

我们总会遇到一些事情需要确定下来，但是在此之前我们没有经验确定怎么样做才是合理的，这个时候你发现其他成员也没有经验，网上也大都是没有实际可以参考的，而事情已经到了必须要做的时候了。这个时候，我们应该做的事尽可能参考周边的例子。比如有一阵子，我们在大面积迁移到SSL的时候，就遇到证书的命名规范和存放路径的问题，因为之前较少使用，所以一下子对于公钥、私钥、CA各自的命名规范、以及存储路径等不确定放在哪里比较合适，因为我们有着上百个实例在运行，同时tomcat/nginx/mysql/RPC都需要这些统一的模式，所以不可能中心存储、也没法使用绝对路径。所以，最后我们暂定为目录根据JDK走，全部放在$BASE_HOME/security下，同时命名规范参考mysql的规则。确定之后，我们就按照这样让测试和运维去执行了，虽然一直这么下来没出什么问题。万一到后面出现问题的话，一定要能主动承认是自己考虑不够到位，并及时进行调整为正确。很多事情，笔者曾见到很多的事情因为没有人愿意决策并推进执行，一年前存在的问题，一年后仍然存在，然后又不停地在反馈事情多、人员少。

6、以身作则。

不管是大公司还是小公司，套路和公关手法通常都是一样的，各种股权、期权、画大饼，我估计很多的开发都听过我们是全员持股、公司是大家的，其实大部分人手里的那点股权或者期权真到兑现那天，稀释的加上辛辛苦苦那么多年失去的外面大公司的收入，并没有让你的收入增加了很多。更何况，95%的创业公司最后都会死去。现在人都很聪明了，所以不要觉得天天画大饼，同学们就会觉得公司真的是他们的。大部分的时候，成员做事的习惯完全是看着顶头上司的行为举止，leader的做事风格决定了下面成员的风格。如果leader每天说我们重视系统质量、产品化、提高稳定性、客户至上、open不限制具体实现，但是生产环境有一二十个版本，不同的部署目录、三方软件版本等等，同时口头上说对于某个方案不限制具体的实现方式、但是真正到做的时候除了最擅长的老套实现外（哪怕存在已知明显的缺陷），其他的都不同意。同时，甚至笔者曾遇到有些领导自己犯的错和bug总找个理由说这个是使用问题、反正就是不承认。类似此类言行不一的事情，基本上出个三五次，下面的人就会形成相同的氛围。所以，作为leader，以身作则不仅可以使你能够树立更好的团队氛围、个人威信，提升整体绩效，甚至对于周边团队来说，当需要进行合作和相互支持时，也为此提前预埋了良好的信誉。

7、如果能整体上有所推进，不要太在意吃小亏。

从出身的那一刻开始，就没有绝对公平，虽然我们人生有两件事是任何人都无法逃避的，死亡和纳税。这也只是绝对而言，相对而言，死亡和纳税也是不公平的，有钱人有很多的避税方法、很多尽可能延缓死亡的方法，但是贫民而言，可能就没有太多的选择。所以，人在江湖，不要在凡事上斤斤计较，任何的组织、任何团队，我相信大概率上都存在一些打酱油的人，亦或是凡事锱铢必较的人，你的事就是你的事、他的事就是他的事，哪怕客户极为不满、线上故障都当做跟他没有关系。还有些人，总是想着能不做的事就不做，至于是不是他做更加合理，压根不放在心上。虽然这样的人并不占据多数（大部分人输在不愿意学习新的业务、技术，导致很多事情做起来吃老本而已，责任心大部分还是不错的），要是真的遇到了这样的事情， 那么我们应该判断下自己多做一些能否改善现状或者推进一些进度、同时如果做甩手掌柜对我们有没有影响，如果可以的话，那就多做吧。

还有些时候，职责到底应该归属谁根据不同的角度来看还真不同。比如说，我们之前有个行情应用的功能，出于安全性考虑，客户端为了得到行情一共有四个节点，客户端-接入MQ-转发服务器-内部MQ-行情服务器，因为有些时候行情推送有延时，于是我们经过研究，决定通过MQ的shovel插件直接在内外部MQ之间转发，不再经过转发服务器，这意味着shovel的配置和维护算是开发的职责还是运维的职责就比较难以一刀切的断定了。这种情况下，最好的方式就是开发或者运维组中有偏爱倒腾开源或者新技术的，让该同学负责可能是最好的，避免了出问题时候的推诿。如果没有这样的角色，只能看就平时的工作而言，要是改动不是特别频繁的话，如果确实能够对降低响应时间有明显好处，则自己做吧。

做这些事的时候，虽然它不会给我们带来立刻性的回报，但也不会让我们少块肉，无非是少了些自己可以安排的时间而已，但是它会促使我们思考怎么做更加合理，同时也是为了更好地总结经验。但是有一天，所有这些我们平时积累的，最终都会有一家公司给你补偿的。

更重要的是，作为技术专家，你没有义务去做这些事，但是作为产品线的管理者，这些事情已经从友情支持变成了你的职责。

8、尽量第一次就把事情做完善。

从软件的术语来说，我们可以称之为防御式编程+契约式编程。其实到管理上也是一样的，不管最后确定了哪种实现方案，很重要的是对于不确定的外界因素或者使用习惯，尽量做好防御性措施，比如说我们在外部系统交互的时候，需要考虑到超时情况，涉及到写批处理脚本时，要考虑到各环境的不一致，此时应该尽量通过规范或者环境变量、域名等等进行事先的判断和约定。再比如，我们再一次中间件架构调整的过程中，涉及到十几个jar、五六个配置文件的增删改，因为不同的业务系统需要不同的配置文件参数定制、同时由于众多的B客户预算不同，有些应用全部在一台服务器上、另外一些数据库独立、还有一些外部HTTP和TCP接入独立，因为我们在测试和演示环境升级了很多次了，所以当发给运维进行升级时，升级了3套环境都是有各种问题，每次都要额外花费很多开发、测试的时间。最后，笔者为此专门又花了半天时间，根据现在各种环境的典型情况确定A\B\C各自部署模式下时执行哪几个脚本的方式确保升级的时候，不管部署模式怎么样都只要执行sh脚本即可，不需要人工重复更改配置文件，对于存在不一致的，启动时提示完善的友好信息，接下去升级的时候就省事了很多，基本上运维没怎么在升级的时候打电话给测试和开发，只是升级完了业务基本都验证过了之后，让开发同学检查下有没有其他异常。

除了上面的主动性事情外，在不少的时候，尤其是分布式系统中，通常多个组需要进行相互之间的RPC调用，这就势必涉及到相关接口的约定，有些开发人员在设计接口的时候甚至都没有花该花的1/2精力去思考接口本身能不能自圆其说，纯属为了应付而应付，设计的接口和编写的程序真的没法直视，一点异常都保护不了，有些领导甚至要求出错的时候一刀切的返回"系统繁忙, 请稍后重试"，然后在log里面也把异常堆栈给吃了，美名曰良好的客户体验。这些做法在当初看起来好像是节省了很多事情，但是却留下了大量的技术债务，从当事人来看或许到后面已经事不关己，但是如果你是个较长时间内在任的leader，切记挖的坑最后都是要填上的，而且花的都是你自己的成本。很多看起来是运维的事情，最后不管运维是强势、弱势、水平高的、低的，最后只要异常都是来找开发，虽然有些能忽悠过去的忽悠过去了，但毕竟忽悠也是花费了很多的人力成本。还有很多我去参与优化的系统中，各种日志级别乱的一塌糊涂，要么都是debug、要么都是info，该是error的地方用debug、该是warning的地方用error，等到某一天系统在盘中异常的时候，为了找到排查问题所要的信息，几十个log文件里面来回切换上下文进行拼凑，好不容易花费很长时间把当事问题解决了，还是不吸取经验，又或者临时抱佛脚的方式进行扫一遍，等到下一次发生的时候仍然是重头开始。很多的时候，由于开发人员的经验水平、leader的不重视、各人员存在着各种侥幸心理导致了心里总想着，问题应该不至于发生在我身上。所以，不管是自己亲自做的事、还是团队成员的任务，尽量第一次就把事情做完善，终归来说成本是最低的，作为leader或者manager，这是你的职责。

9、解决短期目标，预留好已知未来目标的实现计划。

准确的说，这是第1点的增加版，在很多时候，解决问题的途径不是1->2，而是1->1.6->1.4->2这样的曲线方式。这可能会由于很多的原因，更多的是现有的人员技能、兼容性、老员工、领导、三方团队、一次性调整的动作大小等等，从技术角度可能只需要N多资源可以完成的，实际花费的资源很有可能是2N甚至3N，只要目标和实现的计划足够的清晰，并且整个团队都愿意按此方式执行，通常来说事情都没有恶化到非要直接1->2的程度，只要在保证达到目标的过程中足够的稳定+持续的推进，这是完全可以接受的。在更大的团队中，比如超过50个人的规模时，采取小步快跑的方式甚至是管理常态、而不是特例。

10、确定目标，人员、技术灵活组合，投入产出最大化驱动。

做任何事情之前，先好好想想要达到什么样的目标。确定目标之后，再根据人员的水平、储备情况，各技术的核心擅长点，确定合理的计划，实现方式，不要基于限定的具体实现方式、特定于某个人来确定方案。举个例子，在id生成的场景中，可以使用数据库机制，oracle的序列，mysql的自增列，也可以应用中实现，具体如何实现需要考虑当时的业务目标，自己运营的系统、给客户定制的系统、saas很可能选择不同方案，并发量、有序性、是否严格递增等等都会导致不同方案，最主要的是怎么样能够满足业务要求、同时最小化成本（运维+开发）。

11、业务驱动，精通核心业务领域及其附加值，技术广泛涉猎。

12、拥抱变化，不要故步自封于自己过去的成功经验。

13、如果你要做一个解答，这个解答如果是非纯技术答案型的、或者你接受者会生气的、或者可说可不说的，如果接收者是非好基友且保证没有利益纠纷的，那么过一个上午或者下午，你再决定是否要这么仓促的答复。

14、如何应对一根筋、故步自封的人。
15、维护良好的知识库系统。
不管是业务异常、系统异常、使用问题，各种常见的错误总是会反复出现。

1、运行时说明文档，比如配置文件位置、各种取值范围等等。

2、一个新增的module/app，其主要配置、运行时角色、流程，部署方式，依赖等。

16、管理比自己年长的员工。

不管是否接受，公司组织的调整、临时性的应急小组都有可能你所负责的团队内出现资历或者年龄高于自己的员工。所以，不管怎么样，你都要面对这样的挑战。因此，成功地管理比你年长的人是不得不掌握的技能。笔者没有特地研究过和过多的实际经验，之前在网上搜索相关建议和方法的时候看到下面一篇总结，做了一定的调整和编辑。需要认清以下几件事情：
1.各世代的人不同。
我们都是由重大事件、社会趋势和态度塑造出来的。70后、80后、90后可以说是完全不同的三代人，每一代人都有每一代人的优点和缺点，而优秀的老板欣赏这种差异。
2.经验很重要。
人们很容易认为科技改变一切，新业务是全新的领域。但是大多数商业问题从现金流到战略定位到联盟都是由工作多年经验丰富的员工们提供了一些什么会奏效和不奏效的见解后制定出来的。不要仅仅因为不是你自己的经验就低估它。
3.年龄多样性和性别多样性一样难以处理。
但是它也可能同样具有价值。意识到经验当中固有的价值，给予经验更丰富的员工机会去教导年轻人。如果每个人都发挥作用，旧见解和新见解之间的联系可以让人们做事更有效率更具有创新性。
4.社会凝聚力是一种优势。
员工们并不是真的忠于公司而是员工们彼此忠实于对方。一旦年轻的员工与年长的员工之间的关系得到加强，整个公司就会变得更加稳固。这样经验就不会从门缝中溜走，学习不也会消失。如果你能够圆满地将年轻与年长的员工之间的关系加强，这是一种非常巧妙的方法。
如果你是公司中一个小小的领导，而且也要每天面对着比自己年长的下属员工，那么需要认清以上几件事情，抓住他们的优点和缺点，以及想法，在处理问题的时候灵活应对，这样管理任何人都不是问题。

17、对于为期超过2周的任务，明确目标，然后制定、要求制定计划并定期跟踪和记录变更。对于需要全职超过两周或者半个月的任务或者安排，通常会在执行过程中出现各种各样的额外干扰或者变化。对于需要更长时间的工作任务，由于需求的理解歧义或者设计考虑的不完备等等，通常会花费更长的时间，进而会导致粗糙的动工，最后偏差很大而且质量甚至更好。所以，一定要在最开始安排3%-5%的时间做计划，并在执行过程中发生变化的时候及时更新，对于leader来说，应该要求开发每隔5%-10%更新产品进度和存在的待解决问题。为什么是这个频率？因为失控超过20%之后，通常我们就很难在按时高质量的完成目标了。更重要的是，作为owner，如果你不在乎进度，那么你就不要指望所有的人都会主动在乎你那个所谓的时间点，当然我也绝对承认会有一些人主动去做了，他们在乎自己的声誉，但是他们毕竟是少数，所以，只有你对结果足够的关心，他人才会对你要的结果关心。

18、不要纠结于一定要怎么解决，在保证质量、稳定性、性能的情况下，脑洞大开，思路转换为项目经理的角色，最小化成本的去解决。

如果开发人员遇到或者提出一些技术难题，举个例子，就java导入导出excel来说，有很多方式可以根据性能或者内存消耗优化，jxl或者sxssf，但在另外一些时候，我会直接跟开发说用户既然是运维人员，为什么一定要excel格式呢，直接让他们用csv格式就好了，用户的问题我去负责协调，于是问题几分钟解决了，而且稳定性远比excel好得多。

19、培训和招聘

在过去的7年时间里，我发现似乎大部分团队都在开发、测试环境的日常维护、确保顺畅的可用性上花费了不少时间，感觉1/10的时间大家浪费或者等待或者在修复无法正常工作了的环境上应该是有的。通常，出现问题后，采取的第一措施和绝大部分情况下的唯一措施就是重启应用、重启中间件、重启数据库，再不济重启操作系统。遇到更为麻烦的情形时就只能等着团队中可能最厉害的那个人去修复，其他人可能继续其他工作，也可能等着做测试，亦或是一堆人在各种讨论群里不停的催促。几乎没有见到一个团队规定一个职责：所有人对项目所使用的绝大部分基础设施有整体的了解，基本的日常维护和异常应该能够或者有流程性（FAQ式）的对应措施，以便任何时候出现任何问题的时候，绝大部分人都能够自己快速解决，而不必等待特定人员去解决，当然如果遇到数据库文件损坏、因redo损坏等非常规性异常时可以视为特例。恐怕加起来，每年都不止一二十次，我需要协助解决这些问题，他们有部门内部团队的，也有不少来自外部团队的。这些团队的管理者给我的感觉从来就没有想过如何从效率上提高ROI、团队的满意度。每当出现问题的时候，这些团队管理者从来就没有去思考自己的管理是不是IT行业管理的好模式，唯一选择的解决方案就是996，到了最后，甚至很多的开发人员竟然以加班为荣，有些开发人员在第二天被训了之后，来了一句，我昨晚加班到2点多，好吗？。在任何的时候、任何的场合、任何领导在场的情况下，我都对我们的团队内或者周边团队的兄弟姐妹们说，在加班前，你们先思考一下是因为真的事情多到你们一定要加班，还是因为各方面的效率低下问题导致你们加班。比如运维团队，我经常说，你们是最应该准时加班的，除非要升级，如果不升级，你们还不能准时下班，那么要么是因为程序效率低下导致清算过慢，要么就是业务系统有异常导致你们需要人工排查各种数据，这两者都是不应该发生的。如果发生其中任何一者，但是你们没有催着开发解决，这就是你们或者你们领导的问题。但是，除非你们知道这不合理，否则开发团队一句这是合理的，你们就没有反驳的余地。进一步的，事情会扩展到你们选择招聘新的人员来运维新的系统。
国内大部分公司招聘的弊端在于绝大部分具有招聘权的管理者都不想招聘一个薪资在自己之上的人员，进而导致的连环效应是去面试的那些人也只能面试到水平在自己之下（甚至都不可能和自己平级）的应聘者。当然，这可能有多方面的原因，绝大部分公司自认为自己不需要一个水平在BAT公司技术专家或者以上的人员，转而选择两个高级开发人员，这样既可以确保自己能保住权力，又可以扩充自己的团队规模，最主要的是他们认为绝大部分的日常性开发一个高级开发人员就可以完成了，为什么要用一个更高成本的人员呢? 这么做的最大危险在于技术专家能够轻车熟路的很多关键性/致命性事情，高级开发人员需要花费几倍甚至多几十倍的时间去解决，找到的解决方案甚至可能充斥着各种潜在风险，而正是这些从功能数量上来说只有1/10的关键性/致命性特性，才是你的系统让客户愿意为此买单的原因，也是你的系统击败众多竞争者的原因。
SaaS之父曾说，作为manager，你应该把20%的时间放在招聘上，一开始，我觉得这会不会太多了，这么多年，现在回过来想想，其实这一点都不为过。在过去的招聘面试多年中，我发现要想从众多应聘者中招聘到一个真正满足岗位要求的人员概率在起码1/10以下（除非是你极为信任的好友介绍的），如果加上那些还没有进入面试就被淘汰的简历，概率起码在1/30以下。我们说，管理者的职责就是让大部分人去最高效率的开源，留下几个兜底节流，这几个兜底的通常是真正的技术专家、架构师。
所以，就培训和招聘来说，我觉得中基管理者应该将30%的时间用于招聘、培训（业务、技术）、知识库建设。

20、如果不是一次性的产出，则不要因为麻烦而开绿灯。这句话的意思是，当我们作为开发人员角色的时候，当我们发现要解决某个业务问题或者技术问题的时候，采用明文规定的规范、方法、约束要花费更长的开发时间时（非运行时时间），对于实战经验极为丰富的开发人员来说，很可能在未经第二人知道的情况下，已经采取了他认为正确的处理方式。而对于一些资历尚浅的开发人员来说，会征求其直接上级或者其他他认为有权为此拍板的同事的意见，此时作为决策人，我们需要做的事根据该业务模式思考按照常规的方式进行处理，对于初次开发、后续维护、运行时稳定性、性能、用户体验的影响是什么，如果仅仅只是开发层面需要更多的事情，通常我们会要求开发多写一些代码完成。在其他任何情况下，只要是有持续性影响的，我们就应该评估并决定是否将新的开发模式、设计模式、更加合理的处理方式作为规范的一部分。如果仅仅是因为麻烦而开了绿灯，在后续的升级、维护、发布、人员交接过程中，你会发现要想统一回来，又得整个环节鸡飞狗跳一把。

21、办公室政治。如果此时你确实在管理者的岗位上，那么在过去漫长的职业生涯中。我们或多或少的享受了任人唯亲的好处，也遭受了任人唯亲的挫折。我们知道，在为数不少的情况下，两个人向一个领导提出了一个几乎相同的请求，其中一个被批准了，另外一个没有被批准。发生这种情况，我相信大部分人都遭遇过，但这仅限于到此为止，你不应该让这种氛围进一步发展下去。你要知道，办公室任何时候都有着N双眼睛在看着，N个人在思考你的为人。所以，为了让你的团队能够更加持久性的保持稳定和高绩效，你不应该为了自己的喜好或者自己所谓的小圈子给团队成员不同的标准。

N、上述转换是一个永远进行时+改进的过程，而不是某个点或者阶段的结果。

最近又读了本书，相当的不错，名字是《360度全方位领导力》，2013年出版的图书，作者是约翰·麦克斯韦尔。个人觉得相当实用，不像很多给高层的各种战略、领导力书一样，本书还是相当接地气的。

另外几本是：

  • 执行：如何完成任务的学问，这本书5年前读过，至今每日践行。
  • 卓有成效的管理者。
  • QBQ。
  • 几年前的春节假期在新华书店读过一本关于授权的书，不到200页，印象极为深刻，但是名字忘了。
  • 杰克韦尔奇自传。印象还是蛮深刻的，但是有些事情啊，只有你成功了你才知道为什么那么做确实是行得通的，否则你就算知道但心理上却不敢去尝试。
  • 格鲁夫给经理人的第一课，读过两遍，最近又读过一遍，印象没有想象的那么深刻。
  • 马斯洛需求层次理论。

各种沟通方面的书，总结一句话就是"换位思考"。

IT管理方面的（非具体技术）：

相关文章