BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 崔康 关注 1 他的粉丝 发布于 2012年7月31日. 估计阅读时间: 5 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

产品和架构还是不同的 by Kim Ian

产品构建在现有能力的基础上;架构构建在现有信息资产的基础上。
至于这是不是就定义了产品经理和架构师,还有待商榷。
总以为不如由相关的团队或委员会来进行产品管理和架构设计。

大道至简 by Zhang Leric

用户的需求是天马行空,非常散乱的,感觉架构师的工作就像物理研究一样,抽象出一个简单的模型,去拟合用户的需求,同时引导用户发现他真正想要的东西。现实诚然不可能像物理和数学公式一样完美,一个优美的模型会是系统日后成长的坚实基础。

这其实是两个问题 by biao jiang

以客户的需求为主导的,受制于客户需求的是,是项目性的研发团队,中国多的是这种公司,关注于特定的受众群体,为他们量身定做,请问此事你能不被客户的需求牵着鼻子走吗?
另外一种是以产品型主导的开发团队,不是别人告诉你怎么做,而是你做一款产品,然后推动社会的认知和习惯

作者想说什么 by 黄 ZITI

作者可能想表达架构设计应给予某种变与不变边界的模型之上(比如企业模型等等),而不是暂时看到的某些客户需求。
这种想法违反认识的一般过程,一个复杂事物,曾能先看到全局才能设计,有些学究气。
架构,保持简单,做好能做到的就行

Re: 作者想说什么 by 陈 志明

企业需要高老师这样的顾问去讲课,给予一定的视野和技术指导。

架构与需求 by li desheng

看了以上的文章,感觉说法有些偏颇。
需要的彻底理解与分析,是架构的基础吧。而架构在这个基础上,进行设计应该是合理的。只不过在需求的分析基础上,是给客户提供一匹更快的马还是提供一个一匹更快的马-汽车,这都来自于客户的需求。
至于高老师提到的架构师应该对硬件的了解和设计,我颇为赞同。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT