技术管理Note三：技术leader

技术leader说到底是一项领导岗位，他不一定是团队中技术能力最强的人，但一定是一个良好的沟通者、事务的推动者。除了写代码之外，还要从事组织管理、功能迭代计划、项目管理方面的工作。

技术leader不一定是公司职级上的某一级，而是任何一个高级工程师都可能要从事的工作，如果这项工作包括人员管理，则有以下几点：

1、周期性( 如每周)的一对一会议

2、周期性地在事业发展，目标进度、个人优缺点上进行反馈

3、确定要学习的领域，通过项目工作、外部学习和额外的辅导计划帮助他们进步。

即使不是直接进行管理工作，也要对团队成员进行辅导和指引。技术leader是从高级工程师向资深工程师转化的常见方式。技术leader需要花费至少30%的时间和团队编写代码，另外还要学习项目管理这项新技术。

技术leader不仅要影响同事，还要影响上级，其中一项挑战就是有时候需要减缓开发工作，集中精力解决技术债务，提高开发部署和运营的效率。你要向非技术人员，有时甚至是技术人员解释这一切，阐明利弊，以及此举的紧迫性和重要性。

所有伟大的技术leader都要知道的诀窍

要学会平衡，将自己的技术开发与团队相关的工作(如项目管理)进行平衡，不要一直依赖原有的擅长的技能，要花点时间学习新的技能。不要老让一些随机性的会议浪费了时间。

另外要保证团队成员有足够的时间聚焦于开发，帮助管理者合理安排会议，而避免团队开发者受到太多干扰。

成为技术leader

技术leader承担什么职责，取决于他处于项目周期的什么位置，他的职责不单单是编码和做技术决策。他要纵观整个项目，推动项目进行。

1、系统架构师和业务分析师

 思考交付项目，有哪些关键系统需要改变，哪些关键功能需要添加。还可以多想想项目相关的外部因素和问题。这个角色要求你了解项目的整体结构，知道怎么设计一个复杂的系统。还要深入了解业务需求，将它转化为软件模型

2、项目计划者

分解工作，将项目拆解成各个不同阶段的可交付成果。建立一种共识和一致的规范，让团队并行高效地工作，可以找团队中的专家或对该软件了解深入者，让他们提供细节上的帮助。分清软件工作的轻重缓急，对于关键的部分要提前做准备。

3、软件开发者和团队leader

技术leader也写代码，遇到挑战不要总是急着自己解决，向技术主管、产品经理沟通你面临的障碍。对于有些费时不讨好的需求，产品经理是会妥协的。如果你没有时间开发一些功能，要学会分派任务。

ASK CTO：

技术leader有着更重的职责负担，有些管理者甚至希望技术leader在胜任其他职责的同时，能够拥有和原来一样的代码产出。它不一定能迅速带来回报，却是迈向更高级别的阶石。

项目管理

敏捷开发教你分解项目，订立计划，持续地交付产品价值，而非一次性交付，它依然需要项目管理。

计划的价值不在于完美地执行计划，也不在于思考每一个细节，预知未来。而在于你致力于项目之前，能深入地思考这个项目，看看会发生什么，在力所能及的范围内合理地作出一些预测。计划的过程胜过计划的结果。

花时间讲解：

有时候我们总是以为别人，甚至更高级别的技术主管，理解了我们所做的技术工作，也许他们并没有完全理解，可以花时间去讲解，讲解问题域中的一些基本概念，以及我们技术观点背后的动机。

管理一个项目：

项目管理是这样一种工作，将一个复杂的目标拆解成更小的模块，并将这些模块按照最有效率的方式进行排列，思考哪些可以并行地去做，哪些只能串行地进行，并努力取出会导致项目延缓或者失败的未知项。这这一过程中，你可能会犯错，会遗漏掉一些未知项。

1、分解项目工作

 将项目工作分解、再分解，直到变成可衡量的基本单元。你不需要做所有这些分解工作，如果有些模块你不理解，需要请教这方面的人员。然后就是关注工作的顺序和分派。

2、排除困难，推进项目，解决未知项

3、运行项目，按实际情况调整计划

计划并不能做到精确评估，每个人都要被告知项目的当前状况，你可以划出已经达到的里程碑和未来要做的工作。

4、运用在项目计划过程中培养的洞察力管理需求的变动

你在项目计划过程中学到了很多，将这些思考运用在需求变动管理上。如果需求变动增加了项目的风险、需要拟定新的计划或者需要很多额外的工作，要明确表明需求变动的成本。如果项目是有硬性交付期限的，这些努力将对你有所帮助，将工作按优先级排序、在产品许可的范围内削减、简化工作，以获得功能、质量和交付时间的平衡。

5、项目接近尾声时重新审视项目细节

