软件架构师培训

软件架构师培训（精选9篇）

篇1：软件架构师培训

职责:

1、主要负责核心系统的架构设计，框架搭建以及核心模块的开发;

2、负责解决后端系统中的性能瓶颈与技术难题;

3、负责核心系统的技术方案的编写与评审;

4、负责公司技术标准的制定与评审。

任职资格:

1、本科以上学历，专业不限，5年以上Java开发经验，2年以上架构设计经验;

2、精通JAVA的Spring、Mybatis等主流框架，熟悉Hadoop、ZooKeeper等分布式架构和系统;

3、熟悉Oracle、Mongo、Redis等关系与非关系型数据库;

3、知识面广，专研技术，对解决有挑战性的技术问题充满激情;

4、有独立分析和思考问题并加以解决的能力和习惯;

5、有较强的文档编写能力，能独立完成技术方案、设计方案的编写;

6、了解基础的数据结构和算法，对常见问题，能正确运用合适的数据结构和算法加以解决;

7、熟悉两种以上流行的框架，且不停留在单纯使用的层次，必须对框架的实现原理、应用场合、使用限制有基本了解;

8、善于沟通，团队协作精神良好，乐于分享经验与感悟，促进团队共同进步。

篇2：软件架构师培训

1、面向公司战略目标诉求进行架构设计、规划及管控，支撑变革蓝图与变革路标设计;

2、主导公司级项目的业务架构及业务解决方案设计，负责业务需求的转化及2B流程有效拉通;

3、支撑变革、流程、信息化项目中架构的评审，实现架构原则和标准的落地及日常执行;

4、参与公司IoT架构设计与项目实施工作;

5、变革与流程信息化治理体系建设与优化，引导变革解决方案建设实施，提供公司架构治理的方向和策略建议。

任职资格:

1、本科及以上学历，理工科背景优先;

2、优秀的沟通和理论联系实际的能力，精通企业架构及流程管理方法论;

3、熟悉房地产行业流程管理***实践和业界流程管理最新发展趋势优先;

4、8年以上工作经验，3年以上大中型企业的变革、流程、过程改进部门工作经验或咨询公司流程管理咨询经验，5年以上房地产行业相关领域工作经验优先;

5、拥有或曾通过以下一种或多种认证(或同等认证)者优先：

- TOGAF Architect

- PMP

篇3：软件定义服务架构研究

随着国民经济发展,“互联网+”战略的深入推进,中国的经济发展模式正在发生深刻的变革,信息技术服务成为国民经济转型的重要助推器。与此同时,更高技术水平、更易于被传统产业使用的信息技术服务成为核心需求。

云计算、大数据成为新一代信息技术服务的主要支撑技术,商贸领域的信息技术服务云化平台(阿里、京东等)已经在中国获得了重大发展,工业领域的信息技术服务云化平台(西门子的Mind Sphere、GE的Predix等)已经开始在传统工业强国出现。所有这些平台都具备的重要的特点包括:云计算、大覆盖、大数据、应用软件开放。其核心理念是建立智能化的服务平台,形成开放式的API接口标准,通过汇集大批量的软件工作者,以开发充分利用平台能力的各类软件应用,来定义平台所承载的服务特征,释放平台能力与生产力,即“软件定义服务”。

Gartner 2014年度十大战略技术报告中就已经将“软件定义一切”列入其中。该项技术定义囊括了在基础设施可编程性标准提升下不断增长的市场势头、由云计算内在自动化驱动的数据中心互通性、Dev Ops和快速的基础设施提供等。而发展到现在,“软件定义一切”中已经有效落地的主要包括“软件定义网络(SDN)”、“软件定义数据中心(SDDC)”、“软件定义存储(SDS)”和“软件定义基础架构(SDI)”。

国内IT基础设施的发展总体上来说尚处于跟随世界先进水平的阶段,上述各类SDx在国内的华为、浪潮、曙光、联想等公司也都有相应的产品和解决方案。而本文重点描述的“软件定义服务(SDSvc)”逻辑,迄今为止,未见国内外其他组织提出。

2“软件定义服务”定义及目标

按照《信息技术服务服务管理第3部分:技术要求》国家标准编制组(简称“《技术要求》编制组”)的定义,软件定义服务是一种为了灵活调度服务要素和简化配置服务产品而虚拟化服务要素的方式。在ITSS架构中,服务要素由人员、流程、技术和资源构成。“《技术要求》编制组”认为:

●ITSS服务四要素具备通过时空复用和策略配置等手段被虚拟化使用的能力;

●在此基础上,人们有机会提出和设计“软件定义服务”架构来帮助服务组织优化其服务要素配置和更好地管理其服务产品交付;

●同时,由于服务产品生产与交付相缠绕的特性,软件定义服务架构有可能发展成为服务管理的最佳技术支撑架构。

《技术要求》编制组认为,“软件定义服务”架构在国家标准层面要达成的目标如下:

●以国家标准的战略高度,集合一批有能力和有意愿的企业和个人,共同研究创新“软件定义服务”架构,以期在信息技术服务领域涌现出具有技术领先的一批成果,提升信息技术服务领域的技术水平;

●在信息技术服务领域,建立基于该架构的服务工具互联互通标准体系、围绕服务产品管理和配置的中央智能管控标准体系、实现服务要素虚拟化的抽象描述标准体系。

3 架构设计和描述

在研究了大量国内外组织所提出的多种新一代信息技术架构的基础上,《技术要求》编制组已经就“软件定义服务”架构进行了初步的架构设计和探索。整体设计包括了顶层架构、技术平台架构、接口统一架构三大块,并给出了可参考的软件基础逻辑架构设计。

3.1 顶层架构设计

目前的架构顶层描述见图1。

注:图1中的REST(Representational State Transfer)是指表述性状态传递,由Roy Fielding博士在2000年博士论文中提出的一种软件架构风格。它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。

在顶层设计中有如下四个重点:

(1)通过服务平台层的要素虚拟化管理能力实现服务要素的抽象虚拟化;

(2)通过软件控制层中的可编程组件(呼叫中心软件、策略中心软件、自动化智能引擎软件和软件定义服务整合器软件)实现对虚拟化后的要素整合和调度的能力,同时向软件定义层的业务应用提供可编程的SDSvc支撑性服务调用能力;

(3)软件定义层为今后的以SDSvc为核心的服务业务软件提供了扩展空间;

