经验法则3 制定多版本的技术计划
团队成员之间的未来的信任程度将取决于他们有多想承诺和参与我所谓的"技术计划"。这个技术计划是"授权式共识"产生的重要成果，也是将来一切信任的基础。在"授权式共识"建立的大民主的氛围中，每一名团队成员都有资格投票决定技术计划。更为重要的是，每一名成员的观点都会经过严格的审查。技术计划是所有团队行为的基础：理想情况下，它体现了所有团队成员的最佳创意。
技术计划是成员之间协作的约定，也是团队的章程。技术计划每年更新一两次，它表述的是所有团队成员的共同目标。这让成员觉得放松，认为将来能够彼此信任。
技术计划建立了一种可信的"明日世界"。因此，举例来说，如果某位团队成员在当前版本中的工作不是他最喜欢的，他可以期待在下一个版本中分配到更好的工作。或者，如果某位成员不赞同当前产品的发展方向，他知道自己需要忍耐，等到技术计划下次更新时再表达自己的想法。
技术计划在产品推出阶段也有极大优势。如期交付的问题在于：在技术上，开发人员总是雄心勃勃，也因为过于重视技术而延误了推出日期。但是，如果人们相信未来，那么，他们就会有一种紧迫感，因而在最终期限前完成工作。
简单的解决方案很易于理解，人们会说："哦，是的，我知道该如何做了。"
当每个人都清楚地知道他们将会做什么时，大家就会投入工作。这个简单的解决方案也将为你扫清其他一些未知障碍。
技术计划实例
一次，我以观察员的身份加入了一个正在制定技术计划的团队（并非微软公司）。团队的项目经理是该公司主要技术领域的一名高级开发经理，她审阅了下属提交的五份报告。他们决定将项目时间定为5年。（在当今这个技术时代，即使2到3年的时间也已经太长了。我不建议5年。）然后，他们继续辩论与他们所在的领域有关的各种技术的优势。
我发现，他们在长时间讨论一个有趣的问题：他们的一项关键技术长期没有得到更新和修复。他们已经不再为它感到骄傲。这项技术给他们制造了许多麻烦。它容易出错、漏洞百出、庞大臃肿，而且运行缓慢。其中的一些代码甚至是十多年前写的！它已经无法反映现代的设计理念。团队成员甚至都不愿意去接触这段代码。
我怀疑每个开发组织都拥有这样一段（至少一段）复杂陈旧、缺乏灵活性、难以更新而又让人敬而远之的臃肿代码。慢慢地，这样的代码会变得无法维护，或者难以添加新的功能，这极大地抑制了团队创建优秀软件的潜力。
我把这种恶化综合症称做"软件开发的恶性循环"。对于这项技术，你不可能既重新设计它的代码，同时又推出它的下一个版本。谁能够承担这样的后果：花上整整一个或两个产品周期修复代码，而在这个过程中只能为客户提供很少或根本无法提供利益？客户的利益只有在几个版本后才能体现出来，这时灵活性更高、适应性更强的代码能够帮助团队添加更多功能、改善性能，而不会受到旧代码的限制。
更深入和关键的问题是：这种状况是怎么造成的呢？是什么样的技术管理导致了如此可怕的后果？如果不仔细分析导致代码变得如此陈旧臃肿的根本原因，并进行补救，那么，进行大规模修复将会毫无用处；恶性循环仍会再次重演。我们不能重蹈覆辙。
在这个团队，几名新加入的成员和那位高级开发经理（她同样刚刚加入团队）一起负责管理这项陈旧技术。无疑，他们给团队带来了新的活力和希望。团队成员希望重新设计这项问题多多的代码。他们希望为自己（作为技术人员）和客户（作为用户）创造更多的机会。
但是，负责制定计划的几人管理小组却倾向于购买一项全新的技术，以其作为将来开发的基础。当他们向团队成员提出这一想法时，得到的是截然不同的反应。一些成员认为这种做法很棒，因为代码已经过于陈旧，无法修复，他们宁愿购买全新的代码，哪怕与之前版本的代码之间可能存在兼容问题。但其他成员却认为他们完全有能力修复旧的代码--"只要管理层给我们这个机会"。
项目经理也是左右为难。在情感上，她倾向于给团队这次机会，让他们修复他们自己的技术--一项他们付出多年努力的技术。但是，在理智上，她又担心整个团队还没有做好接受如此严峻挑战的准备，特别是考虑到他们糟糕的业绩记录。她并不认为这是"项目管理"上的失误，尽管她认为，任由这种技术性和组织性恶性循环持续至今，是前几届的项目经理失职。
在大多数组织中，如果"管理层"满足于马虎草率的工作，想方设法只利用新技术，而不是持续扶持、发展一门稳定的技术，那么，优秀的人才就会流失。不思进取的人会留在组织中，自尊自重的人则会离开。这样，组织和技术都会慢慢走向衰亡。
不过，在我说的这个例子里，有足够的新生力量（包括经理本人）加入团队，从而打破这项糟糕的技术长久以来形成的一潭死水。但是，团队缺乏的可能是管理层对于优良技术的追求，对于团队成员职业生涯规划、创造力和公共福利的承诺。项目经理希望自身的努力可以改变这种现状。
最终，她冒着被解雇的风险，授予团队权力，支持他们对代码进行修复。她的这个决定不仅使得这项技术仅仅在一个产品周期内就重新焕发出活力，而且还在其中添加了几个关键功能，实现了如期交付和部署！与此同时，她也失去了几名认为团队和该技术无可救药的组员。
第二次更新技术计划时，这位高级经理并没有组建一个小规模的任务小组。相反，她对下面的主管进行培训，让前线队员参与制定技术计划，从而使负责其交付的制定者的梦想和愿望充分体现在计划中。她还鼓励其他主管对技术计划中的其他软件开发原则展开讨论，并与管理高层进行沟通，从而抓住每一个好的创意和达成共识的机会。
制定技术计划的方法有许多种，但最重要的是制定出这么一个技术计划。可靠的技术计划的好处多多。可能最基本的是我们必须有意识地"舍弃"或"割爱"一些东西。如果你明白前进的方向，那么，你就会知道所采取的步骤是否能够帮助你更加接近目标。除非制定清晰的多版本发布计划，否则，你将永远无法获知你需要做多少工作。
完善技术规划
我观察到的另一个技术计划的制定过程是达成"授权式共识"的典型例子。来自开发和项目管理部门的"情报员"接受了任命，用一两个月的时间制定出了大致的设计计划（请参阅经验法则5）。然后，该计划草案将在负责执行计划的团队成员（共约80人）之间传播，由他们发表意见、展开讨论，并最终达成初步一致。
同时，该计划被呈交给上一级主管，由他们将大量相关的技术计划整理成一个多版本的产品计划。这些主管根本不会修改这些计划，因为他们知道，这些计划所达成的共识是多么来之不易和宝贵。但是，他们也注意到，提交的这些计划就像是一份份长长的清单，上面列着一些相互之间毫无关联的功能。如此冗长的功能清单如何能够激发团队开展后续几个版本的工作呢？他们又将如何向外界解释这样的清单？如果简短有力的营销信息要基于数十项无关的功能，他们又如何向全世界传达这样的信息呢？
主管们还发现，这些功能可以分为5种类型：策略型、竞争型、客户满意型、投资型，以及他们称做"示范型"的功能。他们所谓的"示范型"功能，是指如果连续在多个版本中实现这种类型的功能，将最终改变人们的工作方式。当然，这并不是说这种示范的改变不具有竞争优势或者不属于策略目标的一部分，也不是说策略型功能不满足用户的需求。主管们这样分类，只是为了对每一类功能进行准确定义。
策略型功能主要涉及基本和限制性选择：该产品将支持何种操作系统？采用什么样的对象模型？针对哪些微处理器？支持什么语言？而且，这个类型中的特定功能还会在一定程度上影响总公司的发展策略。例如，总公司主要生产由他们提供专门支持的打印机。
竞争型功能主要用于回击乃至打败竞争产品具有而自己没有的功能。它们不需要提供竞争产品所拥有的每一项功能，但是，如果一些功能引起了新闻媒体和客户的关注，则这类功能将成为己方的投资重点。这类功能的数目非常之少。
客户满意型功能是指他们一直听到的客户需要的功能。只要听一听客户的声音，就可以发现大量客户满意型功能。这类功能的数量众多，但开发每一项功能的成本相对较低。
投资型功能是指那些项目团队决定在技术中添加，但其利益不会在下一个版本（甚至是下几个版本）中显现的功能。不言自明，任何投资型功能都必须在
后续版本中释放巨大的潜力。这一原则要求开发团队必须尽力从这部分投资中取得最大回报。
如前所述，示范型功能是指那些改变人们工作方式的功能。基本上，它们代表一个团队为之奋斗的最高目标。在每个版本中，开发团队都会设计出大量功能，希望实现这个梦想。营销部门也会在连续几个版本的对外宣传中宣称，具有这些功能的产品将提供持续的改进，并在市场中占领主导地位。这些功能还会颇具竞争性地改变游戏规则：如果你成功开发出示范型功能，而竞争对手缺乏与之匹敌的功能，那么他们将完全失去竞争能力。
对所有功能进行适当分类后，主管们试图确定每一类功能的投资等级。他们为每一类功能分配了合适比例的资源，然后着手协调投资等级与技术计划要求之间的关系。最终，他们对各开发小组之间的内部资源分配感到满意。请读者以此为练习，确定应为每一类功能分配多大比例的资源。
然后，他们召集所有团队成员，连续5天。每天用两个小时逐步审核整个技术计划，特别是下一个版本的计划。这5天（以及紧随其后的一段时间）是任何人及团队每位成员就计划的合理性发表自己看法的"最后"机会。（当然，计划也不可能一成不变，这也是充分授权的一个基本原则。）因为该计划从一开始就是以自底向上的方式制定的，所以，很少有人对它的内容感到意外。管理层负责将各类功能组合成一个有条理的产品计划，因此，团队成员能够迅速分清该计划的目标并就此展开讨论。整个过程开放而民主，在建立自己的目标时，团队也获得充分的授权，这将极大地减少争议，团队成员的工作热情和积极性也因此高涨。整个团队感到有了共同的前景。事实确实如此。
这是我所观察到的最佳规划过程。在我撰写本书时，根据该计划开发的第一款主要产品即将推出。这看上去是一款伟大的产品！
每个人都必须对技术有一种清晰的使命感，在对新的创意进行详细分析之前，应首先考察这些创意是否在技术计划规定的范围之内。这有助于团队成员了解计划内的工作范围，并认识到任何新点子都必须经历多方面的考察。因此，一个创意必须具有相当的价值并切实可行，才能提交给团队进行考察。这样做有助于减少过于随意的提案，并建立一个相对稳定的环境。
最后，将技术计划中的功能划分为策略型、竞争型、客户满意型、投资型和示范型功能，可以帮助管理层监控投资等级并发现问题。例如，如果产品失去技术领先优势，管理层可以更迅速地强化对示范型功能的投资，同时减少对其他一类或几类功能的投资。