检查项目中还少了什么、进行测试和验证，将所有可能导致上线失败的因素都过一遍，将注意力集中在最重要的细节上。制定上线计划、回滚计划，还有别忘了最后的庆祝。

不知道自己是否想成为技术leader：

如果你觉得自己还没有成为技术专家，还有很多要学，那呆在技术岗位上没什么问题。如果你没有准备好，不要承担管理的职责。因为在更高的层级，哪些技术不够扎实的人很难被提升到管理层。

如果你发现自己个人的技术工作无法挑战你的能力，就试着学习其他技能，而技术leader的能力是值得尝试的。

走技术路线还是管理路线：

1、想象中高级技术人员的生活

你深入思考，解决具有智力挑战的有趣问题，并和其他能人合作。软件中的确有些琐碎事宜，但你主要是做有趣的工作，而且你可以选择做什么。你写代码、修复代码、提升代码性能。

因为你的资历，管理者会向你咨询开发问题，一切已准备就绪，你不需要管理细节。你参加一些重要的决策会议，而这不会打断你日常工作的思绪。初级工程师尊敬你，听取你的每一个建议，而他不会占用你太多时间。

你晋级不会放慢，你总能解决一些大的问题证明你对组织的价值。你努力工作，却很少加班，偶尔加班只是因为你陷入新功能和bug修复的思考而无法中断。

你写书、讲演并且创建开源项目，在行业中也小有名气，没人在意你的沟通技巧，因为你的话实在太重要了。组织中的每个人都了解你，理解你工作的价值，尊重你的选择。

2、高级技术人员的真实生活

当你参与一个合适的项目时，你会遇到新的挑战、学习新的事物，并且比管理者花费更少的时间在会议上。但针对一个项目，你也需要花时间推销自己的观点和方法，或者促使其他团队的成员使用开发好的内部产品。

你的晋升会非常慢，能证明你价值的重大项目很难找到。而你的主管也希望你自己告诉他机会在哪里。你努力了几个月甚至几年的项目可能会被取消。你会嫉妒随着他们团队一起成长的其他伙伴。

有人会崇拜听取你的建议，有人会嫉妒你的影响力，新人会占用你太多时间，或者害怕你。当要领导重大而有趣的项目时，你和同事间会产生一些竞争。

你的主管可能不喜欢你花时间在开源的事务上，他希望你用私人的时间去发展自己的这些兴趣。有时候他会忘记反馈，直到你投入了才告诉你新的方案。有时候他邀请你参加的会议可能会非常无聊而浪费时间。有时候他会要求你及时回复邮件、面试、参加code review。

但是，你大部分的时间还是会被花在项目构建上。

3、想象中管理者的生活

你掌控整个团队，你有决策的权力，并让人按照你的想法去做。你确保每个人都被公平对待，并且开除任何一个跨越红线，给团队带来不良影响的人。

尽管团队成员可能不同意你，但他们知道你尽可能地为他们好。他们参与你的一对一会议，乐于接受你的反馈。

对其他管理者，你可以对他管理上的问题提供自己的建议，他们乐于接受你的建议，并且发现你在管理上是多么富有成效。

你的主管给你提供许多的辅导，但很少规定你做什么。如果你想扩大自己的团队，他会同意给你提供更大的人。他给你的目标总是明确而少有变化的。你尽管责任重大，但还是有时间写博客，发表讲演，这有助于你团队的招聘，提高你在行业中的位置。

这一切都可以使你很快得到晋升，你的前途一片光明。

4、管理者的真实生活

你会发现让人们做事，不是告诉他们就行了的。

有时候一天中你大部分时间都在开会。随着团队的扩大，你碰代码的时间越来越少，最多只是写写脚本，调试下问题。

你可以做一些决定，引导团队的注意力，但团队成员仍未完成的产品roadmap，他们对事情优先级有自己的看法，因此有时你只是帮助他们决策。

你的主管有时会完全改变目标，这一切需要你向团队作解释。

你设立团队文化的标准，这是好事也是坏事，当团队成员以你为榜样时，这是好事，当团队映照出你的缺点时，这是坏事。

你团队成员不一定会自然的同意你，尊重你，喜欢你，权威的来源不完全是职称。当公司一切发展顺利时，生活当然很棒；当发展不顺利时，你很难让团队开心。当你告诉团队成员项目不顺利，不被提升，没有年终奖时，他们会不开心，很可能会离职。你如果没经过漫长的HR流程，甚至无法开除一个人。然而你的工作和辅导仍然会让团队内其中一部分成员感到开心和鼓舞。

