作者 | 邹欣 责编 | 梦依丹

出品 | CSDN（ID：CSDNnews）

问题

CSDN 这个 “软件” （网站

，app
，开发云、猿如意、插件、公众号等）在过去的很多年中
，有很多用户使用
，也有不少用户喜欢
，还有更少的用户为之付钱
。我们在商言商，怎么能让更多的人付钱使用我们的产品呢
？用户的决定是怎么做的呢，我们有什么办法来影响用户的决定呢

？搞软件看似高大上，其实还是有很多规律的
。我们知道：

• 程序 = 算法 数据结构

• 软件 = 程序 软件工程

• 软件企业 = 软件 商业模式

在充分竞争的环境中，一个软件企业要生存发展，和美食一条街的一个小饭馆要生存发展类似，街上人流熙熙攘攘，他们对于一个小饭馆的态度不外乎是下面这个区间之内：

给我钱我也不去吃 … 如果免费，可以尝尝 … 看价格和就餐环境 … 很信任的品牌，有需要就吃 … 即使排队、涨价也要去吃

有人说 CSDN 比小饭馆高大上多了，它是一个有无限可能的平台！好
，我们不妨用 “综合商城” 来比喻
，如何？

给我钱我也不去，那里坏人多 … 那里没啥有意思的 … 免费逛逛，期待不要太高 … 有几个有意思的店但是环境太差 … 以前去过
，后来有其他更好的商城就不去了 … 交钱办了会员，经常去那里的广场跳舞
，吃饭看电影，很多优惠

大家在做这些决定的时候，是理性还是感性的呢？最近有一个做教育的团队不得不改行网上卖货了，结果买的人特别多，这些购买者
，是做了理性还是感性的决定呢
？

我的理解

在我的职业生涯中，我作为一个程序员，研发经理，到现在的 CSDN 职位，我越来越多的关注焦点，从具体的 “我的代码能编译”， “快速解决 bug”， 到 “软件能按时上线”， 到 “用户场景能满足需求”， 到 “研发团队的效率和成本“
，到 “大量用户愿意成为长期付费用户”
， 这些过程中，我和我的小伙伴们不断地做各种决定
，开发出产品和服务
，然后希望用户也做决定，成为我们的高兴的用户，能留存的用户
，直至长期付费用户 … 每一步都有很多决定要做， 在这么多决定中，哪些是感性在主导
，哪些是理性在主导呢
？这篇博客
，就谈这个问题

。讲讲我自己的经历，和看过的别人的经历 – 这篇博客应该是感性的
。

这个问题并不是只有在软件行业才存在， 经济学中的 “行为经济学” 也研究人在经济活动中的决定是怎么做的

。我最近听了几个 Podcast （FreakOnomics）
，谈行为经济学
，刚好把我以前读过的书和一些经历串联起来了
，有些洞察和感想。这些感想我以前也有过，但是没有写下来，就淡忘了
，后来又犯了同样的错误
。我觉得应该写下文字，而且是公开的文字，让自己加深印象。大家工作都很忙
，哪有时间啊
？但是，我觉得
，强迫自己 “闲下来写笔记”
，还是有更好的长期回报的。我的前一篇博客也提到了 “思考，快与慢”，下面再来一句鸡汤：

闲是灵感的源泉

，忙是思维的坟墓。

欢迎大家在评论区闲聊交流一下

。

理性和感性

我们做软件开发，软件方面的创新
，也有理性和感性的部分存在， 很多人以为
，IT 界的创新和采用，大概率是理性的决定吧，其实也未必。

（一）美国硅谷有一个非常有名的研究院
， Xerox Parc，1970-1980 年代，它一度孵化了很多颠覆性的 IT 技术，把这些技术集成起来，就是一个现代化的办公自动化系统 – PC，图形界面，所见即所得的编辑器，局域网


。但是
，它向各大公司推广这一套创新的时候
，这些潜在的顾客并不买账。虽然有很多数据显示这一套系统能大大节约成本，顾客中做决定的人（公司里的大老板，负责 IT 采购的人，那时候还没有流行 CIO 这个头衔）事实上在做一个感性的决定：如果我冒险用了这个系统，而不是 IBM 系统，我会失去什么
？结果

，是这个感性的决定
，让这个先行者失去了很多顾客
。事实上

，XeroxParc 的母公司在东海岸的老板，也是用感性驱动做了决定（“这些西海岸的研究员在胡闹什么？我不懂也不想让他们再胡搞了”）。直到 IBM 推出了 IBM PC

