《黑客与画家》：软件发布得越快，开发者越容易做出好产品

关注吴大爷二三事，一起共同成长

知识分享 丨生活感悟

学习思考，寻找自我。

大家好，我是满肚子鸡汤的吴大爷，一个天天在键盘上敲打心灵，喜欢给人讲知识讲故事的男人。

如果你经历过早期的桌面软件时代，应该对一种事情有印象。

软件用了一段时间，发现有问题。

有些功能不好用，有些操作偶尔出错，

还有一些Bug，平时不一定出现，偏偏在关键时刻冒出来。

怎么办？

等更新。

一款软件的更新，往往像一次集中考试。

这段时间发现的问题，先记下来；

能够修的，尽量修；

修不完的，继续排队。

等到新版本发布，用户再下载安装，重新体验。

这种模式并不是完全没有道理。

桌面软件需要适配不同的操作系统、硬件环境和用户配置，

发布一个版本也需要投入成本。

但它确实有一个明显的问题。

用户发现问题的时间，与开发者解决问题的时间，往往隔着一段距离。

问题出现了，不一定马上解决。

解决方案有了，也不一定马上送到用户手里。

问题积累得越久，开发者越容易忘记最初的使用场景。

等到真正着手修复时，可能已经需要重新排查一遍。

保罗·格雷厄姆在《黑客与画家》中讨论互联网软件时，

特别强调了软件发布方式的变化。

互联网软件最大的变化之一，

就是它不再完全遵循传统桌面软件那套发布逻辑。

软件可以运行在服务器上，用户通过浏览器使用；

开发者修改服务端程序后，也可以更直接地将改动提供给用户。

过去，更新软件像是交付一件新商品。

现在，更新软件越来越像维护一项持续运行的服务。

当软件可以持续更新，

开发者就不必把所有改进都押在下一个大版本上。

一、互联网软件最重要的优势之一：Bug更容易被复现

做软件的人都知道，发现Bug并不一定是最麻烦的事情。

最麻烦的往往是：你知道它发生了，却不知道它为什么发生。

用户说：“这个功能不能用了。”

开发人员问：“怎么操作的？”

用户说：“就是正常操作啊。”

用户可能已经记不清楚了。

于是，客服反复询问，开发人员反复猜测，双方都觉得对方没有说清楚。

更麻烦的是，开发人员在自己的电脑上测试，怎么都无法复现问题。

用户那里确实出错了，但开发人员这里一切正常。

很现实的难题，问题发生的现场，往往没有完整地保留下来。

《黑客与画家》里有一个重要观点。

互联网软件能够复现大部分Bug，

而用户的数据保留在开发者可以管理的服务端环境中，为排查问题提供了便利。

不是简单地把数据放到网上，而是软件的运行方式发生了变化。

在传统桌面软件模式下，

用户使用的软件、文件和运行环境分散在各自的电脑里。

开发者想重现问题，可能需要用户提供文件、描述操作步骤，甚至远程协助检查。

在互联网软件模式下，开发者能够更集中地管理程序运行环境，

也更有机会通过日志、测试数据和问题记录重现故障。

当然，这不意味着所有Bug都能复现，也不意味着开发者应该随意查看用户的私人数据。

权限管理、隐私保护和数据安全仍然是必须考虑的问题。

以前，开发人员可能只能听用户描述故障。

现在，他们更有机会回到故障发生的过程，寻找真正的原因。

解决问题的前提，不只是有人告诉你出了问题，

而是你有能力看见问题究竟怎样发生。

很多事情都是如此，

管理者听员工说项目出了问题，

和亲自看到项目在哪个环节卡住，是两回事。

运营人员听用户说产品不好用，

和亲眼观察用户怎样操作，也是两回事。

信息传递得越多，原始场景就越容易丢失，

能够接近现场的人，往往更容易找到真正的原因。

二、客户支持不应该只是一个接投诉的部门

书里关于客户支持的讨论，我觉得尤其值得互联网公司管理者思考。

很多企业会把客户支持看作一项服务工作。

