极客与团队

前言

2015-05-08 01:03:39

我们把 Subversion移植到 Google的 BigTable架构上，并以Google Code为名发布了一项开源项目托管的服务（类似于 SourceForge）。

注: 
偶遇贵人

2015-05-08 01:06:44

“人基本上就是由一大堆间歇性bug组成的”

第一章 天才程序员的传说

2015-05-08 01:09:20

没有人是完美的，但是在给同事挑错之前，你得先知道自己的毛病。
我们希望你想想自己的反应、行为和态度——
或许你可以从中得到一些心得体会，从而变成一名更成功、
更高效的软件工程师。在处理人际关系的问题上花的精力越少，
你就有越多的时间编写漂亮的代码。

天才的传说

2015-05-08 01:12:23

要小心自己本能地去崇拜事物

2015-05-08 01:13:48

从内心深处来讲我们都默默地希望自己是天才。
极客的终极梦想就是得到一个激动人心的灵感，
然后闭关数周甚至数月将它完美地实现出来，
最后向全世界发布自己的作品，名动天下。
同行们会折服于你的聪明才智，人们会排着队来买你的软件，
名望和财富更是唾手可得。

不好意思先等一下：醒醒吧，你很可能不是什么天才。

隐瞒是有害的

2015-05-08 01:14:56

隐瞒是有害的

假如你一直都是单打独斗的话，你其实是增加了自己失败的风险，
而且浪费了自己成长的可能性。

2015-05-08 01:16:01

“确保失败尽早发生，尽快发生，经常发生”

2015-05-08 01:21:05

你要如何通过反馈来发现自己的计划和设计中需要修改的地方？
答案是：团队合作。埃里克·雷蒙说过，“只要有足够多双眼睛，
就能发现所有的bug，”而更好的说法是，“
足够多双眼睛可以确保你的项目保持正确的方向。”
闭门造车的结果往往是当实现最初的创意后，
却发现世界已经完全改变，原本的产品已经失去意义了。

团队才是王道

2015-05-08 08:30:02

一个人躲在自己小黑屋里抖聪明是没用的。
光靠自己神神秘秘地搞创造发明是不可能改变世界，
令千百万用户受益的。你需要合作，告诉别人你的想法，
让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。

三支柱

2015-05-08 08:30:25

没有人是宇宙中心。谁也不是万能的，谁都会犯错。
你必须不断地提高自己。

尊重

你必须真心实意地关心同事。他们都是活生生的人，
他们的能力和成绩都需要得到肯定。

信任

要相信别人的能力和判断力，在适当的时候懂得放权5。

2015-05-08 08:34:05

不要低估社交的力量。社交不是勾心斗角，或是操纵别人，
它是通过建立起人与人之间的关系来把事情做成功，
而且这种关系延续的时间肯定比项目本身更长。

HRT实战

2015-05-08 08:35:54

通过使用系统并研究如何让系统帮你做事，你就学会了调整系统，
让它按照你的意愿工作。不然的话，
你就得终其一生去和这种潜规则作斗争。

2015-05-08 08:37:55

别把你的自尊和你的代码等同起来

2015-05-08 08:39:05

讨论的范围被限定在代码上，
没有涉及任何人的价值观或是编程技术。

2015-05-08 08:40:22

把不完美的软件展示给用户是可以接受的，另外还需要一些信任，
即用户真的会认同你的努力，并且期望迅速看到改进。

2015-05-08 08:41:19

从错误中学习的诀窍是要记住自己摔倒的地方，
按商业用语来说就是“事后检讨”。但是要特别小心，
千万不能把事后检讨的文件变成一堆无用的道歉和借口——
这不是它的目的。真正的事后检讨应该包含有关“学到了什么”
以及“怎么改正”等经验教训的详细注解。
然后要保证把它放在一个随手可及的地方，
并且认认真真地按照上面所写来实施改进。记住，
正确地记录错误还能让其他人（不管现在还是将来）
方便地了解事情的原委，以避免重复历史。不要抹掉自己的足迹——
像跑道一样点亮它们，为后来人指路吧！

2015-05-08 08:41:36

一份出色的事后检讨应该包含以下内容：

? 简要

? 事件的时间线，从发现到调查，再到最终结果

? 事件发生的主因

? 影响和损失评估

? 立即修正问题的步骤

? 防止事件再次发生的步骤

? 得到的教训

2015-05-08 08:42:47

为学习预留时间

2015-05-08 08:42:35

