高焕堂谈架构师应该如何对待“用户需求”

资深架构师高焕堂在微博中提到：架构师不要围绕着“用户需求”跑，才能创造出更具独特性的产品，给予更好的“用户体验”。对此，他分析了具体的办法和原因：

关于这个问题，我举一个福特汽车的例子。100多年前，福特汽车的销售人员，做完客户需求调研之后，回报给公司说：客户需要的是一匹更快的马。此时身为架构师该如何面对呢? 架构师要试图干掉这项需求，然后想办法设计出汽车，比马跑得快，因为他不能带领福特工程师去弄出更快的马!

架构师要先试图找理由去否定(干掉、删除)客户、老板、或团队的需求；而不是一直找理由去支持(或证实)自己的见解。这也引起许多人的质疑；我只好举出麦肯锡顾问公司的拿手绝招就是“删除法”(英文的MECE)，也就是俗称的“架构简法设计”。

 关于“架构师要先试图找理由去否定(干掉、删除)客户、老板、或团队的需求”，我也不得不再举孔明在<隆中对>里，开场就干掉刘备的需求：统一天下。孔明写到：“操拥兵百万，挟天子以令诸侯，不可与之争峰也”。接着，还删除了刘备的第二项需求：二分天下。好的架构师该如是也。

#架构师思维练习# 许多人认为本质是简单的、不变的，所以架构师应该去分析变与不变、然后呈现其简单的不变性。这种认知可能有错，试想爱因斯坦发现了E=MC^2不变定律，他发现(Discover)定律，并不设计(Design)该定律。因之，如果架构师的职责是架构的“设计”，就不该走分析、不变的“发现”之路。

著名架构师周爱民老师于4年前送我<大道至简>一书，几天前他与我见面，说到我的“容易(包容改变) “说，引发了他写了一本新书：《大道至易》。架构师设计容器去包容人(需求)、内容与机器(硬件平台)的改变，做容器是简单的，但是架构师要随变而做出不同容器，要创意、设计并不简单，更何况要去驾驭改变呢! 

我主张先设计，先想“合”，后“分”析。从愿景而设计，带动分析事实，删除不合理的设计和需求。分析不仅仅解析需求，理解需求的手段也不仅是分析而已，设计也是。 

洋人的麦当劳、肯德基面在顾客提出炸鸡需求时，以“合”待之(半鸡=一支鸡腿+一只翅膀+一块鸡胸)；华人的全聚德烤鸭，则以“分”待之(在客人面前切分烤鸭)。洋人以合(设计)为主导，华人以分(解析)为依归。这不能解释为：洋人有成熟行业，或者洋人有秉赋特异的架构师! 而是思维局限了自己。

俗语说：期望越大失望就越大。这回峰会，架构师对硬件冷漠，对于设计专业疏离，令我大失所望。相对地，我月初访问了韩国三星，其Android架构师Invain和4年前一样，还是说：我们卖设计，不是卖产品。反观，这次我邀请了设计系教授和TCL硬件经理来互动，却没人提问硬件与设计!没有软硬整合思维，已经无法面对移动互联网的时代趋势了，软件架构师还是躲在纯软件的项目管理、测试上，让我对全球硬件生产重镇的深圳，实在搞不懂深圳IT产业的何去何从。

客户需求不应该视为真正的需求，客户期望只是架构师处理愿景、做规划(架构设计)时的一项参考而已，架构设计之后才能产生一项产品或系统开发的需求规格(Spec)。只是许多架构师都位于生产段，而不是位于规划段。

用户体验是用户的整体幸福感，架构设计也必须尽力贡献一些。

大家也对此发表了自己的看法。

大家叫我导演： 从愿景而设计，在电信的时候有一个总体设计过程，不知道是否是高老师所说的内容。涉及到目标业务过程，组织结构，理想业务流程，依赖等。然后从客户需求出发，分析用户诉求。这里面存在和愿景的妥协或者删减以及重构愿景。在实际实施过程中，现实可能骨感！

-cuichao-： 例如这个我觉得这样表达更好： 我们要考虑“用户的需求”，而不是拘于“用户的要求”，用户要求的，未必是他想要的，更未必是他需要的。 你这样上来否定“用户需求”，大家当然不容易理解，个人觉得一定程度上是因为表达上的不精确。比较大家会把用户体验也理解成需求的部分。

徐锋-需求and投资：架构不围绕着需求跑，还有几分道理；给用户带去更好的用户体验，也归入到了架构中，就有点牵强附会了。用户体验关键在于信息、交互与支持：信息的组织、呈现（信息）；功能的位置、样子、交互过程“引导、反馈”、出错处理（交互）；帮助、关联行为、异常、模式（支持）。前两个是UE，后一个是需求。

Pu世海：很多时候用户是不知道自己真正需求的，比如这里的例子，用户的真是需求更快的从A点到B点，而不是非得要更快的马，因为他不知道你能提供汽车。只要分析准确，架构必然围着<用户需求>跑，一切技术都是为了需求.

InfoQ的读者对高焕堂的观点有何看法？欢迎发表自己的意见！