问题的分类

最初在1999年被Dave Snowden开发出来的 Cynefin 框架尝试把世界上的问题划分到了5个域中（大类）：

简单（Simple）问题，该域中的因果关系非常明显，解决这些问题的方法是 感知-分类-响应（Sense-Categorise-Respond），有对应的最佳实践

复合（Complicated）问题，该域中的因果关系需要分析，或者需要一些其他形式的调查和/或专业知识的应用，解决这些问题的方法是感知-分析-响应（Sense-Analyze-Respond），有对应的好的实践

复杂（Complex）问题，该域中的因果关系仅能够从回顾中发现，解决这些问题的方法是探索-感知-响应（Probe-Sense-Respond），我们能够感知涌现实践（emergent practice）

混乱（Chaotic）问题，该域中没有系统级别的因果关系，方法是行动-感知-响应（Act-Sense-Respond），我们能够发现新颖实践（novel practice）

失序（Disorder）问题，该域中没有因果关系，不可感知，其中的问题也无法被解决

显然，金融软件开发开发过程更多地是一个复杂（Complex）问题。在一个产品被开发出来之前，不确定性非常高，团队（包括业务人员和技术人员）对产品的知识也是最少的，而且需要大量的学习和尝试才可以明确下一步可能的方向。不幸的是，很多时候我们需要在一开始（不确定性最高的时候）就为项目做计划。这种从传统行业中非常适合的方法在金融软件开发开发领域不再适用，这也是敏捷开发、精益等方法论在金融软件开发开发中更加适合的原因。

正因为金融软件开发开发事实上是一个学习的过程，我们学习到的新知识反过来会帮助我们对问题的定义，从而带来变化。这里的变化可能来自两个方向：

功能性

非功能性

功能性的变化指随着对业务的深入理解、或者已有业务规则为了匹配市场而产生的变化。比如支付方式由传统的货到付款变成了网银付款，又变成了微信支付、支付宝扫码等等。一个原始的电商平台仅仅提供基本的购物服务，但是后来可以根据已有数据产生推荐商品，从来带来更大的流量。这些变化需要体现在已有的代码中，而对代码的修改往往是牵一发而动全身。

非功能性的变化是指随着业务的发展，用户规模的增加，数据量的变化，安全认知的变化等产生的新的需求。比如100个用户的时候无需考虑性能问题，但是100万用户的时候，性能就变成了必须重视的问题。天气预报应用的数据安全性和网络银行的数据安全性要求也大不相同。

而在业务提出一个需求的时候，往往只是一个简化过的版本。