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

  • 崔康

2012 年 7 月 29 日

话题:架构DevOps语言 & 开发文化 & 方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架构DevOps语言 & 开发文化 & 方法