技术领导力：程序员如何才能带团队

2020030 目前面临着转型，这个是我的又一次重大转型，由技术向技术管理方向靠，所以这本书对我来说是相当锲合，覆盖面很广，很多内容都可以作为工具书了。 对于技术，我感觉自我学习能力足够应对各种新技术。但是对于管理，真是心有忐忑，不知道自己能不能真的做好~ 书中很多话都对我有着指导意义： 1. 有的人喜欢多鼓励，少批评。在平时的交流和会议中，多给予鼓励和表扬，效果有时候比正式会议的褒奖更让人感觉舒适。少批评，但批评的时候一定是声色俱厉、毫不留情。 2. 你的工作是什么呢，除了技术，还需要保护团队中的工程师不被打扰，在各方面给他们支持，帮助他们能顺利完成任务。同时你还需要在重大的方向上输出影响力，做决策，定计划，这也意味着，如果决策是错误的，需要你来承担责任。而有了荣誉的时候，你要退下来，让给团队里那些优秀的人。 作为团队负责人，我们也应该有硬汉本色，不能惧怕外在的威胁。团队成员都在看着你，你决不能懦弱，要勇敢。 在领导层不明确哪个团队做的前提下，对内组织团队尽全力做下去，而且要做好，对外则勇于承担责任，敢于接受挑战。 在电视剧《长沙保卫战》中有一段对话，参谋长对薛岳将军说：“你若下地狱，我绝不上天堂。”这也是我在团队遇到严重挑战的时候，对所有成员说的第一句话。想做成事情，你或者你的核心下属，必须勇于站出来。 3. 被管理者（工程师们）逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感，他们逐渐对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣，而不是仅仅满足于金钱的多少。  4. 作为一名技术团队管理者，你要做的是比别人更早接触新技术，更深入地理解系统架构，全面提高管理团队所需的方方面面的能力，而所有这些都需要勤奋。 ❑ 深入理解一门或多门编程语言❑ 深入理解多种流行的框架❑ 系统架构能力强，拥有复杂系统的设计经验❑ 积极跟随开源社区❑ 积极了解业界技术发展❑ 沟通能力强、情商高❑ 有产品意识，不是技术迷❑ 会带人，服从领导，责任心强❑ 会写专利❑ 再会点别的更好❑ 随叫随到、工资不高。 5. 从技术转管理本身就是一个很大的转变，一旦跳进去，就很难爬出来了。我认为最大的差异就是，技术面对的是系统性问题，需要的是逻辑思维能力，是智商，而管理需要面对的很多是非逻辑思维能力，是情商。系统问题需要智商，而人是活的，你要理解人，就需要情商，情商是什么？我个人理解，情商就是如何站在别人的角度看问题。 6. 在企业里面成功，不可否认仍依仗两个方面：要么你聪明，会交际，懂政治，被人认可；要么你做出成绩，贡献巨大，被认可。  7. 最好的领导，思路敏捷而清晰，做事务实而高效，永远没有废话，永远雷厉风行。和他共事，绝对不会轻松。他不会讲段子哄你干活，他也不会笑眯眯地安抚你的情绪。 8. 不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境。 9. 你还需要弄清楚如何汇报、如何沟通，以及要采取什么样的行动，才能让你的老板认为你是一个高效而成功的员工。 10. 你老板的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大、文字更少、项目符号更多。 11. 不要把每一个问题都带到你老板那里寻求解决方案。仔细地挑选你的问题，只拿那些真正重要的问题去寻求你老板的帮助。 12. 你还要避免只把问题带给领导的情况，最好是拿着几套潜在的解决方案和问题一起交给他。 13. 即使你没有特别好的解决方案，或者没有找到最好的解决方案，也会让领导觉得你已经做好了自己的功课，过来找他是为了寻求他的建议和忠告，而不是直接把问题抛给他。 14. 学会给人惊喜与欢乐。了解哪些事情会让你老板时刻关注，并找到办法超水平完成任务，最好是超过他的预期。有时候其实并不是做得越多越好，而是处理较多复杂问题。 15. 你可以非常好地管理团队并完成项目，但如果没有你老板为你护航，你的职业前途必然坎坷。 16. 为了有效控制进度，开发经理需要请各个小组每天召开“晨会”以检查昨天工作进展，并且布置当天工作；另外，每周五下午召开周例会，项目组全体成员都要参加。

从程序员到初级技术管理者之路，确实是一次角色的转变，关注点的变换会让很多人不适应，似乎就是被彼得定理限制了。 必须以成长型思维来对待技术管理者的日常，毕竟从局部提升到了整体，格局要大才能持久。 本书从团队组建、团队建设、技术研究、技术管理、过程管理、系统架构等方面做了深入交流，很适合第一次转型的程序员同学阅读。