(4)平台API和应用API是实现各层和各类架构组件间通信和服务调用的主要组件。

3.2 技术平台架构

依据上述顶层设计和参考国际标准的SDN架构,《技术要求》编制组还设计了更加详细和清晰化的SDSvc技术平台架构(见图2)。

注:图2中的RPC(Remote Procedure Call Protocol)是指远程过程调用协议,是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。

该技术平台架构描述了顶层架构中软件控制层和服务平台层实现SDSvc能力的软件架构,未包含软件定义层的内部结构,仅为软件定义层提供了服务应用平台API的支持。

在图2所示技术平台架构中,目前考虑的核心处理协议是服务计算要素协议。《技术要求》编制组希望该协议能够实现对ITSS服务四要素在服务产品设计和交付中的动态计算与分配,成为构建软件定义服务架构中的一个核心支撑协议。同时,该技术平台架构还保留了今后增加其他服务要素计算协议的空间。

3.3 接口统一架构

《技术要求》编制组针对接口API设计了如图3的接口统一架构。

在该接口架构中,各类要素管理底层应用通过消息总线完成以下两类信息交互:

(1)各要素管理底层应用之间的信息交互;

(2)各要素管理底层应用与服务的生命周期调度管理器、服务整合器和服务管理应用之间的信息交互。

3.4 可参考的软件基础逻辑架构

为了向本架构的使用者提供可以参考的软件实现方式,基于前述各层架构,并参考Open Stack等新一代信息技术软件基础设施的逻辑架构,《技术要求》编制组设计了如图4的可参考架构。

在该架构中,最基本的软件逻辑架构提供五类服务:

a.SDSvc身份服务;

b.SDSvc对象服务;

c.SDSvc服务产品模版服务;

d.SDSvc服务要素计算服务;

e.SDSvc门户应用服务。

基础业务逻辑由中间的b、c、d三类核心服务协同完成,通过要素计算服务实现抽象化,虚拟对象存储于对象服务数据库,模版服务完成对象的调用组装形成服务产品,模版计算依赖于要素计算服务。

a和e两类服务均为完成业务逻辑必不可少的支持性服务,其中身份服务提供统一认证,门户应用提供服务整合能力。

目前,《技术要求》编制组已经形成了初步的架构研发团队,涵盖了多家甲方单位、服务工具的乙方单位和咨询、认证单位。在各单位的协同下,初步形成了本文所述架构体系。后续工作还将征集更多的甲乙方单位,推动架构向足够技术含量、更易于甲方落地和解决实际问题的方向发展,并在适当时机启动架构落地验证的相关工作。

4 架构作用及影响

新一代信息技术包括云计算、大数据、主机虚拟化、网络功能虚拟化(NFV)、软件定义网络、服务质量和体验质量管理、物联网等,这些技术的基础特征包括:(1)逻辑单元与物理单元的解耦化;(2)控制智能的集中化;(3)大规模可编程;(4)数据智能化。

这些技术特征都来自于业务上更强智能、更易于管理、更高性能和更低单位成本的要求。新一代信息技术服务与此相适应,也具有更敏捷、更智能、更细管理粒度和更多协同的特征。典型的新一代信息技术服务模式是运维领域的Dev Ops模式。Dev Ops相对于ITIL而言,更加强调敏捷环境下小而频的变更管理,这就需要超越以往的开发与运维之间的协同,支撑更敏捷和更细粒度的版本管理工具,更智能的决策支撑能力,更强调工具和协同对于运维服务的支撑作用。

“软件定义服务”的目标是成为引领性标准,这与之前的运维标准等以经验总结为基础不同。通过形成引领性标准,能够快速形成一批有效提升服务供应商技术水平的成果。而引领性标准的研制工作必然离不开验证落地环节,这一环节能够在恰当的客户处有效形成应用成果,从而一开始就能够打通甲方快速应用标准的障碍。

通过架构的研制,信息技术服务产业有机会在服务要素的抽象虚拟化方面领跑世界,改变产业形态、提升产业技术水平和效率。依托中国市场的庞大需求,通过新一代信息技术服务催生出世界级的信息技术服务提供商。

参考文献

[1]颜凯,张军.IT服务管理技术要求标准应用研究[J].信息技术与标准化,2016(1-2):35-38.

[2]Thomas D.Nadeau,Ken Gray.SDN:Software Defined Networks[M].US:O'Reilly Media,Inc.,2013:4.

篇4：做个架构师吧

可你一定知道乔布斯，他的头衔就是首席架构师；

同样假如你有幸与丁磊交换名片，

也会看到他的头衔是网易公司首席架构师，

而不是其他你所熟悉的种种抬头。

似乎悄然间，架构师这一职位变得崇高无比，成为职场上最让人羡慕的职位。

这时候你会更加迷茫些了，是不是只有成为乔布斯、丁磊这样的才能称之为架构师，架构师是不是只存在在于软件技术领域？架构师实际上就是软件的总体设计师。打个通俗的比方：邓小平是中国改革开放的总设计师，用时髦的话语来形容就是邓小平是中国改革开放的首席架构师。架构师的形成一定是在实践中积累起来的，而并非上了几次课，读了几本书就可以成功的，架构师是在工程实践中培养出来的！

举个例子，在软件行业中，一般提到的架构师是技术架构师，而忽略了领域架构师或者领域工程师的概念。一个好的领域专家一定是业务领域的架构师，他能够给出某一个业务领域的架构，只有技术架构和业务架构紧密相结合才有可能创造出一个好的系统！架构师是客户需求和开发者之间的桥梁。那么如何成为优秀的软件架构师呢？首先必须具有丰富的软件设计与开发经验，这有助于理解并诠释所进行的设计是如何映射到现实生活中去的。 其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。第三是具有很强的沟通能力，软件架构师需要经常与客户、市场人员、开发人员、测试人员、 项目经理、 网络管理员、数据库工程师等等打交道。所以，无论在技术方面、管理方面还是市场方面，一个优秀的架构师都必须面面俱到，只有这样才有助于设计出一个满足客户需求的体系结构。

《大道至简》作者、支付宝（中国）公司业务架构师周爱民在《架构之美》一书中曾写过这么一段话：在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以无论如何，架构是可以“做”出来的，而且也应该有一些“做”的方法、技术、技巧。有人问过我：架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。

