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

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.

摆出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到剩下最必要的功能。周而复始

。

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.