《极简项目管理》

工作计划不仅仅是对于项目有着至关重要的作用，在任何方面都需要把计划做在前面。比如：战争时期的作战计划，国民经济发展的五年规划
，企业发展的商业计划，这些都是，试想一下
，要是战争无计划，经济无规划，企业无计划，那成功与否不知道，但失败一定是必然的结果。

但是，也有很多人认为费了半天劲，做了半天的计划，结果没几天就全都变了
，计划这事
，费劲不说
，绝对是个费力不讨好的事
，做了用不了几天，就白做了
。而且，绝对是计划赶不上变化。还不如随机应变来的直接
，还能节省点精力和时间
，抓紧时间推进一下工作来的实际呢
。

千万别，千万别，千万别，因为所谓的“计划赶不上变化”而不做计划，事事都来个“以不变应万变
，随机应变
。”无数的例子已经验证了事前做好计划的优势以及其必要的重要性
。

比如最著名的案例
，就是两支同时首次前往南极探险的探险队，做好计划的阿蒙森团队成功的完成计划任务，而计划不周的斯科特团队最终落的全军覆没的结局，让人惋惜
。

计划的好处是：事前想清楚，事后不折腾，尤其那句“至理名言”：细节是魔鬼啊。

并且要明白一件事：计划本就不是一成不变的，当你做好计划的那一天开始，计划就要开始根据实际情况，随时更新，在确保计划目标不变的前提下
，抓准计划中的核心要点，寻求最佳的前行路线
。就好比开车使用导航软件一样
，起点、路线、终点都规划好了，出发后，导航软件也会根据实际路况的各种变化
，给你推荐到达终点最有效的路线，难道此时你可以不听指令
，执着地继续堵下去吗
？不仅如此，相信你面临堵车
，系统不提示
，你也会主动去规划一条新的最佳路线的，没错吧
？

导航如此
，项目计划也一样，这样是不是就可以理解为什么计划做完之后，不会一成不变的贯彻下去了吧

。那些所谓将因为觉得“计划赶不上变化”而放弃计划的项目人员，往往其主要的原因，是惰性。

关于做好计划的重要性
，不再赘述
，要做好一个项目计划核心有三：

一、要有明确的负责人
，按个手印
，签个名，总之
，把责任到人，才能有效推进，按照心理学来讲

，人要是按了手印
，签了字

，就会在内心升起一杆“责任”的大旗。

二
、要有最终落实的时间，俗称“deadline”最后期限，要是没有时间线把持着整个项目，保不齐就会多几个有“拖延症”出来，“deadline”是“拖延症”的一剂良方；

三、拆解分化工作：Work Breakdown Structure 简称（WBS）
。一个工作
，一个项目，一般来讲都不是一个人的能力可以完成的

，所以项目负责人要根据实际情况

，将项目进行拆解
，分别交由不同的职能部门负责，也就是把大事情拆成各种小事情。比如车辆的制作，要完成一辆整车的制造

，要有专门的轮胎厂商负责轮胎，发动机厂商负责发动机等等。

常用的WBS分解方式如下4种：

按组分解：（按产品）按照产品的结构组件分组
，比如按照车辆的各个零部件来分组，前提是你的项目组是有相对应的“资源能力”
。这里其实也可以理解为，按照项目的执行内容分类来分组
，因为毕竟所谓的“产品”并不一定是有形的。

按功能分解

：（按产品）同样是车
，比如新能源车辆，按照系统来分组也是一种方式
，软件系统，电力系统，控制系统等；

按生命周期分解
：（按阶段）简单解释就是按照项目的时间线来分组，或是项目的执行阶段分组，比如：前期的信息收集阶段，系统设计阶段
，系统集成阶段等等；

按地域/组织分解：（按组职能）按照你手中的项目工作组的能力，所在地域/城市，进行分组
。

以上四种分类
、分组的方式
，全是干货
，要是你正好作为一个项目负责人
，也正好面临“毫无头绪”的工作分工
，正好看看以上这4种分工方式
。但是，这4种WBS并不肯定是一套万能的分解工作的方法，毕竟
，对于WBS而言，没有最好的方法，只有最合适的。

最后
，分解项目工作
，有几点核心，注意避坑：

作为领导

，应该管理的是计划，而不是管人或是管事；

项目也不应该是被某个人管理着，而是应该被计划管理着
；

员工也不是应该被领导管理着
，而是应该按照计划去工作。

对于
，学会工作分解结构
，树形结构好用、清晰；拓扑图架构也没问题，实在不行，做张表格也能分清工作的结构关系
。

对于应该用的工具呢，Excel可以
，PPT也能做，思维导图会用的话更好用，比如：Xmind，微软的Visio都可以，会哪种用哪种，方便就行。