非常好的一本书，能结合实际一步一步走下去，最大的收益是当项目启动或者新业务开始时不要过度设计，不要想太多，先让业务跑起来。在合适的阶段做合适的事情。

当团队中每个人的潜力都被发掘出来，能力的集合才是巨大的，才能所向披靡。技术管理就是这么一种组织团队共同进行研发的工作，它是一门细分工种，随着社会的进步、人类思维的开放、经济水平的提升，被管理者（工程师们）逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感，他们逐渐对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣，而不是仅仅满足于金钱的多少。同时，被管理者之间还存在紧密的社交关系，能够随时保持沟通，分享对在该公司或组织工作的切身感受，分享对于管理者个人能力、品德的认识。每位技术团队管理者，也正在像书一样被摆放在被管理者面前，如果别人懒得翻你，就证明你不能给予他们指导，他们没有归属感，最终都会匆匆离职。

对技术领导力技术管理架构师剖析全面的一本书，个别章节啰嗦低价值扣掉一分。要做技术领导必须技术先行于管理，技术领导最好能在技术团队中起到架构师的作用，对新技术持续的热情，业务中不过度设计又考虑横向纵向的业务拓展后的技术升级或架构铺垫，总之技术的落地要基于业务，业务需求是技术驱动力，不能解决业务问题的技术是无源之水。技术管理人员值得一看的一本书。

技术领导的核心竞争力可以总结为把控技术、组织协调能力、主观能动性、推动项目组成员一起成长，保证团队的稳定性。 技术管理者的发展方向 某一领域的技术深度，拥有技术广度，通过自己的技术能力带领更多队员一起进步，目前都会遇到这几个情况 1）队员工作没有自己做得好，花时间去沟通还不如自己去做。 2）感觉自己的技术在退化，长期不写代码觉得自己没有价值。 3）发现自己不懂的东西越来越多，觉得把管理做好不太容易。 4）上面有领导催活要项目进度，下面有开发要方案提供技术支持，需要评估客户的项目难度和耗时，并对需求进行扯皮，夹在中间心累。 需要提升沟通能力，个人定位能力（是否需要分配代码量给自己，或者充电），技术+管理双向充电。 技术还是王道 为什么对自己没有信心和一丢丢害怕，究其根本就是不了解，对技术、人员、项目的不了解，其中技术占有很大部分。只有拥有了相当的技术广度和深度才能给团队的技术指明方向，在团队成员遇到难题时能加以引导。 工作品质 从说话做事就能看得出工作品质如何，要透露出工作的专业性。分析->执行->总结。才会让大家觉得这这个人很专业，分析、执行力一气呵成。 1、成熟 重视承诺，不拍脑袋，懂得为人处世。任何不清楚的事情不能拍板太快。比如评估工作量和项目进度，若有未知风险或者模糊之处不要马上评估，汇报时要加上如果xx是用xxx方法来做的前提。 2、勇敢 作为团队负责人，遇到困难时，不必要惧怕外在的威胁，团队成员都在看着你，不能懦弱要勇敢。当团队遇到问题了要主动站出来承担责任勇于接受挑战。你就是成员的门面一堵墙，要自信，一旦有了决策，就要落实，不必要拖泥带水（如果自己都不确定，成员就会觉得这次做了会白做？所以决策时要再三确认，一旦确认就去做） 3、勤奋 在软件行业。没有在专业上的持续学习和成长是不会成功的。技术变革如此迅速，如果不坚持学习很快就会被淘汰。 4 逻辑能力 为什么有的程序员能够很快解决Bug，有的则不能？首先，你需要对整个事情的全局情况有深入的了解。知识储备够了才能迅速找到问题所在。有时评审方案时，可能稍不注意就被下属的错误逻辑给“忽悠”了。一个人的逻辑能力属于软实力，它是决定你是否可以承担团队领导职责的关键因素。 5 一线作战能力 无论多么忙，都要不断地抽时间和大家一起讨论架构、业务流程、技术难点、技术方向，这是你的职责，而不是让团队处于流浪状态。简而言之，既然你直接管理团队，就要以身作则，让大家看到这个团队和项目是有人在积极推进的。 管理人才的决策能力 1 会议能力 抓住会议主干线，推动项目进程，解决项目堵塞点，报出项目风险。当下属讨论的细节层次不在议题范围内时，要及时打断，会后在谈。并总结会议的重点，指定推进。时刻抓住会议的目的，保证高效。如果是和业务开会则应在会后发出纪要避免扯皮。 2 判断能力 方案需要决策时，要克服从众心理，要有自己的底线（比如编码规范）。快速的决策通常错误率较高。决策的目标应该是明确的，决策的结论应该是简单而清晰的。 3 自信心 面对困难，不要去逃避，方法总比困难多。培养自己的责任感和义务感，跳出个人的小天地，如此你的自信才能坚实可靠。另外平时交往注意要选择那些有自信心、敢作敢为的人，时间长了，看得多了，你必然会受到积极的影响。 技术调研 1）这些技术分别是什么？ 2）技术调研方案、用例分别是什么？ 3）各个技术或框架之间的区别是什么？ 4）各个技术在通用场景下的优缺点是什么？ 5）各个技术在用户提出的特定业务场景下的优缺点是什么？ 6）根据得出的测试数据，为什么会有这样的结果？ 介入新团队项目开发 人员组成，开发能力，周期评估 核心功能流程图理解 了解历史来源，上下游影响，各个模块的关联关系 需要定位增加的需求风险点，提前调研关联影响 项目核心价值，定位。走什么方向能体现出的团队的价值（继续做业务需求或者提升现有性能），业务提的需求的实际应用型 不合理的设计能否在版本内进行重构 版本约定 1）每个项目都应该有自己的版本和时间点，这样对于团队每个人来说才会有个标杆是否需要加班完成。 2）开发、测试、SIT、UAT、生产演练都需要明确。火车一旦启动，就不给插队。 架构约定 这个又是一件费脑袋的事情，我们需要架构师来回答以下问题，当我们启动项目时都应该明确。 ❑ 我们这个系统的边界是什么？ ❑ 我们系统由哪几部分组成？ ❑ 各模块之间怎么通信？ ❑ 选择什么样的基础技术？ ❑ 为什么要这样选择？ ❑ 技术方案未来会遭遇哪些坑？ ❑ 我们的备选方案有哪些？ ❑从技术角度这个应用将来如何持续扩展功能？