现在， 微软的决策者比尔?盖茨即是“首席架构师”。设立这个特殊职位是因为无论在微软还是在其他公司，首席执行官没有时间管技术，而很多所谓的“首席技术官”却都是没有实权的科学家，决定不了技术发展方向。但是，在一个技术主导的行业里，一个企业没有技术方向的最高决策者是不行的。

在国内，很少有软件企业拥有独立的架构师，通常一个软件高手可能既是项目经理，又是软件架构师，还是软件开发者，有时还要客串一个测试人员。其实这对软件的开发周期和产品质量是很不利的，因为一个人的观点立场是很片面的，而且各方面的工作与压力会影响一个人的情绪，情绪会影响决策，决策影响结果，所以这是一个很值得深思的问题。

又有人会疑问了：是不是架构师更多是在软件领域，跟其他行业无关？错！过去或许架构师更多的在软件行业，但未来，每个行业每个企业都该有自己的架构师。虽然我们很多企业都会有架构师一职，但是更多的架構师只懂技术不懂市场。例如，我们在飞马星驹创业企业孵化项目中就发现，可能企业在某一两个方面有比较突出的地方，但是在整体模式上面还有缺乏，因此要帮助企业做一些架构方面的调整。架构的真正意义是战略管理层面方针，所谓战略就是只有想明白一个点才能理清整个事情，这就是我们所说的战略性思维。一个真正的架构师就是要有这样整体观念，去设计整个企业模式，有完全的架构概念。

篇5：软件架构师岗位职责

2、推动主要的技术决策，并最终表达为软件构架

3、确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”

4、确定设计元素的分组以及这些主要分组之间的接口

5、为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻

6、理解、评价并接收系统需求

篇6：软件架构师工作的职责

职责：

在充分调研和理解客户业务需求的基础上，为企业应用/产品做架构设计

与客户沟通设计方案，协助他们做出关键的技术决策

在构建整个企业系统架构的过程中,能很好的平衡可靠性,可用性，可扩展性，可维护性,易管理性，及安全性等

代码审查

对软件开发生命周期,方法/标准,应用架构以及技术设计/解决方案等方面有较深刻见解

了解最新的技术与方法及如何恰当应用

任职需求：

本科或以上学历，毕业于计算机科学，软件工程，信息技术，信息系统，商务等相关专业，或拥有同等的教育水平和工作经验

___年以上分布式系统设计和开发的经验

在分布式，高需求，软件构架方面有丰富的经验

了解不同的企业软件解决方案,企业级服务器/服务,工具,及___实践

有丰富的面向对象设计和编程知识

曾经在以住的项目中担任过技术架构师

能熟练地运用英语进行书面和口语沟通

能与分布全球各地的团队成员一起顺畅工作

软件架构师工作的职责2

职责:

1、面向公司战略目标诉求进行架构设计、规划及管控，支撑变革蓝图与变革路标设计;

2、主导公司级项目的业务架构及业务解决方案设计，负责业务需求的转化及2B流程有效拉通;

3、支撑变革、流程、信息化项目中架构的评审，实现架构原则和标准的落地及日常执行;

4、参与公司IoT架构设计与项目实施工作;

5、变革与流程信息化治理体系建设与优化，引导变革解决方案建设实施，提供公司架构治理的方向和策略建议。

任职资格:

1、本科及以上学历，理工科背景优先;

2、优秀的沟通和理论联系实际的能力，精通企业架构及流程管理方法论;

3、熟悉房地产行业流程管理___实践和业界流程管理最新发展趋势优先;

4、___年以上工作经验，___年以上大中型企业的变革、流程、过程改进部门工作经验或咨询公司流程管理咨询经验，___年以上房地产行业相关领域工作经验优先;

5、拥有或曾通过以下一种或多种认证(或同等认证)者优先：

TOGAF

Architect

PMP6、熟悉IoT技术以及有相关实施经验优先。

软件架构师工作的职责3

职责:

1、主要负责核心系统的架构设计，框架搭建以及核心模块的开发;

2、负责解决后端系统中的性能瓶颈与技术难题;

3、负责核心系统的技术方案的编写与评审;

4、负责公司技术标准的制定与评审。

任职资格:

1、本科以上学历，专业不限，___年以上Java开发经验，___年以上架构设计经验;

2、精通JAVA的Spring、Mybatis等主流框架，熟悉Hadoop、ZooKeeper等分布式架构和系统;

3、熟悉Oracle、Mongo、Redis等关系与非关系型数据库;

3、知识面广，专研技术，对解决有挑战性的技术问题充满激情;

4、有独立分析和思考问题并加以解决的能力和习惯;

5、有较强的文档编写能力，能独立完成技术方案、设计方案的编写;

6、了解基础的数据结构和算法，对常见问题，能正确运用合适的数据结构和算法加以解决;

7、熟悉两种以上流行的框架，且不停留在单纯使用的层次，必须对框架的实现原理、应用场合、使用限制有基本了解;

8、善于沟通，团队协作精神良好，乐于分享经验与感悟，促进团队共同进步。

软件架构师工作的职责4

职责：

1.负责公司核心业务系统的技术架构，分析、整理出对应的技术架构方案;

2.负责产品架构分析，提出软硬件架构整体设计及数据库存储设计方案;

3.负责核心技术问题的攻关，协助解决项目开发过程中的技术难题，进行新技术的研究与技术积累;

4.改进和评审相关产品系统架构方案，控制产品系统架构质量;

5.参与制定技术标准，编写相应的技术文档，完善并沉淀企业技术架构。

任职要求：

1.本科及以上学历，计算机相关专业，至少___年以上服务端开发经验;

2.精通至少一门主流语言，Java/Python/C#/Go/Ruby等;

3.具备软件产品系统架构设计和实践经验，以及丰富的大中型开发项目总体规划和方案设计经验;

4.熟悉操作系统架构设计与搭建，并能保证架构的稳定性、可扩展性;

5.具备良好的团队沟通与协作能力，责任心强，工作认真细致;

6.有电商、财务、供应链、制造等IT系统开发经验者优先。

软件架构师工作的职责5

职责：

1、负责软件工程的需求调研，进行需求分析，编写需求分析书;

2、负责项目的概要设计，包括功能结构规划、功能子系统划分、实现模型设计、数据库设计等;

3、核心、关键模块的算法设计或功能编码实现;

