转型架构师之路——郑天民

一 、架构师与技术管理者

架构师是一个综合性的角色，需要熟练掌握架构设计方法和开发技术，同时具备良好的组织管理能力。在第2篇《深入剖析架构师角色》中我们分析了架构师的主要职责和所开展的活动，无论这些活动是偏向技术还是偏向管理，架构师都处于一个特定的环境中，活动的开展也不是架构师一个人的战斗，需要与他人进行协作和交互。因此，除了各种专业的业务技能之外，架构师还需要掌握一些额外的技能。

在很多时候，我们也把架构师归为一种技术管理者角色。技术管理者的工作包括设计行业与解决方案、推进业务结构与产品化、架构设计和技术创新、开展软件项目管理和研发过程体系建设等。视环境的不同，架构师也会在这些工作中发挥一定的推动作用。我们把这些推动能力统称为软能力，并从向上管理、向外管理和自我管理的角度出发简要讨论架构师所应具备的软能力。

二 、向下管理

向下管理是组织管理最重要的一个方面，作为技术团队的负责人，通常技术管理者会花费大部分时间在向下管理。这里“向下”的含义不仅仅是指你的直接下属，在大中型团队中，还可能包含你的间接下属，也就是说技术管理者不仅仅需要管理下面的人，也需要指导下面的人去做向下管理，从而提高整个团队的工作效率。管理应该有好的思路和方法论，但期望这些思路和方法论能按照自己想的那样发挥效果，通常只是一种理想。在职权的范围内充分利用人力和客观条件，并以最小的成本办成所需的事情还需要团队负责人的领导力（Leadership）。同时，领导力和激励（Motivation）是两个相辅相成的因素，对于软件开发这一特定领域而言，领导力最主要的表现或者说最能发挥其作用的切入点是激励。

1. 领导力

业界关于领导力的定义有很多，我们这里引用大师 Gerald M. Weinberg 的说法，即所谓领导力，就是创造这样一个环境，每个人都能在其中发挥出更多的能力。从这个定义上讲，领导力就是催生其他人身上的创造力和生产力。

领导力针对的对象一般也可以分为人和过程，其目的是创造一种特定的环境，对环境中的人做出反应，向他们提供选择，并给他们一定的自由度。我们对领导力进行梳理，会发现其首先体现在用人上，找合适的人并进行管理是领导的第一步。其次，我们会形成团队的价值观，并希望团队中的所有成员共同遵守，团队负责人在形成这种价值观时会起到主导作用。同时，提出优化流程的建议并付诸于实施能显著提升领导力，团队成员会在优化的流程中发挥越大的作用，领导力也就会产生越大的影响力。最后，要注意个人在演讲、聚会、会议上的表现，努力提升个人魅力。

对于提升领导力过程中应该遵循的原则，我们有我们的思路。我认为信息透明和授权是领导力相关的两条核心原则。

信息透明在这里可以理解为包含自我透明化、项目透明化和关系透明化三层含义。自我透明化指的是表现自身的优点和缺点、承认自身的实力和兴趣并积极参与上下级沟通，让别人了解你是让产生信任的基础。很多技术人员由于工作环境以及自身性格原因，在自我透明化上存在明显缺陷，难以成为一个技术负责人，或者即使成为团队的负责人之后，因为缺少与团队成员的相互了解导致领导力大打折扣。

项目透明化主要体现在让领导看到你的困难，对时间和进度上的透明度做把控，不能太透明也不能不透明。同时，对项目中技术体系进行合理的的透明化有助于各种外部干系人对技术团队的了解，提高协商过程中的筹码。创建自身的风格并保持不变，在做事情之前进行有效倾听，同时提供让别人透明化的场景和机会是关系透明化相关的实践方法。

授权往往是技术人员所不擅长的一个领域，很多技术负责人在紧急情况下都倾向于自己出手，而忘了整个团队。身体力行，让别人看到你在做事情是提升领导力的一种方法，但在有些场景下，通过授权让团队成员去完成有难度的任务恰恰更能提升领导力。建立信任关系是授权的第一步，需要在平时进行不断经营。而对某个具体场景，在授权之前确保团队成员与团队负责人达成共识。

信息透明化的具体实现可以借助于一些工具来展现可视化信息，而授权的切入点在于使问题简单化。无论采用何种原则，尝试在团队中推销自身的想法，并对核心问题和痛点保持关注。

追求平衡性（Balance）可能是提升和发挥领导力过程中最重要的策略，也可以理解为一种思维模式。对于软件开发而言，围绕平衡性有两个概念需要展开，一个是成功，一个是完美。对技术人员，很多时候我们会追求一种完美，对一个设计进行反复提炼、重构并试图找到所谓的最优解是很多技术人员的做事风格。而对于管理人员而言，从思维模式上更倾向于确保项目和产品取得成功。成功和完美有时候可能会成为一对矛盾体，因为成功的事物不一定完美，完美的事物也不一定成功。技术人员为了追求完美导致项目延期，或者管理人员为了追求成功使用各种非技术手段的现象并不少见。而对于团队负责人而言，我们认为很多时候需要做到结果导向，也就是需要在成功和完美之间追求一种平衡性。