，PC 的浪潮才真正掀起。

（二）我在微软公司的时候，曾经花了两年的时间来推动一件事情 – 在最新的 Windows 系统中推出某个重要改进。这对于简体中文版的 Windows 在用户中的价值是很重要的
。当然，在微软这样伟大的公司
，要说服决策者做这样的决定，还是需要很多工作，其中就有各种数据的支持。我们做了很多轮的实验的设计和数据收集工作，总部还有另外的团队独立来中国收集数据
。我们也做了很多代码的改进
，测试，等等。经过很多次小的讨论，我们终于和决策者开会了
！在会上我展示了很多数据，从各个角度展现，这个改动是有很好的短期和长期的收益的。

但是在我展示这些数据和理性推导的时候
，总部的一个决策者提出：

哎，你这个方面的数据说有 20% 的提高，但是我认为你们做调查的方式不科学吧，数据可信么？

哦
，这个方面的数据，说有总共 12% 的提高，那说明这个项目的收益并不高啊

，我们一定要继续推动么？

我正在想如何反驳 – 因为整个中国市场
，12% 的提高也是很巨大的啊，怎么就是不高呢
？难道Windows 在过去几年中曾有达到 12% 提高的改进么？这时候，一个来自第三方团队的资深的经理说话了：

当这个数据显示改进很大的时候，你说数据不可信
，当这个数据显示改进并不是很大的时候

，你就认为这个数据是可信的
。你不就是铁了心不想要通过这个项目么？

这两位当时脸都涨红了，会议也陷入了沉默

。他的话
，像皇帝的新装里面的小男孩那样
，童言无忌
，指出了决策者并没有什么“理性决策”
，而是一个感性的 “老子就是不愿让这个项目落地
！”

（三）在大厂的环境中工作，很多情况下，是要说服别人同意你去做某事，一次我们要说服某 VP 同意某个提案，在和总监级别的大佬沟通的时候
，他说， 你们的 PPT
，摆事实，讲道理，列数据
，很干巴巴的
，这样的提案 VP 每天要读好几个
，你们要把这个利害关系转化为这个 VP 有 visceral 感受的点
！

啊？啥是 visceral？哦，原来他借用了 Don Norman 的设计的三个层次的术语
。

就是要让被别人感到一种 本能/visceral 的反应 – 我的内心直觉就需要这个，我也说不清！

类似的描述还有：眼前一亮，内心柔软的部分被触动了，等等…

（四）用数据驱动的方式来分析问题，提出假设，再快速验证
，这是很多人推崇的方法，特别是 Money Ball 这本书畅销之后
。我也接受过这样的培训，还带队参加了更多的培训
。我认为总的来看
，这是有好处的
，但是在具体的情况下
，未必
。

我们的一次实战产品设计中
，产品经理想出了一个自认为好的点子

，做了很多准备
，然后我们请了一批符合条件的目标用户来接受访谈
，几个人在采访室和用户聊，几个人通过闭路电视观察。其中的一次采访
， 产品经理充满激情地向受访者描述了使用场景，最后问：你愿意用这个功能么？两个受访者都频频点头。产品经理就笔记本上数据的那个格子中打了✅，高兴地离开了采访室。我们几个在闭路电视中看到，产品经理离开后
，两位用户互相望了一眼，都摇了摇头笑笑，也很快收拾东西离开了

。

那么这个产品的点子，从理性的角度
，得到了用户明确的首肯，但是从用户的肢体语言来看，用户根本就不理解，在产品经理热情的宣讲下，出于礼貌，回应了感性的点头，可能心想 – 快让老子回家吧
。我们仔细分析那个产品经理的提案，充满了内部的术语，用户很难理解他在说什么。

在上面的几个例子中
，理性地说服对方同意你的销售（产品/提案），都不太成功，为什么呢？因为每个人在面对一个产品/提案的时候，他内心的核心问题是 — 我能从中得到什么？我会失去什么
？

（一）在很长的时间里
，美国的 IT 部门，购买 IBM 等少数几个大厂的服务
，才是安全的
，我为何要冒险去支持一个第一代的颠覆式产品？

（二）这位决策者，在一年多前在日本推出了一个类似的改进，被当地的用户狠狠吐槽，作为不懂日文，也不懂中文的决策者，他心里想什么
？

