自从人类进入了工业时代，大生产，集体化运作成为了业界标准，小作坊的时代一去不返；从原始社会开始，人类便开始学会了协作，从数十个人分工协作完成打猎到数十万人进行的集团化战争，协作在逐步的演进和成熟。

   21世纪，电子工业的世纪。计算机的出现，网络的普及让全世界的人和物都耦合到了一起，千丝万缕的联系和更加快捷的信息流动，让世界加速变化。这个世界正在变小，这个世界也变得更加复杂。

软件伴随着计算机的出现而出现，而网络让软件的触角遍布了整个世界，甚至跨越了地球，进入太空，月球，火星，木卫一号，甚至外太空。软件的能量如此巨大，人类的智慧之光从未像今天这样光芒四射，但是随之而来的却是失控。人类创造出了软件，但它的复杂性却超越了人类的控制。复杂性的爆炸性增长使得软件从诞生之日就和不稳定成了孪生兄弟；越是强大的系统越发显得脆弱不堪，一个小小的疏漏就可能导致系统瞬间崩溃。

无数的公司和学者都在研究，如何控制软件的复杂度，如何高效，优雅的组织一个团队去开发一个正确的软件系统。流程和模式由此诞生了。这些流程和模式成功了，从80年代到21世纪，软件的开发效率提升了数十倍，软件产业的规模扩大了几百倍，软件应用的领域覆盖了几乎所有的行业；但这些流程也失败了，迄今为止银弹尚未诞生，还没有一个流程和工程方法能确保软件的成功。软件的不确定性似乎已融入了基因，“不确定”就像病毒一样将自己的基因片段嵌入了宿主。这一切的根源究竟是什么呢？

软件，归根到底，只是人类解决现实问题的一种工具，它的本质同250万年前史前人类打磨的石器并无二致。石器是如此的纯粹，只因它所解决的问题十分单纯，应用的环境简单明确。而现代的软件命运却没这么幸运，它从一出生就开始，就面对这一个烂摊子。

软件需直面三个方面的难题：

       1）需求

       2）实现

       3）演进

“需求”=问题+场景+解决方案

我们先来探讨一下”问题“。问题在现实世界，虚拟世界，bit洪流的信息世界并不是稀缺品，它们甚至多的让人无法忍受。这些问题大都需要通过软件来解决，软件大显身手的时候到了。很多时候问题代表着机遇，能够先人一步的发现问题，往往意味着向成功之路迈进了一大步。然而，很多软件或企业都倒在了发现问题到解决问题的道路上。从一开始的信心满满，到不知不觉陷入泥沼，这一切都是那么的自然。何以至此？软件和它要解决的问题南辕北辙！

软件世界的问题，林林总总，但是大都走过了相似的信息传递路径。从客户到市场人员，到需求分析人员，到开发人员；冗长的传递管道导致大量信息的丢失，并且或多或少的混入各个传递节点自认为“正确”的理解，啼笑皆非的事情时有发生。

有一个患有糖尿病的客户，购买了一台胰岛素注射器，但是由于胰岛素的注射需有严格的周期限制，必须定时注射，即使是在睡眠中也不例外，因此这个客户就向生产商x公司提出了“定时提醒用户进行注射”的需求。x公司市场人员对于这个VIP客户十分重视，要知道他可是y地区有头有脸的 人物，他的影响力可以为x公司的销售额带来两倍的增长。市场人员以最快的速度向开发人员提出了要在注射器上“增加定时闹钟”的需求。经过需求分析人员，开发人员的层层传递和研发，客户在忍受了一年的等待和煎熬后，终于在付出了旧款10倍价格的代价下购买到了x公司开发的最新款的“智能“注射器。注射器的体积增加了一倍，支持wifi功能，可以联通互联网，拥有一块4英寸的液晶显示屏，并且配备一块3000毫安的锂电池（即使如此仍需要每三天充电一次）。在长达50页的的操作指导手册中，用户艰难的学习着如何初始化系统，如何设置和修改闹钟，如何注册x公司的服务账户，如何接入x公司云服务器使用各种“智能”服务..... 终于，这个60岁的患者放弃了。他无奈的将”智能“注射器丢到一旁，看了看手表。还有30分钟就要注射，该去准备胰岛素了。拿着旧款注射器，佝偻着身躯，这位VIP客户的背影从”智能“注射器锃亮的液晶显示器面板上消失了。

看完这个故事，你一定会觉得夸张，现实世界中不可能发生这种事情。是的，你说对了，现实世界的确不曾发生这件事情，这个是我杜撰出来的。但是不能回避的是，现实世界类似的事情在不断的涌现。

通过这个故事中，我想表达几个观点：

   1）"问题"的源头往往是错误的：客户所说的并不代表问题的本质。

   2）“问题”传递的管道往往存在着大量干扰：研发最终接收到的需求参杂着大量的错误信息。

“洞察需求”

    1）“理解用户”：用户的诉求，用户的痛点，使用的场景

    2）“洞察行业”：行业趋势，行业参与者

洞察用户的痛点及使用场景是至关重要，如果这个步骤出错，整个系统将会走上不归路。发现正确的问题就像指南针一样指明了方向，这是成功的第一步。

