达雷尔.曼恩（Darrell Mann）的《软件系统化创新》一书买了已经有一段时间了软件系统化创新 - china-pub网上书店，但一直没有翻开。为什么会买这本书，为什么买了又不看呢？因为没有时间？不，这只是借口。主要原因还是翻开的动力不足。

      那今天怎么突然想翻开看一看呢？一方面是因为昨天一位企业研发主管告诉我，这本书对他们企业用了，反馈非常好，他们拿软件版的发明原理直接用，效率和质量大大提高；另一方面则源于今天和童童老师近90分钟的微信语音交流，她建议大学老师一定要在本科阶段引导学生在技术领域多学习和实践，还提到自己即将在IOT领域开展新的项目合作，期望以后能带着学生到深圳企业去实习。于是，那个久违的软件工程师梦想又再一次被激活。怎么？40+的人还在做“软件工程师“的梦？不，这应该是一个19岁女孩曾经的梦想，只不过至今都还没有实现。

      翻开Darell的书，首先记录了一件事情：他在1985年用100段Fortran代码写一个软件，帮助工程师设计出模拟喷气式发动机并使其“飞翔”，总代码不到500KB。接着，他分享了一段失败经历，这段失败经历使他不得不思考，为什么自己在1985年的开发经验在后面三个不同的项目组里无法复制，而且后面三个项目组都由及其聪明的成员组成，并且每个成员都可以使用很复杂的工具。后来，他总结出事实有两点：一是在1985年那个计算机并不发达的年代，为了避免成堆的打孔带带给自己的痛苦和苦恼，他比后面三个项目组有了更强烈的“想要用巧妙的构思来解决问题”需求。不仅如此，二是当时他对业务领域的知识——喷气式发动机的知识稍有一些了解——即拥有一些领域知识。

    在这本书的前言里，Darell还提及了两个陷阱：一是过度依赖工具，二是习惯将软件行业看作一个封闭的领域。并强调“某些情况下软件工程是需要与外部领域交互的，无论这外部领域是基于硬件定义的，还是由用户定义的，或是由另一个软件定义的，在某个地方都会需要一个接口，而这个接口恰好就是软件最初存在的主要原因。”所以这本书大部分内容都是帮助读者去了解情景。他认为，一旦构建了某种可以通过软件进行改变的情景，本书的其余部分便会专注于帮助大家找出巧妙的可行方案。

    全书共分12个章节，先简述了软件创新简史，然后引出了软件工程——问题是什么？紧接着介绍了七根完美的支柱——完美、摆脱、资源、功能、涌现、矛盾、乌龟。以及连续的“系统化创新流程”，还分享了一些案例和场景，最后还展望了未来。这本书附录了问题定义模板、资源清单、不间断的软件紧化趋势、软件矛盾矩阵，以及40个发明（软件）原理与实例。

    看到这里，是不是觉得好像和TRIZ似乎有某些关联？是的，译者序中其实早有提及。那具体是如何关联并涌现的呢？实践出真知，真希望有机会能够用一用。