大家在做项目的过程中有没有遇到过下面的情况

明明项目启动的时候确认过需求，但在功能上线的冲刺阶段却突然发现有个需求没有做或者要大改。

明明每次前期调研已经做的很详细了，但在团队实现的时候总会有遗漏点。

明明代码写的没有问题，但在上线后总会有Bug。

每当我们信心满满时，总是会有一些意想不到的情况出现，这是纯属意外，还是有规律可循？这篇博客我们就聊聊这个问题。

由于作者能力有限，本文没有对知识，问题，事情这几个概念做区分，会根据描述的便利性进行转换，它们目前属于作者的知道但不理解范围，造成的不便还请谅解。

问题的原因

当我们回顾这些场景的时候，大多数当事人的回答是我当时根本不知道有这些问题。这就是问题的关键，因为不知道还有问题没解决，所以我们相信所有问题都已经解决了，并且信心满满。在这种情况下，以事后诸葛亮的态度，要求当事人多问一些问题，多做一些研究是毫无用处的，因为当事人根本意识不到这些。

这里我们使用唐纳德·亨利·拉姆斯菲尔德的Known and Unknown来对我们需要处理的事情进行分类

Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones

我们以是否知道和是否理解两个维度，把事情分为四个象限，这里是否知道指我们主观上是否知道事情的存在，是否理解指我们客观上是否理解事情的真实含义。

• 知道且理解
  属于这个象限的事情对我们来说是显而易见的，有现成的解决方案，我们只需要按部就班的完成就可以了。例如敏捷实践，我们知道并且理解它的各种实践，只需要按照日程进行Kick Off，Pair，Code Review，Retro，Showcase就好了，不需要投入额外精力。
• 知道但不理解
  属于这个象限的事情是我们需要关注的重点，它们往往没有现成的解决方案，需要我们投入精力进行研究，制定方案。对于一些重复出现的事情，经过我们的研究和方案制定，会迁移到第一象限，也就是知道且理解。
• 不知道但理解
  我们以前处理过类似的事情，但在当前场景下我们不知道它的存在，一旦知道，就会迁移到第一象限。
• 不知道且不理解
  这个象限的事情是最让人头疼的，因为我们往往不知道它们的存在，即便知道了也不能理解它们。它们的出现往往会打破我们完美的计划，让我们措手不及，文章开头所列的场景就属于这个象限。为了减少属于这个象限的事情，我们要想办法把它们迁移到第二象限，也就是尽可能知道当前场景下的所有事情。

从上面的分析可以看到，第三和第四象限是有潜在风险的，要避免它们我们就需要解决不知道的问题。

如何解决不知道的问题？

为了叙述方便，在本节我会使用知识来代替事情，知识可以理解为人们知道的事情。

个人

对于个人来说，知识是有边界的，如何探索边界外的知识呢？主要有两种途径，寻求他人的帮助或不断试错。

面对特定的方向，寻求有相关经验的人的帮助是最快的方式，他们能够快速的指出我们不知道的部分，这也是我们日常生活中最常见的途径。所以经常和不同背景的人聊聊天对我们会大有帮助。

如果无法找到有相关经验的人，可以自己定义问题，解决问题，在不断试错的过程中发现我们以前不知道的知识。例如在日常生活中解决莫名奇妙的Bug时，我们就会采用这种方法。我们会先猜测产生Bug的各种原因，然后尝试解决，最终解决成功的那个原因就是我们以前不知道的知识。

团队

对于团队来说，知识也是有边界的。团队的知识是所有成员知识的全集，其拓展知识边界的方法和个人很类似，例如我们可以参考其他成功产品来发现我们的不足和未来的趋势，也可以通过灰度测试来尝试新的想法。

团队不但要面对知识边界拓展的问题，还需要面对知识整合的问题。所谓知识整合是指如何利用团队的全部知识来解决问题。因为只有部分团队成员会参与问题的解决，他们作为一个子团队，其知识边界必定小于整个团队，所以子团队需要整个团队对其知识边界进行拓展，类似于个人寻求有经验的人的帮助。

知识整合

这里我们以项目开发为例，团队是指所有和项目相关的人的集合，开发团队作为子团队负责项目的开发工作。

在开始阶段，开发团队要尽可能多的邀请利益相关方参与讨论，特别是具有不同业务背景的人，例如PM，QA，Dev，BA，Architect，甚至客户等。邀请的人越多，背景差异性越大，出现不知道的知识的概率就越小。这里之所以强调背景的差异性，是因为相同背景的成员，其知识边界是趋于一致的，无法达到有效拓展知识边界的目的。

在中间阶段，要尽可能快的进行迭代，将每个迭代的成果与尽可能多的利益相关方进行确认。随着时间的推移，每个利益相关方的知识边界也在不断拓展，开发团队不知道的知识也会随之出现，通过迭代确认可以快速收集这些新出现的知识。

在结束阶段，新出现的知识是十分棘手的，例如需求的缺失或修改。这个时候我们可以选择有风险的接受，这样可能会出现其他不知道的知识，也可能需要付出更高的成本。或者将其作为已知问题留在将来解决。

鉴于团队的知识是有边界的，不知道的知识是无法完全避免的。一个很好的例子就是任何产品都会有Bug，而Bug就是一种我们在开发阶段不知道的知识，它可能是我们理解的，也可能是我们不理解的。我们所能做的就是在开始和中间阶段尽可能多的发现不知道的知识，例如敏捷开发中的Iteration，Kick Off，Pair，Showcase，Code Review等实践其实就是在做这个工作。

总结

不知道且不理解的事情是无法避免的，但我们可以通过各种实践来拓展我们的知识边界，以降低其出现的概率。现在你还会觉得日常工作中的一些会议或实践是在浪费时间么？不妨从我可能不知道一些事情的角度重新审视一下它们。