沟通
沟通,是项目管理的工具,也是文化和氛围,更是项目得以生长的养分。
项目管理的沟通,如你划我猜,强调沟通中肢体语言和协作。
划和猜的人,要站在对方视角理解;共同猜的队友,相互给予灵感启发。
沟通和协作,正好是项目管理的灵魂元素。
项目管理中,沟通是多维、多层次的。有效沟通,才能让项目往目标迅速推进。
沟通的关键如下。
1、明确双赢目标
项目管理的两个关键要素是「目标」和「多方」。
事先明确沟通目标,才能保证多方有效沟通,达成双赢。双赢,意味着目标的达成,让双方或多方共同获益。可以理解为,共赢目标达成,可以促使各方独立目标达成。
项目管理的沟通,要聚焦某个沟通目标进行。这个沟通目标背后,有一个共赢目标支撑。共赢目标,来自多方的目标的表达、梳理。
为此,可参考如下问题清单,展开沟通。
- 你要为自己创造什么?
- 你要为对方创造什么?
- 你需要为你们的关系创造什么?
- 沟通的高手都善于管理自己的情绪?
2、控制情绪抓重点
如果没有明确目标,容易从就事论事变成就人论人。
其次,沟通多方背景、视角不同,容易陷入知识的诅咒。以「对方和我有一样的假设」为基调表达,加重对方的不理解。缺少对方视角、缺少明确目标,容易引发负面情绪,导致沟通事故。
对此,控制情绪、保持倾听,等待完整吸收表达者的信息后,基于沟通目标,抓住对方的重点信息,反馈回复。
3、倾听别打断
倾听,不仅是听文字内容,还要关注语气、语调、肢体语言。它们反应出沟通者的态度和背后的意思。
一方表达完后,先冷静处理已表达信息,哪些是观点、情绪、期望,基于目标抓关键信息。过程中,保持耐心,不要轻易打断,无论支持或反对,先听别人说完。
亚马逊推崇的六页纸会议,开始静默的20分钟阅读,让大家一次性了解会议所有内容,再做反馈。避免PPT式分享时,前面打断的询问,后面的内容可以解答。这20分钟阅读时间,相当于强迫所有人一次性听完会议主持人的所有表达。
倾听,要设身处地,主动假设自己变成对方。要绿灯思维,先假设别人的观点和视角是有价值的。
4、肢体语言也很重要
不要忽视对方语言以外的表达。如美国语言学家艾伯特·梅拉比安所说,沟通的总效果=7%的文字语言 38%的声调 55%的肢体语言。
马老师提供了一个正确沟通的沟通公式,如下。
我观察。。。我感觉。。。是因为。。。我请求。。。
马老师还分享了长颈鹿式沟通方法,供大家参考。
- 沟通时,如长颈鹿,视野高一点、眼光远一点、格局大一点。参考项目管理经理角色,主动引导大家想想共赢目标,把时间周期拉长看事情,从宏观、抽象视角看问题。
- 倾听时,主动反应慢一点,脑多动、嘴少动。尊重对方,让对方多表达,由此也更容易观察和理解对方的真实语义。
此外,我们可以用如下「常见错误沟通方式」自查。每次沟通复盘,如果发现错误,记录下来,思考如果重新沟通,我该如何应对,帮助自己从错误中改善。
- 否定式沟通
- 打断式沟通
- 追问式沟通
- 尴尬式沟通:以粗鲁,自以为幽默,低俗的方式,让人不知道怎么接下文
项目管理
源头
PMI是项目管理的源头机构之一,其主持的PMP证书,提供了全球范围的项目管理制度认可。如果我们想要学习更多知识,可直接访问PMI官网、阅读PMP教材。项目管理的关键术语和逻辑,可用作日常管理的基础模型。
定义
三要素
项目管理的质量由三大要素决定:范围、时间、成本,为“项目管理铁三角”。这个公式:范围 时间 成本=质量,可以应用在所有项目认知上。
如果需要判断一件事情,是否是项目,是否可按项目来管理。就看这件事,是否有范围圈定、时间圈定、成本考量。
范围、时间、成本三要素,和STC算子(S为空间,T为时间,C为成本)有相同逻辑。如果我们需要思考如何优化一个项目、如何推动一个项目进程,就变形思考范围、时间、成本三要素。
范围,比如,这个项目目标达成圈定的范围,是否太宽太窄,是否竞争太激烈,产出价值几何,如何调整更匹配上层战略。再比如,这个项目调取的资源范围,是否太宽,导致调取成本太高时间周期太长;是否可以缩减人力资源范围,达成同样的效果。
时间,比如,这个项目的时间结构怎样,按环节拆解、按部门拆解,哪些可以合并,哪些可以省略,哪些可以并行,哪些资源协同创新减少时间周期。
成本,比如,这个项目成本结构如何,哪些成本可以跨项目发挥价值,哪些成本结构变形可以调用更多资源,哪些成本投入可以缩短时间放大范围。
特点
目标、临时、唯一、逐步完善。
目标对应范围,项目存在特定目标,基于特定目标,圈定项目范围,项目是聚焦的。
临时对应时间,项目有明确的时间范围,有开始有结束,达成目标可关闭。
一个复杂的项目,是层层拆解的,依次为项目组合管理、项目集、项目、子项目。
生命周期
项目管理生命周期分五个阶段,启动、计划、执行、监控、收尾。
时间曲线,引自马迪《疯狂汽车城:项目管理和敏捷实践》
如图所示,特定行业,项目生命周期的初期计划分析非常重要,严重影响后续项目开展和成本把控。前期固定成本投入越大,越需要初期深入分析,降低错误修正成本。
比如汽车行业,一旦决定项目生产,投入非常大,调整非常难,前期用户调研、需求分析、产品设计格外重要。试错成本太高,不太适合敏捷管理的快速迭代策略。尽可能用前期变更替代后期变更。为此,汽车行业,需求分析可以长达1-2年。这可能是快消品行业的几十上百倍。
项目干系人
项目管理,本质落到人的管理,理清项目干系人,理解项目干系人,综合权利、利益差异化沟通,非常重要。
参考系统思维,了解干系人在项目系统中的位置、功能、相互关系,跟踪干系人项目系统变化中的进度、影响,设定不同的管理策略。
项目干系人及状态图,引自马迪《疯狂汽车城:项目管理和敏捷实践》
项目组织类型
不同组织类型,各有优劣,新的项目组织结构,是从传统的职能型、项目型进化而来。
就组织长期发展而言,不同类型的组织结构,适合不同的发展阶段和周期,根据其各自优缺点,调整适应。
职能型,强调行业专业技能。部门协调比较困难,部门边界过分清晰。项目目标和部门目标不易匹配共赢,项目推进难。
项目型,项目反馈快、目标达成价值高。项目结束人员分散,缺少团队归属感和个人专业性成长,大家容易变成项目运转的螺丝钉。
矩阵型,试图保证项目发展和专业性成长,双线工作关系,容易导致绩效管理、考核难度上升。
小创业团队,快消零售领域,优势是灵活,原则也是灵活。
比如我们电商团队,职能型、项目型,随时更替或者组合。从当下团队目标出发,选取某种组织类型。新做一个产品时,自然形成项目型结构,协同工作,以打好某个产品为目标。日常产品维护阶段,自然变回职能型,每个人在各个职能岗位,根据工作属性和战略重点决定优先等级,开展工作。
组织类型切换,可能最大的障碍是绩效考核,人力管理工具和制度的设置,将会影响组织灵活变更类型的能力。
应用
项目管理能够顺利推动,一定需要高层重视和支持。公司组建PM体系有以下关键点。
1、标准化输入输出流程。
定义每个环节的输入、输出流程及标准,并且量化处理。
汽车行业为例,标准化可以将流程拆解到十几步,每个步骤每个阶段,设立极其细致的标准,比如,造型有几个版本,什么版面等。
如《长期有耐心》中提及的美团运营原则之一。标准化输入输出流程,是在流程化的基础上,为每个流程设立完成标准,通过量化到机器可读,最后实现自动化。
我们要把复杂的事情简单化,简单的事情标准化,标准的事情流程化,流程的事情自动化。
— 夏华夏
2、赋能而非监管。
组织中建立PM体系,要以赋能为目标,而非监控监管。PM更像是一个救火的消防员,一般有以下关键工作。
- 部门职能边界过分清晰,需要PM帮助大家提高协同能力,以共同目标为基础,重新梳理边界、定义工作范围。
- PM工作的过程监控,是为了发现过程中的问题,即时帮助相关人员解决问题、而非处罚。
- 部门目标和项目目标不匹配,部分部门资源分配等级低,PM协调改善目标达成对部门的影响,保证部门获益。
- 资源冲突,协调各方资源分配或者沟通实现资源共享。
- 团队跟供应商、领高层沟通困难,PM出面沟通解决,争取事项,解决问题。
3、数据驱动
现在数字化已经成熟,人人强调数据驱动。我个人经验,大部分人包括我自己,都曾经、或者现在正在,深深陷入到了数据分析和数字化的陷阱中。误把数字化这个手段,变成了目标,最后费力不讨好。
马老师强调,一个完整的PM体系庞大复杂,对于中小企业,无需全部满足。根据所处阶段、运营属性,选取部分建设即可。
4、注意事项
① 不要多头管理。
多头管理,导致不聚焦。如OKR强调,聚焦是管理的核心之一。不聚焦难达成。其次,管理本质是确认优先级,如果多头管理,可能存在无法明确确认优先级。
② 不要分配任务给非需求方。
遵从目标共赢的原则,如果分配给非需求方,项目目标和部门目标不匹配,难共赢,自然推进困难。任务分配给痛的人,痛才有能力推进。
敏捷管理
中心思想
雪鸟会议对敏捷管理的发展影响极大。会议中,制定并签署了行业历史上最重要的文件之一:敏捷宣言。其中传达的四个重视,正是敏捷开发的精华。
敏捷宣言,引自马迪《疯狂汽车城:项目管理和敏捷实践》
关键要点
1、数字化管理流程,利用数据驱动项目。
比如,通过Story Point将团队交付数字化,进而监控过程,实时发现问题解决问题,保证交付能力的稳定性。可能用到的数字化工具,比如下图的燃尽图。通过跟踪燃尽快慢正常与否,监控项目进度。
2、去中心化,团队共同组成大脑。
团队中成员各自分工,扮演不同角色,协同作战。比如,PO(Product Officer),作为产品代言人的身份,负责快速交付产品方案,算是业务负责人,产品决策者。Master,作为团队协调人,组织安排整个流程,团队成员彼此协同合作沟通流畅。
3、实时反馈,持续迭代。
利用需求收集列表、Product Backlog等,收集需求,区分优先级,安排迭代。整个开发,保持以用户反馈为核心进行,满足用户需求为目标。保持迭代的思路,计划产品开发时,尽量第一次交付就可用,然后后续迭代更好功能,更优体验。
团队之间也会通过Daily Scrum站例会的形式,实时分享和反馈各自的进程和问题,共创解决。
每个Scrum完成,通过Review Meeting(如有机会,给客户演示),总结复盘用户、团队反馈,为下一个Scrum做计划。会中,大家可以坦诚分享心中不爽,共同商讨出解决办法及执行方案。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。