用户打电话过来，客服负责接待；

用户遇到问题，客服负责解释；

用户不满意，客服负责安抚。

从组织分工上看，这似乎很合理。

客服接触客户，开发人员负责写代码，各司其职。

但其中一个容易被忽视的问题。

当客户支持与开发工作分离得太彻底，

用户反馈就很难转化成组织的知识。

比如，用户报告了一个Bug。

客服记录下来，提交工单。

开发人员收到工单，开始排查。

修复完成以后，工单关闭。

从流程上看，事情已经解决了。

但如果这个Bug背后的原因没有被总结，

如果类似问题没有被归纳，

如果开发团队没有理解用户为什么会遇到这个问题，

那么这次支持工作就只解决了一个个案。

下次出现类似情况，大家可能还得从头来过。

更糟糕的是，有些公司会逐渐形成一种习惯：

客服负责处理用户的不满，开发人员尽可能少接触这些麻烦。

用户的抱怨成了客服的工作负担，

而不是开发团队改进产品的线索。

最后，客服越来越擅长解释问题，产品却不一定越来越好。

一个很重要的区别，

客服解决的是用户眼前的问题，

产品团队应该进一步解决产生问题的原因。

比如，用户反复询问某个功能怎么使用。

当然可以让客服写一份操作指南。

但还应该继续追问，

为什么用户总是在这里遇到困难？

是入口太隐蔽？

是命名让人误解？

是操作步骤太多？

还是产品的设计逻辑本来就不符合用户习惯？

如果问题来自产品设计，那么再优秀的客服，

也只能不断解释一个本来可以避免的问题。

这就像一家公司每天都有人在门口摔倒，

管理者可以安排一名员工专门扶人起来，

但真正应该做的事情，可能是把那块湿滑的地砖修好。

一个成熟的组织，不应该只奖励解决问题的人，

还应该鼓励那些让同类问题不再发生的人。

三、客户支持，其实是企业最容易忽视的知识入口

客户支持并不是产品研发的外围工作，

它是为企业理解真实需求的重要入口。

开发人员通常按照需求文档设计功能。

产品经理会通过调研、数据和业务目标确定产品方向，

但用户在真实场景中遇到的问题，可能完全超出原先的设想。

比如，用户不断要求增加某个功能，

表面上看，这是一个新需求，

但如果继续了解，可能会发现用户并不是真的需要这个功能，

只是现有产品无法让他方便地完成某项任务。

这时候，企业有两种选择。

一种是按照用户提出的要求增加功能。

另一种是继续追问：用户为什么需要它？他到底想完成什么？

前一种方式是在满足表面需求，

后一种方式是在寻找真实需求。

用户反馈不应该只是一个等待处理的列表，

它更像一批尚未加工的原始材料。

里面有抱怨，有误解，有重复操作，有失败记录，

也有用户自己都没有意识到的需求。

企业需要做的，不是把这些材料简单地处理完，

而是从中寻找反复出现的规律。

如果一百个用户在不同时间、不同场景下，

都在同一个地方遇到困难，

那么问题很可能不只是某个用户不会使用。

它可能暴露了产品设计中的系统性缺陷。

用户的真实行为，有时候比他们自己表达出来的需求更有参考价值。

客户支持能够带来的另一种价值，

它不仅帮助企业处理问题，

还能帮助企业发现自己原本没有意识到的问题。

四、软件更新越快，开发者越容易进入真正的工作状态

格雷厄姆还提到一个很有意思的观点。

能够即时发布软件，对开发者是一种巨大的激励。

我觉得，它触及了创造性工作中的一个心理问题。

做一件事情，最容易让人失去动力的情况之一，

就是长期看不到结果。

你花了一个月开发一个功能。

写代码、调试、修改、测试。

等到终于完成，还要等待版本发布。

版本发布以后，又要等待用户使用。

用户用了以后，还得等待反馈。

这中间隔着好几道门。

你做的事情和真实世界之间，距离很远，

