上篇提到了两个教训跟理所当然的假设有关。我们可以很笼统的把他们归结为沟通不到位。但哪怕很主动沟通的项目经理也经常会问，我需要沟通什么？假设的验证就是一个很重要的内容。
项目中的假设是什么？按定义，假设是那些你认为是真实的事情：那些你认为以后会发生但还没有发生的事情，你觉得是真实的业务事实尽管你并没有证据。然而记住，我们不把这个叫拍脑袋，我们管这个叫Educted Guesses。
当然了，听这个定义还是觉得相信假设本身就有点想当然，但我们其实是生活在假设中的。比如你过马路，侧向红灯了你开始过马路。你其实是在假设侧方向的车的司机都遵守交通规则，在红灯的时候会停下来等红灯；你假设侧方向的车本身都没有车辆故障，不会出现刹车失灵或者突然启动的现象。
依据假设我们可以预判未来可能发生的事情，并以此进行行动，否则我们在现实中可能寸步难行。
项目中，假设是建设项目环境，做决策，做估算和计划的基础。
我们在项目中的各个方面都可能用到假设：
- 资源：人员什么时候能到位，资源采购什么时候能完成
- 预算：估算的项目预算，项目的应急储备、客户能给到的CR量
- 范围：在确定需求之后，客户还会不会改
- 进度：在什么什么满足的情况下，我们可以在某个时间交付
- 技术方案：假设某个技术方案可以实现业务需求
等等。
那么假设管理的大致流程是怎样呢？类似风险管理，假设管理可以简单分为以下几步：
- 识别假设
- 记录假设
- 验证假设
- 监控及调整
识别假设或者做出假设，是我们在进行项目估算、设计、计划中那些认为为真的东西。项目经理和团队成员一起，将自己认为为真的前提列出来。
项目中的假设有些很好识别，比如上述提到的假设人员什么时候能到位；或者上篇案例中提到的假设对方系统API接口开发多久能完成。有些假设不好识别，比如上篇中提到的客户需求的成熟度，由于客户给到了非常详细的需求，我们就认为需求是非常成熟的，这其实就是一个隐含的假设；或者上篇提到的我们提交了详细的原型设计，但客户回来说他们要一个粗略的，这其实也是对一个完成定义的假设。
识别的假设记录在假设登记册 Assumption Log中（说实话，我以前没有做过这个东西，但是踩过很多次坑之后，我会开始的）
假设登记册需要有一个状态 Status。这个状态有别于其他的登记册，这个状态可以定义为：
- 成立 – 已验证
- 成立 – 前提条件xxx
- 不成立
- 不成立 – 前提条件xxx
项目假设是风险识别的一个重要来源，当假设被证实为“不成立”或者有前提条件的成立时，风险就产生了。
因此，经验证后，不成立的假设或者带条件的假设，一定要有相应的后续活动，风险的管理计划等。
🌰比如有一个项目，我们在项目启动之前，给客户列了两个，假设客户两个服务平台，客户都没有否认。等到项目开始之后，这些平台客户都无法提供，这些需要我们自己来实现。
我跟开发说这个情况，开发不能理解，说我们之前已经跟在方案中跟客户提了这两个平台的呀，我们一直在说这两个平台呀。
没有办法，我只有很直接、直白的说，我们提的是我们的假设，现在假设不成立 （Assumption Failed)，现实如此。
于是我们只能依据事实调整解决方案。
因此，假设的验证需要反复进行。千万不要客户没有反驳就当肯定，也千万不要以为客户说过了就可以高枕无忧。对于那些影响大的假设，多问几次，多方查证，确定肯定，不要怕麻烦。😮💨
项目结束之后做经验教训总结时，也要回顾假设登记册。看哪些是真实有效的，哪些是想当然信以为真最后踩坑的，作为后续项目的是非常宝贵的经验。
最后分享一个项目假设登记册