出版社: 37signals
副标题: The Smarter, Faster, Easier Way to Build a Successful Web Application
出版年: 2009-11-18
页数: 194
定价: USD 24.99
装帧: Paperback
ISBN: 9780578012810
内容简介 · · · · · ·
Getting Real details the business, design, programming, and marketing principles of 37signals. The book is packed with keep-it-simple insights, contrarian points of view, and unconventional approaches to software design. This is not a technical book or a design tutorial, it's a book of ideas. Anyone working on a web app - including entrepreneurs, designers, programmers, executi...
Getting Real details the business, design, programming, and marketing principles of 37signals. The book is packed with keep-it-simple insights, contrarian points of view, and unconventional approaches to software design. This is not a technical book or a design tutorial, it's a book of ideas. Anyone working on a web app - including entrepreneurs, designers, programmers, executives, or marketers - will find value and inspiration in this book. 37signals used the Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no outside funding, no debt, and only 7 people (distributed across 7 time zones). Over 500,000 people around the world use these applications to get things done. Now you can find out how they did it and how you can do it too. It's not as hard as you think if you Get Real.
作者简介 · · · · · ·
Who is 37signals?
We’re a privately-held Chicago-based company committed to building the best web-based software products possible with the least number of features necessary. Our products do less than the competition — intentionally. We’ve been in business since 1999 and love what we do.
喜欢读"Getting Real"的人也喜欢的电子书 · · · · · ·
喜欢读"Getting Real"的人也喜欢 · · · · · ·
Getting Real的话题 · · · · · · ( 全部 条 )



