项目管理的核心是借事修人。其中“事”是项目,但终点是提升人的领导力
所有导致项目失败的问题,冰山下都有同一个源头,那就是“失焦” (关注力不在同一个点上)。这包含以下四个方面。
- 目标的失焦:发起人的预期模糊,目标不清晰,产出无法衡量;
- 人力的失焦:项目团队及干系人,各自有各自的诉求,形不成合力;
- 计划的失焦:团队成员不知道什么时候该干什么,互相依赖冲突;
- 行动的失焦:遇到问题时,你说要这样,他说得那样,没有统一落地的解决方案;
项目管理的底层思维很简单,就是“对焦”两个字。 本质上,项目管理是在不确定性、多变的环境下,追求确定的项目产出。 只有通过在目标、人力、计划、行动四个维度上,不断对焦和清晰,才能真正带领项目走向成功。
项目管理这个角色,经常需要推动别人做事情,如何有效地对他人施加影响以推动事情?主要有三个层次:
- 知道要做(Awareness)
- 有动力做(Desire)
- 有能力做(Ability)
单方面的工作交待和告知,停留在浅层次的信息传达上,知道要做(Awareness),但并不足以让人产生动力(Desire),去促成有效的行动。
讲清楚为什么要做,为什么要现在做,获取理解及认同,激发团队的动力,是项目经理成功授权工作的关键。
在动力(Desire)的基础上,你还要确保你所选择的人,有相应的能力(Ability)来做到这件事情。如果现阶段的团队都没有对应的能力,该怎么办呢?项目成功关键路径上的核心能力缺失,是作为项目管理人员,要当作最高优先级的风险管理的事项
团队人员能力缺乏的解决方案
- 从外部引入相应的人才显然是最直接有效的方式;
- 短期:积极争取短期借调、内部转岗等;
- 长期:需要有意识地发现和投资那些团队中最有潜力的人,给他们安排相应的工作辅导,开展有针对性的培训等,帮助项目组成员发展相应能力,让事情真正落地;
项目经理最该做的,并不是每天监督逐个人、逐条事项,而是要明确目标,建立机制,并让这个机制运转起来,最终在项目组形成一种良性的秩序。
比如,项目经理要带大家一起开启动会,清晰愿景目标,定义阶段里程碑和完成标准,接着制定分段执行的计划,把事情的所有环节从头到尾捋顺了;项目经理要建立上下游协同的流程规则,明确各个角色在整个过程中的职责,获得大家的认同和共识;项目经理还要建立站会、周会等制度和模版,让进展和风险通过这些良好设计的信息渠道汇聚,借助规则和工具来达到监控的目的
项目是为创造独特的产品、服务或成果而进行的临时性工作
项目管理就是将各种知识、技能、工具与技术应用于项目活动,以满足项目的要求
具体来讲,项目管理就是指把各种系统、方法和人员结合在一起,在规定的时间、预算和质量目标范围内,完成项目的各项工作,对组织资源进行计划、引导和控制
项目管理的十大领域,将项目管理的工作内容划分为:
- 整合管理
- 范围管理
- 时间管理
- 成本管理
- 质量管理
- 人力资源管理
- 沟通管理
- 干系人管理
- 风险管理
- 采购管理
其中,进度、成本、质量、范围是 4 个核心领域,风险、沟通、采购、资源、干系人管理是 5 个辅助领域和 1 个整体领域,如下图所示:
PMI 遵循 PDCA 的法则,将所有的项目管理活动分成了五大过程组,分别是启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。如下图所示:
启动过程组意味着正式开始一个项目,或者是开始一个项目中的新阶段,包括识别干系人和制定项目章程两个子过程
-
制定项目章程: 我们在启动一个新项目或新阶段时,首先要建立项目章程(项目的规章制度和流程),并且通过启动会去公开确认。启动会的作用,就好比一个大型的推土机,是面对项目组全员,正式宣告一个新项目或新阶段的开始,公开确认项目章程,包括明晰各方干系人的期望和诉求,设定愿景目标和重要里程碑,确定责任分工和沟通机制等
如果涉及到跨部门的项目,启动会就更加重要了。项目经理要积极创造一个场合,邀请更高的管理层出面,讲清楚项目的背景、目标和重要性。除此之外,启动会也是项目管理人员获得公开授权的有效方式,可以让你之后的推进工作更容易开展
-
识别干系人: 干系人分析,是对项目干系人进行分析和归类,有针对性地规划管理其核心诉求和期望,让干系人可以更好地参与项目,对项目产生积极影响,从而保障项目目标的成功达成
干系人分析的目的:要把拥护我们的人搞得多多的,把反对我们的人搞得少少的!
作为项目管理人员,我们需要通过积极的干系人管理,尽可能把反对的力量变成更多支持的力量,同时发掘和调动中间力量,比如项目中的不积极者、无所谓者。这样一来,项目才会越做越省力
如果按照在项目上的权力和利益相关度对干系人进行划分,可以把项目干系人分成四类:
- “高利益 - 高权力”代表:项目发起人;
- “低利益 - 高权力”代表:职能经理;
- “高利益 - 低权力”代表:项目组成员;
- “低利益 - 低权力”代表:外围支持人员;
- “高权利-高利益”人群:我们沟通更多是以倾听和解惑的方式来沟通,并适时的表达出自己的诉求;
- “高权利—低利益”:我们需要以平等、透明的姿态,把项目的诉求和愿景,以及协作空间沟通清楚,尽量能保证他们的自主控制权;
- “低权利-高利益”人群:可以说是直接干系人,我们需要描述清楚项目的背景,共同制定项目章程,项目规范等;
- “低权利-低利益”人群:更多的是把规矩和范围制定清楚,进度计划沟通明白;
- 启动会怎么开:
启动会的目的是清晰目标,明确授权。要做到这一点,你需要分三步走,分别是 why、what 和 how。
- 第一步: why 是最难讲好的。但实际上,只有充分理解了项目背景、目的和意义,才能更好地唤起团队的参与热情;
- 接着是: what,描绘蓝图,设定清晰的愿景,包括项目的三年目标、五年规划,越清晰越好,为的是让团队看到未来的样子;
- 最后一步是: how,明确团队之间的责任分工以及合作公约;
关于启动会的内容,可以参考以下十个方面着手准备:
- 项目背景:包括项目发起的背景,项目的重要性,与公司更大层面目标的关系
- 项目目标:符合 SMART 原则的项目目标(具体、可衡量、相关性、时效性、可达成)
- 项目范围:当前初步的项目需求稿、策划案、整体内容说明
- 里程碑计划:项目未来一段时间,重要的里程碑及阶段性目标
- 主要风险:影响项目成败的关键风险因素,比如国家政策、人员缺失等
- 组织架构:项目团队及相关干系人的组织架构图,项目成员的联系方式列表
- 责任分工:项目中定义的各角色职责及相应人员,审批确认权限
- 流程机制:文档评审流程、需求变更流程、周会周报机制、风险管理机制
- 沟通方式:项目常规会议的时间安排、召开频率及参与人员
- 支持工具:任务管理、文档管理、代码管理的工具及使用规则,统一的项目沟通群
开好一个启动会,总结来说有三个关键点:造声势、定调子、立规矩
如果说启动是要明确目标,那么,规划就是要把愿景目标转化为可落地的行动方案和工作路线。需要根据预期目标,明确项目范围,确定项目的里程碑阶段目标,为项目的执行做好各项准备。对于一个复杂项目来说,规划通常是一个渐进明晰的过程,近期的规划往往是最具体的,需要拆分到具体版本和工作项,而远期的规划则相对比较模糊。随着收集和掌握的信息逐渐增多,规划也要进一步动态细化,不断更新。如下图所示:
在项目管理中,计划是贯穿始终的重要课题,是各个角色协同工作的基准。实际上,计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。从本质上来讲,计划是用来对焦的!做计划,是个集体对焦的过程。
计划是各角色协调工作的基准,它会把团队各方的工作放在同一条时间线上,让大家明确地知道什么人负责什么事儿,什么时候该干什么事儿,从而解决互相冲突或依赖的问题,设定好协作节奏和行动步调。
计划是讨论出来的( 做计划不是一次性到位的工作),因此需要先有一个可供讨论的最初版本,这个初版很可能是不准确的,但是没有关系,有了这个初版,各个角色的人就可以在一起进行讨论,这个一起做计划的过程,让大家更清晰地进行了对焦,明确彼此的相互依赖和影响,以及接下来我们该怎么更好地合作。
做计划的5个标准动作
- WBS工作分解(Work Breakdown Structure):创建 WBS 的过程,也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程;
- 识别任务依赖及各环节关键路径:关键路径是项目计划中耗时最长的那条路径,关键路径的工期决定了整个项目的工期,所以,任何关键路径上的延迟都将直接影响项目的预期完成时间。清晰了关键路径之后,我们要进行持续关注,把关键路径上的风险作为最高优先级应对;
- 定义完成标准:完成标准就是某时间点需要完成的事项列表,或者是应该达到的某项指标(特定水平的 Bug 数量 / 性能指标等)。进度计划中的任何重要时间节点,都应该有一组完成标准。越早定义完成标准,计划按照期望完成的概率就越大,比如需求/设计确认,这个时间节点的完成标准是,执行所需的需求稿或设计稿已经完成,而且公开评审通过,团队已经准备好要编写产品代码了。值得一提的是,有些团队还会对需求稿或设计稿做一定的要求,比如把未处理的反馈意见数小于多少作为标准。第 2 个是功能完成/提测,这就意味着,所有定义的功能都已经完成,团队已经准备好将焦点转移到质量保证上,并将所有的剩余问题当作 Bug 来跟踪。一些质量基础比较好的团队,也可以把冒烟测试通过率,CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等,作为更加细节具体的完成标准。第 3 个上线发布,怎么定义上线成功,是代码部署成功就ok了吗,有的团队还会加上测试的线上回测和产品经理的线上验收环节均通过,才算上线完成。我曾经碰到一个数据产品的上线案例,不是数据任务上线就代表上线完成了,还需要完成历史数据的追溯才表示上线完成;
- 达成共识并公开透明:做计划本身并不是最难的,真正难的是什么?对焦!没有达成共识的计划,是不具备任何效力的。事实上,PM 在召开规划会之前,排期的内容已经准备得差不多了。在全员规划会上,除了对齐信息之外,更重要的是当面达成共识,这其实也是仪式感和承诺的象征,对于计划后续的有效执行,是至关重要的。因此,达成共识并公开透明,就是做计划的第四个标准动作;
- 变更即时调整:在整个项目周期中,由于随时会可能出现变更,加上对估算的不断细化,计划永远是个反复修正、渐进明晰的过程,我们要对计划进行持续地跟进与调整。重要的是,每一次进行调整,都要确保项目中的每个人知道当前的计划是什么,调整计划需要怎样的决策过程,都需要谁参与决策;
规划做好之后,就是考验执行力的时候了。这个阶段重在整合资源,推进项目落地,完成项目管理计划中确定的工作以实现项目目标。
这时,项目经理的工作更侧重于确保项目一直在正确的轨道上,确保各个环节按照规划进行,并且真正做到位。
在项目执行的过程中,想要降低偏差、减少返工,你就需要构建系统能力,在产品研发的整个过程中,建立起真正闭环反馈的产品验证机制
项目执行过程中有效降低偏差、避免返工的三种闭环验证方法
- OARP 决策机制:OARP 是 Owner、Approver、Reviewer、Participant 的缩写,分别对应四个关键角色。负责人(Owner)负责给出方案,组织各方讨论并推进做出最终的决定。批准者 (Approver)是最终批准者。审核者(Reviewer)负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析,并提出反馈意见,负责人必须重视并给予回复。参与者 (Participant)其他提供意见的人。参与者会收到文档的相关信息,可以对相关问题做出反馈。OARP 是一套决策机制,你需要为项目中每一类方案的评审,确定明确的角色和职责,让各角色应享有的权利、应履行的职责,都得到规则上的保障,这样才能更好地确保方案质量,把后期的返工降到最低;
- Bug Bash(Bug 大扫除):指在项目开发里程碑的末期(比如 Beta 版发布前),划出一个专门的时间段,在这期间,所有参与项目的人员,集中全部精力一起来给项目找 Bug,目的是从各个维度衡量和体验产品;
- 冒烟测试用例:冒烟测试用例,是开发和测试之间最基础的合约。在进入开发环节后,需要安排专门的测试用例评审,让开发和测试对标准冒烟用例集达成约定,这个约定就会成为进入测试的准入标准。开发发起提测以后,测试人员就会依照这个标准用例集进行冒烟,并记录冒烟测试通过率,如果通过率不达标,就打回修正并再次提测;
我的个人项目经验,两类主要的返工和偏差
- 一个是需求和实现的偏差(包括产品提出功能需求和UI设计需求):主要靠提高需求评审和UI评审质量(比如评审前必须提前阅读并标注问题)、每日站会进行持续需求澄清、产品和UI在测试阶段介入测试、上线前验收等各种手段解决
- 一个是提测质量和预期质量标准的偏差:主要靠单测覆盖率和冒烟测试通过率来解决;
那么,怎么判断是否做到位了呢?这就需要用到监控过程组。
执行并不意味着在任何情况下都要一成不变。当外界环境或内部要求发生变化时,项目管理者也要审时度势,沉着应变,适时调整各方,以更好地实现目标。
为了做到这一点,项目经理需要定期对项目的进展、范围、质量等进行跟踪和监控,识别目前的进度与计划之间的偏差,从而快速准确地采取办法进行纠正和调整
监控过程中,进行项目进展汇报的几种方法,包括
- 紧急汇报的五个元素:事件描述、影响后果、跟进分析、响应措施、所需支持;
- 常规项目周报要包含的重要内容:项目周报是向项目团队和干系人沟通项目状态的常用手段,需要用简要的方式呈现项目全貌,客观地展示项目问题,推进问题解决,最必不可少的就是整体项目状态评估、风险和问题列表、项目概况及计划变更情况;
- 运用透明的力量,通过数据汇报推动问题的解决:比工具更为重要的是,需要结合项目组中当前需要重点推进或改进的事项,选择合适的数据和图表去做“透明”;
在这个阶段,项目经理要交付项目成果,组织团队的回顾复盘,归档所有文档等组织过程资产,正式结束一个项目或阶段
项目复盘会,可以说是项目团队有意识地从过去的行为经验中,进行集体学习的过程。一般是在项目或里程碑完结之后,由项目经理组织召集项目成员,一起回顾一下,在项目的整个历程中,团队做对了哪些事,做错了哪些事,再来一次,如何做得更好,借此把项目行进中产生的集体智慧沉淀下来。
在复盘会之前,想清楚我们复盘的目的,设定好复盘的基调,更为重要。
要想让参与者真正进入集体反思区,会前就要设定好开放的复盘基调。其实,我们每个人都可以在自己所处的环境中,看到各种各样的问题。如果复盘是出于追责,那么在会议刚开始时,大家就可以迅速地感受到。这样一来,每个人都会小心地避开自己的问题,转而去说别人的问题,这样的复盘就失去了意义
如何应对需求变更?
- 从源头控制需求质量;
- 过程中建立需求变更控制流程:比如首先要发起变更申请,由变更委员会来综合评估,评估的内容包括变更范围、风险、对现有计划的影响程度等,以此来判断是否接受变更。变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成,如果接受变更,那么就需要判断项目计划是否需要进行相应的调整,最后公告处理结果;
- 实在无法抗拒,实行最低成本试错方法:比如针对老板经常变更的页面,使用可热发布的技术如RN、H5等。或者通过最小代价实现灰度,数据对比说话;
风险识别的主体,应该包含项目中的团队成员在内的各方干系人,而不只是项目经理。组织中的每个层级,都必须有意识地积极识别,并有效管理风险。系统化的风险识别,是一个反复进行的过程,应该从项目构思阶段开始,贯穿规划和执行的始终
识别风险过程的主要输出,就是初始的风险登记册,包括已识别的风险清单,以及潜在应对措施清单。对于已识别的每个风险,都要评估其概率和影响,并进行优先排序
其中,风险概率是指每个具体风险发生的可能性,风险影响则是风险对于项目目标(进度、成本、范围、质量)的潜在影响。
可以通过访谈或会议的形式来进行风险概率和影响的评估,参与人员包括熟悉相应风险类别的人员,以及项目外部的经验丰富人员。以下是一个风险登记册的示例
质量是规划、设计、建造出来的,不是检查出来的。预防高于检查,预防错误的成本通常比在检查中发现并纠正错误的成本低得多
在业务生命周期的不同阶段,质量标准应该是动态变化的。比如,业务初创期追求的是最小化 MVP 模型的快速迭代,在这个阶段,质量往往不会是最关键的因素。但是,当规模扩张到一定程度之后,对于质量的要求就非常高了。不同的项目对质量的要求也相差甚远(项目分级,核心项目/非核心项目),无法一概而论。因此,只能结合具体项目和具体阶段的质量诉求,对质量的标准进行合理定义。
一个已经进入规模增长期的稳定业务对客户端质量标准的定义示例
定义好了质量标准,接下来你要思考的是,在整个项目的进程中,需要规划好哪些质量保障活动,以很好地达到这个标准
质量标准不仅仅包括功能性需求的质量(一般通过p0、p1等级别定义),还包括非功能性需求的质量比如性能、资源消耗(耗电、发热、内存占用)、兼容性(浏览器版本、安卓/ios不同机型+不同版本操作系统)等质量
各个阶段的质量保障手段的列表图示例
从需求到发布的整个过程中的质量活动概览
会议作为一种群体沟通方式,决定了正式信息在项目组内的传递路径
只开最有必要的会,会而有议,议而有决,决而有行
项目管理过程中几个重要会议
- 启动会(见前面启动会部分)
- 每日站会:开好站会的关键,是要还政于民,站会满足的是团队的自组织需要,而不是 leader 的监控需求。站会时间、主持人等措施可以依据团队情况自行组织确定;
- 项目周会:项目周会的目的,是解决整体计划层面、跨团队协同配合的问题。项目周会的内容,除了常规的各角色进度和风险同步之外,你还需要根据项目组每个时期的整体阶段性重点,来设置相应的环节,让大家清晰感受到项目组明确的导向,什么是当前最重要的;
不要盯着会议的数量,而是要追求会议的品质,三个基本要素
- 明确会议边界(会前):每个会议都有特定的主题和目的,并有明确的参会人员范围,这个就叫会议的边界,对于那些与主题不相干的议题,要坚决舍弃。要想改变低效低质会议状态,项目经理要做好两个确保:首先,确保各部分的进展信息在会前统一提交,会议当场只说重要问题、风险及需要支持的地方。同时,确保会议当场严格围绕主题开展,对偏离主题的讨论,及时叫停;
- 建立会议规则(会中):迟到、拖堂、开小会、看手机(电脑)等行为,问题虽然不大,但是频繁发生的话,就会大大地影响会议品质。主持人要引导大家建立会议规则,对于迟到、请假、拖堂、跑题等行为建立公约,并成为规则的守护者。规则上的推陈出新,在活跃了氛围的同时,还共同构建出了高效的会议品质,最终是对每个人的时间负责;
- 做好会后跟进(会后):要想真正做到决而有行,最终靠的是有效的会后跟进,真正把决策落到实处。会议主持人要对讨论的结果及时汇总,形成会议结论。对于无法当场确认的问题,一定也要进行记录,并明确跟进人和完成时间。会后所有跟进事项,直接进任务系统,确保跟进到底。同时,要在会议纪要的邮件中明文呈现,下次会议统一回顾;
只要坚持只开最有必要的会,开真正高效且产生决议的会,团队成员不但不会排斥,还会积极参与
“约法三章式”跨部门沟通的要点:
- 首先,在项目合作开始时,要努力争取合作部门上级领导的支持,达成明确公开的“君子协议”,建立稳定的合作预期;
- 然后,要建立周期检查机制和标准化的流程,而不是想起来才问一句;
- 最后,对于执行过程中的问题,及时跟进解决,对于涉及合作机制类的问题,要及时请双方领导介入进来;
事实上,没有人天生就心甘情愿配合“你”的工作,人们想要的是,更好地完成自己的工作,并且还能得到你的帮助。所以,要么把“你”的工作,也变成对方的工作,也就是统一共同目标。 要么就请先换位思考,特别是在跨部门合作时,提前了解对方当前阶段最重要的事是什么?你想要推动的这件事,在哪些方面可以有所助益。
很多同学都能看到自己项目组中存在这样那样的问题,但是问题太多了,一看到问题就想去改变,就想去整治,就觉得这是一个机会,其实问题还并不等同于时机,你要把问题与痛点相关联,才能形成一个好的时机。 要想促发别人的行动,你必须换位思考,去体会和抓住他的痛点! 围绕着你想要解决的问题,击中几个重要干系人的痛点之后,这个时机就到了
与其说敏捷是一场研发方式的变革,不如说是一场思维方式的变革。
敏捷的特点,就是小即是美(Small is beautiful)。这个小而美,体现在人、事、时间这三个方面:
- 人:拆分成小规模(5~7 人)、跨职能的小团队;
- 事:拆分成一系列小而具体的交付物,按优先级排序,增量交付;
- 时间:拆分成固定大小的短迭代(1~4 周),在每个迭代结束后,对可工作的产出进行演示; 总体来说,就是用小团队在小块时间,做出小块的东西来,周期性地集成组装
个人总结:
- 整体规划(大方向、大框架),增量交付;
- 让所有事情都更早更快地得到反馈,包括开发更快构建代码以反馈代码集成问题、测试更快测试以反馈功能问题、产品更快发布以获得市场反馈;
三项最重要的敏捷精神:
- 快速可靠交付
- 用户价值驱动
- 持续自发改进
两类人:
- 一类碰到任何问题,不经过自己的思考,频繁找上级沟通讨论;
- 一类碰到任何问题,担心上级责怪,选择自己扛也不做向上沟通;
正确的向上沟通方式:
能够站在老板的高度和角度来考虑问题(识别老板的核心关注点和痛点),来识别事情的轻重缓急,选择合适的时机和合适的方式进行向上沟通,通过合适的向上沟通,保障信息的及时共享,并及时得到老板的帮助和支持
高效向上沟通的一些技巧
- 找到上级的“核心关注点”(站在上级的高度和角度来思考问题);
- 用数据和事实来作“论点”(客观反应问题);
- 给出一个小小的“行动点”(不仅谈问题,还给出解决方案);
非职权领导力六力模型:执行力、信息力、感知力、透明力、影响力和整合力
-
执行力: 执行力是非职权领导力的根基,俗称“靠谱”。判断一个人是否靠谱,关键在于是否具有两个特征:主动担责和有始有终。
-
主动担责 管好自己的一亩三分地,并非就是执行力好,需要跳出自己的小圈圈,主动承担更大的责任,而不是眼睁睁地看着项目出现问题,放手不管
-
有始有终(闭环思维):言必信,行必果。交代的任何事情,都有始有终。当很多人都只是在完成任务时,如果你懂得闭环的重要性,势必会事半功倍!一个有始有终的闭环,意味着你要对自己的每一个行为负责,清楚地了解为什么做,目标是什么,做完之后效果是怎样的,还有什么问题,以后要做哪些改进。即使中途有变化,也要及时跟相关方明确说明调整或取消的原因是什么。
-
-
信息力: 在大数据时代,谁掌握着数据和信息,谁就拥有更强大的力量和权力。 信息力可不只是掌握简单的八卦,而是要让流动的信息汇聚起来。作为初学者,你可以通过信息互通机制和平台来帮助自己做到这一点。比如,周会、站会、周报、邮件列表、通讯群,甚至是各类数据平台,都可以成为信息力的承载。除此之外,能够让非正式信息自动流向你,就属于内功的范畴了。在与人交往与合作时,好奇、关心、真诚、友善……这些特质都会帮助你构建起信任基础。连接多了,覆盖面广了,自然会形成规模效应和网络效应,这时就会产生信息力的红利了
-
感知力 感知力建立在信息力的基础之上,不同的是,感知力是对“冰山下”隐性信息的敏锐度。这种对系统敏锐的感知判断,俗称“闻味道”。 要想培养感知力,你需要经历三个层次:
- 现象层:这一层观察的焦点,是在“冰山上”的行为;
- 意图层:这一层观察的焦点,是在“冰山下”行为背后的真正意图。具体要怎么做呢?最简单的是,多问几个为什么;
- 感受层:你要试着从这些现象和意图中,去感受每个人的状态和需要;
-
透明力:信息力和感知力是对环境的观察、观察、再观察,这些观察的结果只有透明出来,才能发挥效用。要想办法把看到的问题可视化,让决策者和团队都能看到问题。
两个透明化呈现的方法:
- 一个是“分析−思考−看见”:走脑法,借助数据、事实、逻辑分析等,调动头脑的智慧,创造共识;
- 一个是“目睹−感受−看见”:走心法,运用图片、视频、故事等形象化的元素,调动情绪的力量,创造共鸣;
想要改善什么,就把什么透明化!在走脑的同时又要走心,让团队的所有人都看见问题,调动起集体的关注力和改变的动力。这样的话,这种透明的力量,就会自然地推动变化的发生。
-
影响力:能让他人买账的这种影响力,对个体来说,就是说服力;对群体来说,就是感染力。影响力的真正秘诀却在于“听”,而不是“说”。 不听,是一切沟通问题的根源所在。要想增强影响力,需要首先培养“听”的能力
-
整合力:整合力就是把互相分离的部分连接在一起,使它们发挥出整体的作用。凡是能促进业务良性运作的,凡是能促进团队健康发展的,都是整合管理的范畴