软件需求的薛定谔之猫

薛定谔的猫（Erwin Schrodinger's Cat）是奥地利物理学家埃尔温·薛定谔试图证明量子力学在宏观条件下的不完备性而提出的一个思想实验。实验内容如下：

 

 

“把一只猫放进一个封闭的盒子里，然后把这个盒子连接到一个包含一个放射性原子核和一个装有有毒气体的容器的实验装置。设想这个放射性原子核在一个小时内有50％的可能性发生衰变。如果发生衰变，它将会发射出一个粒子，而发射出的这个粒子将会触发这个实验装置，打开装有毒气的容器，从而杀死这只猫。根据量子力学，未进行观察时，这个原子核处于已衰变和未衰变的叠加态，但是，如果在一个小时后把盒子打开，实验者只能看到“衰变的原子核和死猫”或者“未衰变的原子核和活猫”两种情况。现在的问题是：这个系统从什么时候开始不再处于两种不同状态的叠加态而成为其中的一种？在打开盒子观察以前，这只猫是死了还是活着抑或半死半活？这个实验的原意是想说明，如果不能对波函数塌缩以及对这只猫所处的状态给出一个合理解释的话，量子力学本身是不完备的。”

 

根据哥本哈根学派的解释，当观察者未打开盒子之前，猫处于一种“又死又活”的状态，该状态可以用一个波函数来描述，而波函数可由薛定谔方程解出。一旦观察者打开盒子观察，波函数会坍塌，猫呈现在观察者面前的只会是“生”或“死”的状态之一，似乎猫的生死是在打开盒子那一瞬间才确定的。这导致了对世界客观性和人意识的作用的讨论。

 

我对理论物理没有研究，也不打算就薛定谔的猫做更深入地了解，本文只想借“薛定谔的猫”做一个隐喻，把它和生活中的一类“不确定性”现象联系起来。我们先来看几个例子：

1.乔布斯常常引用他的偶像亨利.福特的一句名言：“如果我问从来没见过汽车的顾客他们想要什么，他们肯定会告诉我，'一匹更快的马'”。

2.互联网公司某产品经理提了个idea：“我们搞个微型博客，限制用户发文的字数不超过140个，可以关注别人”。众人一片质疑：“限制字数？这不开历史倒车吗？要关注功能直接在博客上加不就行了？”大家说得都有道理，只是老板很支持产品经理试试看，没想到微博推出火得一塌糊涂。

3.A和B是公司的两个很不错的程序员，A更擅长底层开发，B更擅长高层架构设计，一个项目中老板决定让A、B搭档形成优势互补。没想到结果A、B实际配合才发现两人思路差异太大， 不仅没有形成互补反而还互斥。

 

通过上面的几个例子我们可以对不确定性现象有一个感性的认识，即我们很难在一个事物出现或事件发生之前通过理性思辨的方式推导出它出现后的效果。虽然事后我们常常可以总结个一二三，某人为什么成功，某产品为什么受到大家喜爱，某地区房价为什么会暴涨，某潮流为什么符合大趋势，但你能保证这些理由是充分的吗？你能在事前分析并预见到这些结果吗？这说明在分析和预测某些事情的时候光靠理性思辨常常是不可靠的，就像我们软件开发中，每个项目都会定大大小小的计划，但是常常是计划不如变化快，导致程序员常常抱怨需求变化太快而疲于应付。

 

为了更好的认识软件需求的不确定性，我们先来看软件需求有哪些影响因素？我认为用户需求和外部环境是影响软件需求的两大因素。其中，用户需求是指用户所期望的结果，它从目标的角度影响软件需求；外部环境是指软件所运行和依赖的外部环境，它从实现基础的角度影响软件需求。而实际开发中我们面临两大问题：1.用户需求在实际运行前的不确定性；2.外部环境在实际运行前的不确定性。

 

用户需求的不确定性是指“需求无法在用户真正能运行看到效果之前明确下来”，比如：让你开发一套Wow这样大型的游戏，你能想象游戏的效果是设计者一开始就想好了精确到每一个细节吗？实际上，游戏的设计者通常只能借助文档，草图，Use Case等非精确的方式大致提出需求，在看到效果之后才能逐步地细化和明确。所以，实际的开发过程一定是“需求->实现->反馈->需求->...”这样在需求和实现相互反馈的过程中不断进行的，那种希望做出完美的需求分析，让需求稳定以后再来实现的想法往往是不现实的。另外，还有一种极端的情况是根本不存在精确的用户需求，比如：自动化翻译软件，你能在实现之前就把翻译效果精确的描述出来吗？存在绝对正确的翻译方法吗？类似的还有淘宝推荐，它会猜测你喜欢的商品并推荐给你，这类功能存在绝对精确的推荐吗？

 

外部环境的不确定性是指"当我们的系统需要和外部系统集成时，关于外部系统行为的假设也无法在实际集成运行前完全确定"， 比如：你做一套股票客户端系统需要连上交易所系统，尽管通常交易所会有相应的协议，但实际开发过程中，协议会有很多定义不清晰或未定义，甚至有实际行为与协议不符合的地方，这样我们只有先做假设实现，然后在交易所提供的测试环境中去确定。对于像交易所这样非常重视质量的环境都存在协议定义不清或者不全必须在集成测试时才能弄清楚的情况，对于普通的外部系统更是可想而知。所以，我们的开发常常只能先基于一定的假设，但是这些假设随时可能在实际集成的时候被修改。在实际体验外部环境之前，关于它的各种描述都是纸上谈兵，就像你拿着地图去了解一个陌生的地方一样，你了解了地图并不等于你就真的了解了那个地方。

 

由于这两种不确定性的存在，我们的软件开发必然也处于难以完全遵循计划的境地，多数试图在实现之前做出完美的需求分析和设计然后按部就班遵循计划的企图都会以失败告终。实际上，多数软件公司都意识到了需求频繁变动的现象，但是有的公司采取的措施却错得离谱，比如：某国内著名的公司为了应对需求的频繁变动专门成立了“需求评审委员会”，强调加强需求评审，要改变需求必须经委员会批准。这类做法实际上是没有认识到需求不确定性是一种自然的动力，试图通过人为调控改变自然的规律。我们应该承认两种不确定性的普遍性，我们并把它作为制定开发策略的“一等对象”来对待，化被动为主动。