领导力的表现形式有很多种，如带队育人的教导力、合理分配资源的组织力、综合思考的决策力、人心所向的感召力等，技术管理者自身能够快速成长的能力也是领导力的一种表现。

2. 激励

业界关于如何进行激励存在一些主流的认知体系，尽管这些体系偏于理论，但作为技术管理者而言，仍有必要充分理解并进行针对软件开发领域的思考。激励的主流理论包括马斯洛需求层次理论、麦格雷戈的 X-Y 理论、赫茨伯格的双因素理论等。掌握激励理论的目的是为了实施激励措施。因为基本的激励理论面向所有人，所以我们需要针对软件开发人员做进一步分析才能获取相应的激励措施。针对软件开发人员，我们认为典型的激励因素包括以下几个方面：

• 学习成长

在软件行业，技术变更如此迅速，没有专业上的持续学习和成长，就可能很快被淘汰。这一点技术人员心知肚明，所以追求学习并不断成长就成为首要激励因素。对技术人员进行学习成长上的激励，最基本的手段就是营造良好的学习环境。提供进修机会、提供培训和自学的途径、购买专业书籍、为每个新手开发人员指定导师、分配开发人员从事可以扩展其技能的工作都可以是行之有效的工作设计方式。尤其是人员培训，需要有人员培训计划。从入职开发，提供全生命周期培训，不应该只包括技术类培训。确保定期组织，形成一定模式并鼓励全民参与。如果有条件形成专业培训讲师团队，对培训讲师进行考核，并提供一定奖励和报酬。

• 技术工具

技术提升当然也属于学习成长的一方面，这里单独抽离出来是想强调为技术人员提供先进的工具、框架、技术体系上对他们的激励作用。这可能是最容易做到的一项激励措施。确保为技术人员提供专业的开发工具，并在技术框架的选型和技术体系的建立上采用目前最流行的相关框架和架构有助于激发技术人员的开发热情。

• 发展方向

对于那些已经或者即将处于瓶颈期的开发人员而言，为其指明发展方向并提供相应的发展机会将是一项非常有效的激励措施。以开发人员向技术管理者发展为例，开发人员比管理人员更重视技术管理的机会，针对成为技术管理者这一目标，指派每个人分别作为业务模块、数据库、报表等某个特定领域的技术负责人，或者指派每个人分别作为持续集成、代码重构、系统集成等某个任务的技术负责人都是工作设计上的考虑点。

• 认可程度

技术管理工作的一个重要组成部分，是确保技术人员的工作得到认可。技术开发不像营销，很少有直接的物质奖励，要做更多精神层面的激励。技术人员内心渴望被认可，认可的场合可以是公开场合也可以是私下场合，认可的方式可以是简单的口头称赞，也可以是具体某件事情的详细展开。对技术人员工作的认可，将对其工作态度、职业道德以及其他开发人员产生激励效果。

• 工作环境

工作环境对技术人员的激励在互联网行业表现非常明显。无论是灵活打卡或不打卡制度、加班补助制度，还是上文所提到的学习环境等，都对技术人员有良好的激励作用。这些激励因素往往是一种相对的附加效果，没有属于正常，但有的话就能让技术人员高度认可并更加容易融入到工作环境中。

• 直接利益

直接利益一直是个人绩效的重要因素，传统意义上的利益就是指工资、奖金、股票、期权等。高工资和可能拿到的高奖金是最基本的激励因素，但这需要建立在个人以及团队绩效的基础之上。

• 管理风格

团队管理者的管理风格可以说对开发人员的工作表现有至关重要的影响。管理风格的一大表现形式就是对技术的重视程度，技术人员通常希望得到技术上的尊重并希望有一定的自主权，当开发人员为实现自己设定的目标工作时，会比为别人更加努力的工作，这就是从成就感的角度来设定激励目标。体现在工作设计上，项目中的开发进度计划首先应尽可能让开发人员自己把握，这也是一项可以实施的激励措施。

3. 绩效管理

作为向下管理的重要一环，绩效管理是对团队成员进行工作评估和激励的过程。国内中小型研发团队往往是从作坊式开发模式中发展而来，通常对绩效管理的意识比较淡薄，或者干脆没有绩效管理的理念和流程，管理层凭自身主观判断确定员工的绩效结果。当团队发展到一定规模时，管理层发现靠自己的判断已经不行了，所以就要搞一下绩效管理。这时候的绩效管理可以理解为，团队需要进行过程改进的一种预示。我们都知道过程改进领域有一个 PDCA 环，而绩效管理本身实际上也是一个 PDCA 环（见下图）。

过程改进如同项目计划需要进行阶段性规划和控制，绩效管理也是一样。通常绩效管理具有周期性，即以一段时间为限形成上面的 PDCA 环，实际操作过程中以一个月或一个季度作为基准的情况较多，最好不要超过一个季度，否则 PDCA 环的时效性将大打折扣，下文统称这一周期为绩效周期。结合绩效管理的 PDCA 环及其周期性，绩效管理的规程如下：