国有国法，家有家规，一个成熟的行业同样有其运行的法则。一个行业的参与者经过长期的演进后，产品往往趋同。主要的原因有两个。一是随着行业参与者集体的摸索，整个行业内所面临的问题逐渐清晰，每个问题的场景也逐渐明确。二是对于同样问题和场景，大家提出的解决方案基本趋同，成熟的方案大同小异。在这种情况下，产品的设计者如果能够借鉴其他产品的成熟经验就相当于从半空中起飞，这就是后发优势。


  ”适合的解决方案--坚持和妥协“

当明确了需求和使用场景后，我们要做的就是提出正确的解决方案，但是面对纷杂的需求和场景，我们往往会茫然无措；这里我想引用几个案例。

   1）日本的航空业：

日本从二战后迅速崛起，成为了仅次于美国的经济实体，其精工制造业世界领先，但是在航空航天领域，日本一直鲜有建树。日本人的细致和执着想必大家都有所耳闻，为什么航空领域就不行了呢。个人臆想，只见树木不见森林可能是问题的症结。越是复杂的系统，影响其整体功能的要素越多，每个要素多有对应的解决方案，但是这些解决方案经常发生冲突，或者互相纠缠。如果此时过于纠结于具体的要素和细节就会迷失。

   2）AK47和M16：

越战时，美国的战地记者经常看到这样的景象：美军士兵丢弃了制作精良的M16，拿着从越军手里缴获的AK47作战。原来M16为了保障射击精度，结构设计的十分精密，但在恶劣的战场环境下经常卡壳。但是AK47却正好相反，虽然精度不高，但是在严酷的战场环境下却可以正常使用。有人曾经做过十分夸张的试验，将AK47抛入水中侵泡、放进沙堆进行沙浴、使用卡车碾压等，轮番蹂躏后AK47仍然能够正常射击。在惊叹的同时我们不得不佩服苏联的武器专家的睿智，可靠性和射击精度这对天生的冤家在他们手里得到了平衡。M16的设计者不会不考虑战场的严酷环境，在可靠性方面，M16也做了大量的保障措施，但是阳春白雪毕竟不了解下里巴人，远离战场的武器专家低估了战场环境的复杂性，最终导致了一个错误产品的诞生。但M16并不是一无是处，换一个场景，M16又变成了英雄。使用M16和AK47远距离进行精确射击的场景，比如狙击，其命中率远胜AK47。

同一个产品，放在不同的场景下结果却天壤之别；设计师只有充分的了解需求和应用场景后，把握关键要素，在确保关键要素，关键使用场景的情况下兼顾其他次要要素和场景，才能设计出一个能解决关键问题，发挥核心价值的产品。设计师需要有敏锐的洞察力，穿过层层迷雾，直击靶心。

"持续演进"

产品的诞生，其目的是为了解决问题，但是具有讽刺意味的是，新产品的出现往往会带来新的问题。就像一个原本平衡的生态系统中引入一个新物种一样，原有的平衡必然会被打破，但建立新的平衡却没有多少时间。面对陌生环境，新物种必须快速的适应才能生存下去。对于产品来说，快速的演进机制至关重要，产品团队必须构建一个快速的反馈环路，使得产品能够持续演进。那么如何进行持续演进呢？

   1）构建演进的基因。设计师必须在设计之初就考虑好产品的演进方式，并对产品可能的演进方向，即系统的变化点进行预测。对变化点要进行隔离，避免变化引起系统内部的连锁反应。我们经常会出现的问题是，修复一个问题后，更多的问题却诞生了，系统内部的关联过于紧密，牵一发而动全身时有发生。看似毫无关系的部分，却发生了关联，这种情况要极力避免。如何才能设计出简洁的系统？答案是分解和归类。将一个复杂的问题分解为多个简单的问题，并将经过分解的问题归类。对归类的问题提出解决方案，并将这些方案组装起来，构建成一个解决复杂问题的系统。建造金字塔，雕刻雕塑，设计航天飞机，面对复杂的问题我们只能去分解。在生产活动中出于提高效率传递经验的考虑，工程师们发明了模式。模式是针对特定问题，特定场景提出的最优解决方案。我们在设计时可以参考模式，如编程模式，设计模式，体系结构模式等。模式可以看成设计师的工具，所以只有充分的理解所要解决的问题，并熟知相关工具的特点后才能选择出适合的模式。设计人员刚接触模式的时容易滥用，“手里拿着锤子，看什么都像钉子”，我们必须明白，模式只有在它适合场景中才能发挥正能量，一个汽车修理铺里不需要瑞士×××。

   2）为新的需求设计出适合的方案。什么方案才算是适合的方案？解决了核心问题，并且平衡其他各方面的要素，总支出最小，产生的效益最大的就是适合的方案。如何选择适合的方案？首先，针对要解决的问题及影响要素根据优先级设定不同的权重，比如可行性，功能，性能，可靠性，可扩展性，可维护性，成本，上市时间等；评估方案对每个维度的影响并打分，最后对评分加权求和后择优录取。

   3）评估方案的实施效果。是骡子是马拉出来溜溜，这个通俗谚语，用在此处十分恰当。方案上线后需要对实施效果进行评估，因此系统设计之初就应该构建一套监测机制并梳理出关键的监测指标。如何确定关键指标？内部关键指标往往是系统运行的关键路径中的关键节点，每个关键节点都可以提炼出不同维度的指标，比如响应时延，处理任务数，句柄数，流量等等。外部的关键指标需要外部系统配合，系统自身只能对输入和输出进行监控。

   4）根据实施效果，对方案进行修正。