我们来分析一下：成为人群中最睿智的人的确很让人高兴，
而且能够指导别人绝对可以带来了不起的成就感。
但是问题在于一旦攀至顶峰，人们往往就会停止学习了。
而当一个人不再学习的时候，她就会开始觉得厌倦，
一不小心还会变得落伍。虽然当领导很过瘾，
但是只要能放下一点骄傲，你就能开阔眼界，接触新鲜事物。
这说穿了其实还是谦逊的问题和是不是愿意像指导别人一样接受别人
的指导。偶尔应该跳出自己的舒适区，
在更大的舞台上接受各种挑战。这样你才能长久地保持愉快的心情。

2015-05-08 08:44:07

你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮。

2015-05-08 08:44:56

承认自己犯错或是无知从长远来讲其实能提升你的形象。
事实上它蕴含了HRT的全部方面：它对外表示了“谦虚”，
这是有责任心、负责的态度，这也是表示“信任”别人意见的态度，
同时作为回报，别人也会因为你的诚实和坚强而“尊重”你。
所以有时候最好的答案就是：“我不知道。”

为什么要关心它

2015-05-08 08:50:05

简单来说，关心团队文化的原因就在于如果不努力营造它，
那么团队最终会因为某个特别强势的人的出现而被注入他个人的文化
基因。这种文化或许是生产力强劲的健康文化，
能产出大量的优秀代码。但事实往往相反，
你会突然发现自己在争执和争斗中浪费了太多精力，
没有办法集中精神去设计和编写代码。不仅如此，
团队拥有一个共同的价值观并愿意为之奋斗是非常重要的事情。
要是团队不在意自身的团队文化，
那么不仅构建强烈的团队认同感以及对自身工作的骄傲感会变得十分
困难，而且会很容易受新人影响而引入糟粕。

2015-05-08 08:51:13

所谓“强壮的文化”，是指能接受有益的改进，
同时又能抵御有害的激进变化的团队文化。
最成功的团队文化都把大部分的注意力放在了开发优秀软件上面。

2015-05-08 18:23:01

确认新成员的文化契合度的唯一方法就是在面试的时候注意这方面的
东西。

文化和人

2015-05-08 18:23:56

如果你想要优秀的工程师为自己的团队工作，
首要的就是雇佣出色的工程师！

2015-05-08 18:28:08

如果你想找一个能让大多数人高效工作的环境，
那还不如自己去建立一个谦虚、尊重和信任的文化氛围呢！

优秀团队文化中的沟通模式

2015-05-08 18:29:58

沟通的指导原则之一就是在同步沟通的时候（比如开会），
人越少越好。而在异步沟通的时候（比如E-mail），
涉及的听众越多越好。

高层面同步

2015-05-08 18:33:16

GWT的任务是要通过让程序员利用现有的Java工具，
为任何现代浏览器构建全功能的AJAX，
从而彻底改善用户的网络体验。

2015-05-08 18:36:39

如果你正打算做一些新的设计，
那么尽量把会议人数控制在五个人以下——
除非只有一个人可以拍板，
否则在超过五个人的会议室里是做不出任何新设计或者决策的。

2015-05-08 18:38:33

有关开会的五条小贴士：

1．只邀请一定要参加的人；

2．开会前要决定好议程，而且要事先通知所有人；

3．达成目的后应提早散会；

4．注意别跑题；

5．尽量把会议安排在休息时间前后（比如午饭时间，下班前等）。

沟通也是工程的一部分

2015-05-08 18:49:44

注释应该尽量解释为什么代码要那么写，
而不是去解释代码做了什么。

2015-05-09 13:29:39

每个提交都必须经过代码审查

2015-05-09 13:29:57

代码改动应该尽量短小以保证审查的质量——
若改动涉及几千行代码，那么除了挑挑格式的毛病外，
基本是没办法进行审查的。

说到底真正重要的还是代码本身

2015-05-11 01:50:05

尽管为团队招募到合适的人才和为团队注入正确的价值观都是非常重
要的事情，
但最后绝大部分能真正成为文化一部分的努力其实都是来自沟通。
任务宗旨、会议、邮件列表、在线聊天、代码注释、文档，
乃至决策过程都是团队自己以及和外部沟通的不同方式。
很多人都想不到只是为了写代码就要在沟通上花那么多时间和精力（
包括感情上的交流），但这却是事实。代码最终是要和人沟通，
而不是机器。

2015-05-11 01:50:34