• 制定绩效计划

目的是根据团队的项目和研发任务，在绩效周期开始时确定绩效周期内的个人工作计划，确保为绩效分析和沟通提供输入。主要角色是团队中的每一个人。主要步骤上，团队成员根据绩效周期内团队整体工作目标进行分解和细化，确定个人的绩效计划，并形成《个人绩效表》。

• 收集绩效数据

目的是在绩效周期结束时根据个人在绩效周期内的工作情况，收集绩效数据并形成绩效结果，为绩效沟通提供个人的自评。主要角色同样是个人。主要步骤上，团队成员基于在绩效周期初确定的《个人绩效表》中的绩效计划，结合绩效周期中的具体工作完成情况进行自评，并填充《个人绩效表》中的自评绩效数据。

• 评估绩效

目的在于根据绩效周期内的绩效数据以及团队整体计划对团队成员的绩效进行评估，从而明确绩效结果，为绩效沟通提供他评。个人直属上级会主导这一过程。主要步骤是：团队成员的直属上级基于《个人绩效表》中的绩效计划以及绩效周期中的具体工作完成情况进行他评，并填充《个人绩效表》中的他评绩效数据，他评数据中包括对绩效的整体评分。

• 沟通绩效

目的是根据绩效计划、员工自评和上级他评，对结果进行分析并明确改进思路和措施。个人及其直属上级会和人事专员一起参与这一过程。主要步骤为个人及其直属上级进行面对面沟通，对该绩效周期内的结果展开讨论，主要针对其中存在的问题触发团队成员自身的思考并找到改进的切入点。

三 、向外管理

在任何团队中，任何场景都可能会有“扯皮”现象。扯皮现象有利有弊，很多结果有时并不是做出来的，而是协商出来的。有些事情看上去很难，但一协商发现并没那么难，而一点小事如果没有协商可能变成一件大事。

对于协商，换位思考或者说同理心可能是消除协商过程中出现过多扯皮现象的一大原则。站在对方的立场上思考问题，然后再抛出符合对方立场的言论，并能引导到己方利益的观点，这需要技巧性，这种技巧性的培养需要循序渐进的把握协商过程，而不是对任何问题都直奔主题。

同时，在协商过程中，不要掩盖问题，尤其是对双方都有影响的问题确保在协商过程中明确的提出来，并得出确切的结论。最后，关于协商原则记住一句话，态度要和蔼但立场要坚定。

有一些障碍会导致协商过程的正常推进，其中包括组织中的政治因素，对架构师而言，可能也会面临很多技术性障碍。面对障碍，尽量寻找双方的共同点，并采用“足够好”而不是“最完美”的方案。

我们把整个协商过程分成协商前、协商中和协商后三个环节。其中，协商中的过程具体问题具体分析，对协商前和协商后则可以采取一些通用的手段和策略。在协商前，最重要的是明确此次协商的目标，包括最低和最高目标。梳理哪些内容是可以或不可以协商的，明确相关干系人，团结一切可以团结的力量。另一方面，充分的准备是协商成功的一大关键，关于这次协商的数据、文档、环境等因素都在考虑范围之内。对于某些预想中比较难以协商的内容，协商前对关键干系人或某些关键文件数据等进行私人或内部团队之间的预演也是必要的一些环节。

当协商完成之后，不管协商结果如何，记录是必不可少的。对于本次协商中重要的决议确保进行文档化和邮件化，如有必要也可以纳入版本控制系统之中进行管理。对决议的执行过程中，明确决议的边界，执行自身相关的任务。但对于架构师而言，还要尝试学会委派下面的人进行任务执行。

四 、自我管理

自我管理也是一种管理，而且执行起来可能比上面几个管理都要困难。

作为技术管理者，最重要的工作并不是冲到一线做各种技术研发，而是要处理技术以及一些非技术相关的各项事宜。所以处理事情是自我管理中除了个人风格外的又一个重要主题。处理事情需要做到对时间的合理利用以及对事情的管理和跟踪。

技术管理者作为整个技术团队的统一入口和出口，在对每件事情所持有的态度上应该有基本的原则。

• 重要且紧急的事情应该立刻去做
• 重要但不紧急的事情可以有计划的做
• 不重要但紧急的事情应该学会委托他人去做
• 不重要不紧急的事情就尽量别做

以上通过时间管理的理念对事情的优先级做了分析，时间管理的关键在于有一份每天的待办事项清单，同样的，跟踪这些待办事项也很重要。正如你向上级汇报一样，需要时刻关注工作完成情况。一般需要维护日常任务清单，这份清单可以通过一些电子化工具在你的工作电脑或手机移动端进行提醒。

欢迎Java工程师朋友们加入Java进阶高级架构群：795632998

本群提供免费的学习指导 架构资料 以及解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导