4、制定软件开发计划;

5、负责指导软件工程师执行具体的软件开发工作，完善开发方法，提高执行效率。

任职资格：

1、本科以上学历，软件工程等相关专业，___年以上软件开发经验;

2、熟悉C#等高级程序语言，有较好的程序编写经验;

3、熟悉C/S、B/S

网络架构、熟悉基于TCP/IP等的网络编程;

篇7：软件架构师岗位的职责表述

1、负责公司平台级产品的开发指导及核心功能实现;

2、主导公司系统平台及项目整体设计、技术选型、根据开发规范与流程完成模块的设计、编码以及概要设计、详细设计等相关文档;

3、参与基础类库的设计，解决项目中的关键问题和技术难题;

4、与带领团队与智能硬件模块和系统对接，负责智能化项目整体集成的技术支撑;

5、训练队伍、促进团队技术能力;

6、跨部门交流，引进外部信息、介绍内部信息到外部;

7、参与关键项目的竞标、推广。

任职要求：

1、具有 8年以上软件开发经验，3年以上独立架构设计，熟悉C++/JAVA等常用开发语言, 有良好的编码风格;

2、熟悉软件开发流程，如敏捷开发等，丰富的项目经验，有大型项目把控能力;

3、熟悉常见数据库 MySQL、MongoDB，对 NOSQL、消息队列有深入的了解。

4、对分布式、微服务化、服务编排、高可用性系统架构、集群技术处理、网站负载均衡、系统性能调优有丰富的经验。

篇8：软件架构师岗位的具体职责

1.负责云平台核心的架构设计、优化、关键代码编写;

2.参与业务流程，需求分析，架构设计，数据库设计领域分析与建模;

3.根据客户需求及市场行业需求进行软件架构的制定，将需求分解到多个子系统实现，输出设计文档，接口文档;

4.对开发团队进行技术指导和培训，规范开发流程，协助项目经理进行项目的管理。

岗位要求：

1. IT相关专业本科以上学历;

2. 两年以上的互联网平台架构设计经验;

3. 精通Java，熟悉Mysql等主流数据库，熟悉网络和多线程编程;

4. 熟悉主流的WEB框架、缓存技术、DB存储技术;

5. 有支持海量用户的高并发、高可用、分布式互联网后台系统设计经验者优先;

6. 能根据需求规划合适的技术演进路线;

篇9：软件架构师的沟通修炼

架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的，也可能会跨好多个行业单位。由于不能直接管理他人，所以架构师指示别人或群体完成特定行动的能力就受到限制。他们唯一真正有效的手段就是其影响力。靠技术晋级的人主要关注在技术性的专业知识上。成为技术专家，沟通技术知识对于他们往上爬来说是非常关键的技能。这种技能通常意味着维护你的职位，明确特定项目的潜在风险和当前问题。在单位等级结构的这一层上，你应该阻止产生问题、寻找问题并且解决问题。你的上级都在盯着看你的每一步动作。压力往往会非常大。对于靠技术吃饭的人来说，若想迈出跳至管理的第一步(我认为架构师已经在进行部分管理工作了)，阶梯上的下个台阶的特性已经大大变化了。尤其是，首先要求的技能是沟通范围、数量大大地拓宽了。

架构师必备的关键软技能：沟通

架构师的沟通首先基于沟通原则，其次是沟通策略，在此之上是与执行官的有效沟通。

一、沟通原则

学习有效沟通是一个终身的过程——永远都有改善的余地。要学习的沟通原则包括：先听后说、专心致志(人和心思在一处)、正面思考等，这些原则有助于建立与别人的信任关系，使你成为更高超的沟通者。

1.先听后说

你有没有发现自己在某次谈话中总是想寻求一次讲话的机会，而没有真正在听别人说什么?当你没有听时，你传递给那个对你讲话的人什么信息呢?

至少表面上，你显得不在乎别人说什么。大部分人会很快厌倦这样的谈话，因为他们说的话白白在空气中传播却没人去听。说话的人也许会想他还有更好的事要做，而结束此次谈话。如果你只是偶尔这样做，这种行为没什么大不了的。如果这是你的习惯做法，那么你是在自己与别人之间构筑一道墙。

你听的时候，是不是在找机会纠正对方?即便谈论的话题在往前走，但是你的思路还停留在刚才的某一点上?

这种情况说明，我们并没有在听别人说什么。讲话的人对你很在乎，从其忙碌的工作中抽出时间，为你提供这些宝贵的信息，所以应该认真去听他说什么。

当有人与你说话时，要看着他说，并试着理解他想沟通的内容。给对方足够的时间来表达他的观点，然后再向其询问要澄清的问题。向他表达非语言的反馈，例如点头，让他知道你在关注这次谈话。

我认为罗马人Epictetus说得好：“我们有两个耳朵，一个嘴巴，所以我们应该多听少说。”

2.专心致志

不管你在哪里，都应专心致志。生活中有许多事情要分神，例如这个周末你要做什么，几分钟前开会回来如何解决会上的问题，怎样找个办法告诉老板某个负面的消息，小孩今晚的英式足球比赛几点开场……所有这些琐事都很容易让你想入非非。

一般来说，人在任何时刻最多只能同时处理7件±2件那么多的事。如果你的脑袋全是一些无关紧要的琐事，你就无法专心致志地做事。要是有人对你说话，你就会完全听不到他在讲什么。倘若他在问你问题，你可能要他们再说一遍。这种情况下，你其实是在浪费别人的时间，他们不会高兴的。如果房间里有个执行官，你就会给人家留下一个持久的坏印象：真是个浪费钱的家伙!

请你读些时间管理方面的书，列出每天需要关注事情的清单计划。在计划中安排好任务的优先级(当天、本周等)，并标识每个任务准备投入的时间。这个办法能够让你通过计划安排好每件事，节省你的精力去记忆周围各种正在发生的事。

如果某个会议不是真的需要你参加，你就不要去;假如确实需要你参加，就一定要去，而且人和心思都花在那里。

我发现，坐直、将脚放在座位正下方、做笔记、直视正在讲话的人，能够自然而然地全神贯注于会议正在进行的事情，从说话和肢体语言两方面都给人以积极参与的正面印象。

不管你做什么，都要专心致志!

3.正面思考

当你表达信息时，总有许多种方法去传递它们。信息需要真实和准确，然而表现出其意义的方式可以多种多样。