（三）这位 VP 心里扛的是巨大的成本和收益的 KPI，我们的提案，讲了很多技术方面的数据，微软的产品缺技术么
？他心里 visceral 层次上
，什么能打动他？我们能直接表达出这个意思么？

（四）一个产品提案，在数据上获得了 100% 用户的同意，但是用户是真的被说服了，还是出于感性的角度点了点头
？产品经理有工资，只要做了提案，不管最后如何
，做了就好。被采访的用户，公司会给他们几百块钱的礼物前来接受采访，只要点点头

，摇摇头，就可以兑现礼物回家了。这个产品经理后来也把这个提案扔下不管了，那么，他和被采访的目标用户，谁是真的在乎这个使用场景么？

我参与了很多类似的产品提案讨论会，有一次在一个类似的会议上，一位大佬问一个热情播放PPT 的研究员：你真的相信你描述的这个未来么
？如果你真的相信

，你就去马上去做，不必列很多理由的！

从感性的角度，我们可以把一个团队的成员比作 “猪
、鸡、鹦鹉”
，他们合作开早餐店，他们都有想把产品做好的感性愿望，但是每个人的具体投入是不一样的
：

猪：割自己身上的肉来做培根

鸡
：每天贡献一个鸡蛋

鹦鹉：把别处听来的消息给团队转发一遍

你是一个决策者

，你更重视谁的提案呢？

一个功能的成本

每一个功能，都是有成本的：

• 设计、实现成本

• 用户教育、习惯培养成本
  、打扰用户的成本

• 维护成本

• 以后要下线这个功能，还有很多其他成本

我以前在某研究院工作，和研究员一起做了一些创新性的图像特征提取的尝试，发现我们的提取的特征可以大大提高某种类型图像搜索的准确性
。于是我们和搜索引擎团队联系
，看看怎么把这个激动人心的特征放在搜索引擎上
。对方的工程告诉我们

，这个特定领域的图像搜索
，虽然不是少数（不妨想象为搜索 “狗的类型”），但是和搜索引擎的主要图像搜索类型相比
，就小两个数量级
，和文字搜索相比
，又小了一个数量级

，因此，这个研究突破虽然很 excited，但是要放到产品上
，“维护成本” 非常高。因为：

每天有海量的图片 视频进入搜索引擎，我们的工作流程是：

1. 我们的算法要快速处理这些图片 视频，抽取特征 （CPU intensive） –

2. 要把抽取出来的特征（一个向量，或者就是一些 100101010101011）放到内存中（memeoy intensive）-

3. 要保证搜索的检索速度不会变慢（因为99% 的搜索和 “小狗类型” 无关）

4. 这样，那些为数不少，但是占总量 （1%）的对“小狗类型” 感兴趣对用户会发现，这个搜索引擎太厉害了，太方便了，我要用它做默认的搜索工具！

在这个架构下
，每天，公司在全球的机房中的一些CPU，内存就会分配来做上面的这些事情。后来我们的工程师花了大量的时间来改进抽取特征的速度
，用更少的字节来表示抽取特征，直到我换到别的团队，他们都还没有能达到产品组的要求，后来似乎不了了之了。

这在大数据服务中，是比较常见的现象，我们当然要为高频的服务优化，谷歌也有 “牙刷（每天要用两次）标准”， 要看这需求的使用频率是否够高

，是否值得用各种成本（特别是维护成本）来支撑这个功能。如果类似的事情发生在 CSDN， 我们要花费很多维护成本来做一个低频的功能 （例如用 OCR 扫描所有截屏，抽取其中代码，给用户使用），大家也会用数据分析用户获益/成本
，我觉得这是非常理性的做法
。

互联网大数据服务型企业的竞争，拼到最后，就是拼算法，效率，成本。

但是，还有一些功能
，就是在某页面加一个链接，指向用户可能使用的下一个功能，这并没有什么成本，这个我们能快速上线么
？还有一个办法
，直接问用户他们的选择。

80/20 规律能支持我们砍掉用得少的功能么
？

在网上流传一句非常广的话 百分之八十的用户只使用 Office 软件的百分之二十的功能，这的确是如此。但是，这个 ”观察到的现象“ 并不说明 因果关系

， 不同的产品在竞争的不同阶段

，有不同的重点。在下图的 “成长阶段”， 大部分软件都处于 “猛烈的功能军备竞赛” 的阶段
，大家不断拓展软件能解决问题的范围，和易用性。

