中国IT动力,最新最全的IT技术教程
最新100篇 | 推荐100篇 | 专题100篇 | 排行榜 | 搜索 | 在线API文档
首 页 | 程序开发 | 操作系统 | 软件应用 | 图形图象 | 网络应用 | 精文荟萃 | 教育认证 | 硬件维护 | 未整理篇 | 站长教程
ASP JS PHP工程 ASP.NET 网站建设 UML J2EESUN .NET VC VB VFP 网络维护 数据库 DB2 SQL2000 Oracle Mysql
服务器 Win2000 Office C DreamWeaver FireWorks Flash PhotoShop 上网宝典 CorelDraw 协议大全 网络安全 微软认证
硬件维护  CPU  主板  硬盘  内存  显卡  显示器  键盘鼠标  声卡音箱  打印机  机箱电源  BIOS  网卡  C#  Java  Delphi  vs.net2005
  当前位置:> 程序开发 > 软件工程 > 系统分析 > 系统设计 > 系统设计
发明软件
作者:未知 时间:2005-08-07 11:18 出处:系统分析之窗 责编:chinaitpower
              摘要:发明软件

发明软件

Larry Constantine zhen_lei


——创新是一个过程,不是一种产品。一些软件公司宁愿称自己为创新者,却不愿做实际的创新工作

 

 任何软件公司都希望开辟新天地,只是他们不想成为先驱。在这样一个创新占统治地位,每个新的“.com”公司都把创新(first-to-market)作为自己的战斗口号的时代,令人吃惊的是,很多软件开发者和他们的经理实际上破坏了他们自己领导创新之路的创造性潜力。实际上,一些公司只愿称自己为创新者而不去做创新的事情。

不像好莱坞和电视剧表演的那样,创新不是偶然的。发明家很少仅由于运气而偶然获得好想法。发明有用产品的多产发明家知道创新突破出现在特定的情况,产生于特定的实践过程。有用的发明经常从边缘而不是中心切入。创新成功于车库实验室,伴随艰苦的工作,产生于聪明的、不遵从传统的团队。在一定的条件下,实际的创新可以根据要求产生,而且这种成功可以一次又一次地重复出现。其中的秘诀是认识到创新是一个过程而不是一种产品,这几乎被业界所有的创新团队所认识。

多年来,我的公司和用户采用这个秘诀有计划地创造用户界面突破。最终,经我们训练、指导或与之合作的团队生产了一系列软件专利应用,其中的一两项被认为是革命性的图形化用户界面。

我们没有自大地认为仅有我们发现了这个规律。实际上,我们所采用的创造工程过程是可以学习的和传授的,对此,我们深信不疑。最近,我们甚至推出了一个叫做“发明界面”的研讨班。这是一个实验。使我们吃惊和高兴的是,想要参加这个课程的人数超过了房间允许的限制,而且还得到了许多热情的评论。尽管如此,它只是那些真正揭示当今软件工业所面临问题的评价方式的脚注和说明。让我们看一下阻止软件发明的一些内在因素。

寻找答案

我们的“发明界面”课程被策划为集中于动手实践创新过程的研讨班,但一些参加者抱怨将时间花费在学习、实践和采用创新工程技术上。他们希望更多地看到其他人创新的用户界面实例。

画家通过绘画学习怎样绘画。创新工程要通过创新工程过程来学习。这看上去理所当然,但是模仿是创新的对立面。我可以给你看很多创新的用户界面,但你仍然不知道设计者是如何达到这些创新的。如果你希望购买一个现有方案,仔细查看其它人的创新作品是重要的。如果你希望创造些新的并且可以真正工作的产品,你需要知道如何自己去做。

正如一个有关捕鱼的谚语所说的,给人现成的鱼,只够他们一天的生活,而教会他们捕鱼,可以使他们生活一生。我们课堂上的问题是,我们是老师而不是渔夫,但有些参加者只想带几条鱼回家。

