《构建之法》(九)

第16 章  IT行业的创新(一)

一、创新的迷失

迷失之一:灵光一闪现,伟大的创新旧紧随其后

  很多人听到发明创造, 都会想起故事书里的聪明人忽然灵光闪现的故事,灵光闪现, 顿悟这个词叫“Epiphany”, 我们上课的同学也想了不少宏大的创新思想, 但是课程最后什么也没做成,  剩下的就是一个空的构想。

迷失之二:大家都喜欢创新 (?)

  创新就是做和以前不一样的事,  但并不是所有的人都喜欢“不一样“。不但大众不喜欢创新,  甚至连创新者都不例外, 有些创新者甚至恨创新。因为有些创新是颠覆性的 -  disruptive innovation.   这些想法一旦出现, 会引起现有技术拥有者的极大不安。

迷失之三:好的想法会赢

  在现实中, 好的主意不一定赢。

  那怎么样才能让别人喜欢 (至少不痛恨)  你的创新呢?  在我们提出一个创新的想法时, 应该考虑这么几点:

    • Provide “what’s in it for me” for stakeholders   对利益相关人要讲清楚“你能从中得到什么”。
    • Relative Advantage  (创新和目前的应用相比,  有什么相对的优势)
    • Compatibility  (创新和目前的应用是否兼容)
    • Complexity (避免过度地描述复杂的技术)
    • Observability  &  Trialability  (能让别人看到/实验创新的结果么? )

 迷思之四:  创新者都是一马当先

  大部分成功的创新者都不是先行者

迷思之五:要成为领域的专家, 才能创新

   统计数据表明, 70%的创新者说, 他们最成功的创新, 是在他们的拿手领域之外发现的。

  书中举了物理学家Tim Berners-Lee利用 HyperText 实现方便的信息共享和更新;实现通过互联网的HTTP 协议通信的实例,B2B 网站做的最好的是阿里巴巴的创始人是非学计算机, 互联网专业的;由芬兰一家做森林木材相关产品转入通信领域的 Nokia 公司;还有索尼公司的“单放机”(Walkman)这几个事例说明了不是成为领域的专家, 才能创新。

迷思之六:技术的创新是关键

    大家的思想无外乎 - 我们就是要学习各种科学技术, 然后创新, 齐家治国平天下。 例如手机的发展历史。除了技术的创新,在看看其他方面的创新:

商业模式的创新:

  在网上买书

  网络竞拍, 网店

  网络微量交易和支付

用户体验的创新

   iPod 在用户界面上的创新

生态系统的创新

  iPod/mac iTune client/iTune web site 在音乐购买/同步/播放整个流程中整合的创新。

迷思之七 :成功的企业更能创新

  企业因为创新而成功, 创新是他们的企业基因。但是在实际中,  你会发现很多成功的企业进入了一个创新者的两难 (Innovator’s dilemma) .两难表现为: 不断满足已有用户需求, 则进入饱和市场, 不免被新的颠覆性创新淘汰; 如果寻找颠覆性创新, 则遭到公司流程,价值观,文化的排斥。

这个两难有下面的一些症候群, 它们都以 ”成功的企业… ” 开头。

  a)   成功的企业被股东们寄予厚望

  b) 成功的企业有钱请人预测未来

  c) 成功的企业开始捍卫一些价值观

  d) 成功的企业有流程

  e) 成功的企业重视用户

  f) 成功的企业有老大的心理

Performance Oversupply (效能过剩) 和竞争的各个阶段

  我们说了两种技术 sustaining technology 和 disruptive technology, 但是没有一种技术生来就是 sustaining technology, 那么如何判断什么时候一个技术已经到了 sustaining 的阶段呢?  一个重要的特性就是效能过剩。这些技术都到了Performance Oversupply 阶段。

一个产品在它的生存周期有不同的阶段, 每个阶段有不同的关注点, 在适当的时间, 适当的关注点创新, 就能改变竞争的局面, 不合时宜的创新, 则隔靴搔痒, 事倍功半。

迷思之八 :创新的过程是连续的曲线 

  成功人士的故事读多了, 很容易让人产生误解,  认为技术的创新就是一个连续的曲线,  先写论文从理论上论证其可能性 (Innovator 阶段); 然后做出原型供先行者尝鲜 (Early Adopter 阶段);然后广大人民群众中觉悟高的开始接受新技术 (Early Majority 阶段), 再传播到后进群众 (Late Majority), 最后老顽固 (Laggards) 都开始使用这个新技术了。

但是在现实世界中, 这个模型有一道鸿沟, 很多好想法,尽管得到了先行者的好评, 但是它们都跨不过这道鸿沟, 到不了广大用户那里。

从这一小结内容,我知道了IT行业的创新的几个容易迷失点。很多问题,都经历发现它,找到它,解决它的流程。所以对于创新,我们更易知其可避。

