本小节摘自《像外行一样思考，像专家一样实践——科研成功之道》一书，作者：金出武雄 卡耐基.梅隆大学计算机科学和机器人研究所 教授

说到独创、创造，人们就很容易想到那是某个人首先想到的、谁也没想出来的绝佳的构想。但事实上，这种情况少之又少。现实生活中，对于别人成功实现了的构想，总有人说：“我很早之前就想到过。”其实那未必是吹嘘，而很可能是种不服气的说法。

对照自身的经验，也有人说我研究成功的理论：“说来说去，这与标准的最小平方平均应用法本质上没有什么区别。”也有的时候别人得出极好的成果时，我也会感叹：“啊！这个我以前也做过的。”

事实确是如此。纵观科学史和技术史，哪项成就不是以前就有人想到过的。只不过是当时那个人或是没有实现它的能力；或是没有坚持到最后，在研究的道路上半途而废而已；或者是这些努力都做到了，但由于当时能够使用的技术和工作不足而未成功。这样的事情一定很多。

细心地调查一下过去的专利申请，特别是那些最终没有被批准的专利申请，就会发现这是个创新的宝库啊！那些没有被批准的专利申请的想法是先行一步的，但之所以没有通过审批，或者是因为现实情况不允许，或者是因为当时没有这种要求。实际上也有人说因为爱因斯坦曾经在专利局工作，才会有如此成就。

。。。。

大家想的都一样，这样还能发明创造吗？最初的想法的确是相同的，但在此基础上添加东西，使之升华的水平高低才是决定胜负的关键。

据此，大部分的创造都是在模仿的基础上增加其附加值的东西。

独创、创造，不是无中生有的魔术。

• 同样是非常优秀的技术，为什么有的技术得到了广泛的应用，从而走向成功，而有些技术却不被人们接受，从而走向失败呢？有些技术有非常好的应用前景，为什么他们却无法在市场上走向成功呢？
• 你已经发明了一种非常好的技术，怎么样才能让它成功地变成好的产品，最容易地走向市场呢？
• 怎样来评估一项新出现的技术构想？

• 先行者
• 早期接受者
• 早期消费群体
• 晚期消费群体
• 行动缓慢者

• 寻找市场最需要解决的问题
• 由小处着手，从全局思考
• 品牌并不代表全部

• 产品稳定和所有问题的解决（Product stability and resolution of all issues)
• 用户接受产品（Customer acceptance of the product)
• 转移长期管理和支持的所有权（Transfer of ownership for long-term management and support)
• 关注下一个版本(Change in team focus to the next release)

• 产品管理:Beta版本位置管理，推销和开始准备产品发布
• 项目管理：Beta版本管理，项目跟踪/沟通，控制产品开发活动的结束点
• 软件开发：更正Bug，产品发布
• 软件测试：测试和Bug报告
• 用户培训：最终产品，培训教员，发布
• 后勤管理：建立Beta版本位置并提供支持，产品首次展示的管理

• 包装好的产品：对外
  • 冻结变化
• 发布备忘录：对外
  • 冻结变化
• 性能支持元素：对外
  • 由操作和支持控制
• 测试结果和测试工具：内部
  • 存档
• 源代码和可执行程序：内部
  • 存档
• 项目文档：内部
• 存档
• 阶段回顾

• 测试并修复Bug
• 发布各个Beta版本
• 进行用户培训
• 进行产品转化
• 准备正式发布
• 获得开发结束点
• 大量生产
• 阶段回顾
•  

• 功能规范化(All features built to specila) 
• 使用和估计产品(using and evaluating the product,even if testing is not complete)
• 用户试用(customers using the product for the first time under beta conditions)
• 基础要求的配置(deployment of infrastructure required for first use)
• 配置计划要求(deployment plan details)

• 产品管理 : 控制用户的期望，推销，价格，包装    
• 项目管理：项目跟踪 /沟通，Beta版本计划 
• 软件开发：特性开发 /测试 
• 软件测试：测试，保证稳定性
• 用户培训：用户性能支持开发
• 后勤管理：渠道沟通和首次展示计划

• 功能规范：对外
  • 内容固定了