粗略看完第一章就看不下去了。提的要做好技术管理的点太宽泛太抽象，实际上这些点不做技术管理一样也有收益（所以感觉是在说一些正确的废话），那么我干嘛来看这本关于技术管理的书呢？我直接看个人成长之类的不就行了？

从目前的程序员角度不错，介绍了技术的方方面面。但是从一个 CTO 的角度来说这本书就差了那么一点。 关于产品研发，这个产品作用是什么？目标是什么？战略意义？优先级如何？ 之类的问题综合分析了之后，才能决定研发资源，研发周期，技术选型等等。 另外本书本质上没有解决技术管理头上的最大问题：在技术和管理之间应该如何去平衡。 这方面将目前中美是如何做的，差异在哪里？美国之前怎么做的，现在为什么演变成现在的模式了。中国处于哪一个阶段？最终给出技术管理岗未来的演进方向并给出目前的最优策略。 作为一个技术管理人员，甚至CTO不应该只拘泥于代码如何写，而是应该现在公司战略的解角度，行业发展的大背景下分析问题，最终落到技术上才更加的现实。

看完这本书，领导力没学到啥，倒是帮我好好回顾了一下自己职业生涯。 毕业几年，换了好几任leader。一开始觉得leader像导师，帮我成长。后来觉得leader是老顽固，阻碍我引入新技术。再后来觉得leader其实也是伙伴，大家互相成就。 仔细想想，几任leader其实没有本质的差别，只是自己的心态在不断变化。在不断地成长中，我也逐渐明白一个leader的思考方式，和各种迫于业务的无奈。毕竟每个人都有成长过程，leader也一样。 在此感谢我一路走来遇到leader们，谢谢啦！

看了本书之后，真正理解到了技术领悟的管理，真的不同于非技术为主导领悟的管理。作者结合自己多年的管理经验，以图文结合，叙事，心理暗示，的方式向我们解析了互联网行业什么叫管理，什么叫自我管理与向上管理，管理的目的是什么，技术架构师这个站在技术领悟金字塔拥有技术决策权与人员分配使用权的角色该承担哪些岗位职责与做哪些前期的风险评估，通过本书可以了解到互联网公司的架构师与高级管理员这个可以双重合并也可以单独平行的职位如何以自我约束，自我修炼的形式陪伴团队成长，指导团队协作，引领团队技术潮流的形式使得最终的结果是趋向于事情完成得很漂亮，然后团队的技术也更进一步了，团队之间的化学反应也更好了！特写大赞的一本书！