以参与方分类，区块链可以分为：公开链（Public Blockchain）、联盟链（Consortium Blockchain）和私有链（Private Blockchain）。从链与链的关系来分，可以分为主链和侧链。而且，不同区块链还可以形成网络，网络中链与链的互联互通，产生互联链（Interchain）的概念。

国信证券分析报告指出，通过区块链的点对点分布式的时间戳服务器来生成依照时间前后排列并加以记录的电子交易证明，可以解决双重支付问题，从而带来结算成本趋零的可能性。

区块链具有去中心化、可靠数据库、开源可编程、集体维护、安全可信、交易准匿名性等特点。如果一个系统不具有以上特征，将不能被视为基于区块链技术的应用。

区块链的应用前景受到各行各业的高度重视，被认为是继大型机、个人电脑、互联网、移动/社交网络之后计算范式的第5次颠覆式创新，是人类信用进化史上继血亲信用、贵金属信用、央行纸币信用之后的第4个里程碑。

区块链的共识机制目前主要有4类：PoW、PoS、DPoS、分布式一致性算法。

那么如何衡量一种代币呢？通常从如下几个方面思考：是否具有重大创新？是否能因为与比特币的区别从比特币吸引过来用户？是否针对市场或者应用？是否能吸引足够多的矿工来抵御联合作弊？财经和市场指标上，又可以从资本量、预计用户量、日交易量和流通性上来评价一种代币。

定义1：区块链 1）一个分布式的链接账本，每个账本就是一个“区块”； 2）基于分布式的共识算法来决定记账者； 3）账本内交易由密码学签名和哈希算法保证不可篡改； 4）账本按产生时间顺序链接，当前账本含有上一个账本的哈希值，账本间的链接保证不可篡改； 5）所有交易在账本中可追溯。

