第三章 保持精益
第一节 轻装上阵
越精简就越容易改变
一个物体越重，改变方向所需的能量就越大。商业世界的规则与物理世界是一样的。
对于网络技术，改变必须是简单而廉价的。如果不能随时做出调整，你就落于人后。因此你要争取轻装上阵。
以下事项会让质量增加
- 长期合同
- 多余的员工
- 无效的会议
- 繁杂的过程
- 库存
- 硬件、软件、技术上的锁闭
- 专用的数据格式
- 由过去决定未来
- 长期的路线图
- 办公室政治
以下事项会让质量减小
- 及时的思考
- 能充当多面手的团队成员
- 拥抱限制
- 更少的软件、更少的代码
- 更少的功能
- 保持小规模团队
- 单纯
- 简洁的界面
- 开源的产品
- 开放的数据格式
- 开放的文化，让承认错误变得轻松简单
轻装上阵能够让你快速调整方向，及时作出反应和进化。你可以聚焦于好的点子，抛弃坏的想法。你可以倾听客户的反馈并及时作出应对。你可以第一时间整合新的技术。你在驾驶一艘小船而不是航空母舰。
例如，有这样一家精益创业的公司，他们以更少的软件和更少的功能为原则来开发一款产品。另一边，是一家大型公司，他们的产品由更多的软件和功能组成 。这时有一项新技术（例如Ajex）或新概念（例如标签）出现，谁能更快地将其应用于自己的产品？拥有未来12个月路线规划图的团队，还是功能更精简的，能够专注于当下的团队？
很明显，后者能够更快地适应市场的真实需求。当小公司已经做出改变时，大公司还在开会讨论或陷于官僚化的流程中；小公司已经遥遥领先了，大公司还在犹豫如何迈出第一步。
敏捷、灵活、轻量的业务能够迅速地改变整个商业模式、产品、功能和营销策略。他们可以快速修复错误，改变优先级、产品组合等。最重要的是，他们可以改变想法。
第二节 降低改变成本
减少障碍，保持弹性
改变是你最好的朋友。改变的成本越高，做出改变的可能性越低。如果你的竞争对手能比你更快地做出改变，你就处于巨大的劣势。如果改变的成本巨大，你就死定了。
保持精益能带来哪些好处呢？快速改变是小团队的天生属性，大团队不可能拥有。一个大型团队要花几周时间才能改变的事，小团队只需要一天。这个优势是无价的。快速而廉价地作出改变是小团队的秘密武器。
记住：所有的现金、市场、人员都无法买来小团队的灵活。
对于网络技术，改变必须简单而廉价。能够及时转向才能制胜。这就是你需要追求精益的原因。
突发性
突发性是敏捷的基本原则之一，也是最神奇的一个。突发属性无法设计或内建，他们只是作为系统的动态结果而简单地发生。“Emergence”这个词来源于17世纪中叶的拉丁文，意思是“不可预料的事件”。你无法计划或安排，但你可以培养出一个任其发生并从中受益的环境。
突发性的一个经典案例是鸟类的群集行为。在用电脑模拟时，只设定3个简单的规则，但突然间你就会观察到非常复杂的行为，集群以他们自己的方式优雅地翱翔天际，重组障碍。这些高级行为都不是由规则指定的，它们突发于动态的系统。
简单的规则导致复杂的行为（鸟类模拟）。复杂的规则导致愚蠢的行为（大多数国家的税法）。
许多常见的软件开发行为的副作用是消除了产生突发行为的一切可能性。大多数的优化导致了交互与联系在宽度和范围上的减小，而这种宽度和范围正是突发性的来源。在鸟类群集的案例中，作为一个设计良好的系统，正是交互和联系产生了这些有趣的行为。
我们把事物捆绑的越紧，产生创造性、突发性解决方案的空间就越小。无论是在理解前就做出需求锁定，还是过早地优化代码，抑或是在终端用户使用前就发明出复杂的导航和使用场景，结果都是相似的：一个过度复杂的，愚蠢的系统，而不是利用突发性创造出来的，简洁、优雅的系统。
保持小巧，保持简单，静观其变。
Andrew Hunt, The Pragmatic Programmers
第三节 三个火枪手
用三人团队开发 1.0 版本
对于应用的第一版，从三人团队开始。这是一个神奇的数字，既能提供足够的人手，又能保持精简和灵活。一个开发人员、一个设计师、一个清道夫（能够在设计和开发之间迂回的角色）。
可以肯定的是，只由少数几人来开发应用是巨大的挑战。但如果你拥有了正确的团队，这是值得一试的。有天赋的人不需要无限的资源。他们能够利用有限的资源，依靠创造性来解决问题，并从挑战中成长。缺乏人手能够逼迫你在初期就考虑权衡和妥协，这没有关系，这能帮助你尽早确定优先级。
如果你无法依靠三人团队完成第一版，那么你需要更换人手或对初始版本进行瘦身。记住，保持第一版小巧、精简是没错的。你能迅速发现你的想法是不是可行，如果是，你可以在这个干净、简洁的基础上进一步构建。
梅特卡夫原则和项目团队
尽可能保持小团队。可以将梅特卡夫原则（通讯系统的价值与系统用户数量的平方成正比）的推论应用于项目团队：团队的效率与团队人数的平方成反比。我开始认为三人团队是1.0版本的最优选择。首先，降低你对团队人数的预计，然后在此基础上再减少一些。
—Marc Hedlund, entrepreneur-in-residence at O'Reilly Media
信息流转
信息在小团队中的流转速度高于大团队。如果你是团队的唯一成员，沟通是简单的。唯一的通信途径发生在你和客户之间。随着项目人数的增加，通信途径也随之增加。这种增加并不是简单的叠加，它是以乘法形式增长的，与人数的平方成正比。
—— Steve McConnell, Construx Software Builders 首席软件工程师 （from Less is More: Jumpstarting Productivity with Small Teams）
第四节 拥抱限制
让限制把你引向创造性的解决方案
需求永远是无法满足的。没有足够的时间、没有足够的金钱、没有足够的人手。
这是好事。
对于这些限制，不应该崩溃，要拥抱他们。让他们引导你。限制能驱动创新，迫使你专注。让他们成为你的优势，而不是尝试消除限制。
当 37signal 开始搭建 Basecamp 时，我们有众多的限制：
有一家设计公司要运转
现存的客户工作
7 小时的时差（工作伙伴生活在不同的时区）
小团队
没有外部投资
我们感受到了这种“还不够”的忧伤。所以我们控制项目的规模，把大任务分解为可以在一段时间内完成的子任务。我们一步一步地前进，并随之调整优先级。
这逼迫我们想出创造性的方案。我们依靠开发精简的软件来降低变化的成本。我们只给予用户足够的功能，让他们能以自己的方式解决问题，然后我们就收手了。时间和地域的差别让我们在沟通上更有效率。我们用邮件和即时通讯取代了面对面的交流，这让我们迅速找到要点。
限制通常都是好处，只是被隐藏了。忘记风投、忘记长发布周期、忘记快速招聘。只利用你现有的资源。
与枯萎病作斗争
那些曾经被描述成“缓慢的优雅”的东西，更应该被称为“功能枯萎”，就像植物上的真菌，它逐渐吸取产品的汁液，模糊了产品的轮廓。产品枯萎的解药就是“压缩最后期限”。这使得功能的丢弃与部署时间成比例。最有用的功能通常需要最长的时间来部署。因此，枯萎和最后期限的结合，产生了很多我们熟悉并喜欢的软件，他们包含了许多无用的功能。
—— Jef Raskin, 作家 （from "为什么软件是这样的"）
第五节 做你自己
保持个性化和友好来使你区别于更大的公司
很多小公司的错误在于试图让自己表现得像个大公司。因为他们将自己的规模视为应该被掩盖的弱点。这很糟。事实上小是一个巨大的优势，特别是对于沟通来说。
小公司享受着更少的手续，更少的官僚主义，更多的自由。小公司在默认情况下是更贴近用户的。这意味着他们可以用更直接、更加个人化的方式与客户沟通。如果你很小，你可以使用大家都熟悉的语言来取代行业术语。你的网站、产品可以更人性化，而不是一个冰冷的商业机器。保持微小意味着你可以和客户平等交流，而不是高高在上。
小公司在内部交流上同样有优势。你可以抛弃繁文缛节。过程中的每个人都可以坦诚公开地说话。这种让想法自由流动的环境是保持微小的一个巨大优势。
大胆，骄傲地展现你的真实
你以为客户会被公司巨大的员工数量或产品数量所愚弄，但聪明的人永远会知道真相的，无论是通过直觉还是推论。尴尬的是，我曾经是这种善意谎言的一部分，对于重要的商业环节，他们没有任何帮助：为真正需要这项服务的人提供有价值的、长久的、互利的共赢关系。更好的做法是，真诚地对待自己的规模和产品宽度。
—— Khoi Vinh, Subtraction.com
无论何时
无论你在哪个行业，优质的客户服务是每个客户都会提出的要求。一开始，我们保持简单和透明，这样客户可以就他们遇到的任何问题与我们联系。我们在网站上提供了一个免费电话列表可以随时将电话转接到我们的手机上。我们向客户强调，他们可以随时随地向我们咨询任何问题。我们的客户很欣赏这种信任，从来没有人滥用这项服务。
—— Edward Knittel, 市场销售总监， KennelSource