有的人认为只要雇佣一个超级架构师，
再配几个普通程序员就可以做出好产品了。
我们承认这的确是可行的，但是和一群能激发你的灵感、挑战你、
教导你的优秀同事一起工作比起来，这种方式实在是太无聊、
太无趣了。

主管才是新的经理

2015-05-11 01:55:31

传统型经理关心的是怎么完成任务，而主管只关心完成了什么任务…
…（并且相信团队能自己想出解决问题的办法）。

反模式

2015-05-11 08:42:36

反模式：雇佣听话的人

2015-05-11 08:42:43

反模式：无视表现不佳的人

2015-05-11 08:39:21

在Google，
负责所有服务正常运行的那支团队有这样一句座右铭：“
希望可不是一种策略。”而在处理表现差的人的时候，
希望却被当作策略用到滥。

2015-05-11 08:42:29

反模式：无视人际关系

2015-05-11 08:42:53

反模式：和谁都是朋友

2015-05-11 08:44:07

有时候变成好朋友的老板是一件很微妙的事情。假如他管不好自己，
不努力工作的话，大家都会觉得有压力。
我们建议你最好还是尽可能地避免这种情况。

2015-05-11 08:44:10

反模式：降低招聘标准

2015-05-11 08:44:42

史提夫·乔布斯曾经说过：“
顶尖的人会雇佣和自己一样优秀的人才，
而差一点的人只雇得到更差的人。”

2015-05-11 08:46:18

反模式：把团队当小孩子

领袖的处事之道

2015-05-11 08:49:03

“放下自负”里有一部分内容是我们已经讨论过的，
即你应该信任自己的团队。这意味着尊重团队成员的能力，
以及他们之前的成就，哪怕他们是刚刚加入团队也不例外。

2015-05-11 08:51:24

做一个禅师

身为工程师，你可能职业性地变得多疑和愤世嫉俗，
但这对于带领团队来说却是不利的。这不是说盲目乐观是对的，
只不过在告知团队你已经意识到工作中要面对的纷乱和障碍时，
如果能在言语上少一点疑惑就好了。领导的人越多，
保持淡定和冷静就越是重要，因为众人都会（不管是不是有意识地）
看着你，看你在面对事物时的态度和反应是怎么样的。

2015-05-11 18:22:44

傅攀勃之前有个经理名叫比尔11，
他的绝活就是任何时候都能保持冷静。不管发生了什么，
也不管事情变得多糟糕，哪怕火烧眉毛，比尔也没有慌过神。
大多数时候他都会一手插在怀里，另一手托着下巴，
看着一个已经完全不知所措的工程师问他到底发生了什么问题。
这样一来那名工程师也会渐渐冷静下来，
帮助他把思路集中在解决问题上，而不是像无头苍蝇一样不知所措。
傅攀勃曾经开玩笑说，
如果有一天有人跑来告诉比尔说我们有19个数据中心被外星人攻击
了的话，他的回答也只会是：“你知道为什么他们不干脆凑个整数，
攻击20个吗？”

2015-05-11 18:23:39

工程师来问你建议通常不是要你去解决他的问题，
而是要你帮助他解决问题，所以最简单的方法应该是问问题。

2015-05-11 18:23:58

正确的做法应该是在HRT的原则下，帮助他解析分析问题，
从而达到让他自己解决问题的目的。
这通常能引导工程师得出答案13，最重要的是，
这是他自己想出来的答案，
因此也就回到了本章开头所讲的主人翁精神和责任感。

2015-05-11 18:25:17

团队主管最经常要做的事情之一就是引导大家达成共识。

2015-05-11 18:26:03

在帮忙扫除障碍的时候，你用不着通晓一切，
往往认识能解决问题的人就足够了。
很多时候认识正确的人比知道正确答案要有价值得多。

2015-05-11 18:26:45

如果要培养起敢于冒风险的氛围，就一定要让团队明白，
失败没什么了不起的。

2015-05-11 18:28:44

熟悉团队的流程和系统，向他人解释事物的能力，
以及估计被指导的人到底需要多少帮助的能力。

2015-05-11 18:29:42

设置明确的目标，
让团队同心协力的最佳方法就是为他们写一份简明扼要的任务宗旨

2015-05-11 18:31:08

事实上，
亲和力和同情心是让你的批评对象不会立即表现出防御心态的法宝。

2015-05-11 18:33:35

在直截了当反馈或者批评的时候，
表达的方式是确保别人听得进你的意思，不会发生偏差的关键。

