Getting Real

梅特卡夫定律(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）是意大利作曲家。传说中，他的才能不及莫扎特，在嫉妒心的驱使下，毒死了莫扎特。

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 happens and when it does quality often suffers. How does a project get to be a year behind schedule? One day at a time.

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 arrogant, so be it. We’d rather be provocative than water everything down with “it depends...” Of course there will be times when these rules need to be stretched or broken. And some of these tactics may not apply to your situation. Use your judgement and imagination.

书虽小，但真的值得一读。