Getting Real的书评 · · · · · · ( 全部 17 条 )
> 更多书评17篇
-
小楼一夜听春雨 (凡读无益之书皆玩物丧志)
梅特卡夫定律(Metcalfe's Law)和项目团队 保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。 —Marc Hedlund 通信流 通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的..2014-02-16 03:58 1人喜欢
梅特卡夫定律(Metcalfe's Law)和项目团队保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。—Marc Hedlund通信流通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的通信通路是你和客户之间。但是,随着项目人员数目的增长,通信通路的数量也随之增长。它并不是加法形式的增长,随着人员数目的增长,它是乘法形式的增长,正比于人员数目的平方。—史蒂夫·麦克科耐尔(Steve McConnell), Construx软件公司(Construx Software Builders Inc.)首席软件工程师。(摘自 《少即是多——小团队的第一生产力》,Less is More: Jumpstarting Productivity with Small Teams对于每一个新功能你需要…… 1. 对它说不 2. 强迫它证明自己的价值 3. 如果得到否定的答案,就此打住。如果是yes,继续往下…… 4. 为界面绘制草图 5. 设计界面 6. 编写代码 7-15. 测试,改进,测试,改进,测试,改进,测试,改进…… 16. 检查帮助文字是否需要修改 17. 更新产品预览流程(如果有必要的话) 18. 更新用于销售的拷贝(如果有必要的话) 19. 更新服务条款(如果有必要的话) 20. 检查是否违背之前的任何许诺 21. 检查价格体系是否受影响 22. 上线 23. 深吸一口气要快 1. 决定它是否值得做,如果是的话: 2. 尽快去做 — 不需完美,只需做下去 3. 保存。上传。发布。 4. 看人们的反应猜猜在一天中哪一部分完成我们完成的工作最多?独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。如果你有很长时间没有被打扰,你就能渐入佳境。这个情境是你最有生产力的时间;这个时间内你不必在各种各样的任务中切换思维;这个时间你不会受到干扰,比如回答问题或者是查找东西,发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠,你先进入浅睡眠,然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。在工作中建立一条规定:一天中一半的时间作为独处时间。从上午10点到下午两点,任何人都不可以和别人谈话(除了午餐时间)。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的,为了避免破坏生产力的干扰。成功的独处时间意味着赶走交流痴迷。在独处时间中,放弃即时通讯,电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。(Just shut up and get to work.)进入最佳状态我们都知道知识工作者在稳定状态工作最出色,这种状态也被称作“渐入佳境”,他们全神贯注于工作,开足马力,忘了周围的环境。他们忘了时间的流逝, 在绝对的集中精力下产生了巨大的成果...那番在于这种情境太容易被破坏。噪声,电话呼叫,吃午餐,需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰,这足以破坏你的集中经历,那么你需要花费一个小时重新达到有效率,你的总生产力变得很糟糕。分解它当子项目增长的时候,增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。2个人只需要相互沟通;只有一条简单的交流途径。3个人有3条交流途径;4个人有6条。事实上,交流途径的增长是指数级的……很快,备忘录和会议汇占据整个工作时间。解决方法是明显的:把团队分解成小的,自治的和独立的小单位以减少这些交流途径。详细的,把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖(全局变量,函数间传送的数据,共享的硬件等等),找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。编程与莫扎特的安魂曲一个优秀的程序员独自完成一项任务,就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成,他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小,就越能获得额外的收益。人力与工时的互换,真的是一个神话[3]。等等,我还是没说完用许多平庸的程序员取代少数优秀的程序员,这种做法的真正问题在于,不管平庸的程序员工作多长时间,他们做出来的东西,都无法像优秀程序员做得那样好。五个Antonio Salieris[4]也写不出莫扎特的《安魂曲》。永远也写不出,埋头写100年也没用。梅特卡夫定律(Metcalfe's Law)和项目团队保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。—Marc Hedlund通信流通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的通信通路是你和客户之间。但是,随着项目人员数目的增长,通信通路的数量也随之增长。它并不是加法形式的增长,随着人员数目的增长,它是乘法形式的增长,正比于人员数目的平方。—史蒂夫·麦克科耐尔(Steve McConnell), Construx软件公司(Construx Software Builders Inc.)首席软件工程师。(摘自 《少即是多——小团队的第一生产力》,Less is More: Jumpstarting Productivity with Small Teams对于每一个新功能你需要…… 1. 对它说不 2. 强迫它证明自己的价值 3. 如果得到否定的答案,就此打住。如果是yes,继续往下…… 4. 为界面绘制草图 5. 设计界面 6. 编写代码 7-15. 测试,改进,测试,改进,测试,改进,测试,改进…… 16. 检查帮助文字是否需要修改 17. 更新产品预览流程(如果有必要的话) 18. 更新用于销售的拷贝(如果有必要的话) 19. 更新服务条款(如果有必要的话) 20. 检查是否违背之前的任何许诺 21. 检查价格体系是否受影响 22. 上线 23. 深吸一口气要快 1. 决定它是否值得做,如果是的话: 2. 尽快去做 — 不需完美,只需做下去 3. 保存。上传。发布。 4. 看人们的反应猜猜在一天中哪一部分完成我们完成的工作最多?独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。如果你有很长时间没有被打扰,你就能渐入佳境。这个情境是你最有生产力的时间;这个时间内你不必在各种各样的任务中切换思维;这个时间你不会受到干扰,比如回答问题或者是查找东西,发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠,你先进入浅睡眠,然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。在工作中建立一条规定:一天中一半的时间作为独处时间。从上午10点到下午两点,任何人都不可以和别人谈话(除了午餐时间)。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的,为了避免破坏生产力的干扰。成功的独处时间意味着赶走交流痴迷。在独处时间中,放弃即时通讯,电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。(Just shut up and get to work.)进入最佳状态我们都知道知识工作者在稳定状态工作最出色,这种状态也被称作“渐入佳境”,他们全神贯注于工作,开足马力,忘了周围的环境。他们忘了时间的流逝, 在绝对的集中精力下产生了巨大的成果...那番在于这种情境太容易被破坏。噪声,电话呼叫,吃午餐,需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰,这足以破坏你的集中经历,那么你需要花费一个小时重新达到有效率,你的总生产力变得很糟糕。分解它当子项目增长的时候,增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。2个人只需要相互沟通;只有一条简单的交流途径。3个人有3条交流途径;4个人有6条。事实上,交流途径的增长是指数级的……很快,备忘录和会议汇占据整个工作时间。解决方法是明显的:把团队分解成小的,自治的和独立的小单位以减少这些交流途径。详细的,把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖(全局变量,函数间传送的数据,共享的硬件等等),找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。编程与莫扎特的安魂曲一个优秀的程序员独自完成一项任务,就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成,他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小,就越能获得额外的收益。人力与工时的互换,真的是一个神话[3]。等等,我还是没说完用许多平庸的程序员取代少数优秀的程序员,这种做法的真正问题在于,不管平庸的程序员工作多长时间,他们做出来的东西,都无法像优秀程序员做得那样好。五个Antonio Salieris[4]也写不出莫扎特的《安魂曲》。永远也写不出,埋头写100年也没用。--------------------------------------------------------------------------------------[3] 此处指的是Frederick Brooks所写的软件项目管理名著《人月神话》(The Mythical Man-Month)。所谓"人月"就是一个人在一个月内所能完成的工作量。假如有个项目预估需要12个人月,那么派4个人来处理这个项目,理论上只要三个月就能完成。但是,Brooks认为这种换算机制在软件业中行不通,是一个神话,因为软件项目是交互关系复杂的工作,需要大量的沟通成本,人力的增加会使沟通成本急剧上升,反而无法达到缩短工时的目的。在本质上,软件项目的人力与工时是无法互换的,当项目进度落后时,光靠增加人力到该项目中,并不会加快进度,反而有可能使进度更加延后。[4] Antonio Salieris(1750-1825)是意大利作曲家。传说中,他的才能不及莫扎特,在嫉妒心的驱使下,毒死了莫扎特。回应 2014-02-16 03:58 -
Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time. The same theory applies to other problems too. Are you facing an issue that’s too big to wrap your mind around? Break it down.
2011-10-25 00:10 1人喜欢
-
This sort of one-upping Cold War mentality is a dead-end. How do we make these decisions? If it’s something we recognize as being important, we might ask. The rest, we guess. And all that guessing builds up a kind of debt in our applications – an interconnected web of assumptions. There’s a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happe...
2013-12-03 20:23
This sort of one-upping Cold War mentality is a dead-end.How do we makethese decisions? If it’s something we recognize as being important, wemight ask. The rest, we guess. And all that guessing builds up a kind ofdebt in our applications – an interconnected web of assumptions.There’s a myth that goes like this: we can launch on time, onbudget, and on scope. It almost never happens and when it doesquality often suffers.How does a project get to be a year behind schedule? One day at a time.回应 2013-12-03 20:23
-
A你在阅读过程中,感受最深的一句话、一个观点是什么?为什么? 顺其自然 竭尽全力将你的软件定位在一个点上。你的软件代表的是什么?它到底是有关什么的?在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它?它和其他类似产品不同的地方在哪里? 确定最简单的内核,然后看,观察用户的行为。 用户提出的功能需求,你如何管理它们? 你不需要,看完之后,把它们..
2012-12-14 21:42
A你在阅读过程中,感受最深的一句话、一个观点是什么?为什么?顺其自然竭尽全力将你的软件定位在一个点上。你的软件代表的是什么?它到底是有关什么的?在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它?它和其他类似产品不同的地方在哪里?确定最简单的内核,然后看,观察用户的行为。用户提出的功能需求,你如何管理它们? 你不需要,看完之后,把它们扔掉。用户屡次提出来的,就是我们要做的吗?比如:评论?——沿着自己的产品定位,把这种需求转化成一种适合本产品的功能呈现。他们是不可或缺的么——别做“搞定!”决定都是暂时的——快去做做还是不做,这是个问题B 《getting real》中提出工作方法是什么?这种方法的外部约束条件是什么?这种方法的优势是什么?存在什么样的风险?简单尝试,快速迭代外部约束条件:确定你的产品要解决的那个问题(解决自己的问题or解决别人的问题?)简单到什么程度?你能快速到什么程度?优势:能看得到效果,有问题能很快调整,一个尝试失败也没关系风险:简单成了简陋;不够快速,还总是试错C从现实出发,如果采用《getting real》的工作方法,我们需要做什么,现在的工作中是否存在亟待改善的方面?想清楚,快去做回应 2012-12-14 21:42 -
Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wirefames, etc.) and actually building the real thing.
2011-10-25 00:04
-
小楼一夜听春雨 (凡读无益之书皆玩物丧志)
梅特卡夫定律(Metcalfe's Law)和项目团队 保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。 —Marc Hedlund 通信流 通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的..2014-02-16 03:58 1人喜欢
梅特卡夫定律(Metcalfe's Law)和项目团队保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。—Marc Hedlund通信流通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的通信通路是你和客户之间。但是,随着项目人员数目的增长,通信通路的数量也随之增长。它并不是加法形式的增长,随着人员数目的增长,它是乘法形式的增长,正比于人员数目的平方。—史蒂夫·麦克科耐尔(Steve McConnell), Construx软件公司(Construx Software Builders Inc.)首席软件工程师。(摘自 《少即是多——小团队的第一生产力》,Less is More: Jumpstarting Productivity with Small Teams对于每一个新功能你需要…… 1. 对它说不 2. 强迫它证明自己的价值 3. 如果得到否定的答案,就此打住。如果是yes,继续往下…… 4. 为界面绘制草图 5. 设计界面 6. 编写代码 7-15. 测试,改进,测试,改进,测试,改进,测试,改进…… 16. 检查帮助文字是否需要修改 17. 更新产品预览流程(如果有必要的话) 18. 更新用于销售的拷贝(如果有必要的话) 19. 更新服务条款(如果有必要的话) 20. 检查是否违背之前的任何许诺 21. 检查价格体系是否受影响 22. 上线 23. 深吸一口气要快 1. 决定它是否值得做,如果是的话: 2. 尽快去做 — 不需完美,只需做下去 3. 保存。上传。发布。 4. 看人们的反应猜猜在一天中哪一部分完成我们完成的工作最多?独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。如果你有很长时间没有被打扰,你就能渐入佳境。这个情境是你最有生产力的时间;这个时间内你不必在各种各样的任务中切换思维;这个时间你不会受到干扰,比如回答问题或者是查找东西,发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠,你先进入浅睡眠,然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。在工作中建立一条规定:一天中一半的时间作为独处时间。从上午10点到下午两点,任何人都不可以和别人谈话(除了午餐时间)。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的,为了避免破坏生产力的干扰。成功的独处时间意味着赶走交流痴迷。在独处时间中,放弃即时通讯,电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。(Just shut up and get to work.)进入最佳状态我们都知道知识工作者在稳定状态工作最出色,这种状态也被称作“渐入佳境”,他们全神贯注于工作,开足马力,忘了周围的环境。他们忘了时间的流逝, 在绝对的集中精力下产生了巨大的成果...那番在于这种情境太容易被破坏。噪声,电话呼叫,吃午餐,需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰,这足以破坏你的集中经历,那么你需要花费一个小时重新达到有效率,你的总生产力变得很糟糕。分解它当子项目增长的时候,增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。2个人只需要相互沟通;只有一条简单的交流途径。3个人有3条交流途径;4个人有6条。事实上,交流途径的增长是指数级的……很快,备忘录和会议汇占据整个工作时间。解决方法是明显的:把团队分解成小的,自治的和独立的小单位以减少这些交流途径。详细的,把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖(全局变量,函数间传送的数据,共享的硬件等等),找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。编程与莫扎特的安魂曲一个优秀的程序员独自完成一项任务,就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成,他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小,就越能获得额外的收益。人力与工时的互换,真的是一个神话[3]。等等,我还是没说完用许多平庸的程序员取代少数优秀的程序员,这种做法的真正问题在于,不管平庸的程序员工作多长时间,他们做出来的东西,都无法像优秀程序员做得那样好。五个Antonio Salieris[4]也写不出莫扎特的《安魂曲》。永远也写不出,埋头写100年也没用。梅特卡夫定律(Metcalfe's Law)和项目团队保持团队尽可能的小。梅特卡夫定律(Metcalfe's Law),“网路的价值,为使用者的平方”,应用到项目团队的时候得到一个推论:团队的效率和团队人数的平方成反比。我开始觉得三个人对于1.0产品发布 是最优的...从减少你计划添加到团队的人数开始,接着减少更多。—Marc Hedlund通信流通信在小团队比在大团队中更容易流动。如果你是项目中唯一的一人,通信是简单的。唯一的通信通路是你和客户之间。但是,随着项目人员数目的增长,通信通路的数量也随之增长。它并不是加法形式的增长,随着人员数目的增长,它是乘法形式的增长,正比于人员数目的平方。—史蒂夫·麦克科耐尔(Steve McConnell), Construx软件公司(Construx Software Builders Inc.)首席软件工程师。(摘自 《少即是多——小团队的第一生产力》,Less is More: Jumpstarting Productivity with Small Teams对于每一个新功能你需要…… 1. 对它说不 2. 强迫它证明自己的价值 3. 如果得到否定的答案,就此打住。如果是yes,继续往下…… 4. 为界面绘制草图 5. 设计界面 6. 编写代码 7-15. 测试,改进,测试,改进,测试,改进,测试,改进…… 16. 检查帮助文字是否需要修改 17. 更新产品预览流程(如果有必要的话) 18. 更新用于销售的拷贝(如果有必要的话) 19. 更新服务条款(如果有必要的话) 20. 检查是否违背之前的任何许诺 21. 检查价格体系是否受影响 22. 上线 23. 深吸一口气要快 1. 决定它是否值得做,如果是的话: 2. 尽快去做 — 不需完美,只需做下去 3. 保存。上传。发布。 4. 看人们的反应猜猜在一天中哪一部分完成我们完成的工作最多?独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。如果你有很长时间没有被打扰,你就能渐入佳境。这个情境是你最有生产力的时间;这个时间内你不必在各种各样的任务中切换思维;这个时间你不会受到干扰,比如回答问题或者是查找东西,发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠,你先进入浅睡眠,然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。在工作中建立一条规定:一天中一半的时间作为独处时间。从上午10点到下午两点,任何人都不可以和别人谈话(除了午餐时间)。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的,为了避免破坏生产力的干扰。成功的独处时间意味着赶走交流痴迷。在独处时间中,放弃即时通讯,电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。(Just shut up and get to work.)进入最佳状态我们都知道知识工作者在稳定状态工作最出色,这种状态也被称作“渐入佳境”,他们全神贯注于工作,开足马力,忘了周围的环境。他们忘了时间的流逝, 在绝对的集中精力下产生了巨大的成果...那番在于这种情境太容易被破坏。噪声,电话呼叫,吃午餐,需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰,这足以破坏你的集中经历,那么你需要花费一个小时重新达到有效率,你的总生产力变得很糟糕。分解它当子项目增长的时候,增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。2个人只需要相互沟通;只有一条简单的交流途径。3个人有3条交流途径;4个人有6条。事实上,交流途径的增长是指数级的……很快,备忘录和会议汇占据整个工作时间。解决方法是明显的:把团队分解成小的,自治的和独立的小单位以减少这些交流途径。详细的,把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖(全局变量,函数间传送的数据,共享的硬件等等),找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。编程与莫扎特的安魂曲一个优秀的程序员独自完成一项任务,就不需要额外的沟通和协调。如果同样的任务让5个程序员一起完成,他们之间就必须沟通和协调。这会花掉大量时间。开发团队越小,就越能获得额外的收益。人力与工时的互换,真的是一个神话[3]。等等,我还是没说完用许多平庸的程序员取代少数优秀的程序员,这种做法的真正问题在于,不管平庸的程序员工作多长时间,他们做出来的东西,都无法像优秀程序员做得那样好。五个Antonio Salieris[4]也写不出莫扎特的《安魂曲》。永远也写不出,埋头写100年也没用。--------------------------------------------------------------------------------------[3] 此处指的是Frederick Brooks所写的软件项目管理名著《人月神话》(The Mythical Man-Month)。所谓"人月"就是一个人在一个月内所能完成的工作量。假如有个项目预估需要12个人月,那么派4个人来处理这个项目,理论上只要三个月就能完成。但是,Brooks认为这种换算机制在软件业中行不通,是一个神话,因为软件项目是交互关系复杂的工作,需要大量的沟通成本,人力的增加会使沟通成本急剧上升,反而无法达到缩短工时的目的。在本质上,软件项目的人力与工时是无法互换的,当项目进度落后时,光靠增加人力到该项目中,并不会加快进度,反而有可能使进度更加延后。[4] Antonio Salieris(1750-1825)是意大利作曲家。传说中,他的才能不及莫扎特,在嫉妒心的驱使下,毒死了莫扎特。回应 2014-02-16 03:58 -
This sort of one-upping Cold War mentality is a dead-end. How do we make these decisions? If it’s something we recognize as being important, we might ask. The rest, we guess. And all that guessing builds up a kind of debt in our applications – an interconnected web of assumptions. There’s a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happe...
2013-12-03 20:23
This sort of one-upping Cold War mentality is a dead-end.How do we makethese decisions? If it’s something we recognize as being important, wemight ask. The rest, we guess. And all that guessing builds up a kind ofdebt in our applications – an interconnected web of assumptions.There’s a myth that goes like this: we can launch on time, onbudget, and on scope. It almost never happens and when it doesquality often suffers.How does a project get to be a year behind schedule? One day at a time.回应 2013-12-03 20:23 -
Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing. “You take too much of a black and white view.” If our tone seems too know-it-allish, bear with us. We think it’s better to present ideas in bold strokes than to be wishy-washy about it. If that comes off as cocky or arrog...
2013-12-03 19:34
Getting Real is about skipping all the stuff thatrepresents real (charts, graphs, boxes, arrows, schematics,wireframes, etc.) and actually building the real thing.“You take too much of a black and white view.”If our tone seems too know-it-allish, bear with us. We think it’sbetter to present ideas in bold strokes than to be wishy-washyabout it. If that comes off as cocky or arrogant, so be it. We’drather be provocative than water everything down with “itdepends...” Of course there will be times when these rules needto be stretched or broken. And some of these tactics may notapply to your situation. Use your judgement and imagination.回应 2013-12-03 19:34
论坛 · · · · · ·
中文版 | 来自米拉之落 | 13 回应 | 2015-08-08 |
出版社可以考虑引进了 | 来自星火燎原 | 1 回应 | 2011-04-26 |
可以在线看 | 来自ShiningRay | 6 回应 | 2011-04-26 |
在哪儿买这本书 · · · · · ·
以下豆列推荐 · · · · · · ( 全部 )
- 程序员必读经典书籍 (Felven)
- 产品经理书单 (火龙)
- 1000+ 豆瓣9.0+的書 (笃动武者)
- Personal MBA Recommended Reading List ([已注销])
- Ruby与Rails开发书单 (欧阳)
谁读这本书?
二手市场
订阅关于Getting Real的评论:
feed: rss 2.0
0 有用 钟楼小奶糕 2012-04-01
一路颠簸的读完
0 有用 valdanito 2010-12-25
今年看的最有价值的书!
0 有用 怪咖研究院长长 2012-06-30
很实在很实用
0 有用 启明君 2013-03-18
https://www.quora.com/Product-Management/What-are-the-best-books-for-Product-Managers/answer/Runar-Reistrup
1 有用 丸子(^.^)v 2011-09-05
Web2.0 开发的圣经 源出自37signals的日常实践 读完感觉跟rework差不多 不过内容和举例更偏重 具体应用在web开发上的场合……
0 有用 rollaround 2019-01-06
关于精益创业,专注在重要的功能,避免官僚打造高效团队,少写文档多测试,不断打磨和更新产品,更好地服务和引导客户。不论是Getting Real 和Rework,道理都是一样的,关键还是在执行~不论是软件开发还是任何其他项目,永远都是Easily said than doing. 希望可以借由这些习得的原则提升快速反应执行力
0 有用 逍遥未遂 2018-12-14
伟大的软件必须要有自己的理想。伟大的软件必定是有倾向的。当人们使用软件的时候他们不只是在看功能,同时他们也在寻找一个解决方案,一种理想。
0 有用 stotle 2018-09-07
Lean创业的经验总结,都是些熟悉的概念,但都无比的认同。需要注意的是,对于企业级应用很多条款就不那么适用了。
0 有用 CNFeat 2018-07-18
招文字功底好的人 如果你在想从几个人选中挑出哪一个来填补空缺,选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他,写作技巧都很有用。简洁高效的写作和文字编辑能力可以带来简洁高效的代码、设计、邮件、即时信息以及更多。 这是因为要当好写手并不只是堆砌词藻。好写手懂得沟通的技巧,他们让事情易于理解,他们能站在别人的立场考虑问题,他们知道什么是可以忽略的,他们思路清晰。而这正是你需要的... 招文字功底好的人 如果你在想从几个人选中挑出哪一个来填补空缺,选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他,写作技巧都很有用。简洁高效的写作和文字编辑能力可以带来简洁高效的代码、设计、邮件、即时信息以及更多。 这是因为要当好写手并不只是堆砌词藻。好写手懂得沟通的技巧,他们让事情易于理解,他们能站在别人的立场考虑问题,他们知道什么是可以忽略的,他们思路清晰。而这正是你需要的才能。 (展开)
0 有用 dandanboom 2018-07-04
让当年互联网小白的我洗刷三观