2015-05-11 18:35:17

从长远上提高团队生产力（同时减少减员率）
的办法就是在评估团队快乐的程度上多加注意。

2015-05-11 18:36:32

如果知道一些队员私底下的情况，
你就更能了解他们在某段时间里表现出色或者不够专注的原因。
如果某人家里有点变故的话，不妨在工作上多给他点时间，
这样将来团队要是碰到项目很紧的情况时，
他也会更愿意付出以来回报你。

2015-05-11 18:38:19

我们总是会吃惊地发现一些公司不顾员工意愿，
把最优秀的工程师放到管理职位上去。
其实这么做往往只会让你的团队失去一名优秀的工程师，
平添一名蹩脚的经理罢了。

2015-05-11 18:39:19

知道什么时候要做恶人。

2015-05-11 18:39:24

保护团队不受混乱干扰。

2015-05-11 18:39:38

帮团队遮风挡雨。

内部激励和外部激励

2015-05-11 18:43:08

自主、精通、目标19。

2015-05-11 18:47:15

只要你能让他们看到工作的目标，
他们的动力和生产力就会成倍增加22。

什么是“害群”

2015-05-11 18:52:53

好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、
代码审查，以及能让人放心尝试新事物或者快速失败的环境。

2015-05-12 08:30:04

一个人总是让自己沉浸在负面情绪里是不健康的行为——长远来讲，
它会侵蚀你的一切，制造更多麻烦1。

2015-05-12 08:31:26

在带领团队的时候，不要把自己想成是一帮精英，
众志成城地要把所有的烂人都轰走，
而是要培养一种拒绝容忍负面行为的文化氛围，这才是正确的态度。
要剔走的是行为本身，而不是人，
单纯地区分好人和坏人是很幼稚的想法。
规定好哪些是不可容忍的行为，然后予以惩戒，
才是更有建设性的务实态度。

保护团队

2015-05-12 08:33:54

? 写一份明明白白的任务宗旨。这样可以随时保持专注，
知道哪些是目标，哪些不是。

? E-mail 讨论要有礼仪。保留归档，要求新人研读，防范那些“
嘈杂的少数人”。

? 所有历史都要有记录。这不单指代码历史，还有设计决策、
重要的bug修复，以及过去犯下的错误。

? 有效地进行协作。利用版本控制，代码改动要尽可能的小，
方便进行审查，扩大“公车因子”，避免出现领地感2。

? 修复bug，测试，发布软件要有清晰的政策和流程。

? 降低新人加入时的壁垒。

? 依赖基于共识决策，
在无法达成共识的时候也要准备好化解矛盾的方法。

发现威胁

2015-05-12 08:34:43

大多数人在行为出格的时候，要么是没有意识到自己过分了，
要么就是根本不在乎别人的感受。无知和冷漠其实比蓄意更严重。

2015-05-12 08:35:54

不尊重别人的时间

2015-05-12 08:35:59

自负

2015-05-12 08:36:35

这里“自负”可能不是最恰当的词，
我们想要表达的是那种无法接受多数人决议，
无法倾听和尊重其他观点，以及不愿作出妥协的人。

2015-05-12 08:37:45

Subversion 就有过这么一段经历，
当时有一名非常聪明的程序员出现在邮件列表里，
声称产品的整体设计存在严重缺陷，而自己已经成竹在胸，
有一些大刀阔斧的办法来纠正错误，
并且坚持项目应该整个推倒重来。
他甚至还毛遂自荐希望能亲自领导重建工作，
他宣称要是没有他的领导，项目随时都会有覆巢之险。

项目的创始人浪费了整个星期的时间，和这个家伙无休止地争论，
誓要捍卫自己最初的设计目标。所有的注意力和专注力都涣散了。
这个人显然无意作出任何妥协，
也不想把自己的想法融入到现在的产品里，而项目（
已经在公测阶段，拥有大量用户）也不可能重新来过。
所以我们只能选择不再争论，回到自己的步调上来。讽刺的是，
多年以后，事实表明他的预言在很多方面都是对的，但这并不妨碍 Subversion 的巨大成功——
至少在企业级的软件开发上Subversion做得很好。
这里关键的地方不在于谁对谁错，而是能否和而不同，
以及争论是否有继续的必要。一定要提醒自己注意这些问题，
有时候你必须作出决定，舍弃一些东西，继续向前。

2015-05-12 08:37:50

过分索求

2015-05-12 08:38:51

幼稚或是莫名其妙的交流

