我是架构精进之路，点击上方“关注”，坚持天天为你分享技术干货，私信我回复“01”，送你一份程序员成长进阶大礼包。程序员
相信大部分人对于团队管理和技术管理在认知上，存在必定隔阂，无形之中会将【管理岗】和【技术岗】进行对立比较。安全
在国内一些大研发团队，通常会同时设置两类角色来更好地作团队运行管理。微信
-
研发经理/总监，主要负责团队价值输出和业务目标管理；网络
-
技术Leader/架构师，主要负责技术攻坚和技术架构落地。 架构
本文结合本人自身一些浅薄的技术管理认知，跟你们聊一下如何成长为优秀的技术Leader。框架
是否须要一个技术Leader？
首先，第一个问题：咱们是否须要一个技术Leader？ide
也许会有人反对这个角色，并以为优秀的开发人员能够本身作出决策，并作好部分技术Leader的工做。工具
即便存在以上这些完美的状况，在团队成员间公开谈论彼此，在达成一致赞成的解决方案以前讨论利弊，这些种种工做vs利益间微妙的平衡，或许须要技术Leader 这样的一个角色。学习
我以为不该该关注于这个角色是否应该存在，而最好将重点放在其职责可能会带来的收益上。测试
技术Leader 与每一个领导职位同样，糟糕的领导者会使事情变得更糟。
技术Leader 须要具有什么能力？
能够明确的一点是： 一个合格的技术 Leader 有责任来帮助团队的进步 。
做为该角色的人员，他应该具备很是不错的技术视野/经验以及良好的沟通技巧。他对项目或产品的技术方向负责（准确地说是对结果负责），并做为跨团队沟通的首选人。
对于大中型团队而言，Tech Leader 主要的职责包括：
1）指导项目的技术设计及制定开发规范
例如。咱们将使用什么技术，咱们将如何交付项目，咱们将使用哪些模式等。
2）分析风险和跨功能要求
分析风险意味着下降风险：咱们能够选择某种方法，仍是说有太多未知数。
在承担必定风险时，对项目的影响是什么？例如。介绍您在会议上看到的新技术。
3）指导/教练经验不足的新人
极可能在你的团队中有不一样的经验的同窗。一旦谈到项目成本，考虑匹配技能和经验时，它就变得颇有意义。所以，须要重视对经验不足新人的培养。
4）关注跨团队协助与沟通
一个项目团队包含各个相关联角色群体，研发、测试、产品、运营甚至需求业务方等等，其余角色同窗可能在技术上不如开发人员，他们将使用不一样的语言，技术Leader 将须要关注于这一点，并作好协调与沟通。
如何作一个合格的技术Leader？
正如职位所描述的那样，技术 Leader是一份包含技术和管理双重责任的工做，准确地说应该是：先技术，后领导。
那在实际工做过程当中，须要注意作好哪些点呢？
1）倡导技术创新与变革
倡导技术创新与变革，创建积极的思惟模式。当一个流程缓慢或者繁琐时，要尝试去改变它，使其变得更好。这样作的一种方法是使用 OODA 循环：
-
观察（Observe）
-
定位（Orient）
-
决定（Decide）
-
行动（Act）
为了正确观察缓慢或繁琐的流程细节，最好的方式就是成为其中的一员（例如：著名的现场主义），并体验与团队中其余人同样的痛苦。
你应该采起一种不断改善某种情况的心态。日本称之为“Kaizen”（改善法，其起源于丰田公司在生产、机械和商务管理中持续改进的管理法）。
在咱们的研发过程当中，但愿改进的是团队的效率和乐趣，以及软件项目的最终交付。
2）坦然面对失败与成功
-
事情有可能会失败，不用过度担忧失败
技术方案落地可能失败，项目开发建设可能失败、部署上线可能失败、系统重要监控点可能被遗漏、系统宕机崩溃可能会发生。
若是你已经为失败作好了十足的准备，那么应该会比较容易应对。
当事情失败时，不要寻找责怪的人！你是技术 Leader，有承担的责任和义务。
花费你的精力来解决手头的问题并从中吸收教训。固然，不要在一个坑里摔倒两次，若是你须要经历两次相同的失败来解决同一个错误，那么你应该是作出了错误的决定。
从失败中汲取教训，将塑造您的方向，并在将来作出更好的决策。
-
学会为成功喝彩
当团队有成就感时，成员们会感觉到快乐，同时积极的情绪会让后面的工做尽量作到最好。庆祝阶段的小成就很是重要，例如成功地冲刺或完成的功能。
当有人想出一个新想法时，也许是他们在会议上看到的一种方法或框架，若是这个想法得以实现，重要的是任何带有新想法的人都应该被承认。这是很是有益的，将带来更多的合做，创造力和开箱即用的思惟。
形式也许没那么重要，一顿小午饭，也许是一个团队建设都是一个很好的想法，一样能够凝聚一个快乐和积极的团队。
3）保持技术
技术主管有不少非编码职责，但不要忽视实践技术活动是很是重要的：
-
编写代码，进行概念验证，定义接口等，根据团队的成熟程度，您的参与会有所不一样。
-
进行代码CR，并审核您的代码。当新人参与项目时，我倾向于进行大部分代码审查，并且我会很是严格：我会编写致使 NullPointerExceptions 的测试，我会要求他们遵照惯例，使用单一责任原则，当心包装和命名等。我还将详细说明这些评论的推理和所作出的选择。这可能会挑战现有的工做方式并提升代码库的成熟度。他们必须作的更改（审核后）将很快变得更少。
-
确保技术愿景存在，并由团队共享。这一愿景须要符合客户的需求。客户需求将致使重要的限制，例如。关于重用（一个一次性的营销项目与多年的企业努力……但要注意这种类型的约束也可能会改变）。分享您与团队实现这一愿景的方式，将会对其采用产生巨大影响。尝试让团队参与到技术愿景中。并确保他们知道他们如何为实现这一愿景作出贡献。
-
密切关注代码的演变：一段时间后，您所作的实际编码量可能会更低，但您须要及时了解代码的演变。您须要了解系统及其技术限制。
大多数（若是不是所有）开发人员将乐于定义框架，提倡某些方法等。可是，一些非功能性需求（也称为质量属性）（如网络，安全性，部署和一致性）常常被忽视。
4）良好的时间管理
做为技术Leader，您应始终为您的团队服务；提问、支持、指导或作出决定。
-
技术设计 为团队（包括您）准备工做。确保清楚须要实施什么以及如何实施。这一般会考虑不少质量属性，如网络，安全性等。
-
业务：与客户交谈，查看他们的需求和目标，并将这些与项目的技术愿景相匹配。
-
项目管理：定义用户故事，估算，跟进。
-
代码：编写代码，进行代码审查等。
对于每一个人和每一个项目，分配的百分比显然会有所不一样。查看实际状况也很重要，由于这些能够帮助您了解所花费的时间。
5）成为团队导师
-
调解员：技术主管应该是调解员，便于讨论。当人们有不一样的意见时，你应该接受这一点。由于这意味着他们足够关心某些事情来讨论它。最后，咱们朝着同一个目标努力。每一个人均可以从别人的意见中学习。得到团队的意见并尝试达成共识。若是达成共识真的不可能而且须要作出决定，那就作出决定。不决定老是会引起更多的讨论。
-
导师：技术主管应该是开发人员的导师，当老师。当您查看代码或解释某些约定时，请务必清楚地解释您为什么以特定方式执行某些操做的缘由。
-
有效的受权：一段时间后，您的团队将采用某些最佳实践，而且须要较少（严格）的审核或更多人将进行审核。在这一点上，您还能够向更多开发人员提供用户故事的全部权。经过将全部权转让给开发人员，他们将很是积极地作好工做。技术主管不该该试图承担全部责任。技术主管须要确保某人承担责任。
-
匹配目标：将开发人员的我的目标与项目和组织的更大目标相匹配。这是专门针对性的动态指导。动态，由于目标能够改变。在匹配目标时，沟通很是重要：它会让人感到受到重视。
-
针对小组进行优化：团队中的我的很是重要，可是当难以找到共识时，您应该关注的是团队。合做良好的团队将表现得更好，表现良好的团队成员是快乐的成员。
一个好的技术 Leader：
-
知道何时给予输入
-
知道什么时候作出决定
-
知道何时退后一步，让团队得到更多的全部权。
分担责任，给予全部权，但同时要保持负责。
6）学会作评估
霍夫施塔特定律：即便考虑到霍夫施塔特定律，它也老是比你预期的要长。——Douglas Hofstadter
项目工时评估很难，若是你常常这样作，你会变得更好，但你仍然会有可能犯错。
做为 Tech Leader，可能须要在团队实际需求开发以前进行预估。更便于了解实现成本及优先级的安排调整。
为了达到这个目的，我建议使用三点估计，作一个乐观的（Optimism 简称：O），一个最好的猜想（Best Guess 简称：BG）和一个悲观的估计（Pessimism 简称：P），并使用这个公式：
（O + 4BG + P）÷ 6 //获得加权平均值
估计表明了团队执行的能力；不是你本身实施的能力。还要确保，你知道你的可交付成果。这可能不止包括代码和部署工具，例如：代码CR，接口文档等等
掌握评估是一辈子的旅程，它会让你不同凡响。合做方会将你与专业、稳定和高质量的工做联系起来。
7）擅长与外部沟通对接
非技术利益相关者使用的语言可能与开发团队的语言是不一样的。技术 Leader 必须找到一种以非技术人员能够理解的方式交流思想的方法。
这在 DDD （领域驱动设计）世界中，这意味着创建一种链接上下文通用语言。
与客户密切合做，尝试从他们那里检测需求，并不断地将他们的需求与正在进行的实施相关联。
做为技术 Leader，在外部沟通合做中做为关键联系人，与其余技术Leader 的沟通协做一样也不可或缺。
有不少理由将本身与其余技术Leader 联系在一块儿。
-
在我的层面上，它提供了向同行学习的机会：他们如何为团队提供意见，以及他们如何在角色的不一样职责之间分配时间。
-
在组织层面，应该考虑到是否有明确理解的整体目标。跟进技术架构设计的落地很是重要，以确保您的产品可以很好地与其余组件一块儿使用，并确保更大的系统保持一致。有可能依赖于其余团队的产品或其余团队的成员，要确保在编制项目排期时考虑到这些因素。
这种协调在较大型的组织或客户时是一个真正的问题。投入一些时间是必要的，以免超出您的控制范围的意外。
总结
做为技术Leader，也许除了以上列举的几项内容以外，还存在其余不少软性的素质能力。
欲求木之长者必固其本， 欲求流之远者必浚其源：
-
业务感知的背后， 是对商业社会的理解， 是对需求的洞察；
-
人员培养激励的背后， 是对人的理解， 是对人性的洞察。
拥抱文化差别，多样性很是宝贵。全部人都不一样，过着不一样的生活。
总结就是： 每一个人都是团队的一员，应该重视每一个人的意见 。
由于你团队的力量不是单个成员的才能，而是他们的合做，坚韧和相互尊重的总体效能的体现。
- END -
做者：架构精进之路，专一软件架构研究，技术学习与我的成长，关注并私信我回复“01”，送你一份程序员成长进阶大礼包。
往期热文推荐：
「技术架构精进」专一架构研究，技术分享
Thanks for reading!
本文分享自微信公众号 - 架构精进之路（jiagou_jingjin）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。