今天聊一聊项目管理中的容易踩的大坑，那些看得见的、看不见的、认为是理所当然的假设。
这个话题分两篇，第一篇先给大家分享两个让我印象深刻的经验教训。
第一个是之前有一个项目，系统需要与一个其他系统进行对接，需要对方系统给我们开几个API接口。
在项目初期，对于这个数据交换需求与那个系统的技术同事做过初步对接和可行性评估，评估的结果是大概开几个接口，技术也可实现。于是项目就愉快的推进了。
但是对于对方开发这个接口具体需要多长时间，我与对方项目经理基于以往对于这个系统的经验，大概预估需要2个星期，这个时间并没有跟对方技术同事去确认。
这个接口开发需要2个星期就作为我们项目的一个基本假设，我们以此进行项目计划和工作安排。
等到实际我们将具体的接口需求做出来，给对方项目团队提出正式需求的时候，对方技术团队给出了评估：完成接口开发需要2个月，且需要10个接口才能完成业务需求。
傻眼了。
第二个是一个大中华区一个非大陆地区的客户项目。客户在项目启动阶段就给出了非常详细的需求，细化的业务流程、甚至在哪些节点希望得到的邮件提醒（邮件发给谁），这些内容在启动阶段就提供给了我们。
我们欣喜的以为这会是一个业务需求清晰的项目，客户业务方能够清晰的描述业务场景，提供所需的业务资料，需求设计阶段会非常顺利。
基于此理解，我们跟客户展开了多轮的需求讨论，对于他们给出的业务流程、需求文档进行了理解，对于一些不清晰的点也向他们提出。并基于这些理解，我们给出了更新的业务流程图，初步的系统原型。
期中有遇到我们向客户提出要他们现在使用的一些文档、表单模板时遭到了拒绝，但这些我们当时并没有在意，而是基于理解往前推进。
但是当我们给出了70%的系统原型之后，在一个希望进入到高保真原型设计阶段的大型讨论会上，客户突然开始抱怨，说我们的需求阶段做的非常不专业。
我们非常不理解这个抱怨的来源。
我们的需求讨论客户的业务部门和IT部门都有参与，出的业务流程图、系统原型也跟IT部门和业务部门关键用户讨论、审核过多次。为什么会在接近尾声进入到高保真设计阶段遭到投诉。
此时我们才了解到，业务部门之前提供的业务需求，是他们给予对现有业务的理解，经过加工改进，设计的未来的业务方案，并非当前工作流程。
而实际上，业务部门关键用户对于我们的期待是我们能够根据我们的专业知识和经验，对于他们给出的这套方案进行更新和改进，而非直接使用，所以拒绝提供现在使用的文档和表单模板。
甚至对于我们给出的原型方案，其他业务用户提出，他们并没有想到是一个如此完整的原型方案，他们希望的是一个更加初级的方案。
上面两个教训都是跟假设且没有验证有关。第一个是意识到的假设，但是基于经验且过于自信，没有进行验证；第二个是没有意识到的假设，被表象蒙蔽，以为现实如此美好。
下一篇从理论的角度介绍一下假设的定义、来源和验证管理方法。