对我来说,编程——这种对我们来说首先是职业的工作——的真正乐趣在于解决问题,把事情想清楚,而如此多的程序员都一直是在寻找简单的答案。当经理们一直注意他们的竞争对手正在做什么,而不是思考他们自己应该做什么时,这个错误就更严重了。

如果你寻找答案,特别是简单的答案,你通常能得到的最好结果是从解决别人问题的陈旧方案演变而来。实际上,做好你自己的家庭作业,彻底研究那些以前的问题,甚至是有时和你刚好相反的问题,特别是当你需要探索新领域的时候。

我有一个终生的习惯,在看别人的解决方法之前,自己动手尝试解决问题。在我自己努力解决一个问题,得到一个解决方案或者至少发现一个方向后,我会反过来检查自己的思路,与其它人的工作进行对比,而不是把自己陷入到前人的工作中。我经常发现许多事情在我看来是显然的,别人往往会忽略掉。好!又是一个突破。广泛的研究和背景资料的学习对于书写学术论文或学位论文可能是正确的工作模式,但在真实世界中,这会干扰你的思路,将你引入其他人已走过的路。

当然,应该去看别人是什么做的,这是有好的理由的。这些理由包括事后的对比,检查自己的思路与其他人的不同,并且发现有用的补充和创造性的提高。在工作之前,你应该仅为获得灵感而不是寻找答案而去看其他创新设计者对相似问题的解决方案。

只有一条出路

查看其他人的工作的第三个理由是可以帮助打破只有一种方法或只有一种正确方法的思维模式。尤其针对开发经理,需要学习不去接受程序员们的肯定说法。“这可能不灵活(或效率不高,浪费资源,粗糙),但这是采用JavaHTMLC++APIMFC)仅有的一种方法。”,程序员说。“胡说,”精明的经理说,“回去,找到另一种方法。”

更糟糕地是,程序员会这么说,“无路可走!你不可能在Windows中实现这个!”在编程中,没有不可能的事情。在软件中,所有事情都是可能的,只是你愿意在上面花费多少时间和精力的问题。一个可接受的回答是:“根据当前给定的交付计划,我不能为解决它去寻找一个方法。”这个回答说明了问题的真正实质:没有找到方法。

这种“只有一种方法”或“没有办法”的想法将会限制你,阻碍你发现解决难题的创新方法。我们客户的一位有才华的程序员最近为一个创新的工业自动化工具制作一些Windows控件。不幸的是,他的标签对话框不能像新应用所要求的那样工作。当这个问题被提出后,他绝对地坚持那个要求是不可能实现的。我从事编程工作是很

多年前的事情了,但我同样绝对地肯定,事情不是他说的那样。实际上,我不熟悉VBMFCOLE,但我具有理解问题实质和用户界面编程逻辑的经验。在这个问题上,我“发明”了一个技巧,逻辑告诉我它行得通。几周内,我收到了一个Email,告诉我所建议的技巧管用了。

传统的镣铐

传统的影响加重了许多开发员“无法实现”的心理障碍。传统的用户、技术和特性经常阻碍前进的脚步,因为MicrosoftWindows中这么做,或是因为产品前一个版本的错误做法,你就有理由在下一个版本中不做更改。

人类历史上的几乎所有进展都受到人们传统观念的抵制,人们认为老的方法挺好甚至更好。我不是指我们业界中的6个月就出现一组新名词这种“进步”,我指的是那些可能产生新事物或改进旧事物的真正进步。

对许多软件开发员来说,用户的建议是仍然基于老的软件或系统。如果你错误地询问你的用户或顾客,他们是否愿意使用老的用户界面,大多数人会回答接受这个建议。多数人宁愿忍受已知的痛苦,而不愿面对不熟悉和不确定。“至少我知道现在系统的毛病。”问他们,他们就会建议你参考已有的某个笨拙的Windows应用程序。别听他们的。如果我们总是听从这样的用户建议,我们可能还在使用模拟电子打字机的行编辑终端呢。