2015-05-12 08:39:09

偏执妄想

2015-05-12 08:40:32

太追求完美会变得瞻前顾后、犹豫不决。

2015-05-12 08:42:11

对抗有害行为

我们不鼓励仅仅因为别人有点反社会或是不太礼貌就把他们踢走。

2015-05-12 08:43:06

转移完美主义者的注意力

2015-05-12 08:42:41

俗话说，过犹不及。在打造高效团队的时候，
一定要时时警惕不要过于追求完美，否则只会适得其反。

2015-05-12 08:43:18

别去搭理那些挑衅的家伙

2015-05-12 08:46:20

你的任务是写出漂亮的软件，没有义务讨好所有人，
也不需要一再去证明自己存在的价值。你越是情绪化，
就越容易浪费宝贵的时间去写一些激昂的回帖，
而那些都是不值得你关注的人。应战之前应该谨慎一点，
时刻保持冷静，知道哪些人是值得回应的，哪些人是可以无视的。

2015-05-12 08:47:14

保持理智的更深一层含义就是要学会抓住重点。一个人在抱怨、
发泄情绪的时候，一定要认真听他说。
虽然会夹杂一些愤怒和粗俗的话，
但是要相信对方本质上是没有恶意的。他说的到底有没有道理呢？
我们是不是可以从他的经验里学到什么？他的想法是不是值得回应？
很多时候答案都是肯定的——那就是虽然他语言上有点刻薄，
但背后其实是有亮点的，所以应该尽量把争执再次引向技术讨论。5

2015-05-12 08:51:32

虽然短期之内会损失一些注意力和专注力，
长远来讲你真的相信项目会因此受益吗？

? 你相信这些冲突最终会以有益的方式解决吗？

2015-05-12 08:51:54

把注意力放在重要的地方，不要被眼前的东西迷惑

2015-05-12 08:53:21

我有不少朋友都认识他。其中有一个是这样说的，“
他常常游走在天才和疯子之间。可问题是，现在天才已经不稀奇了，
没人会因此接受这样举止古怪的人了”。

——格雷格·哈德森

<div style="font-size:11pt;margin-top:0.5em">
<span style="font-weight:bold;color:#a9a9a9">

注:
<span style="color:#555555">
得是什么样的团队才有信心说这种话

2015-05-12 08:57:01

在这里要再次明确强调：为了短期利益而打破规矩不值得——
特别是对于那些不懂得尊重HRT重要性的家伙来说，
再大的天才也没用。

2015-05-12 08:58:00

你的任务不是要培养傲慢的态度，
把那些没有那么聪明的普通人赶出项目；
你的任务是拒绝容忍毁灭性的行为，明确自己对 HRT的期望。有智慧的人才能体会其中的差别，
而有能力的人才能真正予以执行。

优点、缺点和策略

2015-05-12 18:26:51

大公司是一个复杂无比的有机体系，无论你怎么神通广大，
也需要GPS、手电筒，以及一大堆指示牌才能搞清楚东南西北。

现实的情况：当环境成为成功路上的绊脚石

2015-05-12 18:31:17

幸福的家庭都是相似的，而不幸的家庭则各有各的不幸。——列夫·
托尔斯泰，《安娜·卡列尼娜》。1

操纵你的组织

2015-05-12 18:40:55

“请求谅解比请求许可要容易得多”7

2015-05-12 18:39:36

每次你申诉什么事情，或是要反驳公司里的其他人时，
你都在消耗自己的政治资本。
如果把这些资本用在赢得一堆无关紧要的事情上，
那么当碰到真正重要的事情的时候你会发现自己一无所有。
所以只有在事关重大，或是确信自己有把握赢的时候才去争取。

2015-05-12 18:41:22

路是人走出来的

2015-05-12 18:41:52

假如你想要说服一个人，
如果你能找到几个认同你的人在和他聊天的时候提到你的创意（
或是提案，或是请求），那你成功的概率就能大大增加。
就算你的目标对这一切都心知肚明，
人类的基本心理还是会有暗示作用的。当他从多个渠道（
而不只是你一个人）听到同样的想法时，自然就会对其另眼相看了。

2015-05-12 18:42:41

“坏习惯是停不下来的，你只有用一个好习惯去替换掉它。”

2015-05-12 18:43:38

学习向上管理

2015-05-12 18:47:45

