在提升自身技术能力与管理能力的同时，我也一直在思考，作为 IT 技术管理者，如何做才能让我们在这个领域里发展得更好？
在年龄渐长时能从容应对所谓的“中年危机”，或者说 IT 技术管理者的自我修养，应从哪些方面去努力？
因为文字写的有点多，先贴一张思维导图：
对“管理”的理解
管理，从字面上看包含两层意思：“管”与“理”。管什么？理什么？怎么管？怎么理？可能把这四个问题弄清楚了，管理这个事也就没那么难了。
首先，管什么？有些人可能认为管理就是管人，就是盯人干活，在我看来，管人不是管理的目的。
管理的本质应是协调一切可以协调的资源（人力、物力、财力），努力达成团队或组织的终极目标。
那么为了达成这个目标，技术团队需要管什么？我总结了以下四点：
这里每一点都包含了一个词——持续。不是把事情梳理完，分配完就可以撒手不管了，就可以“放羊”了。
其次，理什么？如果把“管”理解为实践，那么“理”就是理论，只有实践与理论相结合，才能做到有目标，有方法，有效果。
技术团队需要理什么？我也总结了以下四点：
我从提升领导力，方法论两个角度进行了思考与总结。
领导力
领导力我的理解就是带领他人朝着一个目标努力，组织协调最终一起达成目标的能力。
技术管理者如何提高领导力，我认为可以从以下四个方面努力：
技术能力
好的技术团队管理者，一定是该技术领域的技术专家，具备较强的技术能力。
技术人员一般思想都相对单纯，谁比他厉害就服谁，他不懂的你懂，他解决不了的问题你协助他解决了，自然就能提升你的影响力与威信，这对你的管理会带来极大的帮助。
好的技术能力，不仅要有技术的深度，还要有技术的广度。因为只有具有技术的深度，才能帮助下属解决他解决不了的问题，才能在团队遇到棘手问题时迎难而上，带领团队披荆斩棘。
只有具有技术的广度，才能有效地制定团队的技术方向，并且在下属跟你说这个功能实现不了时，才能确认下属是在忽悠你，还是真的实现不了。
业务能力
只有对业务具有较深的理解，才能更好地使用技术手段来服务于业务。一般我们做架构设计时，包括业务架构与技术架构，技术架构要以业务架构为参考，一切脱离业务的架构设计都是耍流氓。
一些中小企业的技术管理者，去参加了一次阿里云栖大会，回来就跟团队鼓吹加人搞中台，对于中小企业来说，很多业务仍处于探索阶段，好多产品或项目可能在你中台还没搭建完就已经玩完了。
从技术的角度，思路可能是对的，但从业务的角度，没有结合实际，没有考虑成本，效率等因素。
不结合具体业务照搬别人的架构，轻则可能把团队拖死，重则可能把公司拖垮。
同时只有对业务具有较深的理解，才能清楚团队是否在沿着正确的方向前进，才能了解评估每个人的工作成果。
协同能力
协同能力就是协调各类资源（人力、物力、财力）的能力，包括向下协同与向上协同两个方面。
向下协同能力，就是组织协调下属的能力，也就是带队伍的能力，如果把团队成员比喻成一个个齿轮。
那么管理者就是既要充当拉动整个组件的皮带的角色，还要充当各个齿轮之间的润滑剂的角色。
他既要拉动团队整体运转，又要在齿轮之间出现摩擦与碰撞时及时添加润滑剂让其减少摩擦平稳运行。
同时要知人善任，要知道把每个齿轮摆在什么位置，才能充分发挥各个齿轮的效用，从而整体动力更强，效益更高。
向上协同能力，就是往上看，与领导处好关系的能力。很多时候，只有与领导处好关系，才能拉到更多更好的资源。
这里的处好关系不是说阿谀奉承溜须拍马，而是做好工作汇 ，让领导认可你，信任你，从而放心地将资源交付你。
争取到更多的资源，才能帮助下属协调他协调不了的资源，团队跟着你干才有“肉”吃，才能保持工作的动力与热情。
心胸宽广
所谓江山易改，秉性难移，上述三点都可以通过努力去外修，而心胸宽广，却是需要内修的一个方面。
技术管理者，既要做到以技服人，以能力服人，也要做到以德服人，以心胸服人。
什么是管理者的心胸宽广呢，我认为主要体现在三个方面，对事不对人，公私分明，有大局观。
对事不对人就是要就事论事，秉着去解决问题，规避问题的角度来处理事情，而不要对任何团队成员存在任何偏见，一出问题就质疑指责别人的能力（有时候虽然确实是能力问题，但最好不要直接这么说，是很伤人自尊的），甚至三观。
公私分明就是不要在管理工作中携带私人情感，对与自己关系好的下属照顾有加，对与自己关系不好的故意刁难，要公平公正，一视同仁。
有大局观就是凡事要以实现终极目标为准绳，有利于此的就要宣扬与坚持，无关大碍的就不要斤斤计较，不要都争个对错。
所以，管理者的领导力是一个内外兼修的事情，既要有外修以提高管理的能力，也要有内修以提高管理的魄力。
方法论
光说不练假把式，以上主要是一些思维方向上的总结，那有没有具体的方法或套路来践行这些思路呢。
结合自己的实践经验，我从制度、规范、工具三个方面做一点分享，但每个团队、企业面对的具体问题不同，可能其中具体的方式方法不一定适用，但是整体的思维方式我认为是相通的。
制度
制度就是为了实现或更高效地实现目标，规定要做的活动。技术团队建立的制度可以包括例会制度、周 制度、需求评审制度、设计审查制度、代码审查制度、绩效考评制度等。
团队的沟通交流很重要，例会制度可以给团队一个相互交流、了解的空间，问题反馈的渠道，同时也给技术管理者一个跟进团队工作状况，宣扬制度、决策的机会。
所以每周一次或几次（根据自身情况衡量）的例会是有必要的。周 制度是团队所有成员对自己一周的工作进行梳理回顾，总结问题经验，同时对下周主要工作作出计划的活动。
周 制度一方面有利于团队管理者了解每个人的工作进度、问题，及时干预保障目标的达成，另一方面也促使团队成员梳理自己的工作，做到有计划有步骤有进展。
需求评审、设计审查、代码审查等制度，可以保障我们对需求的理解是一致的，设计是符合整体架构原则的，代码是符合编码规范并且没有低级错误的，从而提高我们的开发效率与质量。
绩效考评制度主要是避免吃大锅饭，干多干少一个样，干好干坏一个样的情况。
但绩效考评如果不与奖惩机制关联就有点形同虚设，这有时候可能不止是一个团队或部门能决策的，而是公司自上而下的制度规定，相对就较为复杂了。
规范
规范就是定义怎么来做，包括技术规范、流程规范两个方面。技术规范规定对一些常见的通用场景，通过什么样的方式来统一实现。
如前后端交互协议——接口返回的格式，是否 REST 风格，各个服务应该是一致的，再比如异常的处理——业务异常应该怎么处理，非业务异常应该怎么处理等。
技术规范一方面通过对相同问题采取相同解决方法，来避免出错的概率，另一方面对一些通用处理进行封装，避免复制粘贴或重复造轮子。
流程规范对一些活动，指定了什么人在什么阶段，应该做什么，怎么做，以保障工作或制度有序、有效地执行。
工具
工欲善其事，必先利其器。制度有了，规范流程也有了，如何来保障高效地执行，就要依赖于有效的工具。
比较常用的团队管理的工具有：
还有比如像 Jenkins 等提高开发部署效率的工具等等，这些工具或其他替代品我相信在很多公司都有相应的应用，这里就不详述了。
另一个比较特殊的工具，是考核，我们都说考核只是一种工具，而不是目的，并且这种工具还是一把双刃剑，做得好，效果显著，做的不好，可能影响团队的士气，得不偿失。
但是我认为对于一定规模的团队，比如十几人，几十人，不能没有考核，考核不一定很科学很完善，但只要秉着公平公正客观的原则，并辅以一定的监督，就是一个聊胜于无的事情。
制度、规范、工具是可以应用于团队管理的方法，总结一句就是用制度来规定要做什么，用规范来定义怎么做，用工具来让你做的更轻松。
总结
没有人天生具备管理才能，只有在平时多观察，多思考，多实践，多总结，才能不断提高对管理的认知与水平。
各个团队，各个公司面临的问题不同，也没有一个放之四海而皆准的模子让你去套，但是尽管面对问题不同，应对的方式方法各异，整体的思维方式还是相通的。
技术管理者的自我修养，我认为先要有对管理的正确认识，然后从提升领导力，构建团队文化，方法论三个方面去实践，思考总结，调整，再实践，再思考总结，再调整的方式来不断提高。以上，共勉。
【扩展阅读：技术总监之路系列】
喜欢关于程序猿成长的内容，可关注我的头条 “软件真理与光”！
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！