我用 MS Word 写了 4 本书，其中的 3 本书，是我用 Word 手动输入并修改的
。我应该算是一个重度文字写作的用户，但是我的确在 80% 的时间里
，只用其中的很少功能
，可能 10%

，但是我认为很有必要的一两个功能，是别人很少用的，别的编辑器也没有
，只有 Word 有这些（而且以我习惯的方式）。所以
，每个用户长尾有自己的长尾需求，一个面向百万用户的 App 就要提供那些长尾功能，挑战是要 “容易找到，确定性的交付” 这些体验

。

我加入 MS Office 团队的时候 （1996）
，那个时候 Office 传统的 App 如 Word，Excel 的确已经有很多功能了，那时候就有这个 80/20 的说法，我们内部也流传自黑的各种笑话

。还有进一步的数据说明，很多用户向 Word/Excel 团队提出的 “新功能建议” 大部分都是 Word/Excel 已经有的，深入分析发现，用户的痛点在于，面对众多的选择，他不知道他想要的功能藏在那个菜单和子菜单下面
。“容易发现功能” 成为一个巨大的挑战

。那个时候 Office 就开始建立数据采集的平台，根据数据， Office 还尝试了一个创新 – 在显示菜单的时候，先隐藏那些点击率低的项目
，过了两秒钟左右，再来一个动画渐变，显示全部菜单项目。当时的项目经理想，大部分时间用户都是用那些最常用的，这样就替用户节约时间了
。不料这个功能推出以后被骂死，因为

1）很多用户期待的是一个确定性
，“我知道那个菜单项就在第四个，你不要把它提前到第二个，过两秒又改回到第四个！“

2）用户想找不常用功能的时候，更迷惑了
。

在UX 设计的时候，一个用户场景 （scenario / story）的各个菜单
，最好是达到 “don’t make me think” 的状态
， 就安静地排列在那里，让用户习惯，这又怎么了？我们非要焦虑到每三个月改版一次
，把 “blink” 改为 ”微社区“，然后又去掉 “微社区”，改回 “动态”， 位置从上挪到下方正中的圆圈
，然后再挪到上面的另一个位置才显得我们做了事情么
？与此同时那些真正影响用户体验的各种问题，我们的研发，产品，运营每天用我们自己产品的时候（如果用自己的产品的话），注意到这些问题了么？用户反馈读吗？转成 Jira 了吗
？改正后告知用户了么？产品经理、研发带头人写这些bug 产生的模式分析么？

核心是让那些不常用的功能以一种自然的方式容易找到，而不是把它们从 UI 中删除。如果 Office 软件把它菜单中 最不常用 的 20% 从老地方删除
，然后挪到 “Office” – “其他” – “不常用功能” – “这里”
， 用户会出现什么反应呢？

我非常支持系统化地收集数据，系统化地看如何优化用户体验
，改进质量，这里面有需要长期工作才能解决的，有短期工作就能解决的
，有的并不太核心，有的可以做种实验
，有些 bug 也不是一定要连夜修复，但是 团队的 “北极星” 指标还是对齐：CSDN 的 blink/动态 是让用户方便地随时随地交流 – 每天都有值得看的动态
。

80/20 规律有时会给人带来不一样的思路
， 有些是有趣的，有些对公司发展是有害的。我刚来 CSDN 的时候，听到这样的数据和观点
：80 % 的搜索都是命中了 CSDN 前几年的博客，就是说，即使没有这两年的新博客
，我们还能有 80% 的收入

。我认为这是一个幻觉， 如果大家知道已经没有人在 CSDN 写博客了， 你看看用户还会来 CSDN 么！当新的内容和内容创作者离开 CSDN 的时候
，他们是一个一个离开的，这数量虽然少，但是是非常危险的信号。我们要不断提高用户体验
，让 CSDN 的创作飞轮转起来
：

CSDN 有值得创作的话题 → 创作的工具很好用 → 创作后有真实的互动和流量 → 优秀创作者获得名和利的回报。

不正确的 KPI 对一个产品的影响

每个成员感性思考讨论之后，大家的意见会凝聚为一个产品的 KPI，这是理性讨论的结果。

从我自身的观察
，很多大型的产品的衰败，是从使用率不高的功能的命运体现出来的
。曾经一度 MSN messenger 和 Windows Live Space 是两款很不错的产品
，一个是好友通信
，一个是个人博客
。它们一度有一个很好的功能：你的好友更新了他的space，那么他的MSN 聊天头像旁边就有一个小黄花出现
，你点击后就可以看到这个好友的最新博客或者照片了。挺好的一个小功能。但是在一次改版后
，这个功能就没有了。