时间: 2024-12-04 16:16:53

《构建之法》(九)的相关文章

构建之法的八、九、十章读书笔记

构建之法读书笔记 第八章  需求分析 这一章主要是讲需求的分析,对于一个程序项目来说,我觉得,需求是这个项目的向导,他可以决定程序项目会发展成什么样子.书里面需求这里大致分为两个:软件需求和用户需求. 软件需求:我们不仅仅要考虑到项目功能的需求,要实现的功能,还要考虑到开发过程以及非功能方面的需求,还有综合需求. 用户需求:是针对在用户这个角度,用户最需要的东西.我觉得用户需求在需求分析中较为重要,毕竟每一个要做的程序的根本目的是满足用户的要求.      所以书里面野介绍了九种获取用户需求的调

<<构建之法>>第八、九、十章的读后感

阅读不是仅仅为了阅读,读书的可贵之处在于思考和领悟.由于之前六.七章博文的疑问,并没有得到好的回复,于是,我将阅读的重点放在读后的心得体会,从中的收获.以及在<<构建之法>>一书学习到的处事方法. 对于软件开发的意义就是满足用户的需求,这点我非常赞成,如果一个产品没有任何用户基础,再高深的技术也是胡闹.书中详细的写到获取用户需求的种种方法和过程.因为这个快餐文化的时代,绝大部分没有耐心会慢慢地和你反映他的需求是什么,并且,即使面对面的交谈,也会出现表达和理解的误差,所以,需求分析这

《构建之法》—第6-7章

一.要求  阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-program.html Scrum实践

8th 对软件工程的理解(读构建之法有感)

对于任何一个学计算机的人来说,软件都不陌生,甚至于一个普通的朝九晚五的上班族,他的每日生活工作也都与软件有着密不可分的关系.然而,程序又是如何从一行行指尖留下的代码,机器存储的数据变成快捷高效的软件的呢?这中间我们所经历的一系列过程的总和,我们称之为软件工程. 从本科开始学习计算机,我们就不可避免的接触了形形色色的软件,了解大量的软件开发工具,我那个时候甚至没有软件工程这个概念,只认为,我们所用的软件就是开发工具编译.执行.包装.发布的产物.后来,开设了软件工程这门课程,才开始系统地接受软件工程

回望来时的路:构建之法东北师大站 2016春季学期

1.  前因 微软邹欣老师著有<构建之法:现代软件工程>[https://book.douban.com/subject/26577755/].第一版首版以前,我还不知道邹老师是哪一位,就在网上曾经看到过有人转引他的观点,感到说得太有道理了,一拍大腿的感觉.比如他提到教师和学生之间应该是健身教练和学员间的关系,不是教师带领学生参观浏览,也不是狱警和囚徒的关系.比如他批评没有代码量的软件工程教学.<构建之法>到手,第一遍粗读我花了一周的时间,酣畅淋漓.很多处让你再拍大腿,"

三读《构建之法》——源代码的设计、实现、控制与两人合作

现在,<构建之法>的一大半已经读完了,在这一大半本书中,这一部分可以说是对我触动最大的,也应该是整本书对我触动最大的. 整个第二章围绕测试展开,用一个很生动的类比告诉了我们测试的重要性:如果有人说,"一个人写写程序玩玩,单元测试似乎不那么重要.",那么你可以回应他:"你可以大胆对你的女朋友说:'我们只是玩一玩.'看看效果如何". namespace DemoUser{ public class User{ public User(String userE

《构建之法》(四)

本周看了<构建之法>的第八.九章的内容.初步了解了开始做一个软件的初始步骤. 需求分析 1.寻找需求 获取和引导需求.需求不仅是来自外界,甚至也可以来自技术成员团队内部: 分析和定义需求.主要是对需求进行量化: 验证需求.主要跟利益相关者沟通并通过各种方式像其验证对需求的认知. 在软件产品的生命周期中管理需求.需求不一定只在初期才有:在中后期的时候可能因为外界环境变化甚至是成员自身水平变化而出现新的需求 也可从不同角度划分: 对产品功能性需求.对产品开发过程需求.非功能性需求.综合需求 2.软

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

简读《构建之法》,所想问题展示

1,<构建之法>这本书全局语言通俗,学生很容易读懂,但是存在一个隐患:学过软件工程,我们只是笼统的理解,而对这方面的专业知识很少了解,该怎么办? 2,书中提到的软件结构,软件设计与实现具体是怎样的?怎么理解它们之间的关系? 3,软件在不断更新和增加功能的负担下,一定程度下会崩溃.若有一个软件,即将考虑添加下一个功能,但是在添加这个功能之后,系统一定会崩溃,但是这个功能对这个软件的市场前景起着至关重要的作用,这是该怎么办? 4,软件设计和软件构建有区别吗?不同之处是什么? 5,当软件中的依赖关系