钱包分为两种：非决定性钱包和决定性钱包[

钱包从部署场景来说，分为4种，分别为：移动钱包、桌面钱包、互联网钱包，以及纸钱包。

不断对区块报头进行哈希处理，每次尝试改变一个随机数，直到区块报头的哈希值符合一定的条件，比如说起始必须有多少个零，才算挖到一个合格的区块。由于哈希处理不可逆，也就是说根据哈希算法得出的结果，不能反推出输入值，因此不能预知输入的参数，只能随机地试。而且两个不同的输入经哈希处理后得到的结果相同的几率小得可以忽略，因此比特币网络中谁能挖得到矿是一个随机的事件，几率的大小取决于节点的计算能力。

不仅仅把区块链作为一个去中心化的虚拟货币和支付平台，而是通过增加链上的扩展性功能，把区块链的技术范围扩展到支撑一个去中心化的市场，交易内容可以包括房产的契约、权益及债务凭证、知识产权，甚至汽车、艺术品等。

回到顶部

互联网时代要读的书（一本书读懂大数据+一本书读懂互联网思维+一本书读懂互联网+一本书读懂互联网金融）套装共四册 (黄颖；庞晓龙；李天阳)

第一个特征是大数据的来源往往是机器自动的结果。人工不会干涉到新数据的产生过程，完全是机器自动的结果。

第二个特征是大数据作为一个全新的数据源，不仅仅是已有数据的收集扩展，比如在互联网中，顾客与银行、零售商之间可以直接在线交易。

第三个特征是大数据中的大多数设计并非友好。实际上

说明了：1.数据的价值是无可限量的；2.当然这价值犹如沙滩中的黄金一般需要挖掘；3.组合数据的价值要比单一种类的数据价值高得多。

1.数据的价值是无可限量的；2.当然这价值犹如沙滩中的黄金一般需要挖掘；3.组合数据的价值要比单一种类的数据价值高得多。

信息化时代的特征有：主导者就是消费者、个性化生产、网络化协作。

任何一家电子产品的生产商，如果没有自己独立的软件配置，都无法在竞争中生存下来。

第一套是企业用来计算其成交额的，公式为成交额=流量×转化率×单价；另一套指标多用于企业对商品进行促销的时候，公式为，即大促成交额=预热期加入购物车的商品数×商品单价×经验转化率×经验成交额占比。前者是用来评价企业的某一类商品或单个商品的健康度的，后者则是在企业促销的前提下，用来预测大概成交额的。

数据的收集包括两个维度，第一个维度，是衡量数据对企业的生产价值，第二个维护是衡量数据对顾客的价值。第一个维度要求记录顾客行为数据里对企业有价值的那些。

在中国的文化背景下，感情和道德被很多管理者作为管理标准，并将之作为决策依据。数量化管理与中国这样的文化背景相比，可以说是格格不入，这也是工业革命后，西方国家得以超越中国的原因之一。

回到顶部

一本书读懂大数据（每个人都看得懂的大数据入门书） (黄颖)

2005年RFID标签保有量仅为13亿个，这一数字到2010年就已经增加到了300亿个。

什么是常态呢？通常有以下六种：弱、狂、哗、周旋、慵懒、媚。弱态是指那些动作温柔、说话轻声细语，有很强包容性，如小鸟依人一样的常态。狂态则是坚强好胜，不修边幅，言谈举止都如若无人在场。身边朋友一对比就会发现他有什么样的常态。问一个具有狂态的人的意见时，他总认为自己是对的，也愿意把自己的观点表达出来。弱态的人则不会这么做，意见是模棱两可的。哗态的人则大多在遇事时大手一挥，说道：“我来说，你们都别说。”周旋态的人在选择面前总有太多的纠结。慵懒态的人表现常常是非常漫不经心，不在乎一切。媚态则常常出现谄媚的行为。

凡弱且媚的人一定要远离，凡狂且媚的人，通常都比较了不起，这是一条交友法则。

苹果的IPHONE手机本身就是一个移动的信号接收器，在不知不觉的情况下就会收集用户的位置和无线数据，再传回苹果公司。此外谷歌的安卓系统和微软的手机系统也在做同样的工作。

规模优势最大的是超大型公司，小公司则具备灵活性。传统行业当中，大公司的灵活性不如中等规模的公司，而小公司的规模不如中等规模的公司。当大数据时代到来，公司的规模不要求太大，甚至不用足够支撑它的设备投入。往往是那些灵活的小公司才会在大数据时代中获得更大的成功。

例如手机的使用年份可以揭示创业者的人脉资源和人际关系，年龄大约是多少，是否有亲情号码计划或是座机转为手机的经历。手机号码的使用年份一系列信息的处理，投资者能看到更多关于创业者的信息，整个过程是合法的且完全保密地进行。

那些数量已经超越人工或是简单的计算机软件处理能力的庞大海量数据就被称作是大数据。

2012年度网民不同时间的上网活跃度依次为：20：00—21：00（6.53%）、21：00—22：00（6.44%）、16：00－17：00（6.20%）、19：00—20：00（6.13%）、15：00—16：00（6.09%），这当中在晚饭过后的3个小时（19：00—22：00）是网民最为活跃的上网时间段。

现代企业十分关注产销互动，也就是说在供应采购、生产单位和市场营销三者间要彼此通报信息。也就是这样部门和部门之间才能协调好规划。

回到顶部

启示录：打造用户喜爱的产品 (Marty Cagan)

交互设计师(也称为信息架构师、用户界面设计师、用户体验架构师)。交互设计师负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程

产品需求文档(product requirements document，PRD)来完成这项工作，也有人称其为产品说明文档或功能说明文档。同样，我主张采用简化的

开发企业级应用软件的公司，由于非常倚重销售，最容易出现这种问题。销售代表原封不动地把大客户的需求传达给产品经理，再交给开发人员。不用说，这样做很难开发出有价值的、可用的产品。上述二种模式背后都有其原因，认识这一点很重要。很多公司没有意识到错误的模式给他们带来了多大的损失。他们浪费时间，开发出的产品客户却不需要或者只能勉强接受。

开发企业级应用软件的公司如果想从众多竞争对手中脱颖而出，最简单的办法是提供优秀的用户体验。用户体验是大部分企业级产品的弱项。

产品经理会花许多时间写电子邮件、产品说明文档、策划书、同类产品分析文档等等。聪明的产品经理不会浪费时间写没人看的东西，一旦决定动笔就要做到最好，言之有物，让人信服。

永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜。 ——乔治史密斯巴顿

评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。

评估产品机会是产品经理的重要职责。评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。

如果CEO告诉你不管愿不愿意，都要继续开发，该怎么办?在这种情况下，迅速进行机会评估，明确产品需求也是必要的。你得到的结论可能会改变CEO的看法，即使不能，至少你能明确产品目标，大大提高产品成功的可能性。

更通俗她讲，就是原有产品质量差，公司不愿意想办法改进，反而认为开发新产品更容易，导致原有产品无法发挥潜力，产生应有的利润。除非这些公司改变研发产品的方式，否则，新产品难免重蹈覆辙。

如果你天生喜欢探索发明，喜欢自由和创意，那么在执行阶段就要努力控制创造的欲望；如果你天生是“项目经理”类型的人，喜欢排除外界干扰，按部就班完成任务，那么你需要培养自己的宏观思考能力和设计能力。

采用流水线方式并行开发产品。也就是说，一旦1.0版本的产品进入项目执行阶段，就开始定义2.0版本的产品。一旦前一个版本进入开发阶段，就把你的创造热情投入下一个版本。

管理层总是希望尽早获悉成本信息，但开发人员往往要较晚才能精确估算成本(至少要等到具体的解决方案出炉)。结果，要么过早估算导致结果与实际出入很大，要么结果虽然准确，但远远超出预算，让管理层难以接受。

方法很简单，在项目的开始阶段物色至少六位积极、活跃、乐于分享的目标用户(可以先招募8～10人，然后从中筛选)，要求是他们在产品的目标用户中具有一定影响力。至于他们是否使用过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头亟待解决的问题就行。

成为特约用户的好处 l.参与构思产品创意，解决他们手头的问题——他们最清楚产品要解决的问题，因为这些麻烦正在困扰他们。 2.提前试用产品，越早使用产品意味着越早解决麻烦。 3.通常，提前试用产品还可以显著降低用户的各种成本

产品管理的核心在于制定决策——应该抓住哪些机会，解决什么问题，哪些功能最有价值，谁是主要用户。有决策就有失误，但要打造成功的产品必须保证大部分决策是正确的

人物角色可以用来筛选重要的产品功能。假设目标用户是“玛丽”，就该添加对“玛丽”重要的功能；如果某项功能只是针对“山姆”的，就该被淘汰。

不再试图定义最终产品，转而定义只满足基本要求(价值、可用性、可行性)的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获，得预期的效果。

设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。

产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。

首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同，但总有些是可行的。

可行性测试首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同，但总有些是可行的。

产品可用性测试(检验用户能否想明白如何使用产品)和产品价值测试(检验用户是否渴望使用产品)同样重要。

史蒂夫·克鲁格(Steve Krug)的《点石成金：访客至上的网页设计秘笈》。这本书主要谈的是交互设计，但书的末尾举了一个原型测试的例子，令人信服，而且有不少有用的提示。我

史蒂夫·克鲁格(Steve Krug)的《点石成金：访客至上的网页设计秘笈》。这本书主要谈的是交互设计，但书的末尾举了一个原型测试的例子，令人信服，而且有不少有用的提示。

如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。

不了解敏捷方法的读者，请参考http://www.agilemanifesto.org。

瀑布式开发方法有正式和非正式两种形式。正式的形式可以参考美国国防部软件开发标准2167A及后来的标准498，其中详细地描述了该方法所有阶段的流程，以及需要提交的文档。更常见的还是非正式的形式：首先由市场人员收集市场需求，提交给开发人员；接着由开发人员制订开发计划，设计软件架构，进一步完善设计细节；然后进入开发测试阶段，完工后邀请用户测试产品，最后部署。

多数大公司都采取矩阵式的管理方式，核心部门(比如设计部门、开发部门、测试部门、运维部门、市场部门)是共享资源，产品经理要确保争取到足够的资源才能研发出产品。采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本

不管在哪种组织里，沟通都是难题，大公司尤其如此——信息俨然变成了某种货币，大家只想获取，不愿支出。许多人把它看成私有财产，藏起来不愿与人分享。其实有舍才有得，分享信息会让你获得更多的朋友和资源，作为交换，别人也会毫无保留地分享信息给你。充分共享信息对你自己和公司都有好处，这叫共赢

消费者购买产品大多源于情感需求。优秀的产品经理和销售人员明白其中的道理，懂得产品应该满足用户的情感需求。

企业级消费者出于恐惧和贪婪购买产品：如果不买这款产品，竞争对手会超过我，黑客会攻破我的防火墙、客户将弃我而去；如果买了，我会赚得更多、省得更多。

非理性消费是对不满情绪的过度反应，是放大后的情感需求在“作祟”。非理性消费者夸大了产品的价值，产品经理如果深入了解他们的想法和感受，就能抓住这种情感需求。

我的方法叫“新生测试”。回想你踏入中学的第一天，你在小学获得的一切成绩和奖励都无效了，你得重新开始，一切对你来说都是新鲜的，这时你最敏感，最容易感受到细微的变化。如果你带着新生的感觉去发掘每天折磨着大众的情感——孤独、恐惧、挫折、不满，你离发现新产品的日子就不远了。

回到顶部

高效程序员的45个习惯:敏捷开发修炼之道 (图灵程序设计丛书 11) (亨特(Andy Hunt),苏帕拉马尼亚姆(Venkat Subramaniam))

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

在功能不变的情况下，重新设计部分代码，改善代码的质量。这就是所谓的重构，它是软件开发中不可或缺的一部分——编码永远没有真正意义上的“结束”。

想要了解单元测试，可以看《单元测试之道Java版》[HT03]和《单元测试之道C#版》[HT04]，你可以在《JUnit Recipes中文版》[Rai04]一书中找到很多写单元测试的实用技巧。

敏捷方法却背道而驰。只需要一个角色：软件开发者，也就是你。项目需要什么你就做什么，你的任务就是和紧密客户协作，一起开发软件。敏捷依赖人，而不是依赖于项目的甘特图和里程表。

如果你跟踪技术变化，那么学习这些新东西对你来说就是了解这些增量变化。如果你不跟踪变化，技术变化就会显得很突然并且难以应付。这就好比少小离家老大回，你会发现变化很大，甚至有很多地方都不认识了。然而，居住在那里的人们，每天只看到小小的变化，所以非常适应。

“软件技术的变化如此之快，势不可挡，这是它的本性。继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。”

你不可能精通每一项技术，没有必要去做这样的尝试。只要你在某些方面成为专家，就能使用同样的方法，很容易地成为新领域的专家。

在《第五项修炼》一书中就有这样的例子。咨询师访问一个制造设备工厂的经理，就用到了这样一些追根究底的分析。看到地板上有油渍的时候，经理的第一反应是命令工人把它打扫干净。但是，咨询师问：“为什么地板上会有油渍？”经理不熟悉整个流程，就会责备这是清洁队的疏忽。咨询师再次问道：“为什么地板上有油渍？”通过一系列渐次提出的“为什么”和许多不同部门员工的帮助，咨询师最后找到了真正的问题所在：采购政策表述不明确，导致大量采购了一批有缺陷的垫圈。

在许多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律。那样的随机安排很难处理。你根本不知道明天将会发生什么，也不知道什么时候开始下一轮的全体“消防演习”。但是，敏捷项目会有一个节奏和循环，让开发更加轻松。例如，Scrum约定了30天之内不应发生需求变化，这样确保团队有一个良性的开发节奏。这有助于防止一次计划太多的工作和一些过大的需求变更。

Helmuth von Moltke曾说过：“没有任何计划在遇敌后还能继续执行。”我们的敌人不是客户，不是用户，不是队友，也不是管理者。真正的敌人是变化。软件开发如战争，形势的变化快速而又剧烈。

严格的需求—设计—代码—测试开发流程源于理想化的瀑布式②开发方法，它导致在前面进行了过度的设计。这样在项目的生命周期中，更新和维护这些详细的设计文档变成了主要工作，需要时间和资源方面的巨大投资，却只有很少的回报。我们本可以做得更好。

好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。

盲目地为项目选择技术框架，就好比是为了少交税而生孩子

持续集成系统就是在后台不停地检出、构建和测试代码的应用。你可以自己使用脚本快速实现这样的方式，但如果你选择已有的免费、开源的解决方案，它们会提供更多的功能且更加稳定。

即使项目还没有正式开始，我们就有了单元测试、持续集成和基于窗口的安装程序。这样，我们就可以更容易更简单地给用户交付这个演示系统：用户所要做的工作，就是从我们的网站上点击一个链接，然后就可以自己在各种不同的机器上安装这个演示系统了。

没有人的思想和观点可以及时冻结，特别是项目的客户。就算是他们已经告诉你想要的东西了，他们的期望和想法还是在不停地进化——特别是当他们在使用新系统的部分功能时，他们才开始意识到它的影响和可能发生的问题。这就是人的本性。

不一致的术语是导致需求误解的一个主要原因。企业喜欢用看似普遍浅显的词语来表达非常具体、深刻的意义。

回到顶部

走出软件作坊 (阿朱)

交付的时间都被培训、技术支持占去了。为什么我们要做这些？是因为我们软件没有操作说明，其他部门人都不会用。而且我们也没有培训机制，其他部门人更不会用。而且我们的软件不稳定，其他部门人都拒绝实施。由于我们软件不稳定，老出问题，出了问题其他部门人也帮不上忙，只能我们自己去做技术支持。从以上来看，主要矛盾就是在：操作说明、培训机制、稳定性。如何保证这三点。而且从以上来分析，稳定性是最重要的。不稳定，你即使有操作说明和培训机制，其他部门人都躲着实施，谁想去客户那里尴尬丢脸挨骂呀。所以，其他部门人会找各种理由向老板告开发部的状，以躲避实施，说软件太烂，根本无法拿出去。这也就是开发部往往和其他部门关系都不好，开发人员老抱怨自己就闷头辛苦开发解决问题，没有人说好，却被奸人陷害。天长日久，积怨颇深。其实说起来，根源还在开发部自己这里。如何保证稳定性？大家第一想到的就是招测试人员。当然，一些公司的老板是拒绝养测试人员的。另外，如果你只想到招测试人员，其他方法不配合测试人员，即使有了测试人员，软件稳定性仍然不会有提高。所以，有一些工作，是不管有没有测试人员，都必须是我们开发人员要做的：每个人 A参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合的把握。如果队伍中没有这样的人，只有开发经理一个人有这样的经理，那么接到客户需求，分析客户需求，分解析辨是公共代码员来做还是其他开发人员来做。 B公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位内存创建释放有头有尾，代码优美，代码可阅读，代码重构，代码性能和稳定都高 C公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上最好应该说，找一个技术能力好的，工作认真负责的人，应该是不难找到的。而且专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。刚才还讲到一件事，那就是开发经理要熟悉客户需求，而且是深刻理解客户需求。客户需求，客户需求。这个让开发部最头疼的字眼。每当想起客户需求，就想起了以下这些话： 1 程序员说：这是你们家个性的需求，太邪门，我们不做。客户说：不做我们找你们老板去，我们是花钱买了你们的产品的。 2 客户说：我不会用鼠标，你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通，你们给我们做一个吧。程序员：我晕。 3 程序员说：等你们内部斗争完，你们协调完了，我再调研需求。似乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。最后，我们发现，我们的软件无比复杂，谁也不会用了，连开发部门都不会用了，谁也不知道这个需求当时为什么是这样的。因为无比复杂，所以实施、培训、技术支持都成了问题，稳定性更成了问题。代码互相交叉，根本无法理清有多少交叉影响点。维护的程序员都快崩溃了，天天在祈求，千万别接到客户电话，千万别接到客户电话。这个问题终归是问题，而且是软件开发最大的问题。虽然我们也动用了这样的技巧： 1 客户业务部门不能随便提需求。必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司 2 客户IT部门的需求，必须客户方负责IT项目的老板签字才能生效，才能报给软件公司 3 不能随时报，每3个月集中报一次 4 不能口头报（即使在现场实施支持也不行），不能电话报，只能MAIL或传真来报 5 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作 6 软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。经过这么几招，客户也疲了。需求是不提了，开发部欢呼雀跃。但我们真的做好了么？难道客户真的满意了么？客户为什么要用我们的软件？难道仅仅是为了把他们现在手工做的，然后转到计算机去做。让计算机的查询统计计算速度代替人工？客户为什么要提这样的需求？客户要根本解决什么问题？这些问题谁来想，谁来想解决办法？ OH，My God!我们无能为力，因为我们是技术人员，我们不懂业务。那这个问题谁来解决？程序员苦笑了：没有人解决，也没有人能解决。客户就要，你不做他就要给老板打电话。噢，那就让程序员的噩梦继续吧。谁也救不了你，能救你的只有你自己。要救我们自己，必须我们自己走出我们自己。谁让我们就处在这样的处境呢？我们都想过的好，只能我们自己救我们自己。那我们就鼓足勇气，走出来，从我们的设计模式、OO、软件工程、虚拟接口、反射、持久化、框架中走出来。开发经理来承担起客户行业研究来： 1 客户行业这个群体有多大？大中小规模各有多少家，各分布在什么省？我们面对的最佳客户是什么规模什么信息化程度的？我们的次佳客户是什么规模什么信息化程度的？ 2 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？他们各自的优点是什么？他们各自的缺点是什么？我们应该突出的优点是什么？我们的缺点是什么？ 3 客户行业的过去5年，现在2年，未来3年的发展历史和趋势是什么？他们面临哪些挑战和机遇？ 4 我们现在所做的典型客户，他们的组织结构，人员规模，每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程，每个岗位每日每周每月季每年的输入表格，每个岗位每日每周每月季每年的常用数据查询，每个岗位每日每周每月季每年的统计报表 5 针对以上的了解，客户面对未来挑战和机遇，未来应该如何变更他们的岗位和职责和流程，尽量流程少，效率高，运转快？其实，开发经理就相当于业务架构师（因为我们还是游击队，不可能有专职的业务架构师），公共代码开发员就相当于技术架构师。柳传志说的非常好：搭班子，定战略，带队伍。你班子不行，上什么需求管理软件、版本管理软件、项目进度管理软件、自动测试、自动集成软件，都是无法落地执行的。有了夯实的业务+技术，功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求，就都能满足了。这时候再招测试人员，就能把质量再夯实了。而且，测试人员由于熟知产品，他们还能做技术支持呢，这样可以有更多的开发人员来专职开发，开发的专业性就能越来越提高了。好的产品，还需要有好的文档和培训，否则其他部门还是不会接开发部的产品的。那就招一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试（这个很重要，否则文案人员不熟知产品，无法写出有质量的文案）。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于他自己写文案自己用自己的文案做培训，在培训中会有各种提问，会更加增进他对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。好了，开发部的四套马车终于起来了，这就是我要讲的开发模式：从游击队转变为兄弟连，从软件作坊走向记住：业务架构、技术架构、测试兼技术支持、文案兼培训，四套马车。我们一直用它，效果很好，搭建团队容易，循序渐进不革命。有了这么好的团队，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。其他部门也愿意接软件了，软件的实施和培训和技术支持都被其他部门接过去了。开发部门也终于专职专业起来了，整个公司都很协调了，部门间也不互相陷害抱怨了。公司发展速度蹭蹭的。老板看着形式这么好，也不抠门了。奖金福利随之而来。老板看着公司产品销售这么好，也不用再为公司生存发愁了，不用随处找单子养活了，给开发部门更带来了专业理顺的计划发展。老板也开始重视研发部门了，研发部门在公司的地位高多了，给与研发部门的资源和支持也更多了。 OH，My God! 第二章三五个人十来条枪如何成为开发正规军(二) 上一次，写了一篇文章《三五个人十来条枪如何走出软件作坊成为开发正规军》，反响异常激烈。我的一个朋友也看到了我的博文，他是做某个行业企业管理软件的。他说：你这个方法，在我从事的行业不适用。我对他从事的那个信息化的行业还是有一定了解的。他们的实施模式是： 1一个实施项目，大约50万的签单额，做完验收后给最后的20%-30%的尾款。 2他们是一家小公司，为了多做项目多赚钱（企业都希望利润保持的很高，如果毛利低，做软件就不合适了，受的苦和压力和不规律性比其他行业多的多），所以一个项目只派一个人去，而这个人需要培训、辅助导入旧系统数据、清洗合并数据、规范化数据、报表制作、需求协调、推动切换上线、现场运行监控、个性化定制修改代码。 3如果不能推动客户上线，就无法验收结项。不结项，就无法去追尾款。 4一个项目这个人，身兼项目经理、开发员、需求调研、软件设计、功能测试、实施培训、定制化开发，还有时候写培训文档。因为公司里都是这样的人，根本没有分工出专门的文档人员，所以产品根本没有培训手册和帮助手册。除非客户必须要，这个项目的这个人才写一份草稿应付。而公司又没有人来做文档管理工作，所以各个项目各个人写，也没有人合并，也没有人来统一收集。每个文档都在项目每个人的移动硬盘里。 5由于项目就老哥一个人全活儿，所以自己答应了客户修改什么需求就自己修改，根本没有啥需求调研方法和版本管理方法，就看这个老哥和客户之间的博弈了。每个项目一套源代码，而且都在各个项目的各个人手里。返回公司后，往公司的服务器上一扔做个备份。以后谁的项目出了问题或需求，就谁负责继续修改。但是，很有可能这个人已经在做其他项目了，还需要修改前几个项目的需求或BUG，还需要接听前几个项目的支持电话。如果这个老哥是在顶不住压力和焦虑而跑路了，只能把这些所有的活交给现存活的人的手里，啥也没有。无法交接也得交接，反正人要跳槽。 6由于每个人都是这样一人挡一摊或数摊项目，而且项目周期长，每个项目都需要2-3个月的时间。老板也想把公司做大，但是每个项目能去实施的人，要求都非常的高，新人来了一年也上不了前线干不了活。所以，对招新人也是不愿意招，干花钱没见起作用，小公司培养不起人。而对项目游刃有余的人，都是跑单帮跑惯了，带着个新人，还干不了活，还浪费出差费用，真是气死人了，还不如自己亲自动手三下五除二搞定爽。于是，公司五六年了也就那么大规模，老板员工都干的很辛苦，当然老板得到的钱要多一些，赚个500多万没啥问题，自己后半辈子算是有靠了。所以，老板也得过且过，反正现在赚钱速度已经比较满足了，这样也熟练习惯了，经验路径依赖，就这样顺坡下驴做吧。我的朋友是个理想和现实总是不断冲突的人。一方面，他确实想把项目做的很是顺畅，另一方面，他却觉得一切都像是被各种因素牵扯，根本无法转变模式，于是只能认命继续现在。我说，你这种情况其实在中国很普遍。中国大部分软件公司都是从事行业信息化，因为这块技术难度最低，而且只要有人脉关系就可以做销售开干。而很多软件公司的成立，就是由于老板有一个关系，接到了某个项目，于是拉住了某个客户，小活不断，于是成立了公司。这是很多老板成立公司的原因。既然这类公司成立就没有目标，其目的就是认识几个人多拉一些项目多赚一些钱，所以如何复制模式，他们其实关注性也不大。原因很明白，就是自己不认识的客户，要想打入这个单子，很难，每个客户庙前都有N多关系户。对于自己有关系的客户，也就那么多个，有多大关系就能做多大的摊子，那就尽量从现有客户中持续做项目。维护好客户关系是最重要的。这类模式非常常见，并不是你这个行业特殊。老板的生活已经趋向于小康稳定，而你呢？你还在挣工资。你也在一线客户那里天天呆着，要么你把老板的客户抢过来你做，要么为了你自己工作能轻快些，你必须自己给自己找方法。我的朋友说，抢过来不可能。自己虽然天天在第一线和客户天天在一起，关系也处的不错。但现在人先认的是钱，后认的是感情。而老板给他们这帮人都持续吃喝玩乐送东西分回扣，自己只是一个干苦力的。自己只能找方法。但你说的方法是针对一个公司的变革，不是针对我个人而言的，所以不适用。我想有一个方法能帮助我自己的方法，你帮我想想。我想了想我过去写过的文章，确实是，自己一直从事职业经理人操盘产品研发管理，也统管咨询、实施、培训、支持，但都是在公司管理的层面上看问题分析问题解决问题，而没有从一个个体上去思考。而中国，大量像我这样的朋友，他们需要帮助，而我写的却是公司层面的，无法帮助他们，所以他们老说我的文章空洞、理想。我说，咱们俩一起分析解决。也是给大量像我朋友这样辛苦的人带个福音。咱们首先先说一下你想达到什么效果。我朋友说：我现在在这里待的很烦，出差时间太长了，我就想早点回家。那你什么地方费时间了，需要2-3个月在客户现场？我朋友说：嗯，我看完你的那篇文章，我也做了一下反思和总结。我感觉有三个方面特别费时间：客户需求，数据准备，报表制作。一去客户那里，你是见不到客户老板的，也是看不到用户的，你主要面对的是客户信息科的人。他们一开始要求你先做演示，看看是否符合他们本企业使用。在这个演示过程中，就不断提出需求让你修改。而且，你不修改完，他们没法接受你以下的演示，说想象不出后来的样子，对着你画的界面图想象以后的功能变化，有点纸上谈兵的感觉。而且，往往演示的时候必须信息科科长在，否则底下的科员都做不了主，演示了也是白演示。而信息科科长却老不在。而他们上班时间也极为规律，该下班时立马下班，根本不加班。所以边演示变修改再边演示。好容易修改完了，也演示完了，时间一俩个星期就过去了。信息科算是通过了，就需要录入基础数据了。问题又来了。现在大部门企业都已经上过一套软件了，可能是Foxpro的，也可能是PB的。人家要求你把数据倒进新系统中，但是一看过去的数据，都乱七八糟的，过去上线都是没经验，后来也用的乱了，积腋成疾了。现在要导入，真是要把垃圾输入，得出来的也是垃圾。你苦口婆心的说服让他们重新录入，但是他们一看都好几千条，不想录入，让你能导多少导多少，然后在基础上再维护。这一松口不要紧，你不仅忙活了一个多星期写各种SQL导数据，而且往往旧系统也没有文档，数据结构需要你自己理解，理解有误也是你的事。好容易导完了，再维护，发现数据是通过SQL导入的，在界面上却不能维护，因为很多校验都是写死在程序里的，而不是约束在数据库。磕磕碰碰，自己边后台修改数据，边让他们信息科维护。他们信息科首先先检验导进去的数据对不对，没有填写齐的字段填写齐。然后把没有导进去的数据录入进去。然后再打印出来，统一对一遍，看看哪些数据录入的有错误。这样折腾，一个月，22天工作日就过去了，用户还没培训呢。第二个月开始用户培训了，但一培训就发现了问题。用户的需求和信息科所的需求，根本不是一码事。原来一个企业，信息科也和业务科室是两张皮，就和在软件公司一样，开发部和销售部是两张皮。于是，用户和信息科开始吵架，各说各的道理，谁都在维护自而业务部门科员是站在自己轻松使用的角度上提需求，而信息科是为了自己以后维护着想。不断的讨论不断的推翻不断的扯皮。讨论扯皮推翻再讨论再修改。终于消停了。开始培训了。但问题来了，用户上机一操作，发现基础数据很多不是平常现实那样的。计算机数据过去就和现实数据脱离了，现在想借新系统上线再回到计算机管理上。于是，一边培训一边修改数据，有人报告数据错误就修改。而培训没有文档，培训也没有课程，培训也没有专业训练。培训如何层层开展，培训如何组织，都不知道。反正就老哥一个被订在这里了，只能这么上手了。人没有来齐，也得开始。等来了再重新讲一次。一次不会，再讲一次。有人年龄大打字不熟练，有人看不清屏幕，需要调整大字。一调整，界面发生错位了。有人不会用鼠标双击和单击，有人不会控制打印机。过去是UCDOS系统，还没用过WINDOWS的，用不惯。从基础培训起吧。否则怎么办呢？人家不上线用起来，人家不给验收结项啊，尾款回不来啊。用户也培训完了，该上线了，就需要初始化库存了。先得现实盘点，然后再录入计算机，还必须一边得继续营业。于是，真实库存和计算机库存肯定对不上去。由于品种太多，所以只能一批批盘点一批批录入。由于操作不熟练，特殊业务不知道如何处理，只能瞎处理。处理完后发现不对，想冲抵回去。没有冲抵功能，只能修改数据库中的数据。由于前期修改，根本没有测试，就是老哥自己一个人改。改完了有时候烦了连自己都不想测试。于是上线用着用着就不能运行了，需要当时就立即修改，中午晚上的连续作战紧急解决，否则第二天一早还需要开门迎客。好容易业务录入了，但是报表不对。一检查，原来是前段时间录入的非法业务数据造成，功能没想到没拦住。怎么办？偷偷自己修改数据，然后使报表平账。过段时间，发现报表又不平了，发现还是非法数据进入造成。怎么进来的呢？想不明白。只好蹲点现场，直到客户都运行正常了才能走人，算是上线成功。这个累呀，两三个月都是紧着过的。好不容易回来休息会，另一个项目就要启动了，就这么几头能干活的蒜，老板笑着脸让你去。于是，遭遇再次上演，日子就是这么过来了，一月又一月，一年又一年。顶不住的就跑路。我听完了我的朋友的诉苦。我说咱们一件件事情的排查。第一件事，边演示边修改，还得信息科长在，还得他拍板。这段时间的浪费如入缩短。我过去也作过灯塔客户的实施，我过去一去了

回到顶部

5G经济社会影响白皮书

，5G 网络将形成由接入平面、控制平面和转发平面构成的 IT 化新型扁平平台。

更重要的是，5G 还将以其超高可靠性、超低时延的卓越性能，引爆如车联网、移动医疗、工业互联网等垂直行业应用。

5G 投资对经济增长的作用路径体现在两个方面一是投资需求,二是投资供给

回到顶部

上帝掷骰子吗 (曹天元)

量子论的发展几乎就是年轻人的天下。爱因斯坦1905年提出光量子假说的时候，也才26岁。玻尔1913年提出他的原子结构的时候，28岁。德布罗意 1923年提出相波的时候，31岁。而1925年，当量子力学在海森堡的手里得到突破的时候，后来在历史上闪闪发光的那些主要人物也几乎都和海森堡一样年轻：泡利25岁，狄拉克23岁，乌仑贝克25岁，古德施密特23岁，约尔当23岁。和他们比起来，36岁的薛定谔和43岁的波恩简直算是老爷爷了。量子力学被人们戏称为“男孩物理学”，波恩在哥廷根的理论班，也被人叫做“波恩幼儿园”。

我们要学会依赖于数学，而不是日常语言，因为只有数学才具有唯一的意义，才能告诉我们唯一的真实。我们必须认识到这一点：数学怎么说，我们就得接受什么。

回到顶部

华杉讲透国学经典（共3册）（《孙子兵法》、《论语》、《孟子》） (华杉)

五事，是道、天、地、将、法。七计，是主孰有道、将孰有能、天地孰得、法令孰行、兵众孰强、士卒孰练、赏罚孰明。就是比较敌我双方的政治、天时、地利、人才和法治。所以孙子的计，相当于咱们现代管理学讲的SWOT分析，比较敌我双方的优势（Strength）、劣势（Weakness）、机会（Opportunity）和威胁（Threat）。

比如企业的经营活动，可以说一举一动都是“笔下有财产万千，笔下有人命关天，笔下有是非曲直，笔下有毁誉忠奸”。一个举措下去的时候，短期可能看不出什么影响，但只要你错了，它总会反映出来惩罚你。

“死生之地，存亡之道”的敬畏心，仅对手握重兵的军事家有警示意义吗？非也，对我们每个人都有意义。比如企业的经营活动，可以说一举一动都是“笔下有财产万千，笔下有人命关天，笔下有是非曲直，笔下有毁誉忠奸”。一个举措下去的时候，短期可能看不出什么影响，但只要你错了，它总会反映出来惩罚你。

占卜吉凶的龟背骂为朽骨，喝令

“死生之地，存亡之道”的敬畏心，仅对手握重兵的军事家有警示意义吗？非也，对我们每个人都有意义。比如企业的经营活动，可以说一举一动都是“笔下有财产万千，笔下有人命关天，笔下有是非曲直，笔下有毁誉忠奸”。一个举措下去的时候，短期可能看不出什么影响，但只要你错了，它总会反映出来惩罚你。

专任智则贼，遍施仁则懦，固守信则愚，恃勇力则暴，令过严则残。五者兼备，各适其用，方可为将帅。”

梅尧臣说：“智能发谋，信能赏罚，仁能附众，勇能果断，严能立威。”

所以做领导的，不要只关注事，要关注人。不要事情办好了就万事大吉了，要对在办这事的过程中，你手下每个人发挥了什么作用都非常清楚，并能作出奖惩，你的事才能越办越好。

本谋和初心，是我们每天、每事，要对照检核的，要

《韩非子》说：“事以密成，语以泄败。”

冒顿是中国历史上唯一一个不跟任何人商量，一个人把谋反这大事干成的。

上了战场，“兵者，诡道也”，才开始阴谋诡计的发挥，“多方以误之”，想办法引对方失误，这就有“十二诡道”：能而示之不能；用而示之不用；近而示之远，远而示之近；利而诱之；乱而取之；实而备之；强而避之；怒而挠之；卑而骄之；佚而劳之；亲而离之；攻其无备，出其不意。

五事”，是道、天、地、将、法，计算比较敌我双方这五个方面，得到“七计”，七个计算比较的结果：主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？

所以《孙子兵法》第一篇讲实力对比，风险评估，胜算几何，第二篇就讲费用预算，资源保障，这和我们经营的道理，真是一模一样。

“明犯强汉者，虽远必诛。”现在愤青们说起这句话，还饱含热泪和激情。可不知道，这句话的背后，是从政府到民间的全国破产。

汉光武帝刘秀。刘秀破铜马贼于南阳，俘虏了十几万人，整编到自己的部队里。但是人心未安，因为铜马贼之前降过一次，又叛，又被打败，最后又降的，所以贼帅们觉得刘秀不会信任自己。刘秀也知道他们的心思，说你们各归本营，我来慰劳将士们。之后刘秀仅率十余骑，亲探铜马大营，展示了以命相托的绝对诚意。贼帅们感激涕零，说：“萧王推赤心置人腹中，安得不投死乎！”把自己的一颗赤心放到别人肚子里，那么大的诚意！这就是“推心置腹”这个成语的由来。

胜了敌人不等于赢了，关键你自己是变得更强了，还是更弱了。

孙子的思想，做任何事之前，一是先考虑风险，二是考虑代价，第三才考虑利益。

十则围之，五则攻之，倍则分之。

以正合，以奇胜。”

“先为不可胜，以待敌之可胜”，

不可胜在己，可胜在敌。故善战者，能为不可胜，不能使敌之可胜。

回到顶部

只有偏执狂才能生存:特种经理人的培训手册(新版) (安迪•格鲁夫)

既然转折点是不定型的，那么你怎样才能知道应该在什么时候采取正确的措施以变应变，来挽救公司和个人的前途呢？很遗憾，你不能。但你不能等到知道答案后再行动：时间就是一切。如果你能在公司仍然健全、外部业务仍能保护你在内部试验新的经营方式的时候实行改革，你就能更好地保存公司的力量、雇员的利益和你的战略地位。但是，那就意味着你要在情报尚不完全、情况尚不清楚的时候就采取行动。即使是那些平常笃信科学管理方法的人，也不得不靠感觉和个人判断来行事。可悲的是，一旦卷入了战略转折点的急流，就只有感觉和个人判断能够作为你的指南了。

1995年前后新的横向式计算机产业分布

位于得克萨斯州奥斯汀的戴尔计算机公司每年营业额可达50亿美元，它仍忠实于自己的初衷——按照顾客的具体要求组装计算机邮售给顾客。

首先，当战略转折点席卷某一产业时，原有产业结构中的成员越是成功，其身受变革带来的威胁则越大，而其本身则越不愿自我改变以适应变化；其次，新进入一个拥有强大竞争对手的既定产业并向对手挑战所付出的代价可能极大，而当该产业结构即将崩溃，所需的代价便会极小，

依照市场所能承受的限度去定价，依照产品数量去定价，然后拼命地设法降低成本，以期从你的最少投入和你的适当定价上赢利，此举能帮你取得量产量销的规模效益或者说规模经济形态（economics of scale）。必要的大规模投资将会奏效并具深刻意义，因为作为大规模的投入者，你有能力扩展并从投入中赢利，分摊并收回成本。与之相反，以成本为基础的定价经常会将你引入利基市场，使你只能掌握特定利润，而这在当今规模生产型的产业中是不太能获利的。

战略转折点都表现出10倍速变化吗？每一个10倍速变化都会导致战略转折点吗？我认为，从实际运用

它们的直接诱因是竞争力量的10倍速变化，技术上的10倍速变化，顾客作用的10倍速变化，供应者和互助企业作用的10倍速变化，以及规章的建立和清除带来的10倍速变化。10倍速因素到处可见，人们因此会问：每一个战略转折点都表现出10倍速变化吗？每一个10倍速变化都会导致战略转折点吗？我认为，从实际运用上来说，这两个问题的答案都是肯定的。

第二货源曾是计算机产业中普遍的现象。它指的是供应商为了确保其产品拥有广阔的市场转而与其竞争对手合作，向他们提供自己掌握的技术信息。这样，其竞争对手也可以供应他们“自己”的产品了。

理查德· 特德洛教授1993年10月7日曾在英特尔总部发表演说，他指出：“一个优秀的公司之所以遭遇麻烦，有以下三个原因：要么公司脱离用户，要么用户脱离公司，或者两者同时发生。”

战壕里的士兵总是更早地得知战局即将发生的变化。销售人员比管理人员更快看到顾客需求的变化，财务分析人员是看到企业根本转变的第一人。

回到顶部

DevOps实践指南 (吉恩·金(Gene Kim);耶斯·亨布尔(Jez Humble);帕特里克·德布瓦(Patrick Debois);约翰·威尔斯(John Willis))

了DevOps“三步工作法”：流动原则、反馈原则、持续学习与实验原则

公司利润下滑，不得不解雇一些很有才华和经验的员工；由于有大量计划外的工作和紧急任务，剩下的员工无法处理日益增长的客户服务请求；只好投入中层管理团队一道完成合同要求；所有人都认为3年后肯定得重新招标。这种绝望和无助的感受使我加入了这场道义上的征程。开发似乎总是被视为战略性的，而IT运维则被视为战术性的，因此常常被委托甚至整个外包出去，结果是5年后的情形比当初交接时更加糟糕。

大多数公司都不能在几分钟或几小时内完成变更需要的所有部署，往往需要几周甚至几个月的时间。他们更不可能每天在生产环境中做到成百上千次的部署，而是在以月甚至以季度为单位进行部署。对他们而言，生产环境的部署并不是日常工作，因此服务中断和各种事故总是与部署如影随形，“填坑侠”们总是前赴后继。

我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。

通过黑启动（dark launch）技术，即便是复杂的产品和功能发布，也变得稀松平常了。早在发布日期以前，我们就已经将所有功能的代码部署到了生产环境中，它只对内部员工和部分真实用户可见。这使得我们能够测试和改进其功能，直到达到预期的业务目标

当我们增加开发人员的数量时，由于沟通、集成以及测试开销，单个开发人员的生产力通常会显著下降。Frederick Brooks在其著名的《人月神话》一书中强调过这一点。他解释说，当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。

另一个更加极端的例子是亚马逊。2011年，亚马逊每天部署近7000次；到2015年，他们每天要部署130 000次。

技术行业的工作内容是不可见的，这是其与制造业价值流相比的一个显著差异。相对于工业产品的生产过程而言，在技术价值流中很难发现工作过程的阻塞点，例如，在哪里受阻了，在哪个环节产生了积压。而在制造业的价值流中，工作在不同工作中心间的转移通常是显而易见并且缓慢的，因为必须真正地转移库存产品。

如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次优化下面的约束点。环境搭建：如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建。

代码部署：如果代码的部署需要花数周或更长时间（譬如每次部署需要1300个手动、易出错的操作，涉及多达300名工程师），那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署。测试

代码部署：如果代码的部署需要花数周或更长时间（譬如每次部署需要1300个手动、易出错的操作，涉及多达300名工程师），那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署。

紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力。

测试的准备和执行：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度能跟上代码开发的速度。

他发现了复杂系统的另一个特点：相同的事情做两次，结果未必相同。也正是因为这个特点，即便施行了有价值的静态检查和最佳实践，还是不足以防止灾难发生（见附录5）。复杂系统中的故障是存在且不可避免的。因此，无论在制造业还是信息技术行业，我们都必须设计出一个安全的工作系统，让员工能无所畏惧地开展工作，确保早在灾难性后果（例如人员伤害、产品缺陷或负面的客户影响）发生之前，能快速检测出错误。

在技术价值流中，由于缺少快速反馈机制，我们经常会得到糟糕的工作结果。例如，在瀑布型软件项目中，代码的开发可能花相反，我们的目标应该是在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更