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

一 、架构师与技术管理者

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

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

二 、向下管理

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

1. 领导力

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

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

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

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

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

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

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

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

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

2. 激励

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

• 学习成长

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

• 技术工具

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

• 发展方向

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

• 认可程度

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

• 工作环境

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

• 直接利益

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

• 管理风格

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

3. 绩效管理

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