PM总结：保证项目顺利交付4大法则代码片段

CodeSnippet.Cn
代码片段

pm 小笨蛋发布于：2021年07月17日更新于：2021年07月17日 119

### 项目管理的四则运算

项目管理的四则运算，简而言之就是**在合适的阶段针对合适的受众进行相应的加减乘除，最终达到顺利交付的目的。**而何时用何种方法，每个项目经理都有自己的操作习惯，下面就讲下我在历史项目管理中的一些见解。

#### 相关方感知做乘法
在2018年任衢州市智慧交通数据服务项目经理时，我依然按照我的习惯排计划、盯进度，然后节点交付汇报（每个节点周期大约是2个月）。

在一次吃饭我碰到了指挥中心大队长（最终用户），他半开玩笑的和我说：“这么久没过来沟通需求，是不是把我们给忘记了。”当时我没有多想，直到边上ISV的项目经理提醒我说这意思是要多沟通多汇报，我才恍然大悟。随后我找到大队长表达了歉意，并在后期时不时的过去，汇报下当前情况。

后面接手的项目中，即使没有节点交付，我也会和商务一起以满意度调研的名义和业主进行面对面沟通，得到了业主的一致认可。

在PMBOK的相关方参与知识域中，**明确的指出了需要提高相关方的参与度，而参与度主要就体现在了项目经理和相关方的互动环节。**

从上面的案例不难发现，如果是单纯的节点式汇报，并不能让业主充分的感知到我们是在完成项目的。**作为项目经理，更应该积极主动地和相关方交流、互动，让主要相关方明显的感知到你所带领的团队是在努力的完成任务，并能在关键时刻给与充分的支持。**

#### 问题处理做除法
在一次项目中周例会中，我发现一位开发没有完成既定任务，他在会议上一直解释着为什么会造成延误。

在这个过程中我没有针对他的解释发表意见，在会后我把他留了下来，我和他说：“当我们发现延误发生时，应该第一时间商讨应对策略，而不是为延误去做辩解。项目是需要团队配合完成的，配合靠的是信任，如果大家相互信任，就不用做过多的解释。”

当时他表现的很惊讶，或许又带一些不理解，没有做出回应。但是随着时间的推移，大家发现了一个现象，团队很少有甩锅的事情发生，问题发生时都会下意识的去讨论需求解决方案，效率也得到了很大的提升。

**在项目过程中，问题是不可避免的，**这些问题可能来自于团队、外部或者需求的本身。也许是由于环境因素，当问题发生时，很多人会下意识的去强调一些客观原因，以试图得到别人的理解（怜悯），其实这除了费时降效外，毫无用处，甚至会引发冲突。

而除法除去的是发生后的辩解、争吵、推诿等一系列环节，让大家聚焦于问题的解决方案，以相互包容和协作的态度去解决每一个问题，从而**培养团队的信任和协作。**

#### 团队建设做加法
2018年，我接任公司数据部总监，这是一个全新的项目制部门、全新的项目团队。在团队建设初期，我先花了一个月的时间给所有人建立了标签体系；通过标签化的管理，团队内部能清楚的知道自己在项目中的位置。随后面对团队内部的冲突，我采取的是匿名调查问卷的方式让自己能站在一个客观的角度来处理冲突；甚至让团队对我进行反向的匿名调查，以此来进行纠偏操作。

**团队组建易，团队建设难。**团队的建设不是靠简单激励就能完成的，需要项目经理了解团队所长，规避团队所短，并要适时的自我反思。

而当团队有成员形成木桶短板时，**项目经理有义务去协调资源帮助其成长**，这样的团队才会更加的有凝聚力。而你为团队建设所付出的每一分力都是在为团队建设做加法。

#### 需求管控做减法
2019年我担任某大数据局数仓建设项目的项目经理，客户有个需求是在半个月之内完成1块数仓大屏的开发建设，设计稿已完成确认。在产品经理和业主进行指标项确认时，业主又提出了各种要求，比如增加type页面、指标下钻、地图交互等。

得知情况后我先大致了解了新增的需求，并评估了对项目的整体影响。随后我与客户进行了一次沟通，了解到客户增加需求的目的是为了在汇报时能有更多的亮点体现，因为他认为目前版本的亮点不够多。

听取了客户意见后，我先表达了一个观点：亮点不在多而在于能不能抓住省里领导的心，目前虽然亮点少但是贵在精，是解决方案通过省里文件分析出来的，我相信这个版本能够让您这里汇报成功。

随后我从项目现阶段的情况出发，和客户分析了一下新增需求的影响：

1. 本次版本开发实际工作时间只有标准开发时间的80%，交付时间节点非常紧；

3. 之前需求已经确认，整体框架也开发完成，如果需求变更那么将意味着从设计到开发要重新再走一遍.”；

5. 需求反复将无法保证开发作业的连续性，效率上会下降的很明显。

7. 目前这个版本可以满足基础使用和约定的亮点体现，如果追求多亮点，无法交付的风险将会成倍提高，万一真的发生，对我们双方都不利。

最终业主同意叫停所有新增的开发工作，优先保障本次节点交付。随后我和业主确认了新增需求的优先级和实现阶段，同时顺带将本次可有可无的需求内容也一并申请了取消，全部归入2.0和3.0版本交付工作，该版本大屏也得到了按期交付。

**范围管理是项目管理中的核心**。而在日常项目中吐槽项目经理最多的也是范围管理不到位。想要控住范围，就要对客户需求去做一些减法。

**想要做好减法，首先要做好根本原因分析，掌握客户新增需求的真实目的，然后识别风险，研究对策，对症下药。**将每个阶段要做的事情固态化，给团队创建一个安全健康的开发环境才是减法的最终目的。

但是需要注意的是，需求减法并不是简单的拒绝需求，而是**有计划的去分阶段完成**。

### 总结
1. 客户感知做乘法-----让客户加倍感知到团队的努力，增加其参与度，同时让团队感知到客户的支持度，增加项目建设的信心。

3. 问题处理做除法-----聚焦问题，除去不必要的环节，培养团队之间的信任和协作。

5. 团队建设做加法-----提高团队成员信心，增加团队的凝聚力，培养相互帮助的氛围。

7. 需求管控做减法-----帮助团队抵挡节点范围外的需求，让团队可以放心大胆的进行项目建设。

**项目本身成败的关键点就在于项目经理和团队的配合**。而以上四点方法最终都是为了团队能和你朝着一个目标去努力。因为团队成功才是项目经理最大的成功。

这里⇓感觉得写点什么，要不显得有点空，但还没想好写什么... 返回顶部