你可以以积极意义或消极意义提供信息。你可以基于所期望的结果选择某种方法。也可以采用不偏不倚的方式，不带情绪地列举事实，尽管这通常很难做到。

从沟通的观点来看，人们容易注意负面的东西。通常负面消息总会带来恐惧(当我感觉恐惧邻近时，我会把它当做“要求集中精力的行动”的信号)。

作为架构师，你需要避免不必要的偏见信息，让别人能够选择他们要关注的信息。你可以提供若干种替代方案，但这些方案应当是客观平等的。你需要察觉可能的办法，而不是为别人留下疑惑。

4.尽早道歉

在一天的事务中，你可能注意到对他人做的某个事情不合适或不正确。记住放下自尊去给受影响的对方道一个歉。向别人诚心道歉并不是好玩或者容易之举，但你可以赢得别人的尊敬，展示你在尽力成长，尝试变得更好的意图。

如果你道歉，对方就有可能重新审视事情，而原谅你带来的任何苦恼伤痛。有些让人尴尬的事情转而有了积极意义。你与那人的关系就有了增进的机会，而不是就此冷淡。

人的本能倾向就是让冒犯别人后的情势不了了之。遗憾的是，你可能埋下了让它长大成祸患的种子，以致对你造成长期的影响。被得罪的人可能会耿耿于怀，在很长很长时间内记住这件事。那个人也许会把这件事告诉别人，说你是个什么类型的人。你和此人及周围其他人的交往能力可能大打折扣。最后，或许你已经忘记做过的事，但是对方却没有忘记。

道歉时，你要清楚地表达出要道歉的是什么，你说的是什么意思。如果你不是诚心道歉，虚假的说辞可能把事情弄得更糟。如果你不能表达诚意，就不要道歉，但你的目标应当是努力与你所交往的人修缮积极的关系。避免让道歉使你向错误的方向发展，限制你的个人成长。

5.不要在缺陷上招致恼羞成怒

当你在开评审会(例如产品概念评估、需求评审、设计评审、代码评审、测试评审、产品发布评审)时，通常会检查出评审项目的一些缺陷。评审项目的作者对于这些暴露出的缺陷当然会感到不自在。

出于通常的礼貌，一旦在特定领域发现了三四个问题，就不要再过高、过深地批评了。如果你需要指出再多的条目，可以将其写下来，让被困扰的人随后能仔细看到这些要点。否则这些事情会招致对方恼羞成怒。由于被评审人成了众矢之的，在效率上会极大地影响评审的后续进展。

对于评审，有下列一些有效的办法：

确保对评审项目的关注，而评价不是针对生产或创造评审项目的人或单位。换句话说，评审应针对事物、方法，而不是针对人。

避免用“你”、“你的”这类个人化的评价。

设法表达你要求修改的原因是想达成什么目标：确定修改与市场策略有关，基于一般的架构原则，抑或是公司或部门的目标?

评审应关注改善评审项目的方法，不仅仅因为没有遵循某个编码指导原则，而是修改后为什么有用。评审项目的人不仅需要知道怎样把事情做得更好，还要知道为什么这种改进是有用的。

找机会说出已做出的工作的积极成分。大多数人被指出暴露的缺陷后，都会非常想要辩解，而找到工作的好的方面能够软化这种态势。所有与会者都应明白，目标是创造优秀的工作成果，每个人都要求用同样的标准—这是集体的努力。

确保会上的每个人都参与进来。以局外人的身份参加会议是在浪费公司的时间。

模仿你在寻求的行为。拿出当评审你的工作，且结果是“很好，继续干吧”时的行为。目标是创造优秀的工作成果并持续改进它。换句话说，不是关于你的事，而是关于如何奋力争取优秀的事。

举止文雅：倘若角色互换，作为被评审人，你希望别人怎样给你反馈意见?

任何问题都应记录在案—不只是你感兴趣要追踪的事，还包括其他人提出的记录。如果确有一大串条目需要引起注意，可能随后还要再进行一次评审。

二、沟通策略

在我们研究了沟通的核心原则后，现在你可以应用一系列策略来展示恒定、高效的沟通风格。

1.多说“是”，少说“不是”

架构师经常会被咨询问到某个项目的可行性，并提供从战略到战术的多个替代方案，附带若干成本选项，以使商务伙伴能根据特定项目的投资进行判断。架构师与项目评估团队的角色不是决定要构建什么，而是决定怎样构建。我们试图说出的答案是“对，我们能构建这个项目，这些是相关的信息”。产生的信息需要包括诸如所考虑的各种替代方案、项目风险(以及可能的规避策略)、基于的假设条件，以及需要指出的突出问题。我们不是在寻找这样的答案：“不行，这个项目不可行，但我们能构建另一个项目(通过消除原困难项目中的难题，而代之以我们想构建的那些特性)。”

关键点：作为架构师，我们要寻求说“是”的方法。

但是，如果一个项目或任务不可行，我们需要立即巧妙地指出评估结果、解释原因，并提供替代方案。这通常归结于法律法规、行规等原因，以致“不”是正确的回答。当然了，还有其他一些例外情况：提出需求的人是想逃避工作，需求违反了公司的政策，或者你手头有优先级更高的工作，无法让你有足够时间来对需求做出满意的答复。这些情况下，你要清楚地告诉人家你说“不”的原因。

如果执行官要求你做某件事，你要确信这个要求的优先级。如果是高优先级要求，你一定要分析不做其他任务的影响，并反馈给执行官。这将让高一级的经理在确定任务的孰重孰轻时有足够的信息。它也有助于你免于日后陷入两难境地而无法自拔—如果你不得不解释为什么不让另一位经理知道就耽误了其他重要的任务。学会说“是”可以采用多种替代形式。通常，它涉及为某人或某个项目找到继续前行的办法。没有必要你自己来承担任务或需求。也许你可以提供一套合理的替代方案，或者引导提出需求的人找到其他人，后者能够解决项目当前面临的问题。对于需要可行性信息的多数项目而言，最值得期望的方法就是提供一个自助餐式的选项，详细罗列出成本、风险、战略影响以及有效的组合等信息。这种策略让需求者处于决定者的地位，使他可以选取最能产生商业价值的解决方案。提供一组方案供客户和同事选择，这种做法能让你自然而然地与他们建立友好关系。

