《做项目，不得不这么干》阅读分享之项目管理概念篇

图片来自网络

数月前换了工作，忙忙乱乱一段时间，导致8月底看完的书最近才整理了笔记，才来写这篇读书笔记，也正好，就当给自己个机会复习一遍吧。

《做项目不得不这么干》的作者是郭致星老师，封面简介：教授、知名实战派项目管理专家、资深项目经理、工信部高级项目经理、CSERM、PMP......郭老师也有自己的博客，链接在此：郭致星老师博客，本书中的多章经典内容郭老师博客均有同步，感兴趣的同学可以自行查阅。

相比于之前分享的《网易一千零一夜》和《新版一页纸项目管理》两本偏方法论的书，《做项目不得不这么干》更倾向的则是理论建设，对比“项目管理圣经”PMBOK的纯理论，本书贴心的地方在于有诸多大小案例可以帮助读者进行理论理解。

相信在任何一本项目管理相关书籍中，计划和需求都会占相当重量的比重，本书也不例外，对于项目生命周期模型、基于SDLC的项目管理方法及项目规划期间的假设/制约等都进行了或简或繁的描述，这部分也正是笔者比较关注的部分，本篇对于一些重要概念所得，这里与大家进行下分享，常用流程/标准等将后续再行开坑分享。

1、项目生命周期

相较于PMBOK（第六版）中的项目生命周期（预测型或适应型）和开发生命周期（预测型、迭代型、增量型、敏捷型、混合型）的划分，郭老师在书中将项目生命周期划分为了类似的4类——顺序式、迭代式、增量式、敏捷，本质上仍是一个逻辑，笔者认为对比PMBOK的内容会更易对这几种模型进行理解，因此分别附上PMBOK及本书关于此内容的截图。

图片来源于PMBOK（第六版）电子版截图

图片来源于本书内容整理

2、假设和制约（项目限制）

假设条件和制约因素是PMBOK中的高频词汇，是假设日志的重要构成部分，但讲真，笔者在之前的学习过程中其实并没有深入理解这二者的作用，《做项目不得不这么干》中再次看到这两个词后，结合书中案例及扩展内容，终于透彻理解了。

2.1 假设条件

认定为真或认为理所当然的事情。项目有很多因素是尚不清楚的，所以总会做出某些假设。如果某个假设证明不是真的，则意味着一个风险，甚至是重大风险。

2.2 制约

制约是在项目开始时，可能明显也可能不明显的限制或障碍，有些会随着项目的进展浮现出来，制约因素是确定的、客观存在的。（如：项目结束日期，合同终止日期，预算只有500万，最多10个初级工程师，产品都是新手等等）

而作为一个项目管理者，需要做的就是制定相应应对措施，尽量控制那些可以管理的制约因素。

图片来源于网络

3、关键驱动因素

驱动因素是指从客户或发起人的角度：项目需要完成的任务是什么/客户想要什么（范围/功能集合）、何时完成可交付成果/期望何时收到交付物（交付时间/时间）、如何衡量可交付成果/可交付物的质量如何（质量/缺陷等级）等。

项目成功的关键条件就是项目的关键驱动因素。关键驱动因素越多，项目就越不容易管理。关键驱动因素过多，意味着没人知道成功的条件是什么，意味着组织中没人去判断孰轻孰重，应当让管理成决定项目的关键驱动因素。

理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。大部分情况下，我们管理的都是不那么理想化的项目，所以如果项目有一个关键驱动因素、两个约束、三个浮动因素，这也是可以成功的。过多的关键驱动因素或约束，会让项目过于受限。

关键驱动因素是从本书所得的一个很重要的概念，也是笔者长久以来在实践中最为头仍的一个因素，因为作为发起人（老板）通常的心理都是“鱼与熊掌想要兼得”，不接受延期、不接受功能模块分版本上、想要达到线上bug free。就如笔者目前正在经历的一个项目，本来这就是一个大工程，无论从团队的成熟度、项目管理的程度、产品规划能力上看都存在很大不足，项目有着重大延期风险，但老板依然要求在此基础上增加新的功能点，并要求按时上线。这时候，最头疼的就是产品经理和项目经理了，对于此笔者目前仍未有很好的解决方案，尤其是在老板的属性带有“不可说服“的时候，往往只能走一步看一步，最后无奈的形成一个双输的妥协局面。对于这一点，大家有更好的建议，还希望多多指导啦。

图片来源于网络

4、不确定之锥（Cone of Uncertainty）

在项目管理中，不确定性之锥描述了项目中不确定性量的演变过程，即不确定性不仅随着时间的流逝而减少，而且也随风险管理，特别是决策的确立而减小。

在项目刚开始的评估差距可能达到16倍之大，有的人评估的是4倍的工作量，而有的人评估的是1/4的工作量（项目结束之后的实际工作量计为“1”）。但是，随着项目的不断推进，以及既定的工作在不断的完成，随着决策的清晰，评估的难度（或工作量）越来越接近于真实情况，最后回归到圆锥的顶点（最后的评估和事实保持一致），九九归一。

图片来源于网络

图片来源于网络

5、系统变量设计

系统变量设计在技术实现上，通常表现为一个配置文件或者是数据库里的一个表格。在前端，客户可以通过界面自行修改；在后端，技术人员可以根据需要改变配置文件使系统在不修改代码的情况下适应客户变更需求。

说白了其实就是”用户自定义设置“。

图片来源于网络

6、滚动式规划/计划（Rolling Plan）

滚动式计划（Rolling Plan），短期明确的工作详细规划，要在未来远期才完成的可交付成果或子项目，等到这些可交付成果豁子项目的信息足够明确后，再详细计划。滚动式计划是一种传统的动态编制计划的方法，在每次编制或调整计划时，均将计划按时间顺序向前推进一个计划期，即先前滚动一次。

笔者对于滚动式规划的理解就如对假设条件和制约因素的理解，长期以来可能都处于一种似懂非懂的状态中，之前是为了PMP的考试——只要题会做，概念就不求甚解了，此次再碰到这个概念，终于下定决心深究了一下，相信我，配合下图真的可以秒懂这个概念。

图片来源于网络

对于《做项目不得不这么干》的一些项目管理概念，笔者暂时做出如上总结分享，欢迎看过本书的小伙伴们随时补充，后续还将陆续更新阅读本书后的常用流程/标准篇及心理效应篇分享，欢迎大家持续关注，谢谢