• 风险管理计划：对内
  • 是动态变化的，由开发团队的经理控制
• 源代码和执行程序：内部
• 由开发人员控制 
• 性能支持元素：对外
• 由用户培训团队控制
• 测试规范和测试案例：内部
•  由测试人员控制
• 总体产品计划和总体产品进度表：对外
• 稳定的，由项目管理者控制

• 用户界面开发 
• 用户服务开发
• 商业服务开发
• 数据服务开发
• 数据库开发
• 内容开发
• 可用性测试
• 测试并修复Bug
• 基本部署
• 代码检查
• 风险评估

• 单元测试（Unit Test），按照代码的单元组逐个进行测试
• 功能测试（Function Test）或特性测试（Feature Test）：按照软件的功能或特性逐个进行测试。
• 提交测试（Check-in Test）：在开发人员对代码做了任何修改，或者修复了某个Bug时，需要重新Check-In代码，即将修改后的代码放入到整个大的系统中。这时开发人员也要进行测试，看代码是否工作正常。
• 基本验证测试（Build Verification Test)：对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。
• 回归测试（Regression Test）：过一段时间以后，再回头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。

• 配置测试（Configuration Test）：从用户的使用出发进行多方面的测试。
• 兼容性测试（Compatibility Test）：例如一个产品的不同版本，不同厂家的不同产品的兼容性问题
• 强力测试（Stress Test）：在各种极限情况下对产品进行测试（如很多人同时使用该软件，或者反复运行该软件），以检查软件的长期稳定性
• 根据微软的实验经验，如果一个软件产品能通过72小时的强力测试，则该产品超过72小时后出现问题的可能性微乎其微。所以，72小时就成为微软产品强力测试的标志。
• 性能测试（Performance Test）：保证程序具有良好的性能。如果别人的产品只需要5秒就能得出结果，而你的产品需要10秒，就说明你的产品性能不好。如果在测试阶段发现性能问题，修复起来非常艰难。因为这常常意味着程序的算法不好，结构不好，或者设计有问题，因为在产品开发的初期阶段，就要考虑软件的性能问题。
• 文档和帮助文件测试（Documentation and Help FIle Test):因为用户通常是通过文档和帮助文件来学习使用产品的，如果文档和帮助文件存在错误，就可能会导致用户无法正常使用产品。
• Alpha和Beta测试(Alpha and Beta test)：在正式发布产品之前，往往会先发布一些测试版，让用户能够反馈相关信息，或者找到存在的Bug，以便在正式版中解决

• 接受性测试（Acceptance Testing）
• Alpha/Beta测试（Alpha and Beta Testing）
• 菜单/帮助测试（Menu/Help Testing)
• 发行测试（Release Testing）
• 回归测试（Regression Testing）
• RTM测试（Release to Manufacture Testing)
• 功能及系统测试（Function & System Testing)
• 规范验证
• 正确性
• 可用性
• 边界条件
• 性能
• 强力测试
• 错误恢复
• 安全性
• 兼容性
• 软件配置
• 软件安装

• 计算机
• 优秀的办公处理软件（用于编写测试计划和规范）
• 视频设备
• 秒表（计算程序的运行时间，测试产品性能）
• 自动跟踪系统（微软内部使用的是RAID，用来自动跟踪Bug）
• 自动测试工具（产生AutoMation脚本）
• 软件分析工具
• 好的操作系统（如Windows 2000，有很多有用的工具，如文件比较器，查看器，转换器，内存监视器等）
• 多样化平台

• 测试计划
• 测试规范
• 测试案例
• 测试报告
• Bug报告

• 巴迪测试（Buddy Test）
• 友好的关系（Friendly Relationship)
• 测试是独立的（Testing is Independent）
• 保证软件功能的定义有意义（Make sure the feature definitions make sense)
• 学会说不(learn to say "no" if you strongly feel so)
• 项目经理定义的规范也是可以改变的（PM's spec is changeable,too)
• 坚持正确的看法(Insist what is right)
• 职业化(Professionalism)
• 向项目经理和开发人员反馈（Give PM/DEV Feedbacks)

