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