已经安装的旧系统是一个在做设计决定和规划业务策略时必须要考虑的实际问题。但这个问题已被胆小的经理和设计者夸大为一个影响整个软件的巨大问题。除了很少的例外,大多数传统的东西最终会让位于更好的替代品。驾驶“没有马的马车”采用的方向控制和绳子,尽管对于传统用户来说非常熟悉,最终还是让位于能很好控制方向的方向盘。只要时间足够,大部分现在使用的令人厌烦的Windows应用程序都会成为历史。

关于传统特征和传统界面技术的规则实际上比较简单。经理们不要将是否继续支持传统用户作为一个问题,而只是决定什么时候停止支持他们。只有采用这种方法,你才可以创新并且进行有效的过渡。

与旧系统很相近是完美的神话。沿用传统界面是因为(争论来了)市场的力量,用户不断增长的老练程度和技术进步已经消除了Windows的糟粕。这种争论错误地将现在的先进水平等同于最好。这种状态的辩护人经常忽视他们争论的前提。实际上改进从未停止,市场从未停止选择,用户从来没有被固定到一种图形用户界面。仍然有进步与革新的巨大空间,如果你的新产品确实不错,并且有合适的销售方法,市场就会接受它。

那些具有勇气和创新能力的开发员会引导这个方法。如果你真的相信目前的方法是唯一的,并且一直会这样的话,只要比较一下Windows 3.1Windows 2000就可以了。 Microsoft明白,你和你的用户也能明白。

放弃

作为用户界面设计者和设计公司的合作者,我的经验是,好的想法很少是一蹴而就的。即使是最肥沃的土地也需要耕作才能获得好的收成。

在软件中,创新也是如此。许多富于创造性的革新者开始于正确的方向但没有得到结果,因为他们在出现一点问题或发现一点失败的迹象时就准备放弃他们好的想法。不断产生软件专利的创新小组知道,不要过早放弃一个想法。他们将最近发现的缺点、局限、缺陷作为需要创造性解决的新问题。

如果需要是创新之母的话,顽强的坚持不懈就是接生婆。另一方面,如果你想产生软件创新,你必须学习什么时候改变战略。实践中,你会认识到,在重新前进之前什么时候后退和前进以获得对问题的新视角。

未定义的问题

为了解决问题,你要知道需要解决的问题是什么。创新重点放在采用正确的方法定义问题上。例如,每个人都知道多行标签对话框难以使用。甚至Microsoft,尽管可用性实验室里挤满经过高度训练的专业人员,仍采用使用户感到迷惑的多行标签(multi-row tabs)对话框。可用性领袖Jared Spool得出结论,没有好的解决方法,最好不去用它。

但问题是什么?问题不是多行标签而是它们的行为难以向用户解释清楚。程序员坚持认为,当你点击一个处于后面的标签,系统的反应是简单而合乎逻辑的,但对用户来说这个反应好像是随机的,好像行和标签之间发生了互换。

将这个问题作为一个视觉感知问题——用户没有能力理解或感觉实际发生了什么——为找到可行的方案指出了方向。采用动画简明清楚地解决了这个问题。使被选中的行弹到最前面,使其它行隐藏到它的后面,你就获得了一个多行标记对话框,它可以完全被理解,甚至更“直观”。

这个问题解决了,还有其它软件问题,它们正等待有人努力地发现好的解决方案,那可能就是你和你的团队,为什么不呢?

(c) Copyright 2000, L. L. Constantine and L. A. D. Lockwood, all world rights reserved. Translated with the authors' permission. Reprinted from M.van Harmelen, ed., Object-Modeling and User Interface Design: Designing Interactive Systems (Addison-Wesley, 2001; ISBN: 0201657899). Additional information and materials on use cases and usage-centered design can be obtained on the Web at http://foruse.com/.

 

UMLChina保留中译本一切权利


关闭本页
 
首页 | 投资与合作 | 服务条款 | 隐私政策 | 收藏本站 | 设为首页 | 新用户注册 | 免责声明 | 使用帮助
Copyright ©2005-2008 chinaitpower.com All rights reserved. www.chinaitpower.com 版权所有