2.在销售过程中建立起信任关系

想想你上次购买一辆车、盖房或者购置一个大物件的情形。这次购买的成就感或挫折感很大限度上取决于你所打交道的销售员或签约人。销售员总是仔细倾听你想要什么东西，通过提供下列信息，让你能够以决策者的身份决定你想买的东西：

可用的选择方案;

各选择方案的开销;

各选择方案的好处;

各选择方案能够如何组合;

各选择方案涉及的风险;

每种选择方案已知的问题。

销售员不大可能强行把你往这个或那个方向引导，但会帮助你理清需求，为你寻找以最低花费得到最高价值的解决方案。为做到这一点，他的自身利益只能退而求其次。通过将你的需求置于第一位，销售员能够建立与你的信任关系。这种信任让你感觉你是在有足够信息的情况下做决定，而他是你的伙伴。当有人问起你新购置的物件时，你很可能不只对这个物品的方方面面滔滔不绝，还会提到那个了不起的销售员，并推荐他给你周围那些想购买类似物件的人，因而又开启了一个销售周期。

作为架构师，你应当成为那个销售员，值得别人信任。

3.特殊场合才说“不”

从架构师的前景来看，只有在若干种情况下你可以简单地说“不”。大多数时候，你必须提供能让事情完成的替代方案(涉及费用、风险和每种方法的好处)。最后的决定取决于项目的主人(即掌握购买权的人)。

在其他时候，说“不”是合适的(如图3所示)。通常这种拒绝需要有足够合理的深度来支撑，以应付所有必要的质疑。争论的领域很可能与任何项目都存在的关键限制因素有关，如效果、成本、时间和范围。

爱惜你的“不”，而只把它用到礼仪场合——不要轻易用它。

下面是说“不”和不说“不”的一些考虑因素：

对于项目的最后期限，当要求违反“物理法则”，即无法执行项目给定最后期限内的所有步骤(例如：硬件的获取和供应、规划、开发、要求的培训、测试、修正错误和部署)时，说“不”是可接受的。但不能因为工作看起来困难、你不大喜欢它或者有其他不能同时进行的优先级(也许当前需求会很快成为最高优先级—值得将此列为一个风险)。中性地陈述各竞争优先级的任务，从而让执行官能根据各自的相对重要性安排它们。

问自己这些问题：

我表现正直吗?我在会议上公开说的话与我在门廊中说的话一致吗?如果你真的对需求有疑问，应当将它们摆到台面上，即便对你并没有什么好处。与通常一样，这种行动应当以文雅、令人尊敬的方式做出。

有没有替代方案能消除“物理法则”问题?脱开思维框框的束缚。如果这是你的公司，你如何解决问题?(当然了，答案不是解雇你周围的所有人。)如果你在特定领域中没有专业知识，你能引入有这方面专业知识的外包人员吗?其他人有没有解决过类似问题?你能将他引入项目，或者至少请教他一些问题吗?是否有一些概念证明能迅速实施来降低项目在某些地方的风险?你需要更多的时间来评估项目吗?

有没有其他人可以和你一起进行头脑风暴，以找出解决方案?

你能分阶段定义项目，每阶段都有可发布的东西(主要的发布)吗?这个分阶段的办法使你能够分别为每个阶段寻求资金，也能够定位你首先要了解什么内容。随着你了解情况的深入，你可以评估下一个阶段，倘若发现下一阶段并不可行，或者不能提供足够商业价值来继续推进的话，你可能退出项目。

如果你不说“不”，你可能注定是在“死亡行军”(death march)——项目已经有了高度可见性，无休止的加班，客户永远不怎么满意，

要求有适当的期望值来避免这种结果。

特定的环境有时会影响说“是”或“不”的决定。例如，在停业期(layoff)或外包(outsourcing)期间，可能需要更微妙的方法。每个人在此气氛下都很紧张急躁，项目协商变得很具挑战性。

只说“不”或仅仅阐述事实很难让人接受。充分准备来解释所做决定的原因，证明所做决定是好的商业决定。通过列举事实，探究事实背后的根本原因，陈述此根本原因如何支持期望的商业目标。

作为架构师，你就是在推销东西。你需要准备即便出现问题，也要将解决方案推销出去。人们提出问题时，可能看上去与你在作对，而实际上，人们询问是为了确认此解决方案，或者他们要了解此解决方案。他们提出问题，是因为他们随后也可能要向他们所在的单位推销这些提及的解决方案。

你要相信所提到的解决方案。如果你并不真正相信你所推销的东西，你的肢体语言和眼睛会说实话的。你的不诚实如同水中的血腥味那样：你很可能被问及更详细的一些问题，如同鲨鱼在攻击一样。在某种意义上，你是将自己置身于未曾准备好的问题。你需要了解足够多的细节来相信这种解决方案。在你向人们提出某种解决方案时，你也需要自我提问和回答有关的难题。

在所有可能情况下，避免真的说“不”。事实上，根据你所交互的人或群体的语境，解释决定所基于的原因。

4.抑制想自卫的冲动

通常在交谈中，当我们听到并不完全对自己有正面意义的事情时，我们可能会找借口，我们可能会找办法转移话题，并责怪他人，以使自己脱离干系。或者我们想强词夺理，以阐述那些语句。应当避免做出此反应的冲动。相反，代之以等待，并接受别人所说的话。

在上一段描述的反应中，会谈的真正兴趣已经从对别人转移到你身上。听别人说话的行为至少暂时结束了，我们开始与会谈者发出警示信号：“我们把话题引向另一个方向吧，一个和我没关系的方向。”注意你正在用的肢体语言—胳膊交叉在胸前，或者头转向一边告诉别人“我不想听了”。

问自己这个问题：我能从这个人说的话中学到什么?”通常，他给出的信息也许并不是你乐意听到的，但其动机是好的，仍是你接受信息并获得个人成长的机会。

抑制想自卫的冲动的一个例外就是当手头的问题涉及企业政策或你的正直时。如果别人说的话使你真正涉及与公司政策冲突或你出于正直未做某事(假如，你已经正确做出了行动)时，你需要立即抨击这些说法。你可能想用澄清问题的办法来明确要点，比如“你的意思是我做过某事吗”。如果别人说“是的”，你就以“这并不准确”来明确回应;倘若人家回答“不是”，要感谢他澄清了此事。

5.倾听建议来改善合作