其他管理者对你的建议不敢兴趣，反而觉得你侵犯了他们的地盘。你的主管并不认为你需要扩大团队，也没有解释原因。他的辅导技能很多有待提高，或者他担心你会超过他，他也不喜欢你经常出办公室讲演。如何在领导的同时不削弱你同行和boss的权威，这个比你想象中的要难办。如果你能扩大自己的团队，你也将获得提升，你的路也就更清晰了。当你发现团队中某位工程师赚得比你还多时，你可能会情绪失控，所以你最好想办法尽快组建一个更大的团队，否则，所有这些压力和废话有什么意义呢?

管理或者技术路径，都有它的优势和不足，如果你愿意，可以转换自己的路径。

好的管理者,还是坏的管理者:流程沙皇

流程沙皇认为,如果流程被正确地实现并且执行,可以解决团队中所有的大问题.流程沙皇痴迷于敏捷、scrum,或者瀑布式方法.他们对于on-call如何工作,code review如何进行,发布如何操作,有非常准确的看法。他们对细节很细致,清楚规则并且准确地执行.

流程沙皇在QA、项目管理之类的团队中比较常见,这里,对具体工作进程的衡量是被推崇的。他们在项目管理团队中是很有价值的,因为他们确保没有任务被遗忘,所以事情都在正确的轨道上。

当人们不按照流程进行时,他们会感到很不自然。他们把所有的问题都归咎于没有按照最好的流程进行,却不承认灵活性的需要,还有,有些变化是不可避免的。他们总是关注于容易衡量的事物,如工作时间,却忽视了一些细微之处。

迷信“工作中合适的工具”的工程师在成为技术leader之后可能会成为流程沙皇,他们寻找正确的工具解决计划、时间管理、工作优先级方面的所有问题.他们会试着停下所有工作来寻找最佳流程,或不断推送工具和流程来解决团队中越发糟糕的人际互动。

流程沙皇的反面并不是完全放弃流程，而是明白流程必须满足团队和工作的需要。让人感到讽刺的是，“敏捷”总是以一种死板的方式被执行。敏捷开发四句宣言总结了健康的流程领导方式：

个体与交互 胜过 过程与工具

可以工作的软件 胜过  面面俱到的文档

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

作为技术lead，不要希望通过流程来解决由沟通和领导鸿沟导致的问题，流程改良有时候是有益的，但他并不是银弹，两个出色的团队其流程和工作方式也不尽然相同。请寻找可以自我调整的流程，如果你发现自己扮演了一个监督关于谁破坏规则，违反流程的工头角色，请看看流程本身是否可以改进，使其更容易被遵守。这一角色浪费了你的时间，而自动化可以让规则更清楚。

作为流程沙皇的主管，有时要让他能坦然接受模糊性定义，痴迷于流程多是因为害怕失败，防止意外。要让他有一定的安全感，不要过度害怕失败和不完美，放松一些，容许生活中一丁点儿的模糊性。不要让他花费所有的时间在流程和工具上，并让他相信他们的团队不会因为不遵循流程而被处罚。

如何成为出色的技术leader

1、理解架构：

如果你不能理解你正在改造的架构，是不能很好地领导这些项目的。花时间去理解他，学习他，产品是怎么样的，核心逻辑是什么，他们的联系是什么，数据如果保存，如何流转等等。

2、做团队合作者：

不要总是做系统中有趣的工作,看看系统中棘手、无聊、恼人的部分,看看是否能分离这部分,其中你可能发现流程中的瓶颈,在无聊、令人沮丧的项目中,你也能发现一些东西。也不要一直做无聊的工作,你要给团队成员成长的机会,但你也是高级技术人员,只要有时间,偶尔给自己分配有趣的、更有挑战的工作。

3、领导技术决策：

你将参与团队中绝大多数的技术决策,但不是未征求团队的情况下决定所有事项,不然,当事情变糟时他们会抱怨责怪你。也不是将一切决定交给团队,不然很多可以快速决定下来的事项将拖延不决。

有些事需要你决定,有些事需要专家决定,有些事需要整个团队决定,不管什么情况,都要搞清楚问题所在,并沟通出结果。

4、沟通：

就生产力而言,整个团队的生产力优先于你个人的生产力。这意味着你要花费一些时间成本在沟通上,有时候不是让团队每个成员参与会议,而是你代表团队参加,沟通他们的需求,并从会上带回来一些信息。将成功的领导者和平庸的领导者区分开来的一个普遍特征就是沟通技能.他们写得好,读得仔细,在站在众人面前发言,他们专注于会议,不断测试他们和团队的知识局限性。

要锻炼自己的沟通技能,沟通过程中不要忘记倾听,让别人参与沟通,重复他们的话,确保你已经理解他们。听听他们说什么,用自己的语言复述一次。你还需要成为一个不错的会议记录者。不管你以后走的是技术还是管理方向,如果你不能很好地沟通和倾听,你的职业生涯将会面临不少挫折。

java达人

ID：drjava

（长按或扫码识别）