敏捷开发：中国十八年目睹之怪现状
持续交付领域专家乔梁老师是一个好人，他讲话特别委婉。乔老师说：“你不改变你的工作方式就不能得到 10 倍的效果。”大家听了这个话以后就觉得，他讲的是一个抽象的“人群”。每个人听到这个话以后都有一个自我暗示：乔老师说的是其他人，我不包含在内。因为他是好人，他不肯把话说得太直白。其实乔老师批评业内敏捷现状的话，说直白了就是断水流大师兄的话：“我不是针对你，我是说在座各位……”
当然这个现状不完全是你们造成的。台下的各位大部分还很年轻，这些现状形成的历史因素很可能你们还不了解。我今天分享的就是这些行业历史的故事。
中国 IT 行业的发展不是自然而然的。有人认为，经济自然发展到一定的程度就自然会推动信息科技的发展。不是这样的。有一个反例就摆在面前，香港现在的 IT 行业就非常糟糕，经济的发展并没有自然而然地推动香港 IT 的发展。IT 是一个非常高端的行业，它不是自然就会发展起来，它需要政府有相当大的主导意向。
因“18 号文件”而兴起的中国 IT 业
大家可以查一下 2000 年 6 月颁布的国务院 18 号文件《鼓励软件产业和集成电路产业发展的若干政策》，中国的 IT 行业完全是这个发文推动起来的，其中给了这个行业很多的优惠政策，很多政策直到今天仍然在推动这个行业的发展。
在“18 号文件”颁布之前，2000 年的时候，中国 IT 行业从业人员大概是十几万人，是一个很小的行业。到 10 年以后，这个人群发展到了数百万人。这个发展的速度，人的大脑本能理解不了。我们可以做个对比：中国的经济发展也是很快的，每年 10% 左右；当时政府的预测是 IT 行业可以有每年百分之十几的增长，超过 GDP 增速。但是实际上，从 2000 年以后的 10 年，IT 行业保持了每年 50% 以上的增长，这是“放火箭”一样的发展，超出所有人的理解能力。在 10 年的时间从业人数增加了数十倍，这对整个行业来说是一个巨大的考验。
很快，这个行业就遇到了挑战：软件质量差、交付进度难以保障，等等。这种现象大家很熟悉，软件工程的教材上讲过，这个叫软件危机。当时专家的意见是：为什么会出现软件危机，是因为技术环节不过关，社会化大生产没有形成，解决的办法就是要提高软件工程水平。
这是 2001 年的行业大背景。当时的行业对软件工程有一种非常迫切的需求。于是那个时候，行业就去引进了 CMM。
以 CMM 为代表的软件工程理论准确识别软件开发的基本功
2001 年，我给《程序员》杂志社采访了号称“CMM 始祖”的一个印度人。CMM 在 2001 年左右传入中国，非常明确给中国软件行业指出了问题所在。它非常清楚地指出软件开发应该具备哪些基本的能力：需求管理，项目管理，配置管理，质量保障等。这些能力就是 CMM 二级里面定义的，大家回头找 CMM 二级来看一下就知道了。从这个角度来说，CMM 是一个非常有价值的框架。
国家对 CMM 做了很多的补贴。当时科技部主导，从北京市开始各地都有相应的补贴政策：通过 CMM 二级认证补贴 20 万，三级 30 万，五级 50 万。
十八年后，行业的基本功扎实了吗？
有这么好的政策在这儿，十八年以后，我们行业的基本功补齐了吗？我们行业的基本功扎实了吗？
我觉得这个事情不能用非常抽象的方式来讲，我来讲几个真实的“鬼故事”。
需求管理？
比如说需求管理我可以讲个故事。2009 年、2010 年的时候，我当时在很著名的某家通信企业指导一个项目，当时跟华为的两个系统工程师去客户那调研需求。去之前这两位工程师说：“你不知道，我们这个客户是妖怪，没事儿就骂我们，动不动就改需求，特别的可怕。”我说我去看一下吧，了解一下这个妖怪的客户都是怎么回事儿。
约到客户上午 9 点钟开始调研需求，我们几个人走过去，这两位系统工程师上去：“你好，现在你有什么需求，请告诉我们。”后来我看《人民的名义》那个片，我就联想起这两位系统工程师调研需求的场景，他走到那儿把手一伸：“请开始你的表演。”然后客户就开始讲，一上午三个小时，客户大概讲了 2 小时 58 分钟，两个系统工程师讲了可能不到 10 句话，包括“你好”、“请开始你的表演”、“谢谢”。
然后需求调研就完了，中午的时间写会议纪要，写完以后给客户发出去，20 分钟以后客户打电话过来开始骂人，整个办公室都听见了：“你们做的是什么需求调研？我一早上给你讲了 3 个小时，讲了 5 个要点，你邮件纪要发过来只有 3 个要点，你浪费我一早上时间逗我玩吗？”
这个就是我们行业里面很领先的企业调研需求的方式。类似的行为我后来看到过很多次，大家去“调研需求”到底是干什么？就是走去：“客户爸爸你好，请问你有什么需求，请你告诉我。”这样调研需求，需要什么技能、需要什么专业能力？什么都不需要。这个就是人类本能好吗？“我想知道一件事，请你告诉我可以吗？”这个 6 岁小孩也会。从这些现象里，我后来总结出来一个概念叫做“全凭本能工作”。我们这个行业里有很多本来应该是专业人士做的专业工作，实际上是全凭本能在做，看不到专业的能力。
项目管理？
说完需求管理我们再来说项目管理。我们这个行业的项目管理到底是怎么做？你找一个项目经理来问，你的项目管理是怎么做的？他能跟你讲很多大道理。但你到软件开发的现场里面去，到项目组里面待个两星期，你看看项目管理到底怎么发生的。真实的情况经常是这样：
项目经理走过来问：“你这个任务哪天可以完成？”
开发：“下个礼拜一吧。”
项目经理：“下个礼拜一？这个时间太长，礼拜五能不能完成？”
开发：“不行，这工作量太大了。“
项目经理：“就礼拜五，我们礼拜五就上线了。“
开发：“好吧，礼拜五就礼拜五，我加个班，挑战一下！“
是不是我们真正的项目管理就是这样发生的？你说这个项目管理，到底管理什么？真实项目里的工作量评估是怎么估的？
开发说：“做这个要 5 天。“
项目经理：“凭什么要 5 天，明明 2 天就做完了。“
开发：“那 3 天吧。“
这是项目管理吗？这是卖白菜。
配置管理？
然后我们再来说配置管理。我以前做一个持续集成的咨询项目，我先非常自信地把代码库 check out 出来，然后我去打一杯咖啡回来再看看。打完咖啡，发现还没有 check out 完，那我再去开个会。开完会回来看看，还没有 check out 完，那我再去吃个午饭。吃完饭回来看看，还没有 check out 完，我就纳闷了。
我：你们这个代码库怎么这么久还没有 check out 完呢？
客户开发：你自己在 check out？，我们都不这么干，我们都是从别人那里拿一个移动硬盘拷过过来。
我：你代码库多大？
客户开发：代码库有 5 个 G……
后来我拿一个移动硬盘把代码拷过来一看，这个代码库有 5 个 G，上面有一千多个分支。这就是 CMM 五级的企业的配置管理水平。很多故事我都不好意思说，鬼故事讲出来吓死人。
质量管理？
接着我们再说说质量保障。为什么现在行业里面大家搞迭代，周期都是两个礼拜一个版本，成了行业共识？ 因为都是一帮测试小姑娘跟着屁股后面做人肉测试，你怎么敢继续缩短呢？你缩短到一个礼拜发一个版本，然后小姑娘就得每个礼拜天天加班。这就是我们这个行业里的质量保障水平。
所以，像我这种工作时间长的人就非常好奇。我 2001 年就看见了当时搞 CMM 的时候，有很多的培训公司讲课，然后政府又有补贴，通过 CMM 的公司非常多。那这个事情到底是怎么跑偏的？为什么大家搞了十几年的 CMM，到现在行业里面的能力是这样的，各个公司都是全凭本能在工作？前两天有一个群里有人说：“我们公司的研发管理做减法，不写文档了，做完减法之后我们非常敏捷。”我说你们从来就没有研发管理，做的什么减法呢？你们有一堆文档，但是文档跟真正发生的研发根本就是两码事，实际上的研发就是大学实验室的工作方法，大家全凭本能在工作。
软件工程是如何跑偏的？
那么软件工程到底是什么时候跑偏的呢？我去年写《敏捷中国史》的时候看了很多的材料，然后发现很多的事情是从根子上跑偏的。一开始，很多专家把软件的生产和制造业相关联。但是非常有趣，尽管这些中国软件工程专家经常讲制造业，但是他们对制造业根本不懂，他们根本不知道这个制造业是怎么发展。
1995 年左右，美国里海大学亚科卡学院受国防部的委托，做了一个叫做《21 世纪制造业挑战》的研究，这个研究报告里讲 21 世纪的制造业有什么特征？是需要高度的定制化、高度的柔性，需要减小批量。听着像什么？像敏捷。而我们国家的软件工程专家们根本不了解制造业的这些新发展。他们在脑子里面自己想象了一个“制造业”，然后说我们的软件工程应该像制造业。他们想象的制造业是少数的精英在上面做设计、下面有大量的软件蓝领把精英的设计一模一样的写出来就完了。
基于这么一个模型，他们就开始搞培训，要求程序员踏踏实实搞工作，不要去想别的，不要去跟需求方打交道，这就是软件蓝领。而同一时期，美国的制造业在说：不应该严格区分设计和制造，不应该限制员工思考的空间。这些专家想象的制造业，跟制造业的发展方向根本南辕北辙。
CMM 是如何跑偏的
那么 CMM 明明已经提出了很好的问题，为什么这个问题没有得到解决？国内软件专家的误解呢，只能说他的知识不够多，不知道国外的软件和制造业到底是怎么样的发展，所以有了自己的想象。而 CMM 我认为很大程度上是个人品问题。从最早的“CMM 始祖”Ron Radice 开始，CMM 周围就一直有这种人品问题。
这个号称 CMM 始祖的人 2001 年到中国来访问，我当时参加了对他的采访。当时总共有 5 家媒体对他做了采访，宣传做得到处都是。我后来做了对这个人比较深入的调查，他是在发明 CMM 的研究小组里面一个研究员，他大概只发表过 2 篇论文，没有什么重要的学术著作。他在 CMM 的创始过程当中只能说起到了非常辅助的作用。据说印度的总理专门接见了他，我起码花了 5、6 个小时的时间尝试去找到这么一个接见的报道，没有任何结果，我认为这是编造出来的。
我觉得这个人非常有象征意义：CMM 从传入中国的第一年开始就充满了编造、吹捧、虚假、欺骗。2002 年的时候，这种现象已经引起 SEI 的关注了。SEI 认为一家企业在一年时间里从 CMM 二级过到五级，这是不可能的事情。而这个不可能的事情在中国 2002 年、2003 年连续发生了三次。所以当时 SEI 自己开始撇清关系了，就说我们认为这是非常不可能的。
这么不可能的任务，这些公司是怎么做到的？非常简单，叫做裁判下场踢球。非常简单的一个逻辑：公司想要这个认证，找谁做咨询？这个咨询师就是未来的评估师。咨询师收了你 10 万以后，然后他自己做的咨询，他自己回头再来评估，当然评估就通过了。就是一个很简单的玩法。那么企业为什么要花这个 10 万来请这个咨询师？因为有政府补贴。政府会补贴你 20 万通过二级。所以就成为了一个完整的利益输送链，咨询师、主任评估师和企业联手搞一个认证通过，就可以从政府那儿掏钱出来，企业白拿一个证，从政府那套的钱比它自己花的经费还多。这是一个完整的利益输送链。
我经常讲，“18 号文件”做了很多的好事情，但是其中的一件事情做的非常糟糕而且匪夷所思，就是对 CMM 的补贴。对 CMM 的政策补贴，这是中国改革开放史上前所未有的事情，不知道以后会不会有来者。前所未有在什么地方？中国改革开放史上有很多的产业补贴，比如对光伏的补贴，对大数据的补贴，对出口创汇的补贴，但是这些补贴政策至少都有一个出发点，就是你得做东西，对吧？你要领光伏的补贴，你得做出光伏来。你要领出口创汇的补贴，你得出口创汇。而对 CMM 的补贴是中国改革开放史上仅有的一个：你这个企业什么都不用干，不用开发软件，不用有收入，不用提升团队的能力，就可以领补贴。这是一个非常奇怪的政策。在这个政策的鼓励下，CMM 全国到处一片疯，所有的企业都去搞这个事情，因为是可以赚钱的。这就是政策补贴之下的乱象。因为有了这个政策补贴，搞 CMM 的全是骗子，没有一个例外。现在，我经常跟搞 Scrum 认证的这些朋友在打交道，我跟他们开玩笑说你们搞 Scrum 幸运就幸运在没有什么补贴，没有补贴就不怎么招骗子。所以搞 CMM 的全是骗子，你们搞 Scrum 的不全是骗子。
一线的实践者在干什么
CMM 咨询师在骗钱的时候， 一线的实践者在做什么？在一线干活的这些人是真正感受到了非常迫切的对软件基础能力的诉求，所以是有一些人在干一些很扎实的事情。
林星当时在厦门国际银行做项目经理，他在 2001 年发表的几篇文章，很大程度上讲的就是极限编程里面用户故事这一部分的内容。
另一个极限编程的先行者石一楹 2001 年的时候在杭州，他是国内最早翻译跟重构相关内容的技术作者。他发表了这个系列文章以后，我看到这些文章觉得非常的激动，其中对于代码的理解、对代码的质量和美感的追求，对我来说是一个很重要的启蒙。后来我知道，他是看了《重构》这本书以后，从里面提取的内容。我后来翻译《重构》这本书，和石一楹给我的启蒙是有很大的关系。我看了他的文章以后非常受鼓舞，就在《程序员》杂志上做了《重构》的技术专题，后来又做了极限编程一系列的文章。
2002 年时候，人民出版社引进了极限编程系列丛书，这是中国第一本关于敏捷的图书，这本书直到今天去看还是非常有价值的。
唐东铭这个同学他其实是一个相当传统的软件工程改进的这么一个人。他后来在 18 年的职业生涯当中，没有真正的做过敏捷的项目。人生的机缘巧合就是这么难以预料，他最早引进敏捷的书，可是一直没有得到机会去做敏捷的项目。
当时中兴有几个人，包括邓辉、孙鸣他们，对敏捷非常有想法。邓辉 2003 年翻译出版了《敏捷软件开发》这本书，我翻译的《重构》也是 2003 年出版的。这些敏捷的基础理论的准备基本上 15 年前就已经完成了。直到现在，很多人问我这个问题怎么解决、那个问题怎么解决，我拿出来的答案都是 15 年前的书。
十八年来唯一真正抓基本功的方法
18 年来，行业里有很多的方法来来去去，真正可以抓软件开发的基本功、真正可以提升软件团队的能力的方法，我觉得就只有极限编程。CMM 提出的这些核心能力，只有极限编程真正提供了。
一件事应该怎么做，你在书上看到一个说法，和你真正在工作上能做这件事，是相差很大的。
再比如项目管理，极限编程会告诉你迭代怎么去管，根据什么来看项目的进度。当然项目管理这一部分，我认为 Scrum 也是很好的，非常有效地告诉大家项目管理的方法。
再说配置管理。到底什么是配置管理？其实配置管理落到根本上就是持续集成。有持续集成，你就有有效的配置管理；没有有效的持续集成，就是没有配置管理，就是这么简单的事情。没有持续集成，你可以说在纸面上有很多配置管理的流程，但真到了需要软件的时候你怎么办？你只能依赖一个配置管理员来手工打包。越是你着急需要打包软件的时候，这个人就越出错、越是打不出包来。好不容易打出来的包一测有问题，然后大家一起加班。所以我说配置管理很简单，你有持续集成、每天可以有一个候选版本通过持续集成打出来，你就有配置管理；出不来，你就没有配置管理。
那为了让持续集成有效，最后的最后一切都会落到重构和单元测试上面。是不是拥有高覆盖率的、可靠的、运行快速的单元测试，这是一个决定性的分水岭。而高覆盖率的、可靠的、运行快速的单元测试集，得到这个东西最有效的办法，就是测试驱动开发，就是你必须先写测试、再写实现，你才可能得到这么一个有效的测试集。有很多人跟我讲，我们先赶紧写完了实现，回头再去补单元测试。“写完实现再去补单元测试”，这个鬼故事，我每年都听十几次，你们谁见它真正发生的？我们经常听到这个对话：
领导：单元测试很重要，我们要写单元测试。
开发：好好好，等我改完这个版本我就补单元测试。
改完了这个版本就有空了吗？有空了还有下一个版本呢。你在写代码的时候根本没有考虑怎么单元测试，为什么你认为写完实现代码以后就可以补上测试了？你补不上。你会对着一大堆草率堆上去的代码长叹一口气，因为你一开始写代码的时候就没考虑代码的可测试性。
这件事情我觉得非常有趣：软件工程的教科书里面都写着，单元测试是软件开发的重要环节。所有人都认同单元测试的价值，但是谁也不做。然后到了实践里面，大家说我写完这个版本我就补单元测试，然后这个版本完了之后没有补，然后下一个版本来了之后又说，我写完这个版本就补单元测试，下一个版本做完也没有补。这种现象使我对于人类作为一个整体的学习能力非常担忧，因为大家没有从历史中学习的能力：补单元测试这个事情是从来没有发生过的，所以未来它也不会发生，这才是合理的。你根本就不应该相信“我做完这个版本补单元测试”这种话。
所以一切的一切最后都会归结到有没有有效的单元测试集。得到有效的单元测试集最直接的办法，叫做测试驱动开发。我翻译《重构》第二版的时候跟另一个译者林从羽开玩笑说，你告诉任何一个敏捷实施当中遇到的问题，我都可以告诉你这个问题是因为没有做好 TDD。
Scrum 为何僵尸化？
比如说前段时间有人发明了一个词叫“僵尸 Scrum”，什么意思？大家早上开晨会的时候都低着头无精打采的：“我昨天在做这个任务，我今天继续做这个任务，我没有什么问题。”就跟一群僵尸一样的，毫无生气。你们都见过这个现象吧？为什么会有僵尸 Scrum？因为每个人的任务、每个人负责的代码，是一块一块隔开的，谁跟谁都没有关系。那为什么要把开发一个个隔开呢？因为谁也不敢改别人的代码，别人的代码看也看不懂，看懂也不敢改，改了也不知道有没有引入 Bug。为什么别人的代码看不懂、不敢改、改了不知道有没有破坏功能？因为没有单元测试嘛！为什么没有单元测试？因为你没有 TDD 嘛！
这就是个例子。我半开玩笑说，你告诉我任何一个跟敏捷实施相关的问题，我都能给你推导出来，是因为你没有 TDD。但是这个逻辑太绕，太曲折，很难跟人讲通。我昨天在一个敏捷群里面又跟人吵架。我说我的标准非常简单，有 TDD 的敏捷就是好敏捷，没有 TDD 的敏捷就是伪敏捷。再多的逻辑我都懒得跟他们讲了。郭德纲有一个话，说一个外行跑去跟火箭科学家说你们火箭的燃料不行，得烧煤，还得是精煤，水洗的不行，那科学家要是拿正眼看他一眼都输了——我就输了，那群里的“敏捷专家”连代码都不会写，我还跟他讲 TDD。
持续交互、研发云、微服务、DevOps...
再往后就有了很多新的方法，持续交互、研发云、微服务、DevOps......，每一波我都经历过。每一波新方法流行，就会有客户来问我对这个有什么看法。每一次他们来找我问的时候，我发现他们要解决的都是同一个问题。这个问题就是软件开发的质量很差、速度很慢。然后就开始想各种办法绕过这个问题。
比如说微服务流行那年，大家想的是：如果说开发一个单体应用质量很差、开发很慢，那我们是不是可以把单体应用拆分成若干个微服务，每个人负责一小块微服务，然后就可以对质量的要求没有那么高？最后发现，还是不行。一波一波的浪潮过去，看多了之后，我终于明白一个很简单的道理。最后决定开发的质量和效率的是什么？是持续集成，是持续集成里面运行的测试集的效率和质量。你可以得到一个高效率、高质量的测试集，你就能做好软件。没有高效率、高质量的测试集，软件开发的效率和质量就不会好。
于是我们又回到这儿来了。大家一波一波的尝试解决同一个问题，但是从来不去解决这个问题的核心，都在绕着问题走，都在想可以用什么样的流程和工具去解决问题，就是不敢直面核心的问题：我的人基本功不行，我们不会 TDD。一次一次去绕，一次一次绕不开。《敏捷宣言》第一句怎么说？人和交互重于流程和工具。但是搞敏捷的公司在做什么？十几年了，一次一次想用流程和工具解决人和交互不行的问题。
以前我做咨询的时候，我必须要为了项目的需要、为了公司收入的需要去配合这些客户，跟他们一起想办法，用流程和工具稍微缓解一下问题。现在我不做咨询了，我终于可以说实话了：这个核心问题绕不开，没有办法。软件开发的质量和效率不行的问题，它就是一个人和交互的问题：“人”就是个人能力的问题，“交互”就是团队能力的问题。人的能力和团队的能力不提升，基本功没有扎实，用什么样的工具都解决不了这个问题。
没有基本功，什么花哨套路都白搭
软件做不好，就是因为不知道怎么开发。没有基本功，什么花哨的套路都玩不了，玩到最后你都会面临同样的一个问题：我今天在这儿改一行代码，我怎么知道改完以后整个系统到底是不是好的？怎么回答这个问题，是决定性的分水岭。如果你没有一套完备、可靠、快速的测试集，那么回答这个问题唯一的办法就是改完这行代码然后叫测试部的小姑娘来回归测试。但是测试部的小姑娘她会很反感老是这么人肉回归，她就会打我。她打了我之后，我下一次不敢随便找她了，于是我就多攒一堆修改再去找她：“姐姐，给我一起回归一下呗。”现实就是这样的，软件开发的周期就是这么被拖长的。没有 TDD，你就解决不了这个问题。所以软件开发的核心问题，不管讲 DevOps 也好，讲持续交付也好，最终都得回到极限编程这里来。
之前有大概几年的时间，我对这个信念产生了怀疑：我说极限编程是不是太难了？是不是不适合这个行业？其实细想想这个说法也挺不好的。当我说“是不是极限编程不适合这个行业”的时候，我心里面想的是：在座的各位智商是不是有点不足，所以你们掌握不了极限编程？但我觉得实际情况不是这样。我觉得大家都是有这个能力的。所以我重新坚定了信念。
回到极限编程，回到软件开发基本功
今年不是讲“不忘初心、牢记使命”吗，我现在重新找回了我的初心和使命：极限编程是正确的，极限编程是真正有效的软件开发方法。所以我们一帮朋友把极限编程的中文网站做出来了。网站做出来以后非常的有效：别人问我很多软件开发方法和管理方法的问题，我直接从极限编程网站找一段，截一个图甩过去，很多问题直接就可以解答。
同时，我想证明一件事情：极限编程没有那么难，它不是在座各位不可以掌握的，它不是一个有着巨高的智力门槛的事情，它是所有人都可以掌握的。为了证明这件事情，我到现在为止开了 5 期的极限编程的练功房，每一期几百人，到现在为止大概有 2000 人在我的练功房里面学 TDD，学重构。事实证明这些东西不是学不会的，还不会的这些同学缺的就是刻意练习，你没有动手去练而已。
基本功的提升办法只有一个：刻意练习
什么是刻意练习？
刻意练习有三个要素。
第一是大量的重复练习。你在书上看到一个东西，不等于你就会了这个技能。看完书以后你可能可以跟领导去白活两句，面试的时候可以吹一吹，但是你肯定不会。这个技能，你在工作中用不出来，这个就是不会。要掌握一个技能，就必须要练，必须要大量重复的练习。
第二，要在学习区去练习。那就需要有人来设计练习的节奏，设计每天该练什么。大家可以去看 Kent Beck 的《测试驱动开发》那本书，非常好的一本书，由浅入深循序渐进的。但是很多人看那本书，一上来就被打懵，根本看不下去。为什么？我做了这些培训之后才知道，很多人自己的电脑上开发环境没有准备好，JUnit 测试怎么写、怎么运行都不知道。所以一定要有人给你设置每天练习的目标，给你拆解每天该练什么、掌握什么技能，才能一步步练下去。
第三是要有及时的反馈。有人告诉你今天练得对不对。在这些练功房的培训里面，我看到跑偏的太多了，跑偏的方式千奇百怪。所以必须有人看到，这个同学今天这个练习是跑偏了，然后要告诉他正确的练习方法是什么样子的，他才会有所进步。
做了这些练功房的培训以后，我最近开始反思另外一个问题：我们这个行业里面的培训、知识付费，这些东西到底在干嘛？我前两天跟另外一个知识付费的平台谈合作，他说他们的课程是以音频为主，要给学员听声音。我就好奇了，什么场景下大家需要一个音频为主的学习方式呢？他说，比如说我们学员早上开车的时候就可以听这个课，晚上睡觉之前可以抱着手机听一节课。你早上开车的时候听一节课可以学到什么有效的知识？你什么都学不到。你只能获得一种幻觉，这个幻觉叫做“我今天早上开车的时候学到知识了”。
所以我突然之间发现，这个行业里面大量的知识付费都是骗子，因为他根本没有让你掌握一个技能。比如说我举个例子，吴恩达的机器学习的课，你如果不去做他的练习，你就看一遍他的视频，甚至于更糟糕的，你听一遍他的音频，你可以学会机器学习吗？不可能的。你一定要反复练习，要有人告诉你练习的效果，你才会学到东西。那这些知识付费到底在干嘛？这个问题非常的困扰。