我在微软研究院的时候，和 MSN 的团队打过几次交道，livespace 的团队倒没有，但是从类似的经历中，我可以想象出， livespace 的KPI 包括了 PV，如果有两种方式：

a）用户遍历他的所有好友的页面
，看有没有更新

b）用户在另一个app上，只要看到了好友的更新，才来看网页

哪个对 PV 的 KPI 有利呢
？

很多小功能就是在一些大功能的接缝处，帮用户节约时间和步骤
，例如上面的那朵小黄花。但是，不正确的 KPI
，往往统计的是 input metrics，或者过程性的metrics （页面 PV，搜索次数）

，这些指标当然有价值，但未必是 “用户满意度”
。就这样，用户喜欢的小功能都慢慢没有了
， 因为资源要投在 “大流量” 的地方， 用户越不来，产品经理就用越露骨的方法来拉用户
，用户的满意度并没有提高，后来
，Windows livespace 和 MSN 都没有了
，当时微软还提出
，用户可以多按几个按钮，转移到 WordPress 和 Skype，我也转移了，但是照片和很多联系人都丢失了 … …

后来我和同事们闲聊

，有两个同事在不同的场合都说
， 看到 MSN 的联系人头像旁浮现了小黄花，是我一天中最愉悦的时刻，微软的产品经理脑子装了什么，要把这种愉悦的体验删除呢？见不得用户用软件顺手么
？

网上也有评论
：https://www.zhihu.com/question/299685950 一个公司要发展，当然要做各种决定，例如为了成本砍掉一些服务，停止维护一些服务
，等
。但是我们要考虑的是，后续的收益是什么？是为了满足哪个 KPI 呢？

我们运营的是开发者的平台，我们也有海量的内容，如果简单的 ”海量内容“ 是我们的 KPI 的话，我们经常达到

，有时还超额了。但是，用户真正关心的是 “高质量
，确定性，能解决问题的内容”
。

如果追求错误的 KPI
， 我们会短期达到这些 KPI
，但是它们的负面影响很难消除。

我们过份把用户 “物化” 为数据
，把他们当作实现我们短期 KPI 的 “物料”
， 用户也会弃 CSDN 如敝履，在知乎，头条上看看用户对 CSDN 对评价，这可能是 20% 不满的用户发出的
，可能是过去的印象， 甚至是别有用心的用户发的，但是这些信息说明了很多问题。这是我们客服特地说明的这些已经纠正的 “老印象”
， 理性地说，我们解决了这些问题，用户应该马上抛弃他们的旧印象
，但是，感性地说
，人并不是这样思考和做决定的。这些坏印象，可能要花 10X 的努力和时间来消除
。

一些小众场景要修复么？一个软件如何提高它的质量

一个软件产品从小到大，从几个用户，到几万个
，几百万个用户，我们当然要看很多因素
，当你有上百万人都在有 PV

，这个软件应该很可以了吧？再出问题，再不爽，也是万分之一，要重视么？要修复么
？

大家觉得我们的App 直播连麦功能如何？早已经上线了，应该是 “足够好”
，对吧？我原来也是这么认为的。2021/11/25， 我开始第一次实际主持 1 小时的 “直达CSDN” 连麦活动
，第一次连麦就出现几个小 bug：

以后每周四晚上
，我或者王路敏每次连麦都有新的 bug 出现
，一次编辑部主持了一次和几个专家的连麦
，使用某种版本的安卓手机的专家干脆就说不了话，这是比较尴尬的。那么我们怎么熬过来的呢？

产品经理
，研发组长，研发总监每周四晚上出 bug 后都分析log
，找到核心原因，快速解决，快速发版。（这里要鸣谢我们的 mobiles 研发大牛：瑞瑞）

经过二十多个星期每次连麦 报bug 修复bug 上线，终于有一天晚上 9 点钟，我们结束了一个小时的连麦后
，意识到今天一个 bug 都没有出现。这个 0-bug 时刻
，就这样达到了。

最近的连麦还有几个小bug 出现

，但是严重程度比最初已经轻很多了
。这个时候，才是一种有信心的 “足够好”。

