这篇项目经理(项目经理项目管理项目的人风险)

最近我参加了几个项目经理的面试，对于其中的情况有些感触
无论是野路子出身还是学习了正规项目管理认证（如PMP），很多人都无法抓住项目管理的核心要点
在本文中，我将探讨这个问题
一方面，这是基于我的亲身经历所发表的感想，另一方面，项目管理实际上也是架构师职责范畴的一部分
学习过PMP的人都了解项目的定义：项目是在特定资源和要求的限制下，为实现某种目标而相互关联的一次性工作任务
这个定义特别符合程序员的思维方式，所以在我上PMP课程的第一次，老师问了这个问题，即使我在还没阅读课本的情况下，也能够直接给出几乎相同的答案
对于程序员来说，所有的问题都可以归结为“在给定的条件下，找到一个算法，得到相应的答案”
项目管理也是如此：当我们要开发一个软件时，无论你如何设计，真正推动项目变成现实的是组成团队的人（当然，团队人员是一个动态的因素）
项目经理的任务是找到一种方法，让项目顺利、按质按量地完成，这就是项目经理的工作理念
项目管理是一项复杂而多元的任务，需要进行事前预估、过程定义、甘特图管理和关系网建立等工作
在项目管理中，扮演不同的角色如知心大姐、鼓劲领袖和拿鞭子的监工等，任务繁琐且各有不同
因此，很多人往往无法抓住重点
即使他们正式学习了PMP，对于项目管理方法只是停留在表面，学完后仍然按照自己的方式行事
他们在应用PMP时，往往只是学会了一些术语来炫耀或者为自己的身份背书，却无法真正理解如何掌控项目
这个问题是关于“守弱”的核心：相信解决问题的方法，而不是仅仅相信概念本身
因此，项目的定义变得非常重要：你进行项目管控，并不是为了迎合PMP的方法论，而是为了实现项目目标
你拥有有限的筹码，如何用好这些筹码来换取你想要的结果呢？（放心，我并不是说要无为而治，无为是架构师的事情，而项目经理则负责谦虚坦诚地解决实际问题）
因此，项目经理的核心工作是解决两个问题：WBS（甘特图）和风险管理
其他工作只是围绕这两个核心工作对特定问题进行补充
WBS（Work Breakdown Structure）可以采用各种形式，可以将其记录在笔记本上，使用MS Project绘制图表，或者用Excel等工具编写成列表，这些工具对于解决许多问题都有所帮助，但并非问题的核心所在
问题的核心在于，无论进行何种长期计划，都不会将终点作为唯一目标，因此必然需要进行阶段性划分
对于工作依赖性极为复杂的情况（例如数据中心建设项目，涉及采购、招标、申领牌照、开发、部署等多个工作），普通的任务列表并不足以有效管理，此时能够绘制甘特图的软件能够大大提高工作效率
而对于小型软件开发项目而言，通常由几个大迭代周期组成，使用任务列表已经足够好地进行管理
每个项目经理都会制定WBS，因为无论采取何种方式，将任务划分为阶段并分配给相应的人员都是一项基本功能，无法被替代的
然而，项目管理真正体现能力的地方在于风险管理
许多人错误地将风险管理视为项目管理的一个方面（与许多其他方面并列），将其看作是添加花样的一部分
但是，他们没有认清楚，风险管理实际上是整个项目管理工作的核心
我们需要项目经理的一个重要原因就是他们有能力管理所有的风险
因为若项目最后无法按质按量完成，根源往往是当初对WBS的假设存在误差，我们需要保护WBS，即提前发现WBS中的漏洞，并予以修正
我注意到许多项目经理并没有认真地看待风险管理，他们列出的风险清单往往如下所示：“团队成员技术水平低，可能无法按时完成设计”，“人力配置存在风险，需要领导施加更大压力”等
但这些实际上并不能称为风险管理，这只是在告诉“领导”或“投资人”“这个事情办不成，别怪我”
如果项目经理只有这种水平，那确实难怪别人会认为项目经理只是在打杂
许多小型组织通常将项目经理和技术专家（领队）合二为一，原因就在于此，因为项目经理本质上就是打杂的
独立养活一个项目经理根本负担不起（功劳与投入不成正比），但项目管理却是一项专职工作
基本上，如果你需要管理一个10人以上的团队，并且已经确定了具体的交付目标，将核心技术人员（如架构师）和项目经理合二为一，这个人将同时兼顾项目管理和架构师两个工作（即使该团队具备高度的自组织能力）
人越多，时间越久，一起做一件事就会面临无数风险的挑战：张三的母亲突然生病，紧急请假；李四找到了更好的工作，新人难以理解并接手他的工作；一块关键的开发板在入关时不符合规定被海关扣留；合作伙伴突然被收购，团队中离职的成员较多；国家突然发布新规定，要求软件通过广电认证；某项技术过于困难，难以实现；项目进展时间过长，投资方失去信心，取消项目等等
回想一下你曾失败或延期的项目，它们最终是如何失败和延期的？只有弄清楚这个问题，你才能认真对待风险管理
即使没有那些意想不到的风险，仍然存在一种风险是永远无法避免的：你对设计目标和工期的预计可能是错误的
有些人认为技术专家比那些对技术理解不够深的人（比如以管理为主的项目经理）更能准确地预估技术工作的时间
然而，这种观点是自欺欺人的
对于已经开发过程序的人来说，你们能够如实预测一个模块的开发时间吗？以技术为基础来预测工期远不如以项目管理经验来预测准确
解决技术问题和预测工期本质上是两个不同的维度，将它们放在一起考虑基本上就是一个错误的开始
项目经理并不是只是制定计划后就开始指手画脚的人
你可能看到他们在督促任务进展，但实际上他们每天都在思考着：“如果这个任务再延期，我就必须停掉那个任务，调遣人手加强这个任务
”这是整个软件工程成功过程中一项独立而又必不可少的工作量庞大的任务
试图让专注于技术的工程师“随便做一下”这个工作，就好像让一位擅长编写Java脚本的工程师去设计PCB板一样，根本无法专心致志
作为架构师，我每天都对我分解的模块充满了热情，渴望亲自实现它们
实现一个模块后，立刻能够感受到运行和成功的喜悦，而架构设计则需要等到产品成功之后才能体会到快乐
项目经理也一样，谁不想立即看到一个程序或一个模块呢？但项目经理的快乐需要等到项目成功之后才能评判
实际上，你的角色决定了项目的成败，如果你是一个项目经理，那么你需要承担起项目的责任；否则，你只是一个执行任务的人
这句话听起来可能很鼓舞人心，但实际上是很现实的：如果你不对投资负责，投资为什么要关心你呢？为什么宠辱若惊，当贵大患如身？组织给予你投资，对组织来说是一种风险和压力，而你却轻松得不用承担太多压力，想进入就进入，想退出就退出，想贡献一点劳动力就要求高额回报？这个世界没有这样的好事情存在
只有那些能与组织共同生死的人，才能获得更多组织内的利益，这样的组织才有前途
如果你被组织切除，那会很痛苦，因为这才证明了你的存在价值
回到风险管理的话题上，要把项目的成败放在自己肩上，项目经理需要掌握三个关键要点：1. 风险识别不由项目经理单独完成，风险识别主要来自于WBS（工作分解结构）任务的执行者，需要以软件工程师收集需求的心态去识别风险
有必要通过一些手段，如威胁或激励，逼迫他们透露可能存在的风险
2. 为每个风险设定规避计划和应急计划，尤其是应急计划
许多项目经理虽然会管理风险列表，却没有认真准备应急计划，甚至混淆了规避计划和应急计划的区别
我要求我的项目经理必须制定应急计划，因为只有你有应急计划，你才真正认识到这是一个风险（而不是一个延期的借口），许多风险是有一定几率会发生的，一旦发生，会对你的项目造成严重影响，你能否应对得当？这才是问题的关键
通过观察项目计划中是否包含风险应急计划，往往可以判断项目经理是否足够专业
（我敢告诉你，就算你试图欺骗我，一个没有背景知识的人也能一眼看出一个没经验做出来的应急计划）3. 在执行过程中，要基于风险管理来管理WBS，不断响应变化
只有在有项目经理的情况下，以技术或业务为中心的成员（无论他们在组织中地位高低）才能有效地输出结果
如果能够做到这三点，那你就是一位出色且专业的项目经理了
需要推荐靠谱PMP机构的同学可以关注我后台回复【推荐机构】备考资料分享如下：