先寻求理解别人，再寻求被人理解。——作家、演讲家Stephen Covey

从软件开发的角度看，批评别人和被批评的情况经常发生。因为有软件评审、设计评审、架构方法评审、单元测试、功能测试、缺陷跟踪，或者只是简单地向别人寻求帮助，与上司一对一地谈话，这个列表不断在进行。在所有情况下，总有机会将别人说的话特定到你身上。

一旦你把谈话话题转移到自己身上，而不是工作成果或某些事件上，你本能的自卫意识就来了。这时，你听进去任何事情的能力就变得有限，“要么拼命，要么逃跑”的本能反应开始占据上风，而你的大脑指挥身体开始变得激动，以准备自我保护。所沟通的用于改善工作成果的有价值信息烟消云散。从商业角度看，将一项工作产品做得尽可能优秀以符合每个人的最大利益，因为我们越能为产品增加价值，公司越有机会从投资中得到回报。

如果你能避免在谈话中个人化，你听取别人说话的能力就大大提升了。要试着找出他说话的真正用意(即便你不同意他说的话)。以适当的方式取得他想传递的本意，复述一遍要点。一般情况下，别人只是想被理解，他并不是在寻求你同意他的观点。当你倾听并能理解对方表达的要点时，你就能和他心灵相通。

关键点：通过倾听并复述所说过的话，来理清自己的理解。

6.了解别人和自己的沟通需求

在架构师的世界中，你需要例行地与许多人交流。你可能在上一次会议上与有些人谈过话，也可能没有和这些人谈话。挑战就是快速了解人们在说什么，他们怎么说这些话，来“读懂”本次会议。

观察关键的时刻，即做出决定的时刻是一个要点，以此识别人们提出的问题和关心的地方，来加强核心概念，帮助你关注会议的方向以及把会议引向一个成功的结论。为了认识这些关键时刻，我们需要吸收所有信息，包括提供给我们的语言或非语言信息。

观察别人的举止能够告诉我们如何与每个人最好地沟通。由于每个人都不相同，并且对沟通也有不同的需求，架构师必须让传递信息的方式适应这些需求，以确保有效沟通。

关键点就是我们要基于每个听众成员的沟通需求来匹配交流风格。有些人的反应是能够看出来的，他们的偏好能够用诸如“我明白你的意思”之类的话辨别。另外有些人需要倾听，并吸纳语言细节，他们的偏好能够用诸如“我在听你说”之类的话辨别。还有一些人在交谈中比较情绪化，他们的偏好能够用诸如“我觉得怎样怎样”之类的话辨别。

除此之外，大部分人的肢体语言(如无精打采、坐姿端正、胳膊交叉、与别人交谈，或者说话时用手势)都能给你关于此人的线索，表明此人在本次会议或集会上是专心致志还是心不在焉的。事实上，电话会议的一个主要麻烦就是你无法看到电话另一端人们的肢体语言。后果就是你不能取得同样多的反馈信息来帮助引导会谈。而一般会谈中很容易看出需要谈到或考察的问题、人们关心的地方及思路。如果仔细倾听，你还是能够从与会者的语音、语调及说话的速度等方面观察出端倪—来自所有这些方面的反馈有助于了解沟通的效果。

电话会议的另一个挑战就是你可能不了解电话另一端的所有人，也无法琢磨其沟通方式、语境。要克服这类知识的匮乏，应在会议开始时做到下列事情：

收集电话另一端所有人的名字。

重视每个人的响应。

注意所有与会者的交流方式、开会的方法(如态度、言辞、语调)及角色。

在将来的电话会议上使用这些知识来引导交互过程。

诸如WebEx之类的在线开会，比电话会议效果好，至少你能够看到他人当前如何反应。这些可视性也有助于主导会谈。

在视频会议中，每个人都能看到自己，这是对电话会议或在线会议的重大改进。我们能够看到活生生的对方，或者说是某个人的图像，使得交互更具人性化，能够大大改善与其他参会者的沟通能力。

要记住这种交谈的一个关键方面就是，在交谈中别人不仅以多种方式将他们的所思所想告诉你，你也在给他们传递类似的信息。在会议中，你需要本能地意识到你的身体正在给别人传递信息。

你的肢体语言会“大声说话”—所以要谨慎你“说”的内容

在会议中记住这些事项：

你在微笑吗?

你坐姿端正吗?

你赞成时点头吗?

你的眼神对着正在讲话的人吗?

你的声音或者说语调是抑扬顿挫的吗?

你参加会议时的装束风格和别人类似吗?

你真的在倾听并理解别人说的话吗?

你做笔记吗?

你主张对抗吗?

所有这些条目组合在一起，可以让别人知道或确认你要发出的消息的一致性。你是在笑着讲述一个伤心的故事吗?如果是这样，这种不一致性就会剥夺你所试图发出消息的完整性。

对于同样的一个消息，要努力发展自己说什么、怎么说的技巧。这种持之以恒的表现会增强你有效沟通的能力。

7.才思敏捷

随时准备好回答别人的提问。当人们提问时，不大可能先给出预告。也就是说，你不会有任何时间去准备理由充分的答案。问题可能来自任何方面(单位中职务比你高的、和你平级的或者低于你的)。

作为架构师，你需要对迅速切换语境游刃有余，即记住头脑中每个活跃的事情，将其压入要记忆的栈中，然后集中全部注意力来快速处理面前的语境。这种活动称作“才思敏捷”。

在这种情况发生时，试用下列模式来处理此形势：

关注是谁在问此问题。这个人的背景如何?他需要知道什么信息来理解你的反应?倘若你对他的问题有所反应，这是否合适?

想出三点解释，如果可能的话，包含一条支持这些解释的商业根本原因。在你有限的时间里，试着对你要沟通的答案构想出一幅场景。

如果对方要求你做出某个决定，暂停并思考你要说的话对单位的影响。因为这项决定将在单位中贯彻，别的群体将如何反应?

如果你已经安抚寻求决定的人，也清楚地知道其他群体将对决定的影响有所反应，你应当认识到不久后的日程上将有一系列不令人愉快的会谈。

你也许在考虑做出一项决定，这一决定会导致涉及的每个组都不太高兴。通常，如果你能做到这一点，你就是协商的高手。当每个人在这场游戏中都有利益关系时，所有参与方会在未来更好地合作。如果没有相关的利益，他们会认为自己并未被挑选出来，现在可以集中精力解决手头的现实问题。

