爱数新闻

以前看《人月神话》的时候，对其中所述的“概念一致性”这个词的记忆最为深刻。尽管当时并不真正知道这个词在产品设计中有什么重要的作用。直到最近在设计爱数 AnyBackup Cloud 的 MSP 版本时，才真正在实际的产品上体会到概念一致性的重要性。

说得重一点，概念一致性是决定一个产品失败与成功的关键。

当前软件产品的开发，已经完全越过了远古与中世纪时期的个人英雄主义时代，取而代之的是团队协同作战。软件开发是从需求的收集、提取、分析，再导入到实际的开发过程，最终形成产品交付给用户。在这个过程中如何保证需求的传递没有变样呢？三人成虎便是沟通出现问题的典型场景。

虽然在需求传递过程中，并不见得有人会故意加入不存在的因素来造成干扰。但是一定会有主观的理解因素加入，这也就导致大多时候，产品会对研发人员说“这个需求很简单啊，用不了一个发布周期就可以搞定。”

从原理上说，在市场中我需要快捷支付手段来满足交易需求，这样的需求是一个最简单不过的了。但是支付的发展就从来没有停止变化，也就是说在不断调整支付方式来适应用户的需求。

所以，在产品的开发过程中，市场人员，售前人员，设计人员，研发人员采用什么样的沟通方式不是最重要的。最重要的是，这个团队中的人对于自己要开发的产品的产出（即概念），有没有一致的理解才是最重要的。有时我们发现我们一天到晚都在沟通，都很忙的样子，但是实际上这些人是不是在基于同一个目标在讨论呢？

比如下面这组图，很直观地说出了在需求沟通中容易出现的问题。

正如之前我加入爱数 AnyBackup Cloud 团队之始，在理解 MSP 业务与共享灾备业务时，其实存在理解上的困难。而当时AnyBackup Cloud所设计的功能中有计费，有云，有管理各种功能，但是我却没有办法将这些功能用一个统一的概念来理解。我无法从细节上去说明，为什么这些功能揉合在一起后，感觉那么不协调。而这种情况带来的问题就是，在产品的设计与实现上要经常改动，因为没有一致的概念，做出来的东西，一定不是另一个人所要的东西，结果就是越改越不像之前所描述的东西。

现在回过头来想，其实就是产品团队内部对于产品的概念的一致性没有理解，或者没有很好地将产品内部进行传达，或者这也是在产品的摸索阶段的问题。但是无论怎样，产品人员以及架构师，除了打通需求到研发之间的通道外，一个更重要的问题就是要在团队内传递一致的产品视图。在这个一致的视图下讨论问题，才是有效的。如果发现我在描述问题时，你无法理解，那么我要做的不是一遍遍地重复，而是回过头来梳理我们是不是在讲同一个事情。

在传递概念一致性的过程中，细节是非常重要的，有时会决定了构架的设计。所以产品人员在沟通需求时，尽量将所有细节都要表达出来。

比如，在AnyBackup Cloud与 H3C 在沟通 MSP 业务产品开发的过程中，产品的运行平台、业务模式，甚至是网络的访问限制都会对研发的实现产生重要影响。在 H3C 的平台上运行时，网络的 NAT接入方式就导致了AnyBackup对于AnyBackup Cloud授权方式的改变，而这个改变对于研发代码的重构也产生了重大影响。

另一个细节，也决定了AnyBackup Cloud的构架上的决策。

以常规的AnyBackup结点的方式来做 MSP 业务，在实现目前的一些需求时，成本是比较高的。而且架构的灵活性也受到极大的限制。而如果AnyBackup结点是类似于按需创建的话，之前的架构灵活性的问题就基本消除了。因此也可以采用目前构架方式来匹配 MSP 业务，并且成本低，结构简单，对于用户也好，对于产品开发也好，都非常好理解，也不需要引入什么高大上的技术方案。这样保持了AnyBackup Cloud在两个不同业务场景下产品结构与定义的协调统一，在概念上也就统一了。

因此，产品的概念一致性是一个非常重要的产品目标，基本上是可以上升为“道”的级别。

而研发方法，项目管理方案都是要基于这个“道”之下的“术”。产品人员向用户讲述的是产品“做什么”的故事，而向研发团队讲述的是产品“是什么”的故事。只有这个“是什么”讲述清楚了，架构才会清楚，研发才会清楚。

而且，在讲述故事时，所有可得到的细节都要一并传递，不要以为不重要，因为魔鬼都藏在细节里。