有了这次糟糕的经验后，本开始把所有的工作分成“进取性”和“
防御性”两大类。进取性的工作通常是指用户看得见的新功能——
在外人眼里这些都是很炫、很令人兴奋的东西，
或是能展现产品优势的地方（比如，界面改进、速度提升，
或是互操作性的增强等）。
而防御性的工作主要是着重产品长期的健康状况（比如，代码重构、
特性重写、修改数据库模式、数据迁移，或是改进紧急监控等）。
这些防御工作能让产品更稳定可靠，可维护性更强。
然而尽管这些工作至关重要，却得不到任何政治上的好处。
所以你要是把时间都花在这上面，在外人看来，
你的项目就好像停滞了一样。套用一句成语就是“先入为主”啊！9

2015-05-12 18:45:32

不管技术债务有多少，
团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性
的工作，否则就等于政治自杀。

2015-05-13 08:29:30

那就是人们会记住你曾经在他们遇到困难的时候出手相助，
而不是甩下一句“这不关我的事”。

2015-05-13 08:28:29

在公司里的位置越高（
不管是作为负责具体工作的人还是担任领导职务），
你就越能掌控自己在公司里的命运。

2015-05-13 08:32:22

事实上，经过多年的试错后，
我们发现越短的邮件就越有机会得到回复。

2015-05-13 08:33:02

写得好的三个论点和一个行动的邮件（最多）包含三个点，
让你解释问题的细节，然后一个（只能有一个）行动请求，
绝不能有其他的内容。这份E-mail应该可以被轻易转发

B计划：走为上

2015-05-13 08:34:42

只做正确的事，随时准备被炒

<div style="font-size:11pt;margin-top:0.5em">
<span style="font-weight:bold;color:#a9a9a9">

注:
<span style="color:#555555">
真没想到在这本书中遇见陈一鸣

2015-05-13 08:37:48

将来有一天，等你到了我这个年纪的时候，
不妨花点时间和你自己的父亲聊聊他的职业生涯，
你就会发现自己和父亲有多像了，保证又惊又喜。

管理大众的印象

2015-05-13 08:44:00

正因为我们对营销的印象是专门歪曲事实的东西，（所以）
它违背了工程师对完美的本能追求。
我们相信最好的产品一定会赢得一切。我们所谓的“最好”
指的是产品从客观上拥有最优异的品质，功能是最有效的，
而不是华而不实的电视广告里演的那些东西。但我们一而再、
再而三地看到优秀的技术被打败：很多人都觉得 Betamax 要胜过 VHS，Laserdisc也要比DVD更好，
或者Lisp仍然是最好的编程语言（
我们只是乘机把这个事实告诉大家而已）。
就算是在版本控制工具圈子里，Subversion 也统治了企业市场，尽管很多新系统在技术上具备更多的优越性。

2015-05-13 08:45:21

注意第一印象

2015-05-13 08:46:07

说得再具体一点，即用户在软件启动后30 秒能体验到了什么？光有一个技术上的答案（“
她会看到一个选择菜单，还有一个登录框”）是不够的，
还要有一个情感上的答案。新用户在一分钟之内的感受是怎么样的？
是感到有用呢，还是觉得很迷惑？你要怎么做才能改善这种体验？

2015-05-13 08:46:33

承诺的时候要谨言，做产品的时候要超出预期

2015-05-13 08:49:11

关注用户，其他的东西自会随之而来。

2015-05-13 22:15:39

“速度也是特性。”

管理和用户之间的关系

2015-05-14 08:30:13

信任是最神圣的资源，必须悉心呵护、步步为营。
任何举动都要三思而行。决策的时候，眼光要长远，
不要只注重眼前利益。

2015-05-14 08:30:45

长远来讲，有技巧地增加一点愉悦和幽默，
能让用户体会到你是真地关心他们，在乎和他们的关系。

2015-05-14 08:31:17

作为程序员，我们每天都有各种分散注意力的事情——代码审查，
设计审查，摆弄工具，产品出问题了要去救火，
还要给bug分门别类——
这让我们有时候会忘了自己为什么要编写软件。不是为了自己，
不是为了团队，也不是为了公司，而是为了给用户带来方便。
关注用户在想什么，如何评论你的产品，
以及长期使用的感受是至关重要的，用户才是你的软件成功的源泉。
一分耕耘才有一分收获。

结语

2015-05-14 08:32:17

我们先不要把事情想得太复杂。
假如你要从我们的故事里学到点什么的话，只要记住HRT就好了：
谦虚、尊重、信任。

多看笔记 来自多看阅读 for iOS