mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-17 06:33:48 +08:00
del
This commit is contained in:
155
极客时间专栏/geek/项目管理实战20讲/软实力篇/16 | 向上沟通:你必须要注意的三个误区.md
Normal file
155
极客时间专栏/geek/项目管理实战20讲/软实力篇/16 | 向上沟通:你必须要注意的三个误区.md
Normal file
@@ -0,0 +1,155 @@
|
||||
<audio id="audio" title="16 | 向上沟通:你必须要注意的三个误区" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/18/07/180c2c480072259c5df71db4c2dbd807.mp3"></audio>
|
||||
|
||||
你好,我是雷蓓蓓。
|
||||
|
||||
根据多年的实践经验,我发现,项目管理不只是一种硬技能,更是一项软实力。就软实力而言,最重要的不是招式,而是内功。从这一讲开始,我就来教你修炼内功。
|
||||
|
||||
今天是“软实力篇”的第一讲,我会结合自己的亲身经历和我踩过的“坑”,来聊一聊向上沟通的三个误区。
|
||||
|
||||
## 误区一:所有问题,都自己扛!
|
||||
|
||||
不得不说,这一条,在技术人员中相当普遍。
|
||||
|
||||
在我还是个刚刚转岗的PM小菜鸟时,我负责管理一个项目,代号叫“KK”,这个项目是为公司的战略项目提供底层支撑的。
|
||||
|
||||
在跟进这个项目的前几个月里,我跟技术负责人阿仑配合得还算默契。但是,我发现他有个特点,就是所有问题,都自己扛。
|
||||
|
||||
距离里程碑发布只剩一周了,但在测试时,我们还在不断地发现新的Bug。以目前的进度和剩余Bug的潜在影响来看,按原计划上线,质量风险很高。
|
||||
|
||||
这天,开站会时,我请团队中的每个人,在白板上画出自己的发布信心指数。总体来看,情况非常不乐观。
|
||||
|
||||
我跟阿仑一起做好当天的安排之后,特意提醒他:“现在的情况不是很好,我们最好跟方雷提前报备一下。”我说的方雷,是这个项目的发起人,也是阿仑的上级。阿仑没有应声,转而找旁边的开发,开始讨论别的问题了。我心里很着急,但也只好作罢。
|
||||
|
||||
实际上,我的担忧并不是空穴来风。方雷曾经在很多个场合强调过,KK是今年的重点,稳定性更是重中之重。最近几次线上出问题,我们团队没少挨骂。这次的上线风险这么高,要不要及时告诉方雷呢?
|
||||
|
||||
我在方雷的办公室门前,绕了两个弯,各种纠结顾虑,再一想到方雷那严厉的神情,就打起了退堂鼓。最终,我什么都没说,就离开了。
|
||||
|
||||
新版本最后还是如期上线了,但我却并没有因此感到轻松。且不说遗留Bug的潜在风险,由于时间紧张,我们连线上监控都没做到位,也没时间充分考虑应急预案和演练。
|
||||
|
||||
正当团队全力补漏的时候,线上还是出事了:底层依赖的第三方服务报错,导致很多线上用户请求失败。大晚上接到客户侧的紧急电话,我们才知道出了事。
|
||||
|
||||
第二天,方雷在邮件里,劈头盖脸就责骂了我们一顿:“之前我一再强调监控,结果已经预见到的问题,你们都没有做应对,这是非常严重的人为事故!”
|
||||
|
||||
看到这里,你觉得我冤不冤呢?
|
||||
|
||||
其实,我明明知道这样上线会有很大问题,也明白现阶段最好的应对方式是什么,甚至还在心中打了无数的底稿,可以说服方雷调整上线计划。
|
||||
|
||||
可是,当我站在方雷的办公室门口时,却死活迈不出自己心里的那道坎,这个“坎”究竟是什么呢?
|
||||
|
||||
首先是层级差在无形之中给我带来的心理压力,包括方雷平日里强硬的作风,都让我有点怵,不自觉就想躲开。
|
||||
|
||||
其次,都快上线了,项目还有这么多问题,作为项目经理,我也是有很大责任的。
|
||||
|
||||
另外,因为阿仑不想去汇报,如果我汇报了,我会觉得像打小报告,不仗义。
|
||||
|
||||
实际上,做好一次紧急问题的汇报沟通,并不是什么难事。只要你按照我在[第7讲](https://time.geekbang.org/column/article/164235)中给出的沟通模板,组织好思路即可。
|
||||
|
||||
**但是,迈过自己内心的那道坎,主动大胆地发起沟通,是做好向上沟通的第一步**。
|
||||
|
||||
事实上,我们首先必须要明确,这类严重影响稳定性的问题,已经不属于可以自己扛的级别了,必须要让上级知晓。
|
||||
|
||||
明确了这一点,处理方式可以有很多种。比如,跟阿仑深入探讨下项目的处境,尝试说服他一起去找方雷。即便他不去,我也可以跟他说明自己的判断和接下来的行动,因为客观暴露风险,合理应对,这本身就是项目经理的职责所在。
|
||||
|
||||
当然,我也可以尝试用邮件的形式,发一封项目风险告警,客观描述现在的风险和影响,提醒方雷特别关注,等等。
|
||||
|
||||
这里的关键是,**不管通过什么途径,我们必须时刻从大局出发,让这些项目关键信息,及时有效地流动,保障及时有效的决策**。
|
||||
|
||||
当真正重要、紧急的事情发生时,直接打电话或走过去敲门,确保第一时间沟通,才是更合适的做法。**记住,你不需要所有问题,都自己扛**。
|
||||
|
||||
## 误区二:只知道吐槽,不知道争取
|
||||
|
||||
在KK项目组,连续加班是常有的事,半夜2点爬起来升级,也是家常便饭。即便我们的工作强度已经这么高了,线上仍然问题不断,项目组从上到下都压力很大。
|
||||
|
||||
在如此“恶劣”的生存环境中,团队成员彼此之间就好比“难兄难弟”,私底下经常一起吃饭。当然,少不了的,就是一起“吐槽”。
|
||||
|
||||
某个周末,又是一次通宵上线,我们忙到凌晨4点多钟,结果更新之后,出现了个突发情况,按照流程果断回退了。第二天,在定位解决问题后,又重新来过。在连续了两个通宵之后,项目得以成功上线,但团队却撑不住了。
|
||||
|
||||
在看不到尽头的艰苦境况中,吐槽似乎成了最有效的排解压力的方式。比如,我们可能经常听到这样的吐槽:“出了问题挨骂”“没出问题是应该的”……
|
||||
|
||||
刚开始,我也会跟着吐槽几句,因为我也一样,拼死拼活却得不到认可。可是,除了私下吐吐苦水,又能做什么呢?
|
||||
|
||||
你看,这就是我踩过的第二个“坑”。当团队和管理层之间关系紧张时,很多项目经理会特别容易掉进一个误区,那就是,**尽自己的努力帮团队解决问题,脏活累活都自己来**。
|
||||
|
||||
这样的“老好人”,在团队中会有很好的人缘,但是,跟着大家一起吐槽,似乎并不能带给团队真正的帮助。特别是当你同时受到高层压力的驱使,被迫去快速拿结果时,就很容易演变成“夹心饼”,吃苦受累,最后反而落得两头埋怨。
|
||||
|
||||
那么,破局的点在哪里呢?
|
||||
|
||||
**答案就是,把“夹心饼”变成“连接器”,成为高层干系人与团队之间紧密联系的纽带。**
|
||||
|
||||
事实上,经过层层汇报,高层干系人能够得到的一线团队的信息,相当有限。很多自上而下的决策,如果不能根据一线反馈,及时调整的话,就很容易走形,偏离本意。
|
||||
|
||||
作为项目经理,**当需要高层重视和支持的事件发生时,该出手时就得出手,引发高层关注,把团队最一手的相关动态信息及时传递给他,争取高层必要的支持,而不是跟着团队一起吐槽**。
|
||||
|
||||
所以,这一次,我立刻想到了方雷!我应该让他听到团队的声音,让他意识到,长期这样下去的严重影响。而且,他才是解开这个困境的最合适的人。
|
||||
|
||||
事实表明,方雷的介入,大大提升了团队士气。
|
||||
|
||||
## 误区三:抓不住重点,给不出方案
|
||||
|
||||
那么,我是怎么得到方雷的支持的呢?
|
||||
|
||||
某次会议散会之后,我叫住了他。我说:“我们团队最近加班很严重,已经连轴工作好几天了,这样下去,恐怕会……”我的话还没说完,方雷就毫不客气地打断了我,说:“现在这些年轻人,加几天班,就叫苦叫累的,想当年,我加班可多了去了……(此处省略一万字)”
|
||||
|
||||
你看,在得到方雷的支持之前,我又踩了一个“坑”,也就是我想说的第3个误区:**抓不住重点,给不出方案**。
|
||||
|
||||
“团队现在加班很严重”“团队任务不及时更新”“某某工作不主动、总是迟到”……**如果你只是这样反映问题,只是说这里不好、那里不好,却没有告诉他,为什么要关注这个问题的话,你的意见不仅不会得到重视,甚至还会产生反效果**。
|
||||
|
||||
高层干系人的时间往往很宝贵,所以,在沟通之前,做好充分的准备,是必不可少的。**你要反映的问题,与高层干系人的核心关注点是否相匹配,这是能否引起其关注并进一步行动的关键所在**。
|
||||
|
||||
**在向高层干系人提问题的同时,一定要给他一个明确的“点”,让他知道,为什么要关注这个问题**。在[第13讲](https://time.geekbang.org/column/article/170693)中,我跟你分享了一些抓住痛点的具体方法,如果你不记得了,可以再复习一下。
|
||||
|
||||
实际上,抓住了对方真正的核心关注点,你才能在后续的沟通中,更加有针对性地进行高效管理。
|
||||
|
||||
虽然我很了解方雷的脾气,但还是被刚刚这架势吓住了。还好,我提前就有所准备了。于是,我打开电脑,把准备好的数据摆在方雷面前,说:“你知道,**我们的线上质量是容不得半点闪失的**。这是我们团队前两个月的连续加班记录。
|
||||
|
||||
“有人曾经做过统计,连续加班三周,人的身体、心理、情绪都会降到谷底。现在团队已经连续加班和通宵两个月了。再加上每次上线的心理压力,这样下去,恐怕会很容易犯错。昨天这次上线,团队吸取了教训,最终还是很平稳的,也算是这么长时间以来一次小小的胜利了!我在想,我们是不是应该简单庆祝下,帮大家先从心理上减减压,鼓舞下士气,也好有一个新的开始?”
|
||||
|
||||
我一口气说完了事先准备好的“台词”,方雷先是有些吃惊,但他很快认可了我的判断。他说:“确实,我们得想办法鼓励下大家,而且一定要及时!”
|
||||
|
||||
我灵机一动,接着说:“嗯!我看今天就是一个很好的时机。我们正打算下午开复盘会,我这就去准备些零食饮料,可以的话,请你到场跟大家讲两句话吧!”
|
||||
|
||||
在复盘会上,方雷显然事先认真准备过。他从这个项目对大部门的重要性,讲到对大家的辛苦付出的感谢,再到绩效及奖励措施上的承诺。看得出来,他不太习惯公开说这么多鼓励的话,气氛稍有些诡异。
|
||||
|
||||
最后,他说:“我相信这次的成功只是一个开始,希望KK项目以此为始,步入一个正向循环,越做越好!”
|
||||
|
||||
方雷的这些话,让每个团队成员的脸上都呈现出了“难以置信又受宠若惊”的表情。最重要的是,在团队的共同努力下,这些话的的确确变成了现实。
|
||||
|
||||
你看,这次沟通就很有效,对吧?现在,我就来为你拆解一下,其中做得好的几个地方。
|
||||
|
||||
首先,我并没有因为方雷否定了自己的说法,就转向附和跟随,而是在坚持自己的观点的同时,快速改变策略,从方雷的核心关注“点”,也就是线上质量开始说起,一下子就抓住了方雷的心。
|
||||
|
||||
在经验、阅历等方面,项目经理可能会跟高层干系人有差距。但是,即使是这样,你也不要一味跟随,而是要努力成为他的“镜子”。高层领导也是人,是人,就有他的盲区。比如,他可能会因为信息不对称,做出错误的决策。这个时候,你就需要大胆说出来。
|
||||
|
||||
其次,我不止是空口说说,我还拿出了加班数据和事实结论作为“论点”,很好地阐释了为什么方雷要关注这个问题。这样清晰的逻辑表达,可以很好地帮助干系人快速地做出决策。
|
||||
|
||||
最后,对于自己提出的问题,我还**适时地给出了一个小小的“行动点”,也就是近在眼前的解决方案**:下午的复盘会,邀请方雷来为大家打气。
|
||||
|
||||
**针对提出的问题,列举可能的解决方案,这一点非常重要**。需要注意的是,你并不需要一下子给出完整的解决方案,因为这些问题通常已经超出你个人的能力范围。但即便如此,我依然强烈建议你,不要只是把锅甩给领导,而是在提出问题的同时,**给出前进一小步的解决方案,给领导,也给自己,一个小小的行动暗示**。
|
||||
|
||||
总之,想要抓住重点,高效沟通,你要记住三点:
|
||||
|
||||
- 找到“**核心关注点**”;
|
||||
- 用数据和事实来作“**论点**”;
|
||||
- 给出一个小小的“**行动点**”。
|
||||
|
||||
## 总结
|
||||
|
||||
今天,我结合我曾经的真实经历,跟你深入剖析了向上管理的三个误区。
|
||||
|
||||
- 第一个误区:所有问题,都自己扛。
|
||||
- 第二个误区:只知道吐槽,不知道争取。
|
||||
- 第三个误区:抓不住重点,给不出方案。
|
||||
|
||||
高层干系人,往往会对项目的成败起到决定性的作用,是项目经理需要重点管理的对象。优秀的向上管理能力,不只是对你个人有利,对于项目和团队来说,都是福音。
|
||||
|
||||
人们常说“直言不讳”,虽说毫无顾忌的坦率直言,精神可嘉,但同时呢,你也要懂得讲究方法,用对方听得进去的方式来讲,这就是门艺术了。
|
||||
|
||||
其实,不光是项目经理,向上沟通更是职场中的一堂必修课,需要勇气,更需要智慧!
|
||||
|
||||
## 畅所欲言
|
||||
|
||||
今天,我给你分享了三个误区,你对哪个误区比较有共鸣呢?另外,希望你能分享一下,自己在向上沟通的过程中踩过的“坑”,我们一起学习。最后,请你结合自身的项目情况,给自己制定一个向上沟通的行动计划。
|
||||
|
||||
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
|
||||
|
||||
|
||||
129
极客时间专栏/geek/项目管理实战20讲/软实力篇/17 | 跨部门沟通:怎么让不归你管的人积极配合你?.md
Normal file
129
极客时间专栏/geek/项目管理实战20讲/软实力篇/17 | 跨部门沟通:怎么让不归你管的人积极配合你?.md
Normal file
@@ -0,0 +1,129 @@
|
||||
<audio id="audio" title="17 | 跨部门沟通:怎么让不归你管的人积极配合你?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/dc/32/dce4709cd0f35c16843ccfe866eeb932.mp3"></audio>
|
||||
|
||||
你好,我是雷蓓蓓。这一讲,我们来聊聊跨部门沟通。
|
||||
|
||||
曾经,有位程序员跟我说:“我们自己内部的进度都很好管,可是,一旦涉及到跨部门合作,管起来就很困难。人家又不归我们管,不可控因素太多了。如果在合作的过程中,出现了什么问题,拿他们也没办法。针对这种情况,你说怎么办呢?”
|
||||
|
||||
其实,人类社会的很多冲突,都始于“边界”二字。比如,部门与部门之间存在边界,所以就有了“部门墙”。别看只是跨了个部门,各项沟通的复杂度就会直线上升。
|
||||
|
||||
为啥呢?不是“自己人”了啊。那么,我们该如何应对跨部门沟通的问题呢?我跟你分享两种方法。
|
||||
|
||||
- 约法三章,先说清楚。
|
||||
- 打开边界,一起想办法。
|
||||
|
||||
## 约法三章,先说清楚
|
||||
|
||||
我们先来看看第一种:约法三章。既然不是自己人,那就要分清楚哪些事情该我干,哪些该你干。那么,该如何约法三章呢?
|
||||
|
||||
**第一步:建立君子协定**
|
||||
|
||||
在合作前,你要跟对方建立合约,明确**合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人**。建立合约时,要由双方负责人进行邮件确认,公开做出正式的承诺。
|
||||
|
||||
需要注意的是,**在刚开始合作时,建立稳定的预期是关键,双方责任及进度要求,必须要得到公开确认**。否则,这些问题如果不明不白的话,就会给后续工作带来极大的隐患。
|
||||
|
||||
我给你分享一份合作说明书的示例文档。你可以点击[网盘链接](https://pan.baidu.com/s/1PFIvDLnvYypmF6k2XhbuJw)获取,提取码是35qw。这是某公共技术部门与某事业部达成的战略合作,里面清晰地约定了合作内容、具体需求及总体进度计划。这份文档就需要两个部门的最高领导通过邮件进行确认。
|
||||
|
||||
必要的时候,可以筹备、召开一个跨部门的项目启动会,邀请双方的领导层参与,通过这种正式的仪式,让合作项目成为大家共同的目标。
|
||||
|
||||
为什么很多公司级的战略合作都会举办一个签字仪式呢?其实,这就是因为**承诺越公开,越正式,日后对双方的约束效力就越大**。
|
||||
|
||||
**第二步:建立机制**
|
||||
|
||||
万万不要以为,签完合约就万事大吉了。
|
||||
|
||||
曾经,我们就遇到这样的情况:眼看着要到联调的Deadline了,对方的任务还没完成。我问了对方之后,才知道,说好的功能接口不能准时交付了。他们给出了很多原因,比如,工作比想象得复杂,还有人员休产假、离职等等。
|
||||
|
||||
在项目进行中,各种情况都有可能发生,只有及时获知、甚至是提前预知风险,才能让项目始终保持可控。
|
||||
|
||||
**合作建立之后,需要建立常规的沟通机制来持续推动**。比如,项目信息开放共享,每周在固定的时间开碰头会,双方相关人员交流工作进展及风险情况。更进一步的话,你还可以借助标准的任务管理和文档管理工具,对项目任务和文档做到统一的流程化管理,在过程中确保及时地跟进检查。
|
||||
|
||||
常规机制及工具搭建好之后,在运行过程中,你还需要经常自检,确认下流程上是否有疏忽的地方。比如,**是否存在“三不管”地带?每个依赖任务的职责是否明确,责任是否具体到个人?**
|
||||
|
||||
如果你发现了模糊地带的存在,要及时明确需要共同协作的内容是什么,该由哪个部门、哪个人负责,做到权责分明和分工合理,避免后期出现相互推诿、扯皮的情况。
|
||||
|
||||
**第三步:解决问题**
|
||||
|
||||
通过周期检查,我们可以及时发现问题。但是,如果事先约定好了,并做了周期检查,对方负责的事情还是出问题了,该怎么办呢?
|
||||
|
||||
有同学会说:“找他们领导!”在跨部门沟通中,打出领导牌的确会起到一定的作用,但是,这张牌属于“王炸”,不到特别时刻,不要随便拿出来用。
|
||||
|
||||
在找领导之前,建议你先自己摸清楚状况,**尽快启动风险应对机制,确定问题处理方案**,比如改变方案、调整时间、增加资源、减少范围等。
|
||||
|
||||
另外,你要把问题和相应的决议结果抄送给双方的负责人,让双方清楚问题对整体项目的影响及调整方案。同时,你还要明确的是,**今后要采取哪些预防措施,以避免问题的再次发生**。
|
||||
|
||||
那么,什么时候该找领导呢?
|
||||
|
||||
我曾经就遇到过一种情况:两边的领导已经达成了正式的约定,但是,不是每个牵涉进去的协作方都会立马配合。
|
||||
|
||||
原因有很多,比如,这个部门的KPI早就定义好了,目前上面的领导虽然认可了合作方案,但是没改KPI,原来的目标依然有效。对于这部分新增的工作,他们要额外投人去做。因此,他们非常担心,虽然增加了工作量,但产出却不受领导的重视。
|
||||
|
||||
类似这种会影响合作落地的根本机制问题,你就需要引入双方的领导,来一起研究解决方案。比如,在双方的绩效考核指标中,加入跨部门利益的指标,来强化这种目标和利益的捆绑,让双方真正把劲往一处使。
|
||||
|
||||
我们总结一下“约法三章式”跨部门沟通的要点。首先,在项目合作开始时,要努力争取合作部门上级领导的支持,达成明确公开的“君子协议”,建立稳定的合作预期。然后,你要建立周期检查机制和标准化的流程,而不是想起来才问一句。最后,对于执行过程中的问题,及时跟进解决,对于涉及合作机制类的问题,要及时请双方领导介入进来。
|
||||
|
||||
## 打开边界,一起想办法
|
||||
|
||||
“约法三章”,可以说是最为常见的一种跨部门沟通的应对方式。接下来,我们再来看看第二种方法:打开边界,一起想办法。尽管不是自己人,咱还是要把对方当成自己人看待,好,就一起好;出了问题,大家就一起扛。
|
||||
|
||||
为什么说跨部门沟通还需要打开边界呢?我给你分享一个我经历过的项目,你就明白了。
|
||||
|
||||
X项目是一个非常典型的跨部门、跨职能的大型项目集,项目组人员接近两百个,涉及到的跨职能小组就有12个。由于技术复杂性,各模块之间的依赖和耦合很强,再加上各业务模块都有自己的目标和优先级,跨部门沟通的成本很高。
|
||||
|
||||
在这样的背景下,每个业务模块都反馈说:“跨部门协调这个事,太难了。”一个很小的改进,可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个会议,要想把人叫齐,都颇费周折。
|
||||
|
||||
这种跨部门的协作,已经融入到每一天的工作中了。这时,“约法三章”的沟通方式,显然已经不适合我们了。那怎么办呢?
|
||||
|
||||
**首先,要建立统一、清晰的节奏感。**
|
||||
|
||||
你需要结合不同业务模块的功能、相互之间的依赖关系,来为各个业务模块设计统一的交付节奏,也就是根据项目中的关键依赖,把交付时间错开排布。
|
||||
|
||||
比如,在X项目中,我们在每个月固定设置了四个发布窗口,分别是5号、10号、15号和20号。接着,根据这12个模块的先后依赖关系,我们把它们安排在不同的窗口进行发布。
|
||||
|
||||
在此之前,这些模块的发布时间都是自行定义的,现在,每月有了统一的规划和交付节奏,协同复杂度降低了很多,因为彼此之间有了稳定的交付预期和协同基准。
|
||||
|
||||
需要注意的是,节奏的设定没有固定模式可循,你需要在自己的情境中,尝试总结规律,并把它们固化下来。有一个指示性的指标,就是**重新设定节奏之后,如果跨部门协调的问题明显变少了,那么,当前这个节奏就是更合适的**。
|
||||
|
||||
**其次,想要打开边界,你还需要主动往前一步。**
|
||||
|
||||
对于这个项目集里的12个子业务模块来说,每个模块既可能是底层服务的用户,同时又是上层服务的依赖方,彼此互为上下游。在这样的情况下,如果没有彼此的通力合作,那就谁也做不好。
|
||||
|
||||
曾经,我见过两个部门的负责人来来回回地在邮件里争吵,据理力争地互怼。后来,因为实在无法直接沟通了,他们就跟我说:“给我们加个项目经理吧。”
|
||||
|
||||
在了解了需求之后,我发现,每个模块的日子都不好过,要么是被需求的反复弄得焦头烂额,一肚子怨气,说:“明明之前都约定好了,需求还是说变就变。我辛辛苦苦做出来了,说不用就不用,全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地,纷纷吐槽:“底层服务又出问题,害我挨用户一顿臭骂。整天出问题,真是拿我们当小白鼠。”
|
||||
|
||||
不管是哪一方,每个人都盯着别人的问题,同时捂住自己的问题。像这样的情况,就算是再放10个项目经理,估计都很难从整体上改善局面。那么,该怎么办呢?
|
||||
|
||||
在和项目集的高层领导一起深入地剖析了现状之后,我们都认为,“头痛医头,脚痛医脚”的方式,并不是我们想要寻求的解决方案。
|
||||
|
||||
于是,我们在Leader层发起了一次跨部门的交流讨论,取名为“上有老,下有小”,意思是,在这个项目集生态里,各个模块是层层嵌套在一起的,每个模块都在持续建设中,还远未成熟。上面,有人要调用我的服务;下面,我要依赖另外一个服务提供底层能力。每个模块都是“上有老,下有小”,如果我们想要获得整体改善,该怎么做?
|
||||
|
||||
我们收集了大家的改进建议,并进行了统一整理,形成了我们所定义的“担当力模型”(如下图所示)。这个模型总共分为四层,它们分别描述了我们在遇到跨部门沟通的问题时的四种不同心态和行为。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/28/a0/28d1887e744f28392b5b24f686b4a3a0.jpg" alt="">
|
||||
|
||||
- 第一层:放弃。这背后的心态是:“见怪不怪,反正我已经绝望了。”抱着这种心态,于是,你就什么都没做。
|
||||
- 第二层;责怪。这背后的心理是:“你怎么搞的,每次都这样?”这样想着,你依然是,什么都没做。
|
||||
- 第三层:完成任务。这背后的心态是:“真是不省心,下次我得特意盯着你点!”抱着这种完成任务的心态,你会针对问题做全面的排查,增强对应的监控。
|
||||
- 第四层:担当。这一层的表现是:“出问题不可怕,但我们绝对不能再犯同一个错误。”你会把错误当作完善的机会,帮助用户方和依赖方共同成长。
|
||||
|
||||
我们把真正的担当解释为“上敬老,下爱小”。什么意思呢?上敬老,是说对于用户方,你要去主动深挖用户方的需求及业务背景,走在用户前面;下爱小,是指对于依赖方,你要全面监控、必要容错、并帮助它不断改进。
|
||||
|
||||
通过这次的深入讨论,我们认识到,只有各个模块都往前走一步,才能够引发系统的改善。与其去责怪对方,不如跟他一起找到合作共赢的方式,最终让所有人获益。这四层担当力模型,本质上是心态上的差异,而每次主动往前一步,最终必将体现到工作的长期效果上,从而形成持久化差异。
|
||||
|
||||
## 总结
|
||||
|
||||
今天,我介绍了跨部门沟通的两种应对之道,分别是约法三章,先说清楚,以及打开边界,一起想办法。那么,我们怎么区分什么时候该使用哪种方式呢?
|
||||
|
||||
答案就是,**看双方之间的依赖关系和合作性质**。如果更多是单方面依赖、单方面受益,且是一次性的合作,第一种方式会更加适合。如果是互相依赖,而且是长期合作的共生关系,那么,你就不能只考虑短期利益了。你要从长期的合作关系着眼,建立协同共荣的生态。需要注意的是,这两种方式并不一定是非此即彼的,你也可以结合起来使用。
|
||||
|
||||
跨部门协作之所以很难,究其根源,就在于边界所引发的“分别心”,也就是你是你,我是我。如果执着于你我之间的“界限”,必然会导致各种摩擦。也正因为这样,在跨部门合作时,你需要付出更多的努力,在保障项目推进的同时,用心经营、维护良好的合作关系。
|
||||
|
||||
共同目标、利益捆绑、流程约束是基础,除此之外,你还需要更加开放的心态,去找到更多合作共赢的方式,共同做大事业。
|
||||
|
||||
## 畅所欲言
|
||||
|
||||
在跨部门沟通上,你有什么很好的经验吗?
|
||||
|
||||
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
|
||||
|
||||
|
||||
109
极客时间专栏/geek/项目管理实战20讲/软实力篇/18 | 向下沟通(上):无权无势,他们不听你的怎么办?.md
Normal file
109
极客时间专栏/geek/项目管理实战20讲/软实力篇/18 | 向下沟通(上):无权无势,他们不听你的怎么办?.md
Normal file
@@ -0,0 +1,109 @@
|
||||
<audio id="audio" title="18 | 向下沟通(上):无权无势,他们不听你的怎么办?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/21/ca/216e39b938f82520a56ba4fde3180cca.mp3"></audio>
|
||||
|
||||
你好,我是雷蓓蓓。
|
||||
|
||||
在做项目管理的前几年时间里,我经常会听到一种声音:“项目经理无权无势,不就是个打杂的吗?”老实说,刚开始从小白起步时,我也经常有这样的困惑。
|
||||
|
||||
没有权力,却要承担很大的责任,还得让别人愿意听我的,互相配合着把事情做好,难度真的非常高。但正因为这样,我们项目管理部的项目经理们,在这些磨练中,个个都发展出了一身武艺。这其中最厉害的一项本事,叫作“**非职权领导力**”。
|
||||
|
||||
今天我们就来聊一聊,如何在团队中让自己拥有更大的Power。
|
||||
|
||||
在大量的实践中,我逐步总结梳理出了**非职权领导力的六力模型**。“六力”分别是**执行力、信息力、感知力、透明力、影响力和整合力**,这六力是层层递进的关系,代表了非职权领导力发展之路上的六个层次。
|
||||
|
||||
在接下来的两讲内容中,我就围绕着这“六力”,来跟你分享一下向下沟通的正确方法。我们今天先来看前“三力”,即**执行力、信息力和感知力。**
|
||||
|
||||
## 执行力
|
||||
|
||||
执行力是非职权领导力的根基,俗称“靠谱”,这是项目经理的立身之本。我们判断一个人是否靠谱,往往是在说这个人是否具有两个特征:主动担责和有始有终。
|
||||
|
||||
1.**主动担责**
|
||||
|
||||
管好自己的一亩三分地,并非就是执行力好。
|
||||
|
||||
比如,我见过很多策划,在写好策划案之后就甩手不管了。但是,我曾遇到过这样一位策划,他不仅把自己的本职工作做得很出色,还会帮忙给所有策划制作一张总进度表,即时同步信息,汇报进展。
|
||||
|
||||
如果中间过程出现了问题,比如开发跟测试发生了冲突,他也会主动想办法协调解决,推进项目落地。
|
||||
|
||||
一段时间后,他被Leader点名表扬,很快从几个同级中脱颖而出,得到了晋升。我问他:“你为啥做这么多事?”他笑笑说:“也没啥,我就是很想看到整个产品都做得很好,不能忍受有些环节出了问题没人管,没人上,那就我上呗。”
|
||||
|
||||
所以,你看,执行力的第一层,并没有什么神奇的,你首先需要跳出自己的小圈圈,主动承担更大的责任,而不是眼睁睁地看着项目出现问题,放手不管。
|
||||
|
||||
2.**有始有终**
|
||||
|
||||
言必信,行必果。交给你的任何事情,都有始有终。当很多人都只是在完成任务时,如果你懂得闭环的重要性,势必会事半功倍!
|
||||
|
||||
关于这一点,我想跟你分享一下我的第一位项目管理导师给我上的宝贵一课。
|
||||
|
||||
当时,我在团队中发起了一项“零Bug”的改进活动,后来因为一些原因没有坚持做下去。她在了解了情况之后,很严厉地跟我说:“作为一个项目经理,你发起的任何一件事都要有‘Close’的动作。你既然跟团队讲过要做这件事,现在不做了,就算自认为原因再合理,都需要给大家一个交待,而不是不声不响地就停止了。”
|
||||
|
||||
实际上,**一个有始有终的闭环,意味着你要对自己的每一个行为负责,清楚地了解为什么做,目标是什么,做完之后效果是怎样的,还有什么问题,以后要做哪些改进。如果中途有变化,也要及时跟相关方明确说明调整或取消的原因是什么**。
|
||||
|
||||
总结一下,想要做一个“靠谱”的人,我给了你两条建议:第一,跨出自己的边界,主动担责;第二,言必信,行必果,做事情有始有终。
|
||||
|
||||
一屋不扫,何以扫天下?执行力可以说是你能够影响他人,继而具备非职权领导力的根本。
|
||||
|
||||
## 信息力
|
||||
|
||||
在大数据时代,**谁掌握着数据和信息,谁就拥有更强大的力量和权力**。由于自身的职责和信息渠道的便利,项目管理人员会很容易成为团队中拥有最大信息量的人。大到全局的战略、项目的初衷和发展方向、决策的起因和前后变迁,小到每个团队每天在干什么,都尽在项目管理人员的掌控之中。因此,项目经理就好比是项目信息的交换中心。
|
||||
|
||||
我曾遇到过一个项目经理,他就拥有这种神通广大的信息力。不只是项目组里,甚至是公司里上上下下发生的事情,他都能第一时间获悉。所以,遇到拿不定主意的事情时,我经常向他打听消息。
|
||||
|
||||
有一次,我忍不住问他:“你到底是怎么做到的?”他说:“没什么神秘的,我这个就是好奇心强,而且比较热心。我对别人很感兴趣,就会经常跟大家多聊几句,不管聊的东西有没有用,我都记得清清楚楚。而且,我还特别喜欢帮助别人。比如,我觉得某个机会适合某某,我就会推荐他去试试看。久而久之,大家就会主动给我提供信息,让我帮忙出谋划策,所以我就成了最有信息力的人啦!”
|
||||
|
||||
当然,信息力可不只是掌握简单的八卦,而是**要让流动的信息汇聚起来**。作为初学者,你可以通过**信息互通机制和平台**来帮助自己做到这一点。比如,**周会、站会、周报、邮件列表、通讯群,甚至是各类数据平台,都可以成为信息力的承载**。
|
||||
|
||||
除此之外,能够**让非正式信息自动流向你**,就属于内功的范畴了。在与人交往与合作时,好奇、关心、真诚、友善……这些特质都会帮助你构建起信任基础。连接多了,覆盖面广了,自然会形成规模效应和网络效应,这时就会产生信息力的红利了。
|
||||
|
||||
## 感知力
|
||||
|
||||
感知力建立在信息力的基础之上,不同的是,**感知力是对“冰山下”隐性信息的敏锐度**。这种对系统敏锐的感知判断,俗称“闻味道”。
|
||||
|
||||
据说,马云就是个“闻味道”的高手。如果他出差一个月不在公司,那么,他回公司之后做的第一件事,就是把十层楼的办公区都跑一遍,然后找副总们开会,精准地说出公司存在的问题,观察之细密往往让人佩服至极。
|
||||
|
||||
感知力是日积月累的功力,但也并不是什么深奥的功夫,你也可以做得到,重点就是平常在开会时,你要多练习、多观察。
|
||||
|
||||
举个例子,某业务负责人请我给他的管理层做一次共创会,请大家根据总体规划,各个角色共同定义下半年各自的工作重点。拿到这个需求之后,我先跟几个管理者开了一次沟通会。
|
||||
|
||||
会后,我找到这位负责人,跟他同步了我对管理团队的观察,并且提出了我的共创方案:“在这次共创之前,我们必须先有个复盘环节,否则,以咱们团队现在的这种合作状态,根本没法很好地共创。咱们得提前准备,我需要你的大力配合。”
|
||||
|
||||
他很快就认可了我的方案,并且惊讶地问我:“你是怎么做到在这么的短时间内捕捉到这么多复杂的背景信息的?”
|
||||
|
||||
你可能也很好奇,事实上,这就是感知力在现实场景中的运用。要想培养感知力,你需要经历三个层次。
|
||||
|
||||
**第一层:现象层。这一层观察的焦点,是在“冰山上”的行为**。比如,你观察到开发和产品在会上吵起来了,这时,你注意到的是行为,还不是真正的感知。
|
||||
|
||||
**第二层:意图层。这一层观察的焦点,是在“冰山下”行为背后的真正意图。具体要怎么做呢?最简单的是,多问几个为什么**。比如,他们为什么会吵起来,各自想要达成什么目标。仔细思考之后,你会发现,原来技术已经对于产品的频繁变更忍无可忍了,技术Leader有很大的压力,想要为受苦受难的开发们出头;而产品的意图也很直接,他们的想法是:“业务KPI在那儿摆着,咱能不能别那么磨叽?快速推进不行吗?”观察到这一层,你就很接近冲突的根源了。
|
||||
|
||||
**第三层:感受层。你要试着从这些现象和意图中,去感受每个人的状态和需要**。你会发现,开发的核心感受显然是愤怒;产品直接承担着业务指标带来的高压,老大的想法又一直在变,技术的不配合让他们受到双面夹击,早已是苦不堪言,核心感受是苦涩。
|
||||
|
||||
体会到这些之后,你会发现,如果不事先处理好这些强烈的感受,这些人是根本没有办法在一起很好地进行共创的。
|
||||
|
||||
于是,在共创开始前,我安排了一个之前提到过的复盘环节,就是让每个成员画出自己从项目启动以来的状态、经历,并把其中的“高光时刻”和“至暗时刻”分享给大家。
|
||||
|
||||
当天,这位负责人第一个发言,跟大家分享了开创新业务以来自己的坎坷经历。他的开放和坦诚让大家一下子轻松了许多。
|
||||
|
||||
接着,轮到产品,她提到了刚上线就被苹果推荐的成就和喜悦,同时又分享了最近“两头受夹板气”的惨痛经历。开发同学则拿出自己的画,说自己自始至终都是“压力山大”,从来都没轻松过……就这样,大家开始一点点地敞开了心扉。
|
||||
|
||||
那些平时看不到的真实一面,被集体看见和理解之后,团队内部淤积的压力也终于得到了释放。于是,大家开始聚焦在共创下一步真正有效的解决方案。
|
||||
|
||||
**总之,要想培养感知力,就要在日常的观察之中下功夫。从关注行为,到关注行为背后的意图,再到关注意图背后个体的核心感受和深层需要,最后着眼于团队中的气场和互动品质**。
|
||||
|
||||
这样一来,你就能找到“四两拨千斤”的杠杆点,从“救火式”的应对问题,变成“治未病”的先知先觉,从而在团队中积累起自己的独特影响力。
|
||||
|
||||
## 总结
|
||||
|
||||
回到题目中的问题,“项目经理无权无势,别人不听你的怎么办?”如果你想靠自己的力量,让别人真心信服,并没有捷径可走。你只能从自身做起,在一点一滴的行动中,从头构建非职权领导力。
|
||||
|
||||
今天,我跟你分享了非职权领导力“六力模型”中的前“三力”,分别是执行力、信息力和感知力。可以说,执行力是所有一切的根基。正人先正己,项目经理要影响别人正确地做事,自己就要先要成为标杆,严格约束自己的一言一行。
|
||||
|
||||
信息力和感知力,则是对项目和团队的现状做重新的审视和梳理,是对于环境的观察、观察、再观察。一个有经验的项目经理,可以通过信息搜集和观察感知,“闻”出一个团队的味道,快速定位到问题点。观察的角度、深度、广度,会极大地影响你接下来选择的行动方案。
|
||||
|
||||
问题的解决也见功力。“头痛医头、脚痛医脚”的做法,往往治标不治本。在下一讲中,我会接着往下剖析,跟你分享如何运用观察到的事实、信息、数据,有效地影响和整合团队力量。
|
||||
|
||||
## 畅所欲言
|
||||
|
||||
对照着非职权领导力的“六力模型”,分析一下,哪些力是你最擅长的?哪些力是当前最缺失的?另外,请你谈一谈学习这节课的收获或者是你的困惑。
|
||||
|
||||
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
|
||||
|
||||
|
||||
107
极客时间专栏/geek/项目管理实战20讲/软实力篇/19 | 向下沟通(下):无权无势,他们不听你的怎么办?.md
Normal file
107
极客时间专栏/geek/项目管理实战20讲/软实力篇/19 | 向下沟通(下):无权无势,他们不听你的怎么办?.md
Normal file
@@ -0,0 +1,107 @@
|
||||
<audio id="audio" title="19 | 向下沟通(下):无权无势,他们不听你的怎么办?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/63/942bedd09407576fe31366be54e8d163.mp3"></audio>
|
||||
|
||||
你好,我是雷蓓蓓。
|
||||
|
||||
上一讲,我给你介绍了非职权领导力“六力模型”中的前“三力”,分别是执行力、信息力和感知力。今天,我们接着来看后面的“三力”。
|
||||
|
||||
## 透明力
|
||||
|
||||
我在上一讲中提到过,信息力和感知力是对环境的观察、观察、再观察。你需要注意的是,这些观察的结果只有透明出来,才能发挥效用。你要想办法把你看到的问题可视化,让决策者和团队都能看到这些问题。这就是我经常说到的透明的力量。
|
||||
|
||||
那么,怎么运用透明的力量呢?我给你讲个例子,你就明白了。
|
||||
|
||||
我在一个团队中经常听到这样的声音:“搞什么需求评审、交互评审?要做什么先说好,然后就别再来烦我了。让我安静地写会儿代码,不行吗?”
|
||||
|
||||
于是,这些评审会能不开就不开。结果,在Deadline之前,需求稿、设计稿和技术方案的问题不断爆发,要熬上好几个通宵,才能保证版本的正常发布。但是到了下一个版本,情况依然如此,循环往复。
|
||||
|
||||
经过仔细了解,我发现,如果在早期投入精力的话,这些导致发布延期的大多数问题都是可以有效避免的,发布的风险也会大大降低。
|
||||
|
||||
实际上,定位问题并不难,但是要想解决这个问题就很难了。因为这个团队三四年来一直都是这样,他们早就已经习惯这种模式了。**想要引发改变,不是仅凭一人之力就可以做得到的。要打破这个恶性循环,就一定得让大家真正地看见问题,并且从心底里达成共识**。
|
||||
|
||||
我教你两个透明化呈现的方法:一个是“**分析−思考−看见**”,一个是“**目睹−感受−看见**”。前者走脑,是指借助数据、事实、逻辑分析等,调动头脑的智慧,创造共识;后者走心,是指运用图片、视频、故事等形象化的元素,调动情绪的力量,创造共鸣。如果你能结合起来用,效果会更好。
|
||||
|
||||
看到这里,你可能会问,我是怎么解决那个项目的问题的呢?
|
||||
|
||||
在一次版本总结回顾时,我给大家讲了一个“熊猫大侠”的故事。这位“熊猫大侠”是一个苦兮兮的程序员,他有着熊猫一样的黑眼圈,他的黑眼圈是怎么来的呢?
|
||||
|
||||
我以这个问题为切入点,以故事的形式**带领大家回顾了整个版本进行过程中的一幕幕场景**,从上个版本结束时的“累觉不爱”,需求评审会上的睡意朦胧,讲到提测前对设计方案的争执不下,最后到上线前的“兵荒马乱”。“熊猫大侠”的故事,使团队成员深度地看到了项目的现状,并产生了共鸣。
|
||||
|
||||
接着,我**晒出了各种过程数据**,包括需求变更率、需求和设计问题发生的阶段及成本、各阶段等待时间、研发负荷度等,邀请团队一起来想办法解开Deadline的“魔咒”。
|
||||
|
||||
看见这些事实和数据之后,大家才真正地意识到早期那些看似无聊的评审工作的重要性。除此之外,团队还进一步定义了各角色的协作规则,以达到更合理的节奏。
|
||||
|
||||
最后,在团队的共同努力下,我们进一步建立了基于过程数据的效能改进机制,各角色的协同状况得到了持续的改善。
|
||||
|
||||
所以,你看,**想要改善什么,就把什么透明化!在走脑的同时又要走心,让团队的所有人都看见问题,调动起集体的关注力和改变的动力**。这样的话,这种透明的力量就会自然地推动变化的发生。
|
||||
|
||||
## 影响力
|
||||
|
||||
项目经理无权无势,行走江湖,靠的是大家肯买你的账。能让他人买账的这种影响力,对个体来说,就是说服力;对群体来说,就是感染力。
|
||||
|
||||
人们通常认为,要想提升影响力,一定要能讲,会讲。但很有意思的是,**影响力的真正秘诀却在于“听”,而不是“讲”。**
|
||||
|
||||
举个例子,我们在听马丁·路德·金的演讲时,往往会觉得非常震撼。这是因为,真正能够征服人心的演讲都具有强大的说服力和感染力,而这些都是建立在对听众的深度理解的基础之上的。因为理解,所以才能创造共鸣。如果演讲者自己激情澎湃,但听众并不受用,那根本就无法产生真正的影响力。
|
||||
|
||||
我曾经跟一位产品总监合作,他本人聪明又强势,属于公认的特别难搞的类型。有一次,他主动跟我说:“别人跟我讲话,我向来只听两句就忍不住想打断,但是你说的话,我几乎全都听完了。”
|
||||
|
||||
他之所以会这样说,并不是因为我的表达能力比别人强、我的逻辑更清晰、我的话更有道理,而是因为在他讲话的时候,我做到了**真正的听**。跟其他人相比,我更懂他的逻辑,我明白他是出于什么样的考虑,才会那么说、那么做的。**我给他提的每一条建议都是建立在我对他的理解之上的,所以才能被他听进去**。
|
||||
|
||||
**不听,是一切沟通问题的根源**。要想增强你的影响力,你需要先培养“听”的能力。那么,该怎么培养这种能力呢?
|
||||
|
||||
我给你分享一个小技巧。你可以找一位项目中的成员,请他聊一聊,在最近的工作中,他有没有什么高兴或者烦恼的事。在听他说话的时候,你一定不要打断他,也不需要特意去想自己该怎么回应。
|
||||
|
||||
你只要简单地把注意力放在对方身上,清空你的思绪,打开你的所有感官,留心去体会对方的状态和需求就可以了。试着保持至少五分钟的专注,并在结束后记录自己的体会。
|
||||
|
||||
同时,我鼓励你跟对方分享一下,在刚刚的对话中,你留意到了什么。另外,你也可以跟他沟通下,有没有什么事情是你可以帮他一起做的。
|
||||
|
||||
实际上,在真正有说服力的对话中,恰恰并不存在什么“一定要去说服”的想法,这又是一个有意思的悖论。
|
||||
|
||||
实际上,只有当你真诚地抱着想要了解和倾听对方的愿望,放下对自己的想法的执着时,你才能留意到对方真正的需要。**这样自然的交流分享,反而更容易产生碰撞,引发共振**。
|
||||
|
||||
如果你能够在你的每次工作对话中有意识地坚持运用这个小练习,半年之后,你的影响力就能够得到很大的提升。
|
||||
|
||||
## 整合力
|
||||
|
||||
在一个业务团队中,除了总负责人之外,项目经理往往是唯一站在全局层面的人。毕竟,其他人都各有各的职责分工。在这样的定位之下,项目经理一定要成为一个“多面手”。因此,**优秀的全局整合能力非常关键**。
|
||||
|
||||
简单来说,整合力就是把互相分离的部分连接在一起,使它们发挥出整体作用的力量。**一群优秀的人结合在一起,也并不一定能成为一个优秀的团队,不一定能真的做成一个业务**。
|
||||
|
||||
作为项目经理,整合力就意味着你要去主动发现项目组中的各类风险和问题,综合运用各种能力,跨部门、跨角色地整合资源,以实现全链条的共同目标。
|
||||
|
||||
关于整合力,我定义了两个“凡是”:**凡是能促进业务良性运作的,凡是能促进团队健康发展的,都是整合管理的范畴。**
|
||||
|
||||
举个例子,我身边有个项目曾经遭遇到了发展上的瓶颈,军心溃散,士气低落,这时,我就变身成了教练,借助教练技术,给业务负责人及核心团队“照镜子”,帮助他们看到限制他们的模式到底是什么,促发团队进行深度思考和交流,共同梳理出当前局面之下最好的思路和打法,从而帮助团队更好地走出困境。
|
||||
|
||||
所以,你看,所谓的整合力,就是不受限于你自己的角色、从头到尾把事做成的能力。这种整合力来源于你对项目环境的观察和感知,最后要落地到全局层面的行动中去。
|
||||
|
||||
## 总结
|
||||
|
||||
好了, 我们来对这两讲的内容进行一下总结。如何让自己在团队中拥有更大的影响力呢?“六力模型”为你提供了一个知行合一的框架。
|
||||
|
||||
在“六力模型”中,执行力是从现在的“行”开始,想要影响别人,就要先做好自己,走出自己的小圈圈,去承担更大的职责,并且把你在日常执行中遇到的每一个问题,都视为一个开启新循环的机会。
|
||||
|
||||
信息力和感知力是指你要不断拓展自己对环境的准确认知和把握,观察、观察、再观察,从复杂的系统中找到一个恰当的发力点,通过把它有效地透明出来,让集体共同看见,从而获取新的共识,也就是新知。
|
||||
|
||||
最后,你还需要通过影响力和整合力去践行这个新知,反向影响和改造环境,最终推进新知的有效落地。
|
||||
|
||||
## 实践中的“六力模型”
|
||||
|
||||
讲到这里,关于实战的内容基本上就到尾声了。你还记得我在[第5讲](https://time.geekbang.org/column/article/162272)中提到的刚刚升任项目经理的小勤吗?
|
||||
|
||||
我们再见面时,她的气质变了很多,给人一种更有力的感觉。她说,“六力模型”对她帮助很大。之前,她发现产品的问题不是在于研发环节,而是在于销售和研发环节的脱节,可是她很难改变这个现状,她担心直接指出问题的话会得罪别人。
|
||||
|
||||
在把研发过程梳理清楚之后,她开始着手收集相关的数据,并且做了大量的调研和分析,摸清问题对整体的影响(**信息力**),然后去感知项目中各个角色的声音和诉求,这让她找到了最迫切想要改变的力量(**感知力**)。接着,她想办法把问题透明给销售主管及各部门的负责人,引发了更大的关注(**透明力**)。除此之外,她还主动找各方讨论可能的应对方案,促成变化的发生(**影响力**)。最终,她推动这件事被列为部门下个阶段的重点改进目标之一(**整合力**)。
|
||||
|
||||
现在,这个销售环节的漏洞早已被堵上了,销售和研发之间的衔接流程更加规范化、透明化,甚至还因此增加了相应的考核项。
|
||||
|
||||
小勤用自己的实践给我们展示了“六力模型”的魔力。这个知行合一的闭环,是从“行”开始,到让团队获得“新知”,再落地到“行”的转变过程。很显然,这个过程让小勤在团队中积攒了更大的影响力!
|
||||
|
||||
我们一起学习了这么久,希望你也能有和小勤一样的变化,如果是这样的话,那就是我最满足的事情啦。
|
||||
|
||||
## 畅所欲言
|
||||
|
||||
我给你介绍了向上沟通、跨部门沟通、向下沟通的各种方法,现在,关于项目中的各类沟通,你还有什么问题吗?
|
||||
|
||||
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
|
||||
|
||||
|
||||
145
极客时间专栏/geek/项目管理实战20讲/软实力篇/20 | 进阶之路:项目经理预备战之PMP认证攻略.md
Normal file
145
极客时间专栏/geek/项目管理实战20讲/软实力篇/20 | 进阶之路:项目经理预备战之PMP认证攻略.md
Normal file
@@ -0,0 +1,145 @@
|
||||
<audio id="audio" title="20 | 进阶之路:项目经理预备战之PMP认证攻略" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c6/c3/c656769976568b09a44f35723bea85c3.mp3"></audio>
|
||||
|
||||
你好,我是雷蓓蓓。
|
||||
|
||||
很多同学留言问我,要不要去考PMP?PMP认证的含金量怎么样?老实说,我一向认为,认证考级不是最终的目的,千万不要舍本逐末,为了证书去考试。**让考级最大程度地帮助自己提升专业技能,才是最重要的**。
|
||||
|
||||
## 为什么要考PMP?
|
||||
|
||||
在决定投入精力考证之前,我们要先搞清楚,为什么要考PMP?
|
||||
|
||||
实际上,PMP®认证近几年在国内的前沿行业很受欢迎。截至2019年10月,全球PMP有效认证人数为99万。其中,中国的PMP认证人数占总人数的三分之一。
|
||||
|
||||
PMI的研究报告预测,2027年,中国的项目管理职位空缺将达到4600万个。未来在中国,项目管理岗位将成为最热门的职业之一。
|
||||
|
||||
PMI的中国代表曾经专程来网易访谈调研。他们想要了解一下,PMP认证在中国推广了这么多年,它的价值到底在哪里。
|
||||
|
||||
调研小组从多个方面进行了探讨,最后得出的最重要的一条结论就是,**PMP认证的普及为我们创造了项目管理专业的共同语境**。比如,我们会自然地讨论“根据当前的WBS工作分解,计划中的关键路径是什么”“风险管理计划要怎么做”,等等。
|
||||
|
||||
不要小看这个标准术语带来的好处,统一的共同语境为管理者正确地认知项目管理的作用、为项目运作建立良好的组织环境,都做了非常好的铺垫。
|
||||
|
||||
**实际上,PMP的认证过程也是我们学习并掌握一门项目管理的国际标准语言的过程,就好比是学会了另一门英语。**
|
||||
|
||||
回到很多同学关心的问题上:“PMP认证有用吗?值得考吗?”其实,这些问题背后的疑惑是:“考了这个证,会给我带来什么?升职加薪?还是增加面试和录用机会?”
|
||||
|
||||
我想说的是,对于想尝试转岗项目管理的同学来说,PMP认证的确可以作为“敲门砖”,在一定程度上增加你获取专业面试的机会。但是,在大多数企业中,PMP认证只是一个基础项,**决定你是否被录取的,还是你的实战经验和实战水平。再进一步去看的话,还有建立在实战经验之上的、你对专业方法论的掌握和应用水平**。
|
||||
|
||||
所以,你看,**学习中最怕的就是本末倒置**。PMP证书的含金量不在于证书本身,而是在这个准备考试的过程中你所付出的大量努力,以及你把理论框架和亲身实战融会贯通之后,你的自身能力得到的提升。
|
||||
|
||||
因此,**我建议你在具备一定的实战经验之后再去系统化地学习这门课程**。否则,对你来说,考这个证无异于超大浓度的理论灌输加知识记忆。如果大量的知识无法被消化和吸收,它们就会成为你的“知识障”,屏蔽你进行自我思考和尝试的动力。
|
||||
|
||||
## 如何有效备考PMP?
|
||||
|
||||
那么,如果你已经具备了实战经验,决定要考PMP了,就要提早了解一些PMP认证攻略,不打无准备之仗。
|
||||
|
||||
接下来,我就给你介绍一下备考PMP的几个关键步骤。
|
||||
|
||||
**第一步:确定考试的目标时间**
|
||||
|
||||
PMP每年有4次考试,分别在3月、6月、9月和12月。确定要考之后,你要做的第一步就是安排合适的考试时间,给自己锚定一个目标点。
|
||||
|
||||
**怎么确定什么是合适的时间阶段呢?**
|
||||
|
||||
首先,你要**确保至少完整地经历过两到三个项目周期**,从启动、规划、执行、监控一直到收尾,自己有切身的实践体会。
|
||||
|
||||
其次,**避开工作高峰期,选择自己相对空闲的季度**。这是因为,要考PMP的话,你需要投入大量的时间和精力,至少要留出三个月的备考期。对于这一点,你要提前做好准备,因为它真的会占用你所有的业余时间。
|
||||
|
||||
必须要提醒你的是,你一定要提前确认PMP认证官方要求的报名条件。实际上,**你并不一定需要有明确的项目经理岗位,只要有相应的项目经验,并且达到足够的时长积累,就可以报名了**。
|
||||
|
||||
**第二步:完成中英文报名**
|
||||
|
||||
PMP考试属于国际认证,报名需要两个步骤,先进行英文报名,后进行中文报名。确定好考试日期之后,你至少要提前3个月完成英文报名,提前2个月完成中文报名。
|
||||
|
||||
为什么我要把“报名”这条单独列出来呢?因为我想提醒你,英文申请全年都可以提交,**没有时间限制,但是有5~7天的审核时间,审核成功后,账户有一年的有效期。如果英文申请没有通过,是不能完成中文报名的**。所以,我建议你尽量在中文报名开始之前完成英文报名,以不耽误考试。
|
||||
|
||||
**第三步:课程学习和备考**
|
||||
|
||||
PMI规定,报名考生需要具备PMI授权的培训机构所颁发的35PDU培训证书。一般来说,各类培训班的开班时间通常会至少提前三个月,分别在12月、3月、6月和9月。
|
||||
|
||||
总体来说,培训班通常分为线下和线上两种。线下培训的话,学习的互动感更强,建议你尽量挑选你所在城市的正规培训机构,线下组队形成学习小组,互相督促,一起学习,效果会更好。
|
||||
|
||||
PMI中国联合项目管理专委会开设了官方组织的培训班,目前,浙江地区已经开始招生了,你可以留意一下。
|
||||
|
||||
时空受限的同学也可以选择线上培训的方式。我当时就是选择的线上培训,因为时间更灵活,随时可以补课,对于自律性好的同学来说,效果是一样的。
|
||||
|
||||
接下来,我们再聊聊备考PMP的学习材料,其实主要就是《PMBOK指南》。这本书很经典,但即便我现在读起来,都感觉并不轻松。全书有600多页,而且大多是理论方法的描述说明,很容易让人望而生畏。
|
||||
|
||||
为了帮助你达到更好的学习效果,我结合我的经历,为你梳理、总结出了三步学习法。
|
||||
|
||||
**1.通读**
|
||||
|
||||
对于十大知识领域五大过程组来说,不同阶段的各种方法浩如烟海,这第一步就好比是在知识的森林里,到处逛一圈,先做个路标。
|
||||
|
||||
第一次阅读时,你可以单纯地浏览一下,**别求全部看懂,也不要追求速度**。在读的过程中,建议你结合自己的项目经验,随时做批注,在书上画圈圈,把你感兴趣的内容或者暂时不理解的内容都先标记下来。
|
||||
|
||||
**2.精读**
|
||||
|
||||
参加培训期间,你要根据老师的讲解和讲义,并结合自己的项目经验和问题,重新检视并深入理解每个概念,建立起对体系结构的清晰认知。
|
||||
|
||||
在这个阶段,我建议你跟着培训进度,逐个精读这本书的每个章节,特别要留心那些跟你在实际工作中差距比较大的部分,以及之前做好的路标。
|
||||
|
||||
**你要真正把培训老师当作你的资源,遇到问题多思考、抓住时机多提问,在弄懂方法原理的同时,更要去主动思考,你如何将这个学习引入自己的工作**。只有这样去学的话,你才能把枯燥的考级过程变成一个很好的实战能力提升机会。
|
||||
|
||||
除此之外,我鼓励你结合专栏中对应章节的内容来学习。对照着实战中的要点,重新温习并深度理解,让理论与实践中的重点、难点充分融合在一起,以提升你的学习效果。
|
||||
|
||||
**3.记忆**
|
||||
|
||||
在考试之前,你要按照老师划的重点和考点进行必要的记忆,并完成足量的刷题练习。一般来说,培训机构在考前都会为你准备包含记忆点及重点题型的小册子,内容每年会有一定的翻新。
|
||||
|
||||
这个阶段的重点是,**多总结学习和做题过程中遇到的问题,回顾书上的常见考点,反复加深理解。对于那些重点、难点,你要刻意去背诵下来。在考试之前,你要对熟练掌握各个知识点,并达到融会贯通的效果**。
|
||||
|
||||
以前,我自己在学习的过程中,往往会重理解、轻背诵,特别是对这种应试型的死记硬背,我一点也不“感冒”,不自觉地总会忽视。后来我发现,经典的背诵式学习也是一种科学的学习方法。
|
||||
|
||||
举个例子。小时候,我总被要求背诵诗文,可我当时并不理解,甚至还有些抗拒。但是,那些反复背诵下来的诗就好像刻录进了我的深层意识。在我遇到某些情景时,它们就会自然地跑出来,时常让我觉得惊叹不已。所以,**你看,从死记硬背到真正理解诗歌在表达什么,需要时间和阅历**。
|
||||
|
||||
在PMP的学习中,有很多东西会超越你当前的经历。如果你实在无法理解,**那就允许自己先囫囵吞枣,考前把它们先背下来,耐心地等待它们自己酝酿、发酵**。总有一天,当你遇到合适的情景时,这些记忆就会跳出来,真正地在实战中帮助到你。
|
||||
|
||||
## 项目管理进阶之路
|
||||
|
||||
除了拿到PMP认证,有些同学还想在项目管理之路上继续进阶,甚至已经在考虑转型去做专业的项目经理了。这个时候,你需要考虑哪些因素呢?
|
||||
|
||||
首先,**一旦涉及到职业选择,最关键的一点就是,尽可能不要让自己被很多外在的因素所左右**。你要回归自己的内心,问问自己为什么要做项目管理。
|
||||
|
||||
我在留言区,经常看到两种典型的心态。
|
||||
|
||||
**心态一:**
|
||||
|
||||
>
|
||||
“Leader安排我做项目管理,可能是看我能担事吧,就把越来越多的事,都往我这里塞。”
|
||||
|
||||
|
||||
如果你当前处于这个阶段,我建议你先不要着急进阶,而是**留些空间给自己,先想好,如果没有Leader的影响和要求,你自己个人的决定到底会是什么**。
|
||||
|
||||
如果你发现自己的答案也是要做,那就调整心态,**变被动为主动,为自己的职业道路负起责任**;如果在尝试之后,你觉得自己确实不适合做项目管理,那就主动去和你的Leader沟通,把精力用在更适合你发挥专长的领域。这对公司来说,也是更好的选择。
|
||||
|
||||
**心态二:**
|
||||
|
||||
>
|
||||
“程序员这个工种,可能没法干到老,我年纪也不小了,得提前为自己找条出路。”
|
||||
|
||||
|
||||
主动为自己规划未来,这样的做法值得肯定。但是,这种心态最大的问题是,**如果说程序员这个岗位不适合你一直干下去,那么,你如何确定项目经理就适合你呢?**
|
||||
|
||||
实际上,想要确认这个职业与自己的匹配度,你需要注意的是,**性格内向或外向并不是影响转型的决定性因素**。如果你结合“六力模型”来看的话,你会发现,外向者在信息力上会更有优势,但内向者普遍拥有更加敏锐的感知力。可以说,对成为项目经理而言,这两种性格各有优劣,不分伯仲。那么,到底该如何确认呢?
|
||||
|
||||
答案其实很简单,就是**看这项工作是否能够激发你更大的热情**。程序员和项目经理这两个职位的最大不同就在于,前者研究的是机器,后者研究的是人。如果说,程序员研究的是“**一堆代码在一起,如何运行会更好**”,那么项目经理研究的就是“**一群人在一起共同做一件事,如何运作会更好**”。
|
||||
|
||||
要想成为一名专业的项目经理,你需要对人有敏感度,并且要发自内心地认为**研究人比研究代码更加有趣**。这也是我自己虽然在这条路上遇到了很多挑战,但依然乐此不疲的原因。
|
||||
|
||||
除此之外,**在拥有热情的前提下,经验背景的差异都是可以用时间弥补的**。只要你坚持将学习与实战相结合,不断在实践中整合自己的经验,你就一定会不断精进。
|
||||
|
||||
## 总结
|
||||
|
||||
今天,我给你分享了我对PMP认证及考试的认识,希望能真正地给到你一些必要的参考。
|
||||
|
||||
项目管理的进阶之路是一个螺旋式上升的过程,每一轮都需要以扎实的实战经验为依托。在这些经验的基础上,理论框架的萃取和点拨,才能起到画龙点睛的作用。
|
||||
|
||||
**实战永远是我们不变的基调**。只有你把PMP的认证过程当作对自己的一次系统化的理论充电,让实战经验与理论框架充分碰撞,你才能真正地吸取PMP给你带来的真正价值。
|
||||
|
||||
## 畅所欲言
|
||||
|
||||
讲到这里,专栏的20讲内容就全部结束了。如果你在项目管理的进阶之路上有任何的疑问或困惑,都可以通过留言反馈给我。
|
||||
|
||||
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user