• 开发人员能够集中精力做开发，而不被管理琐事所困扰
• 开发队伍需要视野良好的领导
• 项目组内部不同角色人员之间需要好的沟通和协调
• 工程开发和商业运作之间的差别需要有人从中进行连接和平衡
• 开发队伍与外界的联系沟通需要有专人进行管理和协调

• 制定产品的远景规划，写出项目规格说明书
• 制定工作详细任务表，跟踪这些任务的执行情况，保证其符合规格说明书的原始设计
• 组织会议，评审程序错误
• 指导项目开发的过程设计和实现
• 对各种具体实现方案进行取舍并作出决定
• 协调各组人员之间的交互配合，包括开发工程师，测试工程师，产品经理，用户教育和本地化人员

• 对生产软件产品有激情，具有领导才能，并对产品有很强的拥有意识
• 对产品设计有强烈的兴趣，同时对技术问题能透彻理解
• 有敏锐的时间和日程观念，能对复杂的问题或任务紧密跟踪，并能区分优先次序和轻重缓急
• 总能充分利用各种渠道和方法来分析和解决问题，对可利用的资源能充分把握
• 有能力迅速而胸有成竹地做出决定，并能做出合理的取舍

• 项目陈述(Project Deliverables)
• 功能和优先级(Features and Priorities)
• 项目风险(Risks)
• 发布日期(Ship Date)
• 商业要求(Business requirements)
• 产品功能规范(Functional Specilfication)
• 产品计划(Project Plan)
• 产品进度表(Project Schedule)

• 产品管理：概念设计和市场推销计划/进度表
• 项目管理：逻辑设计、功能规范、以及总体计划/进度表
• 软件开发：物理设计和开发计划/进度表
• 软件测试：用户性能支持设计和用户培训计划/进度表
• 用户培训：设计评估和测试计划/进度表
• 后勤管理：设计评估和后勤计划/进度表

• 功能规范：对外
  • 由产品管理团队控制
• 风险管理计划：对内
  • 是动态变化的，由开发团队的头控制
• 项目总体计划：对外
  • 是稳定的，由项目管理团队控制

• 概念设计 
• 逻辑设计
• 物理设计
• 风险评估
• 功能规范商议
• 评估任务难度
• 确定开发计划和进度
• 阶段回顾

• 用户
• 系统能给他带来商业利益
• 产品管理人员
• 系统满足已知的要求
• 项目管理人员
• 职责和提交的进度表是稳定的，可行的
• 开发人员
• 能够根据设计编程，并且实现的风险是可以接受的
• 测试人员
• 测试策略和规范所需的平台、脚本、和数据都是完整的
• 用户培训人员
• 用户的需求已定义
• 后勤人员
• 所有组织、应用及系统接口都是确定的
• 所有人员
• 新产品发布日期确定得比较合理

• 提出一个长远目标（Long-Range Vision）
• 制定短期的目标（Shorter-Range Vision）
• 新产品的机会和风险（Opportunities and Risks）
• 假设（Assumptions）
• 约束（Constraints）
• 项目资源（Project Resources）
• 时间和工作强度（Time and Effort for Planning Phase)

• 产品管理：分析是否应该做这个产品，尽量证明这个产品是值得做的[本阶段的主导团队]
• 项目管理：根据产品管理团队决定要做的新产品，设计新产品的目标，以及具体的实现方法
• 软件开发：开发一些技术原型，来检验该新产品是否有意义，并向大家展示一下该产品未来的样子。另外，还要对开发过程中的一些大的结论提出建议
• 软件测试：判断该新产品是否可用，是否可接受
• 用户培训：分析用户的需求
• 后勤管理：对长期的支持管理提出建议

• 想法和意图文档：对外
• 基线（BaseLined），由产品管理团队控制
• 风险管理计划：对内
• 是动态变化的，由开发团队的头控制
• 产品结构：对外
• 是稳定的，由项目管理团队控制

• 确定团队关键成员
• 定义想法和意图
• 定义设计目标
• 风险评估
• 收集商业需要
• 确定基本管理问题
• 商议想法和意图
• 阶段回顾