blink 在它的发展过程中
，也有用户开始用它的 “使用率低“ 的功能， 有一次我们 top10 用户说要在 blink 帖一个他做俯卧撑的视频，搞了半天
，就是贴不上。他的前一个帖子获得了 700 个评论，但是自从这次视频bug 之后
，我看他就隐退了。有一次另一个重要用户要亲自在 blink 发帖子，庆祝一个重要日子

，帖子带几个图片

，但是死活发不出，我们研发连夜 debug，终于解决了

，但是这个日子也过去了
，用户也没有发帖子
。这些万分之一的用户不爽之后，即使她是 top 用户
，top 员工
，要让他们再回来，也是非常难的
。这些人走了之后
，他们再也不会出现在我们的数据报表中了，无论我们如何埋点
，如何分析。

在我职业生涯中，我过得还是比较顺的，最不顺的一段时间是 2005 年，我在 Brian Harry 领导下要开发下一代的软件项目管理系统 （TFS
，是VS online 的前身）
。Brian Harry 早年开发了 Visual Source Safe，是一个比较简单的源代码管理软件
。类似 TFS 的项目做了一次，失败了，这是第二次努力，而且是用全新的 .Net 框架来写的
， 我们当时用还是内测版的 C# 语言
，内测版的 CLR 框架，内测版的 SQL Server，开发我们项目管理系统，不用说，bug 非常多

。有一天 Brian 说，我们的产品可以跑了，我们就用这个版本来管理我们现在的项目。大家非常不满

，说我们知道现在 bug 多
，速度慢
，但是这些都会修复，我们目前用内部的老系统来管理不是很好么
？他坚持。于是就出现了：

我用最新版本的 TFS 报 bug：「TFS 在保存带附件的 bug 的时候崩溃」
， 果不其然
，在我填好数据
，上传了附件

，要保存的时候
，TFS 崩溃了。bug 也没保存上

。

怎么办
？只好连夜修复
，第二天用新版
。那一段时间我每天都加班到深夜
，Brian 带了部分团队在远程工作，他有时直接打电话来找人谈 bug，态度也很严厉。团队中有不少人都换组了
， 因为微软这个伟大的公司，压力小而且管理友善的团队多得很，大家都可以自由换组。Brian 解释这样做的原因：

1. 真正用我们的产品
   ，我们的代码要在实际使用中反复使用

2. 如果我们这几十人，全球分布的团队可以用 TFS 把我们的复杂项目管理好，我们才可以有信心把它卖给其他公司
   。

TFS 后来发布了，反响还不错
。我也离开那个团队
。微软有系统化的员工反馈系统
，一度每个员工都可以查任何经理的业务目标和团队反馈数据。几年后我查了一下 Brian 的数据，他的员工反馈有一条 “希望团队文化更加包容 …”，我就笑了。

CSDN 要做一流的开发者的平台，成就一亿人，这一亿人就会带了很多 “小众” 场景，我们的产品也很丰富，一亿用户的需求也多种多样，我们自己也是 IT 人，我们平时用自己的产品么？写博客用到所有博客编辑器的 20% 还是 80% 的功能么

？它们好用么？每一个给我们发帖发微信反馈 bug 的用户，他身后都有 100 个碰到同样的 bug 但是懒得告诉 CSDN，逐渐不用我们产品的用户，就像发 blink 遇到 “小众” 的 bug 的用户那样。我们对于这些纷纷扰扰，千头万绪的需求，bug，KPI
，是如何设定优先级，如何处理的呢？

CSDN 是一个公司，每个人对于这个公司的目标要投入多少，自然是不一样的 （可以看猪、鸡
、鹦鹉的故事）。离我 2005 年加班的时间又过了 17 年，经历了很多的项目和形形色色的人， 我自己也看了很多的埋点
，数据，用户体验报告，和很多这样的同事共事过
。还也看了很多软件工程、创业的书
。我现在非常理解 Brian Harry 了
。要把一件事请做成功，很重要的方面是要做 Hard 的选择
，坚持解决 Hard 的问题。太包容，善良，有时 hard 的问题就主动找上来，例如发工资的钱不够了
。

有些问题虽然表面上是小问题
，但是这个小问题能出现，反映了团队的大问题
，我们一起分析和解决这些大大小小的 hard 的问题吧

。感性和理性，都在不同的阶段非常需要。

参考资料
：

我以前读过关于 XeroxParc 的两本书：

• Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age

• “玩闪电的牛人们” … 施乐公司PARC 研究院的故事
  ，可歌可泣可叹
  。1970

原文链接
：https://blog.csdn.net/SoftwareTeacher/article/details/128638754