而当发布周期缩短以后，情况就不一样了。

今天写了一段代码，今天就有机会看到它产生的效果。

今天修复一个问题，用户很快就可能感受到变化。

今天发布一个功能，很快就能观察真实用户如何使用它。

这种反馈会让开发者更直接地感受到自己的工作产生了什么影响。

工作成果越快进入真实世界，创造者就越容易建立起行动与结果之间的联系。

这并不只是软件开发的特点，做内容也一样。

如果一篇文章写完以后，半年才有机会发布，

发布后又没有任何反馈，那么创作者很难判断自己做得怎么样。

如果能够持续发布、观察读者反应、调整选题和表达方式，学习速度就会快得多。

创业也是如此，

一个产品从想法到上线，如果需要两年时间，

等到市场告诉你方向错了，付出的代价可能已经很大。

如果能先做出一个小版本，让真实用户试用，再根据反馈调整，很多错误就可以更早被发现。

所以，快速发布的真正价值，

它还缩短了一个重要的周期，是持续进步的基础。

五、即时发布，不是把所有Bug都直接扔给用户

不过，这里也需要区分一件事情。

快速发布，不等于不做测试。

持续更新，也不意味着每次修改都应该立即面向所有用户。

如果为了追求速度，跳过必要的验证，

把明显不稳定的功能交给用户承担后果，那不是高效，

而是把内部成本转嫁给外部。

真正值得学习的，是快速反馈的机制，

而不是盲目追求发布次数。

一个成熟的软件团队，可以先在小范围内验证新功能，

观察是否出现异常，再逐步扩大使用范围；

也可以保留回滚机制，在新版本出现问题时及时恢复。

这些做法的核心，不是让所有事情都变快，

而是尽可能缩短发现问题、理解问题和修复问题之间的距离。

有些事情需要慢，

比如涉及数据安全、资金交易和关键业务的修改，就需要足够谨慎。

但有些事情不应该慢，

比如一个已经明确、风险可控、修复方案经过验证的问题，

就没有必要因为等待下一次大型版本更新而拖延很久。

好的开发流程，不是永远追求最快，

而是让每一次修改都尽早接受真实世界的检验，同时把风险控制在合理范围内。

六、软件发布方式的变化，实际上改变了企业的组织方式

把前面几个观点放在一起，会发现互联网软件的变化并不局限于技术层面。

它还会反过来影响公司的组织结构。

传统软件的开发与发布周期比较长，企业很容易形成一种阶段性的工作方式。

先规划需求，再集中开发；

开发完成后统一测试；测试结束后发布版本；

发布之后再处理用户反馈。

每个环节有相对明确的边界，

这种方式有它适用的场景，但也容易让不同团队之间产生距离。

开发团队认为自己的任务是按时交付。

客服团队认为自己的任务是处理投诉。

产品团队认为自己的任务是整理需求。

至于用户最后有没有真正解决问题，可能需要经过多个部门才能得到答案。

互联网软件持续更新以后，这些边界就有机会重新调整。

开发人员能够更快看到用户反馈；

产品人员能够更快验证需求；

客服人员能够把高频问题反馈给产品团队；

数据分析人员能够更快观察改动产生的结果。

如果组织设计得合理，这些环节就能形成一个持续循环。

产品上线，不代表项目结束，

反而意味着新一轮学习开始。

企业真正需要建立的能力，不只是快速开发，

而是让信息在不同角色之间流动起来。

否则，即使更新速度再快，也可能只是在更快地重复犯错。

技术缩短了反馈周期，组织能不能利用这个周期，

决定了技术优势能否真正转化为竞争优势。

七、从软件开发到日常工作，我们都需要缩短反馈周期

我想到一个在工作中很常见的现象。

有些人特别喜欢做长期规划。

一个项目启动，先做完整方案。

方案反复讨论，细节不断补充。

等到所有人都觉得准备充分了，才开始执行。

最后发现，用户不买账，市场环境变了，或者最初的假设根本不成立。

还有一些人，做事情习惯先找一个最小的可行方案。