• 想法和意图的批准里程碑——Vision/Scope Approved
• 涉及的团队角色：产品管理
• 包括三个过程：项目提出、市场分析、技术可行性分析
• 目标是：努力使新产品的想法和意图得到通过
• 必须做的工作
• 陈述项目的目标文档
• 评估新产品的风险
• 描述新产品大概的结构
• 产品计划的通过里程碑——Project Plan Approved
• 涉及的团队角色：项目管理
• 此阶段的目标主要如下
• 定义功能规范
• 评估风险
• 总体计划
• 总体进度表
• 范围完成/第一次使用里程碑——Scope Complete/First Use
• 涉及的团队角色：软件开发+用户培训
• 此阶段的目标主要如下
• 完成全功能代码的编写
• 风险评估
• 在线和打印的文档
• 测试规范
• 版本化的功能规范
• 更新的进度表
• 发布里程碑——Release
• 涉及的团队角色：软件测试+后勤管理
• 此阶段的主要目的：让产品越来越稳定、越来越完善、将所有需要解决的问题都尽快更正
• 得到最后的产品
• 发布的文档
• 版本资源
• 培训手册
• 产品所有的文件
• 产品出现的问题库
• 包括已经解决的，以及还未解决的问题和Bug
• 不同设备和平台的安装
• 软件/数据的安装/转换

• 新产品项目的提议
• 市场分析预测
• 技术可行性分析
• 产品研发实施步骤
• 高层论证和审批
• 项目确定和执行
• 产品开发

• 产品管理：确定产品的远景，获取并确定用户的需求，开发并维护商业安全，满足用户的需求
• 项目管理：制定开发功能规范，在团队内进行沟通和协商，维持产品进度并报告产品状态，保证能够尽快尽好地在产品约束条件下发布产品
• 软件开发：开发出满足设计规范和用户要求的产品
• 软件测试：开发测试策略和计划，保证在解决了所有已知问题后再发布产品
• 用户培训：保证使用文档要全部很清楚地写出来，提高用户使用产品的技能，保证大多数用户都能够充分利用产品的功能
• 后勤管理：保证产品能够平稳地发展

• 软件开发
• 项目管理+后勤管理
• 软件测试+产品管理+用户培训

• 小型并具有多功能的团队
• 角色互相依赖并分担责任
• 具有深厚的技术和商业敏锐性
• 关注于完成产品
• 有明确的工作目标
• 用户积极参与
• 共享产品远景
• 人人参与设计
• 努力从过去的产品中学习
• 共享产品总体管理和决策
• 所有团队成员都在同一个地方工作
• 大团队的工作方式类似于小团队

• 软件的开发过程是由目标驱动的，而不是由具体任务驱动的
• 开发过程的各个里程碑都是显而易见的
• 基于版本的发布
• 进度表是基于风险驱动来制定的
• 依靠完全的团队合作来完成
• 严格管理，保证质量

• 在制定进度表时，要明白我们要面对的是一个不确定的将来
• 通过有效的风险管理使不确定性因素达到最小
• 定期的编译和快速地测试来实现产品的稳定性和可用性达到最佳
• 产品的开发周期要快速
• 通过创造性来实现功能的改进而不增加资源
• 建立固定的进度表
• 使用小团队来并行工作，以达到最多的同步点
• 将一个大的产品分割成一些易于管理的，可以在几个月之内完成发布的小部分
• 要避免任何不必要的功能扩展
• 使用概念证明的技术的原型来做开发前的测试
• 要本着零缺陷的态度（一般来说，一个软件产品不可能真正零缺陷，这里指的是产品发布时没有影响产品功能和使用的缺陷）
• 在阶段回顾时要集中于功能和产品的改进，而不是挑任何人的过失

• 在开发任何一个新产品时，所有文档都是非常齐全的，项目的规范也很清楚。所以，每一个开发人员都很清楚自己需要做的任务。
• 开发人员之间需要互相阅读其他人新编写的代码。这样，一来相互之间能够非常了解，最重要，产品很难由一个人控制。
• 所有代码都需要有清楚的注释。微软的产品一般至少有两个版本，DEV和三SHIP