软件开发中的理性和感性决定喜羊羊与灰太狼:羊守7遨游神秘洋将登场,四个神秘岛屿等待解锁

2023-06-02 0 780

软件开发中的理性和感性决定喜羊羊与灰太狼:羊守7遨游神秘洋将登场,四个神秘岛屿等待解锁
作者 | 邹欣 责编 | 梦依丹出品 | CSDN(ID:CSDNnews)

问题

欢,还有更少的用户为之付钱。我们在商言商,怎么能让更多的人付钱使用我们的产品呢?用户的决定是怎么做的呢,我们有什么办法来影响用户的决定呢?搞软件看似高大上,其实还是有很多规律的。我们知道:

程序 = 算法+数据结构

软件 = 程序 + 软件工程

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

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

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

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

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

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

我的理解

“用户场景能满足需求”, 到 “研发团队的效率和成本“,到 “大量用户愿意成为长期付费用户”, 这些过程中,我和我的小伙伴们不断地做各种决定,开发出产品和服务,然后希望用户也做决定,成为我们的高兴的用户,能留存的用户,直至长期付费用户 … 每一步都有很多决定要做, 在这么多决定中,哪些是感性在主导,哪些是理性在主导呢?这篇博客,就谈这个问题。讲讲我自己的经历,和看过的别人的经历 – 这篇博客应该是感性的。

这个问题并不是只有在软件行业才存在, 经济学中的 “行为经济学” 也研究人在经济活动中的决定是怎么做的。我最近听了几个 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,但是要放到产品上,“维护成本” 非常高。因为:

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

我们的算法要快速处理这些图片+视频,抽取特征 (CPU intensive) –

要把抽取出来的特征(一个向量,或者就是一些 100101010101011)放到内存中(memeoy intensive)-

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

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

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

这在大数据服务中,是比较常见的现象,我们当然要为高频的服务优化,谷歌也有 “牙刷(每天要用两次)标准”, 要看这需求的使用频率是否够高,是否值得用各种成本(特别是维护成本)来支撑这个功能。如果类似的事情发生在 CSDN, 我们要花费很多维护成本来做一个低频的功能 (例如用 OCR 扫描所有截屏,抽取其中代码,给用户使用),大家也会用数据分析用户获益/成本,我觉得这是非常理性的做法。

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

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

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

在网上流传一句非常广的话 百分之八十的用户只使用 Office 软件的百分之二十的功能,这的确是如此。但是,这个 ”观察到的现象“ 并不说明 因果关系, 不同的产品在竞争的不同阶段,有不同的重点。在下图的 “成长阶段”, 大部分软件都处于 “猛烈的功能军备竞赛” 的阶段,大家不断拓展软件能解决问题的范围,和易用性。

软件开发中的理性和感性决定喜羊羊与灰太狼:羊守7遨游神秘洋将登场,四个神秘岛屿等待解锁

我用 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 的努力和时间来消除。

软件开发中的理性和感性决定喜羊羊与灰太狼:羊守7遨游神秘洋将登场,四个神秘岛屿等待解锁

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

一个软件产品从小到大,从几个用户,到几万个,几百万个用户,我们当然要看很多因素,当你有上百万人都在有 PV,这个软件应该很可以了吧?再出问题,再不爽,也是万分之一,要重视么?要修复么?

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

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

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

经过二十多个星期每次连麦 + 报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 解释这样做的原因:

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

如果我们这几十人,全球分布的团队可以用 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

软件开发中的理性和感性决定喜羊羊与灰太狼:羊守7遨游神秘洋将登场,四个神秘岛屿等待解锁

相关文章

发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务