先验证关键假设，再根据结果调整。

两种方式各有适用场景，但在不确定性很高的事情上，

后一种方式通常更有机会降低试错成本。

因为你不必等到所有事情都想明白，才开始接触现实。

你可以让现实帮助你想明白。

这里最关键的不是“快”，而是反馈。

没有反馈的快速行动，只是更快地消耗资源。

有反馈的行动，才能逐渐提高判断质量。

我现在会特别关注一件事情。

从我做出一个决定，到我知道这个决定究竟对不对，中间隔了多久？

如果一个项目做了半年才知道方向错了，反馈周期就太长了。

如果一个运营方案执行一周就能观察到关键指标的变化，那么下一次调整就有了依据。

如果一篇文章发布后能够观察读者真正关注的内容，也就更容易发现自己的表达问题。

当然，短期反馈不一定代表长期价值。

阅读量、转化率等指标也可能受到偶然因素影响。

重要的是不能把单次反馈当成最终结论，

而应该持续积累证据。

无论如何，越早接触真实结果，通常就越有机会及时修正错误。

八、创造者真正需要的，是一个能够不断学习的系统

如果把这篇读书笔记压缩成一个简单的工作模型，我觉得可以分成四步。

第一步，尽快把想法变成可以验证的东西。

不要让想法长期停留在文档里。

第二步，让它进入真实使用场景。

只有接触真实用户、真实业务和真实环境，才能发现原先看不到的问题。

第三步，尽可能保留反馈。

用户怎么操作，哪里失败，为什么抱怨，哪些地方反复出现问题，都应该成为后续改进的依据。

第四步，把反馈转化为下一次行动。

不是每次都重新开始，而是把已经获得的经验沉淀下来，避免同类问题反复出现。

这四步连在一起，就是一个能够持续学习的系统。

软件如此，团队如此，个人成长也一样。

我们很容易把成长理解为不断增加知识。

读更多书，学更多技能，接触更多方法，

但如果学到的东西从来没有经过现实检验，它们可能只是储存在脑子里的信息。

真正的成长，是把知识带到现实中，接受反馈，再修正自己的判断。

从这个意义上说，互联网软件的持续发布机制，

给我们的启发不只是技术上的。

它提醒我们不要把一次交付当成终点，

不要把一次成功当成永远正确，

也不要把一次失败当成彻底否定。

真正重要的是，能不能持续从结果中学习。

结语：别把一次发布，当成一次毕业

我觉得《黑客与画家》里关于互联网软件发布方式的讨论，今天读起来特别自然。

我们早已习惯在线更新、云端服务和快速修复，

甚至很少有人会专门感叹，

原来软件可以不用每次都重新安装。

但在这些已经成为常识的事情背后，藏着一种值得重视的工作方式。

过去，软件开发容易被理解为一个阶段性的任务。

做完、测试、发布，然后进入下一个版本。

互联网软件让我们越来越清楚地看到，

一个产品真正进入用户生活之后，才开始接受最重要的检验。

用户怎么用它，哪里出了问题，哪些功能没有价值，

哪些需求被忽略，都需要在真实世界中慢慢发现。

发布不是结束，它是反馈的开始。

所以，无论是开发软件、做产品、写文章，

还是经营一家企业，我觉得都可以问自己一个问题。

我现在做的事情，有没有一条足够短的反馈路径？

如果没有，我是不是正在花很长时间，反复打磨一个未经验证的假设？

如果有，我又有没有认真听取反馈，并把它转化成真正的改进？

技术会继续变化。

软件的形态会变，发布方式会变，用户与产品之间的关系也会变。

但有一件事始终值得坚持，

不要只追求把东西做出来，

还要尽可能让它早点进入真实世界，

再根据真实世界的反应继续改进。

因为真正优秀的产品，

不是某一天突然完美的，

而是在一次又一次的发布、观察、修复和调整中，逐渐变好的。

欢迎点赞、转发、评论。

我是吴大爷，夜风同学

愿一路陪你共同成长！