序言：
今天写的是：构建完整的解决方案。 原因是在过去的几年中，经常面临“需求变化”的问题。努力寻找了很多年的解决方案，现在想来，或许问题还是出在我们自己身上，因为我们当初的基础不对。一句“客户并不真的清楚自己的需求”，我们真的明白这句话的含义并知道如何应对了么?
什么是“完整的解决方案”?
“完整解决方案”顾名思义，就是包含了客户的所有真实需求，并可以合理实施的方案。定义很简单，简单的像围棋只有黑白二子一样，唯一的问题就是：可能的变化多了点，不确定性高了点。
相对围棋而言，软件的需求和方案的问题简单很多了。
主要的问题在于，我们的“需求”中忽略了很多客户的隐形需求。
隐形需求包含哪些呢?一般而言包括：
1.1 维护需求
1.2 升级需求
1.3 易用性需求
1.4 性能需求
基本而言，现在客户也在不断成熟，以上需求会或多或少的提到，但是，请注意，很可能不够全面。 所以我们需要认认真真的考虑一下，这些需求到底应该包含些什么。
维护需求
客户对维护的要求，一般至少包括这么几个：
1. 日志需求。 这个比较复杂，后面会单独考虑。
2. 故障定位的能力。 就是说，当系统出现问题时，客户希望系统能够通过某种方式迅速查明故障的原因，并找到解决或者规避的办法。
3. 日常维护。 通常包括软件和硬件的“健康检查”。
4. 故障报警。 当系统出现严重故障时，能够给出足够的信息，并触发故障处理流程。
升级需求
一般来说，客户对升级的需求有这么几点：
1. 可控制的升级。 即检测是否可升级、是否执行升级、多个升级目标的选择、升级的计划任务等都是可以控制的，比如可以设定自动检测是否升级;设定自动升级到***版本;设定执行升级必须为手工设置;设置手工升级时可以立即升级也可以指定计划任务时间等等。
2. 不影响业务的升级。 基本上客户都希望升级这个事情，不要影响他们的业务。但是有些系统实在太老了，基于这种旧系统的再开发项目必然受限于原系统的升级方案。这时就考虑：1.能不能通过升级，使系统以后升级不再影响业务;2.如果不能，怎样使(本次后以后)升级对业务的影响最小。
3. 升级的简单性。升级应该简单快捷，没有太多的参数需要配置，没有太多需要手工干预的步骤。
4. 升级的完整性。尤其是对于分布式系统，升级时需要考虑各个部件之间版本的一致性。一个升级方案必须是完整的，不能在升级以后出现由于版本间不兼容的原因而导致系统无法工作。举个例子：
一个简单的CS系统，采用加密通道进行通讯，现在升级加密算法，该如何设计呢?
假设是互联网应用，有上万个客户端，该如何设计呢?
从这个例子可以看出，系统的设计，从一开始就必须考虑这些“隐性”需求，否则系统架构可能都要****重来。
易用性需求
通常提到易用性，大家会觉得无非是界面啦，帮助啦。没错，但是不全。
让我们看几个例子，可以大概理解一下易用性是什么概念。
在桌面系统的竞争中，专业而强大的Unix败给了经常被人批评的Windows系列，因为windows安装简单，升级简单，安装新的游戏或者软件也很简单，操作起来更是如此，直观的图形界面虽然设计和功能不太丰富和强大，但是相对于unix必须先学习“文件系统”概念，再学习命令行而言，“树”的概念用户可以无师自通，拖拽更是没有命令行可以比拟;
同样是微软，C++语言乘微软之名，挟操作系统之利，语言和开发环境都不可谓不强大，但是结果怎样呢?IDE方面多数人还是用SI，语言方面，微软更是不得不推出C#来与Java抗衡。就因为SI看代码的时候查找上下文方便;Java比C++开发起来方便;
在中文输入法的竞争中，强大高效的笔画输入法败给了拼音输入法。现在拼音输入法大行其道，笔画输入几乎鲜有提起。
最主要的，是业务模型要和客户的一致。这个应该算是基础。业务模型代表着思维模式(比如输入法)，也就是说，要从客户的角度来设计系统，而不是机械的堆砌数据和流程。
一般来言，易用性的需求还包括：
1. 常用的功能应该能够直接了当的访问。比如财务系统，不同的角色有不同的常用功能，系统应该设计为可以根据角色来打开不同的初始页面;再比如我们常见的游戏，Save/Load菜单通常都在主页面上，没有谁设计成非得看完片头(还不能跳过)再新建游戏然后再一路杀到存取点才可以读取进度。
这里，不推荐严格的学术分级模式。或许这样看起来很专业，但是不好用。
2. 操作应该照顾客户的习惯，尽可能的降低客户的学习成本。当然，前提是正确定位你的客户群。
3. 优雅。举个例子，log。
写log的时候，不要一口气写个7、8G的log文件，尽可能的根据某些标准来归类和拆分。例如按照时间，按照log的级别。
还是用MS的VS Studio做例子，编译错误可以直接通过双击跳转到源代码所在，而不像Makefile那样只是生硬的输出文件和行号。
打开一个巨大的文件，给出一个可度量的进度条，总比只显示一个沙漏要好吧?
现在，应该可以理解什么是“优雅”了吧?我的理解，就是专业，而且体贴。
性能需求
好像现在性能需求越来越被重视了，所以我的废话也不多说，简单讲，包括：
1. 首先分清楚哪些部分各自有什么样的性能需求。用户参与的操作，性能要求通常高于其他操作。
2. 知道自己的上限。达到上限的时候，通过合理的方法让系统给予提示，而不是直接瘫痪。当然，这是理想主义。只能无限接近，不能达到;
性能是需要设计的，而不是仅靠硬件来实现。所以，在客户没有提到性能需求时，你需要通过各种渠道，真正的确定系统的性能要求是什么。“先做做试试”的结果往往是推倒重来。子曰“有的放矢”是也。
日志需求
***来说说日志需求。
日志需求是和客户的隐性需求密切相关，并且几乎全部涉及的一种需求。例如：日志要记录维护信息和升级信息，日志还要简单明了，一看就知道写的啥意思，另外日志记录功能还不能对系统的性能有大的影响。
【编辑推荐】