有意思的是，在这个所有人都不太高兴的时刻，每个人都变得更通情达理，想出更多的可替代方案来使问题以更简单、更快速、更省钱的方式解决。当答案浮出水面时—可能是真正革新型的解决方案，就准备说“是”吧。

如果你的答案有消极影响，要展示别的答案也是“有问题”的。陈词滥调过后，大家同病相怜—一起共享不快，滋味总比吞咽药丸感觉好一些。

当然了，能让每个利益相关者高兴的决定有时可能存在的，也总是最可取的。

三、与执行官沟通

执行官在任何公司都是独特的个人。他们的职责很广。执行官的沟通能力、领导才能和关系技能都经过刻苦磨炼。学习与执行官沟通需要花费时间和经过实践，但你只有一次机会来取得第一印象，所以务必准备好。

1.执行官需要信任、忠诚和连贯性

执行官对信任、忠诚和连贯性有着热切的渴望。

当你在与执行官沟通时(特别是那些对你工作领域不甚了解的执行官)，你需要注重与之建立信任和忠诚关系。在你继续与之工作的过程中，你给出的信息应当具备一致性：你不能某天告诉高级经理一个故事，而第二天却是个完全不同的故事。不要对呈交的信息有偏见，以显得你是对的，而别人不好。关心的事实应尽可能简洁且开门见山，要知道执行官都是一些大忙人。

当你会见执行官时，不要嘲笑那些不在场的人。这样的行为只能证明你不值得信任，也不够忠诚。

当你呈交信息时，提供事实，而不是关于人们的观点。事实是能够理性处理的东西，即便是不在场的人也能够理性处理事实。要确保你适当地传递了信息，这样当执行官向有关人员索要事实信息时，即便原先不在场的人也不会措手不及。

我曾经有过一些这样的参加会议的经历，执行官召集其他的人一起进入房间讨论，来验证我所给出的所有信息。要确保你讲的故事是想在别人面前重复的，因为你可能有机会立即这么做。

2.清晰性甚于完整性

作为一般性的经验方法，给人提供细节信息的数量应当反比于此人在单位中的级别。换句话说，开发者可能需要海量的信息来构建某个东西，而执行官在项目定期更新状态时，只需要有关项目的高度概括性信息。但信息需要清晰、简明扼要。你需要给执行官提供正确的信息，并提供适当的背景，多些商务信息的成分，少些技术信息的成分。

执行官不大可能会顾及所有技术信息。他们想知道你精通技术，但他们没有时间关心所有的项目细节。这样过滤的一个主要原因就是执行官受时间限制，必须工作于信任的基础上。他们寻求将所有权、执行权和照看项目的责任委派给你。他们希望你处理问题、做好规划，以及照顾项目的其他方方面面。

执行官想知道的就是如下这些东西：

有哪些风险会导致项目无法如期完成或者按预算完成?风险是否已得到控制?

能创造什么战略资产来支持当前或未来项目的需要?

单位中谁是“升起的新星”?

执行官要求你提供的是准确的信息。他们希望你保持一致性。一旦你给出一个答案，就应坚持它，所以要谨慎选择你的答案。有的执行官可能会深入项目的特定方面。你至少应该准备探索这方面。执行官可能借此找出你知识的边界及疏忽在哪里。开会时，倘若你处于你不知道或不确信某些信息的境地，要明确表达自己不知道，但声明自己随后会关注被问及的这些信息。永远记住：如果你不这样做，你可能会将自己辛苦挣得的信任关系付诸东流。

你和执行官最好的交互过程就是把你的扑克牌都放在桌面上。也就是说，让他们能看清你所有的东西(好的、坏的、丑的)。你可能因为彻底袒露、容易被人挑刺而感觉不踏实。但这样的行为能让你在信任和忠诚方面—这是执行官最看重的——增加好感。

当你真正需要执行官来介入处理事情时，你已经建立了与之关键的关系，这使你能够与高级经理一起处理这些事情。执行官不想知道的就是项目中存在的争执。部门A与部门B之间的分歧完全是“你的”问题，你应该去解决它。如果你请执行官来介入“解决”某个争端，你和所涉及的团队都不会对后果感到高兴。执行官似乎有第六感，他会选择争端中最痛苦的解决方案。既然如此，建议你简明扼要，并坚持在符合执行官而非IT人员需要的层次上解释相关的事实。

3.不要让执行官感到惊讶

谈到不断积累的问题时，执行官不喜欢惊讶，尤其是那种惊讶：他们必须在很短时间做出行动、剩下的选择少之又少，而结果是他们必须将坏消息通知给单位的其他部门。

执行官不喜欢惊讶。如果你有坏消息，就早些告诉他们。

绝大多数项目的风险是逐渐累积的。从事或接近项目的参与者知道这些风险。如果仔细倾听，你会知道到处都在反映这些信息。遗憾的是，风险发出的隆隆声并不总能让需要听到的人听见。当人们与高层的管理人员和执行官说话时，他们在本能上会报喜不报忧。结果就是，他们不太想把一些看起来不妙的事情呈递上去。

中层经理不会在来不及处理风险的情况下，乐意被人将风险暴露给他们的上司或其上司的上司—那就是，围绕风险的推销问题。如果风险会随时间而膨胀，应尽早暴露出来。通常要有个判断过程来确定何时告诉别人这个生长着的麻烦。没有捷径知道确切的时间。作为一个经验规则，早些暴露远比问题发生为时已晚要好得多，因为后者要迫使高级经理人员和执行官去处理善后事宜。

如果你发现你的上司或管理人员没有将所需的信息沟通给执行官，你可能需要自己呈递这些信息(倘若你决定采取行动，必须极度小心，也许有些你未意识到的因素导致别人那样做)。当你真的呈送消息时，确信所有中层管理人员都意识到了风险。他们需要有机会拟定行为计划来处理这些风险。这仍然是关于信任和忠诚的问题。

当执行官越早知道存在的风险，他们就越能够成功应付它们，并最大限度地降低负面影响。如果执行官被搞得惊讶，他们不会高兴的。假如你还没有破坏他们对你的信任(你工作非常努力才换来的信任)，你可能已经在朝这个方向做了。当晋升机会到来时，你可能不会得到执行官的多少支持，因为你曾经引起他的不快。