颠倒的过程

需求分析和软件设计的一个基本指导原则，就是先确定What，然后再谈论How。What是问题，How是方案，当然是搞清楚问题再谈方案，这不需要解释。

What和How的不是绝对滴，而是相对滴概念。前一个阶段的How是下一个阶段的What，重复交替向前。如,用户提出需求是What，需求分析得到的具体功能是How，这些具体功能对设计阶段而言就是What。What和How之间的界限有时是模糊的，难以辨请。

需求拿到开发人员面前，许多就是“功能说明”，而不是用户的真正原始需求。没有人问“究竟真正要解决的问题是什么？有没有更好的方式？”。这种需求许多是想当然的How，脱离了更前面的What，有着巨大的风险。同时这也极大的压缩了开发人员的发挥空间，让开发人员成为流水线上的机械员工。

就像我所曾经说：任何一个不合理的存在，背后都有更多更大的不合理存在来和他适应，你看到的是冰山露出水面的一角。如果你想挑战眼前的这个不合理，你最终面对的是它背后的千军万马。他们团结一致，而你孤立无援。毕竟在整体上而言，存在于当前历史阶段的世界是荒谬的。

分析原因，暂时能想到下面几个：
1)用户提不出具体的需求，有时候是因为项目负责人是不了解现状的领导，真正将来使用系统的用户很少能参与交流。领导们听市场人员讨论方案，并以他们能理解的方式谈论方案。
2)从问题到方案，在IT领域有许多的思维定势。许多人脱离的方案就没有办法讨论问题，因为最广为人知的概念都来自于方案领域而不是问题领域。这些定势最终成为创新的障碍。
3)销售人员在介绍方案时，总是喜欢贩卖“IT业的时尚概念”，用户也追逐这些概念，大家都不关心这些华丽概念的真正价值。更麻烦的，用户会从多家销售人员那里学习一堆这样的概念，然后和你谈论。用户很多时候是因为有这些概念才立项，才和你谈论。他们的项目标书常是各种流行概念的混杂体。
4)为什么用户不关心问题而关心技术了呢？许多用户在听取厂商介绍产品的时候，总是喜欢挑战厂商，他们关心当前产品存在的技术上的限制性，然后不断的要求你突破这些限制，制造“万能软件”。而他们不知道，这种能适应各种情况的“万能软件“，往往不能很好地适应用户实际的特定环境。用户在合同上很高兴能提出技术上的难题要求厂商解决。其实并不是能解决难技术题的产品才是好的产品，能以最简单，最可靠的方式解决用户实际问题的产品才是好产品。

开发人员在回答How前，必须反过来问What，在可能的范围内接近用户原始的需求，针对用户面对的实际问题。给出自己的建议，甚至应该反复和用户确认，要求和真正使用软件的人交流。依靠洞察力识别各种风险，重新定义这些功能说明，让他的存在合理化，以能存在的更久远一些，不要浪费大家的感情和精力。