1. 前言
本来写《IT技术管理者的自我修养》与《IT技术人员的自我修养》是一开始就有的想法。但发表《IT技术人员的自我修养》后，收到了不少良好的反馈，博客园的编辑对该文进行了置顶推荐，迅速带来了4000多的浏览量，阿里菜鸟国际的大牛也通过私信投来了橄榄枝，现在都还没来得及回复，也有网友留言申请了转载，虽然被改的面目全非。在此非常感谢大家的认可，只要有共鸣，有收获，就不枉我敲这么多字了（^_^）。但同时，也对我继续写《IT技术管理者的自我修养》带来了不少的压力，怕写不好，怕辜负大家的期望，迟迟不敢下笔。但又一想，我又不是什么公众人物，何必有这个心理负担，权当自己的思考梳理，放置于网上，任其评说。再者，丑媳妇总有见公婆的时候，于是，就有了本文。同前所述，本文不是所谓成功人士的经验之谈（作者离自己理解的成功还有十万七千九百九十里—— 一周的时候还是能前进十里吧），而是以一个有几年经验的技术管理者的角度做的一些思考与总结，希望能给有志于从事技术管理的同僚以参考，与之共勉。
因为文字写的有点多，先贴一张思维导图，如果看了有兴趣则可继续，如果没有也可就此打住，不浪费时间了。
！！！长文预警 ！！！
2. 对“管理”的理解
管理管理，从字面上看包含两层意思：“管”与“理”。管什么？理什么？怎么管？怎么理？可能把这四个问题弄清楚了，管理这个事也就没那么难了。
首先，管什么？有些人可能认为管理就是管人，就是盯人干活，在我看来，管人不是管理的目的，管理的本质应是协调一切可以协调的资源（人力、物力、财力），努力达成团队或组织的终极目标。企业管理的终极目标无非就是成功 —— 行业领先、可持续成长、受人尊重。技术团队管理的终极目标，就是在服务于企业终极目标的同时，让团队有所成长 —— 团队成员在能力、收入、素养各方面得到进步。那么为了达成这个目标，技术团队需要管什么？我总结了以下四点。
1. 管执行。就是要持续跟进确认你的决策（制度、流程、任务）是否被执行到位，是否在按正确的方向前进，是否存在问题，并及时拨乱反正，及时提供必要的协助—— 协助协调下属协调不了的资源，协助解决他解决不了的问题。
2. 管进度。就是要持续确认你的目标是否在一步一步按部就班地完成，是否存在风险，并及时做出必要的调整以应对各种风险。
3. 管效果。就是要持续验证各个阶段的成果是否符合当初的预期，并及时制定措施弥补不符合预期的结果。
4. 管成长。就是要持续为你的团队营造一个良好的成长环境与空间，让每一个人都能发挥自己的能力，并且得到有效的成长。
这里每一点都包含了一个词 —— 持续。不是把事情梳理完，分配完就可以撒手不管了，就可以“放羊”了，而是应持续跟进，只有持续跟进，出现问题时，你才能及时发现，及时修正，才能确保最终达成目标。放牛班有春天，“放羊”班一般是没有春天的。
其次，理什么？如果把“管”理解为实践，那么“理”就是理论，只有实践与理论相结合，才能做到有目标，有方法，有效果。技术团队需要理什么？我也总结了以下四点。
1. 理目标。一般包括两个层面，由上而下的业务目标，比如产品里程碑，项目阶段验收节点，以及由下而上的技术目标，如服务端重构、Web页面优化、架构升级、系统运行监控、用户体验的提升等。
2. 理制度。为了实现或更高效地实现目标，需要通过哪些手段或环节，规定要做的活动，如例会制度、周（日）报制度、需求评审制度、设计审查制度、代码审查制度等。
3. 理规范。定义怎么来做，包括技术规范、流程规范两个方面。技术规范规定对某些常见的场景，通过什么样的方式来统一执行，如前后端对接的协议、异常的处理、日志的规范等；流程规范对一些活动，指定了什么人在什么阶段，应该做什么，怎么做，如转测流程，要求开发人员在转测时写转测文档，提供转测内容、影响因素等信息，测试人员测试完成后，提供测试结论，遗留哪些问题，是否同意上线等。
4. 理问题。任何一个团队都存在这样那样的问题，如果一个团队没有任何问题，那这本身就是一个问题（没有复制上文，还是一个字一个字敲的）。 要擅于去发现问题，并建立顺畅的问题反馈渠道。同时对问题的处理，不应终止于解决，一般遵循“发现问题 => 分析问题 => 解决问题 => 复盘问题 => 规避问题”的流程形式。
管理，既要管，也要理，在管的过程中理，理清楚后再应用于管，管与理相辅相成，融为一体，形成管理。管理是一个比较复杂的事情——只要与人打交道的就没有简单的事，既要注意方式方法，又要尊重人性，比如人都有爱自由的天性，对任何管理与约束都有一种本能的对抗，但同时人也有懒惰的天性，“放牛班”有春天，“放羊”班几乎不可能有春天。因此在管理与约束的行为上就要做到既给一定的自由度，又要有相对的控制力，有所为有所不为，做到管控有度。而这个“度”，可能就是所谓的管理艺术了吧。
有人把管理比喻为放风筝，我觉得挺贴切的。管理者是风筝的操纵者，团队成员就是风筝，管理者应该给团队成员一个像风筝一样发挥主观能动性的广阔的空间，把风筝敢于放向蔚蓝的天空，但同时也能把控它的方向，并随时可以把它收回来。管理能做到像放风筝一样收放自如，那就是真正的艺术了。
上面梳理总结了管什么、理什么的问题。那么对于技术团队的管理者来说，怎么管、怎么理，或者沿用上一文的口吻，技术管理者的自我修养，应从哪些方面去努力。我从提升领导力，构建团队文化，方法论三个角度进行了思考与总结。
3. 领导力
领导力我的理解就是带领他人朝着一个目标努力，组织协调最终一起达成目标的能力。技术管理者如何提高领导力，我认为可以从以下四个方面努力。
1. 技术能力。好的技术团队管理者，一定是该技术领域的技术专家，具备较强的技术能力。技术人员一般思想都相对单纯，谁比他厉害就服谁，他不懂的你懂，他解决不了的问题你协助他解决了，自然就能提升你的影响力与威信，这对你的管理会带来极大的帮助。好的技术能力，不仅要有技术的深度，还要有技术的广度。因为只有具有技术的深度，才能帮助下属解决他解决不了的问题，才能在团队遇到棘手问题时迎难而上，带领团队披荆斩棘；只有具有技术的广度，才能有效地制定团队的技术方向，并且在下属跟你说这个功能实现不了时，才能确认下属是在忽悠你，还是真的实现不了。
2. 业务能力。只有对业务具有较深的理解，才能更好地使用技术手段来服务于业务。一般我们做架构设计时，包括业务架构与技术架构，技术架构要以业务架构为参考，一切脱离业务的架构设计都是耍流氓。一些中小企业的技术管理者，去参加了一次阿里云栖大会，回来就跟团队鼓吹加人搞中台，对于中小企业来说，很多业务仍处于探索阶段，好多产品或项目可能在你中台还没搭建完就已经玩完了。从技术的角度，思路可能是对的，但从业务的角度，没有结合实际，没有考虑成本，效率等因素。不结合具体业务照搬别人的架构，轻则可能把团队拖死，重则可能把公司拖垮。同时只有对业务具有较深的理解，才能清楚团队是否在沿着正确的方向前进，才能了解评估每个人的工作成果。如果一个技术管理者，既不精于技术，也不去熟悉业务，每次开会都开成了对自己的答疑解惑会，并且一开就是两三个小时，那就真如旧社会老太婆的裹脚布，又臭又长了。因此，对于技术管理者，技术能力与业务能力，两手都要抓，两手都要硬。
3. 协同能力。协同能力就是协调各类资源（人力、物力、财力）的能力。包括向下协同与向上协同两个方面。向下协同能力，就是组织协调下属的能力，也就是带队伍的能力，如果把团队成员比喻成一个个齿轮，那么管理者就是既要充当拉动整个组件的皮带的角色，还要充当各个齿轮之间的润滑剂的角色，既要拉动团队整体运转，又要在齿轮之间出现摩擦与碰撞时及时添加润滑剂让其减少摩擦平稳运行。同时要知人善任，要知道把每个齿轮摆在什么位置，才能充分发挥各个齿轮的效用，从而整体动力更强，效益更高。向上协同能力，就是往上看，与领导处好关系的能力。很多时候，只有与领导处好关系，才能拉到更多更好的资源，这里的处好关系不是说阿谀奉承溜须拍马，而是做好工作汇报，让领导认可你，信任你，从而放心地将资源交付你。争取到更多的资源，才能帮助下属协调他协调不了的资源，团队跟着你干才有“肉”吃，才能保持工作的动力与热情。
4. 心胸宽广。所谓江山易改，秉性难移，上述三点都可以通过努力去外修，而心胸宽广，却是需要内修的一个方面。技术管理者，既要做到以技服人，以能力服人，也要做到以德服人，以心胸服人。什么是管理者的心胸宽广呢，我认为主要体现在三个方面，对事不对人，公私分明，有大局观。对事不对人就是要就事论事，秉着去解决问题，规避问题的角度来处理事情，而不要对任何团队成员存在任何偏见，一出问题就质疑指责别人的能力（有时候虽然确实是能力问题，但最好不要直接这么说，是很伤人自尊的），甚至三观。公私分明就是不要在管理工作中携带私人情感，对与自己关系好的下属照顾有加，对与自己关系不好的故意刁难，要公平公正，一视同仁。有大局观就是凡事要以实现终极目标为准绳，有利于此的就要宣扬与坚持，无关大碍的就不要斤斤计较，不要都争个对错。
所以，管理者的领导力是一个内外兼修的事情，既要有外修以提高管理的能力，也要有内修以提高管理的魄力。，
4. 构建团队文化
企业有企业的文化，一般包括企业愿景、使命、核心价值观等，同样，团队也应有团队的文化，我理解的技术团队的愿景、使命很简单，就是要服务于企业终极目标的同时，让团队有所成长。而技术团队的价值观就是团队行为的是非标准，哪些是应该做的，鼓励做的，哪些是不应该做的，禁止做的。如何构建团队文化，我总结了如下几个方面。
1. 互相尊重。管理者与下属的关系，虽然存在管理与被管理的事实，但是不要摆出一副居高临下、高人一等的姿态，而更多的是应该扮演一个服务者，协调者的角色。要学会倾听下属不同的意见，尽力满足下属合理的需求。有些管理者动不动就跟这个怼，跟那个怼，甚至在会议这种公开场合互怼，以此来彰显他的权威与地位，殊不知，这种做法不仅解决不了问题，而且有损管理者的威信，给人心胸不够宽广，能力水平有限的印象。如果出现公开场合比如会上个别下属不配合的情况，我认为正确的做法是先继续开会，并要求他会后留下私下沟通。私下沟通建议采用欲抑先扬的方式，先肯定他在某些方面做得很好，你是肯定的，但是在某某方面做得不对或不够，并且说明为什么不对或不够，希望能有所改善。这种方式最容易让人接受，也体现了管理者的管理魄力。总之，就是不论是管理者与下属之间，还是下属与下属之间，都要建立起一种互相尊重，互相理解的氛围。
2. 重视规范。规范就是对一些常见的场景定义一套统一的标准的做法，包括技术规范，流程规范。技术规范对一些常见的技术实现进行统一，如前后端接口交互规范，异常处理规范，数据库设计规范，日志记录规范等。流程规范就是在各个环节，什么人在什么阶段，应该做什么，怎么做，比如开发流程规范，要先设计再编码，设计需review，代码需review，各个review流程具体又是怎么做，都要有明确定义。规范是保障团队步调一致的有效方式，用相同的方式处理相同的问题，从而减少错误的出现，提高协作的效率。重视规范，既要制定规范，又要跟进规范的执行，没有制定，就无从谈跟进执行，没有跟进执行，就会流于形式或执行不到位，也无法对规范逐步进行调整、优化。因此，制定与跟进，两者缺一不可。
3. 结果导向。很多人认为，结果导向就是只看结果，不管过程，我认为是有点片面的。结果导向，既要看重结果，也要跟进过程。既要把控整体看成果，也要把控关键节点，跟进过程，就是本文开头所说“管”部分的管执行，管进度。只有跟进过程，你才能及时知道团队是否在按正确的方向前进，是否存在需要处理的问题，是否存在可能的风险，从而及时做出应对方案，保障最终导向一个良好的结果，我认为这才是真正的“结果导向”。“放羊”班没有春天。
4. 轻松高效。IT技术相对来说是一个具备一定创造性的工作，同样一个问题，可能有许多种解决方案，解决方案的优劣既依赖于解决者的能力水平，也依赖于解决者的状态，因此，营造一个轻松高效的工作环境，充分发挥团队成员的创造能力水平，也显得很重要。技术人员的管理不应像监督车间工人一样看你某个时刻是不是在偷懒，开小差，只要你把任务保质保量按期完成好，不论你是学习还是看新闻，刷微博，只要不影响其他同事或违反规章制度，我觉得都无可厚非。这可能也是“结果导向”的另一种解读。（然而不幸的是，事实上，很多老板或管理者因为无法做好规划，或者出于自身的焦虑，要求技术人员无时无刻都要在“工作”状态，甚至有事没事都要求加班，这种做法，往往也都难有较好的成效）
5. 主动担当。团队成员需要有主动担当，管理者更应有主动担当。管理者是一个团队或部门的领头羊，团队出了问题，管理者应承担最大的责任，应主动去为团队担当。如果管理者没有主动担当，其团队内部必然会产生背锅、甩锅的文化，所有人都怕背锅，所有人都在甩锅，从而导致难做的工作无人敢去做 ，导致各人自扫门前雪，莫管他人瓦上霜的局面。技术团队的管理者，从一开始就要做好“背锅侠”的准备，你是老大，你就是最大的“背锅侠”，只有你在前面承担压力，团队成员才会放手去干，并且你的担当，也会无形中对团队成员产生正面影响，提高他们自身的担当意识，把工作做好。
6. 学习分享。技术团队需要不断学习来提高，因此营造一种良好的学习、分享氛围，也是技术管理者的职责之一。团队的每个人，只有在团队中获得成长，才能获得一定的成就感，归属感，同时，团队成员成长了，也才能更好地服务于团队、公司，这是一个双赢的事情。技术管理者在平时应该尽可能地鼓励分享，组织专题学习，做好团队知识管理。
以上，是我总结的技术团队团队文化构建的几个方面，技术管理者应该在平常有意识地不断灌输，并以身作则，让团队按这种文化来协作、工作。
5. 方法论
光说不练假把式，以上主要是一些思维方向上的总结，那有没有具体的方法或套路来践行这些思路呢。结合自己的实践经验，我从制度、规范、工具三个方面做一点分享，但每个团队、企业面对的具体问题不同，可能其中具体的方式方法不一定适用，但是整体的思维方式我认为是相通的。
1. 制度。制度就是为了实现或更高效地实现目标，规定要做的活动。技术团队建立的制度可以包括例会制度、周报制度、需求评审制度、设计审查制度、代码审查制度、绩效考评制度等。团队的沟通交流很重要，例会制度可以给团队一个相互交流、了解的空间，问题反馈的渠道，同时也给技术管理者一个跟进团队工作状况，宣扬制度、决策的机会。所以每周一次或几次（根据自身情况衡量）的例会是有必要的。周报制度是团队所有成员对自己一周的工作进行梳理回顾，总结问题经验，同时对下周主要工作作出计划的活动，周报制度一方面有利于团队管理者了解每个人的工作进度、问题，及时干预保障目标的达成，另一方面也促使团队成员梳理自己的工作，做到有计划有步骤有进展。需求评审、设计审查、代码审查等制度，可以保障我们对需求的理解是一致的，设计是符合整体架构原则的，代码是符合编码规范并且没有低级错误的，从而提高我们的开发效率与质量。绩效考评制度主要是避免吃大锅饭，干多干少一个样，干好干坏一个样的情况，但绩效考评如果不与奖惩机制关联就有点形同虚设，这有时候可能不止是一个团队或部门能决策的，而是公司自上而下的制度规定，相对就较为复杂了。
2. 规范。规范就是定义怎么来做，包括技术规范、流程规范两个方面。技术规范规定对一些常见的通用场景，通过什么样的方式来统一实现，如前后端交互协议——接口返回的格式，是否REST风格，各个服务应该是一致的，再比如异常的处理——业务异常应该怎么处理，非业务异常应该怎么处理等，相关内容可参考我的其它技术分享文章。技术规范一方面通过对相同问题采取相同解决方法，来避免出错的概率，另一方面对一些通用处理进行封装，避免复制粘贴或重复造轮子；流程规范对一些活动，指定了什么人在什么阶段，应该做什么，怎么做，以保障工作或制度有序、有效地执行。之前的《软件项目研发流程该怎么规范》对项目协作流程做了基本的介绍，可查阅参考，《研发团队如何借助Gitlab来做代码review》对代码review流程做了详细介绍，也欢迎参考交流。
3. 工具。工欲善其事，必先利其器。制度有了，规范流程也有了，如何来保障高效地执行，就要依赖于有效的工具。比较常用的团队管理的工具有
- Confluence，知识管理工具，可对项目或部门的各类知识文档进行集中管理，如需求文档、设计文档、转测文档、上线文档，技术规范文档、技术分享文档、会议记录等等。
- Jira，任务、bug跟踪管理工具，基于所有问题可跟踪的原则，将需求任务、bug、优化都以任务单的形式录入Jira，集中跟进管理，并且Jira的Agile插件可很好地用于项目敏捷管理。
- Worktile，worktile应用于OKR管理可能比较适用，但对软件项目的版本管理总觉得不太友好（可能是不够熟练的原因），所以对于软件项目管理，我更倾向于Jira。
- Gitlab，这作为代码管理工具没什么好说的了，但基于它来实现代码review流程可能不是太多见，《研发团队如何借助Gitlab来做代码review》介绍了通过Gitlab结合钉钉机器人实现代码review的具体实践步骤，可参考交流。
还有比如像jenkins等提高开发部署效率的工具等等，这些工具或其它替代品我相信在很多公司都有相应的应用，这里就不详述了。另一个比较特殊的工具，是考核，我们都说考核只是一种工具，而不是目的，并且这种工具还是一把双刃剑，做得好，效果显著，做的不好，可能影响团队的士气，得不偿失。但是我认为对于一定规模的团队，比如十几人，几十人，不能没有考核，考核不一定很科学很完善，但只要秉着公平公正客观的原则，并辅以一定的监督，就是一个聊胜于无的事情。
制度、规范、工具是可以应用于团队管理的方法，总结一句就是用制度来规定要做什么，用规范来定义怎么做，用工具来让你做的更轻松。
6. 总结
没有人天生具备管理才能，只有在平时多观察，多思考，多实践，多总结，才能不断提高对管理的认知与水平。各个团队，各个公司面临的问题不同，也没有一个放之四海而皆准的模子让你去套，但是尽管面对问题不同，应对的方式方法各异，整体的思维方式还是相通的。技术管理者的自我修养，我认为先要有对管理的正确认识，然后从提升领导力，构建团队文化，方法论三个方面去实践，思考总结，调整，再实践，再思考总结，再调整的方式来不断提高。
以上，共勉。
作者：空山新雨
本文发表于微信公众号：“空山新雨的技术空间”，欢迎关注，一起交流企业技术实战与IT领域的点滴
原文地址：https://www.cnblogs.com/spec-dog/p/11302357.html