史蒂文·辛诺夫斯基(Steven
Sinofsky)，微软Windows事业部前主管。微软Windows业务前总裁史蒂芬·辛诺夫斯基(Steve Sinofsky)本周在个人博客中刊文，阐述了在项目管理中如何确定项目范围。他认为，确定项目范围是项目开发最重要的第一步。原文较长，精简版请点击：Windows前主管：如何进行产品开发决策。
开发一款产品，无论是新产品还是产品升级，都意味着需要决定产品中需要及不需要哪些内容。在执行中，主要的限制因素是你愿意向产品投入多少时间，或者说多少开发人员。在计划中，你需要确定合适的工作量，合理调整产品计划。确保项目有着合适的规模，同时仍能很好地实现目标，这就是核心的产品开发技能。
什么是合理调整？
对产品开发的讨论大多处于细粒度的水平，包括某项特定功能，投资结构，以及如何沟通工作。不过，仍有一些宏观因素会对产品开发产生较大影响。项目最重要的第一步就是确定"范围"。确定项目范围需要各个利益相关方的积极对话。
在软件和服务项目中，项目等同于软件和服务。这种项目的范围决定了一系列选择，甚至你阐述项目范围的方式都会带来或摒除一些选择。一开始，你需要确认当前的基础：
全新的产品。对于新产品，你有机会设计一个最小功能集或最小需求集的产品。换句话说，你可以有意识地选择最少的功能和投资，来实现你的应用场景和目标。这通常被称作"最小竞争力产品"。"新产品"的另一个方面在于，这样的产品对公司或者对整个行业来说是否是全新的。对公司而言的新产品和对行业而言的新产品通常有着不同的范围。对创业公司而言，最小竞争力产品很有意义，因为它们并不知道"最小"为何物。而对成熟公司来说，这将存在挑战，全球化、可访问性、安全性，以及与现有基础设施的整合都是需要考虑的问题。成熟公司可以为"最小"设立更高的标准。
对现有产品的改进。大部分软件都是对现有产品的改进。在改进现有产品时，需要确认的范围主要在于这些改进是否与当前产品兼容，这包括用户体验(按键点击、信息流)、数据(文件格式、此前存档的文件和设置)、功能(产品能干什么)和平台(API、插件)。在为现有产品制定计划时，预先确定所有方面将会使你付出代价。但对外部人士和管理层而言，这难以理解。回归测试、设计限制，甚至是你选择对现有功能做什么样的调整，这些都会影响新版本所需工作的范围。有时，尽管只是对现有产品的改进，但一款产品对某家公司来说仍将是全新的。在这种情况下，从市场竞争角度而言，以上的限制因素也会存在。
彻底改造现有产品。任何项目在一段时间内都可以接受增量式改进，但最终仍需要大幅度调整，具体原因包括应用场景发生变化、规模受限，以及用户体验老化等。在项目最初，如果你已经意识到需要彻底改造一款产品，那么你将面临不同的项目范围挑战。首先也是最重要的是，你需要明确项目的哪一部分需要改造。例如，你是考虑重新实现现有产品，还是希望对产品的某些部分，例如用户界面、API和功能，进行架构的重新设计。有些时候，产品对你的公司来说是全新的，但将对一款竞争对手产品造成很大影响，这意味着需要从不同角度去看待产品面临的限制。
并行的产品。考虑项目范围的一种方式在于，预先确定你的项目将与另一款产品共存，帮助你的客户或公司解决一个类似的问题。这种方式在企业内部IT系统中非常典型。在这类场合中，新系统在搭建之后将与老系统并存，并经历一段转换过渡期。对消费类产品而言，并行产品可以被简单地描述为"继续以你的方式去做，但同时也可以试试我们的系统"。这样的方式在项目开发早期可用于你瞄准的客户。
这样的分类方式更好地覆盖，或更加贴近我们很多人从事的软件项目。通常，我们看待一个项目的方式只是"新产品"或"升级"，但却过度简化了项目范围。
如果团队不太清楚项目范围，那么项目在起步初期将遭遇困难。确定项目范围是一个工程选择，而不仅仅是在介绍产品时对产品进行定位的一种方式。例如，你开发的一款产品可能是对当前产品的改进，但却没有确保一些基本功能的实现。试图将产品定位为"全新"或"并行"也可能带来麻烦，因为代码中的许多选择并不符合这样的定位。人为的缝隙对客户和评测者来说可能非常明显。由于在产品开发中可能有许多挑战，你可以回顾项目历史，包括成功的历史和失败的历史，以发现常见的挑战。
确定项目范围时的陷阱
确定项目范围并就此达成一致是重要的第一步。在这一过程中，团队不同成员可能会对此提出异议。
如果你在开发一款企业级产品，并提出了将打破兼容性的一些元素，那么你需要做好项目范围的确定，因为你将立刻面临企业销售团队的"要求"，即在计划中恢复兼容性。
而涉及笔记和写作的消费类产品毫无疑问需要提供基本的文字和图像处理功能。人们可以预计，评测者会将这样的产品与现有的热门、成熟产品进行对比。我们已经很熟悉，一些产品的最初版本尽管带来了颠覆，但仍遭到了尖锐的批评，因为其缺少某些"必需的核心功能"，例如复制粘贴。
在确定项目范围时，大部分情况下最初的理念误区在于，被搁置的分歧，或者说不同观点，未来能够很容易地解决。在人们的观念中，一种应对方法是，产品的创新性对各方来说都显而易见，因此一旦人们看见产品之后，所有"超出范围"的问题都将从分歧走向共同的理解。但根据我的经验，这样的方式并不一定有效。
当你确定一个项目的范围时，最困难的挑战是，你认为"显而易见"的东西，在用户没有看见产品的情况下，对用户来说很容易被忽略。你可能知道，你能增加一些市场上现有的功能，可以打破兼容性，可能需要与其他产品并行，或者还没有准备好添加复杂字符集，但如果产品没有被展示给同事、管理层和评测者，甚至说团队没有看见整个产品，那么你总有可能遭遇许多麻烦。如果曾经有过这种经历，那么你肯定不会对这种情况感到陌生，你将准备好继续推动项目进行，同时不断阐述你如何以及为何做出这样的选择。
即使做好了这样的准备，在项目从规划到执行的过程中，合理调整项目规模仍会出现一些常见的陷阱。这些陷阱可能会在产品集合到一起时出现，也有可能在首个客户看到产品时出现。这也可以成为一款产品无法最终推出的原因。
- 设定不同的项目范围。对任何项目，最严重的失败在于你认为可以在项目进展过程中重新评估项目范围，同时仍可以按时交付。如果你决定打破一款现有产品的兼容性，并开发全新的功能，那么你将需要为新功能重新设计架构，对现有产品进行删减，或是采取巧妙的折中做法。退一步说，你真正要做的是重新评估对整个产品的做法。尽管这是可能的，但你不可能凭借已有的资源，按进度完成工作。
- 项目范围过大。我们大部分人在确定项目范围时，都会尝试去做凭现有时间和资源难以完成的工作量。如果你对项目范围非常清楚，那么一个健壮的产品计划将拥有相当大的灵活性来解决这方面问题。换句话说，过长的功能列表很容易被缩减。这与尝试调整项目范围完全不同，因为调整范围可能意味着对一款产品的彻底改造将变成增量式改进。如果你面对太多的功能，但产品发布意图仍符合这一很长的列表，那么我可以肯定其中一些功能可以被删除。
- 项目范围过小。在当前的环境下，最小竞争力产品是一种开发创新产品的好方式，但采取这种做法时，你很可能会使项目范围变得过小。在开发新产品时，这意味着你还没有真正瞄准创新，或者产品的附加值。类似地，对任何涉及数据中心(或其他资源)部署，以及存在合作伙伴承诺的项目，应该更多地考虑总投资，而不是总投资回报。而在对现有产品进行改进时，采用这种方式的产品发布可能会被认为过于保守。这也可能导致你失去关注重点，在许多方面都仅仅完成了很少的工作。
- 错误的事情。在确定项目范围时，一个常常被忽视的陷阱是，你可能会选择解决错误的问题。换句话说，计划可能是切实、可实现的，但对项目范围的错误定义导致你从事了错误的工作。简单地说，这就是选择去做错误的事情。这一陷阱通常出现在你做这些事的过程中，例如增加更多工作量，在途中重新确定项目范围，或是彻底改变项目范围等。在改进现有产品时，从事了错误的工作是一个常见陷阱，这通常是由于在确定项目范围时缺乏对工作优先级前后一致的看法。
- 针对本地市场或全球市场的优化。确定项目范围本质上是为了优化。对改进现有产品来说，你可以选择某一特定方面，并在下一版产品中对其进行重新优化。对新产品开发来说，最小竞争力产品就是寻找价值链的某一环进行优化。撇开项目范围，问题在于，在项目进行过程中进行的调整是在优化一个正确的计划，还是一个错误的计划？你可以进行多版本测试，或是重新定位产品，但如果你所关注的价值曲线的某一部分并不具有太大价值，那么这无法带来帮助。你所进行的优化是针对一个最理想的产品，或者只是改进你自己的那一部分，并不足以给整个产品带来改变？
当然，项目出现错误的方式多种多样，一些问题严重，另一些问题则不大。实际上，项目开发的一部分就是处理这些不可避免的问题。不会有什么项目一帆风顺。正如"阿波罗13号"，当第一个小故障出现时，你可以告诉自己"先生们，我们似乎出现了故障"，也可以警示自己将有更多故障出现。这是复杂产品开发过程中的正常现象。
合理调整的方法
提前对项目进行合理调整将同时带来约束和灵活性。
合理调整意味着提前弄清项目的边界。如果你对项目的条件限制和战略限制很清楚，那么你就实现了使一切保持正轨的第一步，能够确保你对团队、客户和管理层有关产品开发的承诺。考虑这些限制的一种方式是关注项目范围的关键变量。通过提前确定这些变量的值，你将可以对项目进行合理调整。
从项目管理角度来看，条件限制是项目的支柱。你可以将这些视作预算或基础，或者起始点。
- 人员。有多少人将会工作于这个项目？这是一个最简单的问题，也是最容易在一开始就解决的问题。一个好的原则是，项目计划的制定应当基于你从第一天开始有多少人员。尽管许多项目将随时间而加人，但如果依靠这些人去做关键工作(尤其如果这一项目不会持续很多年)，那么你很可能会失望。由于人员的自然流动，大部分项目在进行过程中都会出现人员调整，因此最好的做法是假定补充的人员只能填补离开的人。
- 时间。另一个简单的项目范围变量是，你的项目将持续多长时间。无论是按周还是按年，你都需要提前确定。持续集成模式的使用者还需要弄清，在某一特定代码以某种方式发布给客户之前，代码的计划和编写需要多长时间。如果有多个团队同时需要发布代码，那么确定这一时间并不是一个孤立工作。对于团队成员，你可以增加工作时间，但不要期待工作成果的相应增加。众所周知，一旦项目启动，如果试图减少工作，那么结果往往难以达到预期。许多利益相关方都会对项目应当持续的时间有自己的看法，但这不能独立于你所能完成的工作去看。
- 准则和工具。对任何从现有产品基础上开始的项目而言，项目经理需要慎重考虑，什么样的代码需要继续开发，什么代码需要被替代或调整架构。从一款现有产品开始意味着许多其他因素也遭到限制，例如工具、编程语言，以及云计算基础设施。对于新产品，提前确定这些将是合理调整项目范围的重要一部分，而在项目进行过程中这些选择不可能改变，因为这不仅仅影响项目进度，还将影响功能的实现(例如原生应用和HTML5应用，以及采用什么样的身份验证基础设施)。提前确定的准则将影响与兼容性有关的项目范围。
这些条件因素与产品策略有关，但不会决定产品策略。一般情况下，产品发布节奏是一种策略，但也反映了项目的种种条件因素。战略限制是项目的围墙，构建在条件限制之上。你的战略就是你如何选择项目去做什么，不做什么。一些战略限制需要提前考虑。
- 大赌注。每一个项目都会下几个，甚至一个大赌注。对现有产品来说，赌注可能是新的用户界面或新的业务模式。对新产品来说，这可能是关键的知识产权和全新的应用场景。这样的大赌注是团队中所有人的战斗口号，也是所有人愿意为之付出的动力。
- 用户。所有项目在开始之初都需要知道，谁将会使用产品。毫无疑问，这听起来很容易，但在确定项目范围时，这意味着项目瞄准的所有潜在客户，其需求都不可能100%的被满足。了解如何给相关客户带来价值是合理调整项目范围的关键一部分。如果你在现有产品基础上开发，或是打破现有产品，或是开发新产品，那么毫无疑问一些人会认为，新产品无法满足他们的需求。但这并不是说，你永远无法满足他们的需求，也不是说，所有客户都会这样认为。
- 长期前景。在合理调整项目范围时，你会希望知道，你将向何处发展。有很多方式去了解，包括复杂的方式和简单的方式。以往的业务决定了你将向当前工作投入多少资源。如果你能知道未来的发展方向，而不仅仅只是当前一个版本，那么你可以走过更长的路。对长期前景的讨论并不等同于长期规划。长期规划是一种复杂的方式，你可能会做出一些无法实现的承诺。我们都知道，团队、市场和业务的所有方面都会发生变化。但对长期前景的讨论将使所有人都感觉到"思考"正在进行。对待这种工具的方式之一在于，确保对话关于团队正在思考什么，而不是团队正在做什么，因此对长期前景的讨论不会变成列举长期承诺。
总而言之，建立产品计划的第一步是对产品范围的合理调整。在这一步中，常见的问题是极端化，例如过小或过大。在实际情况下，业务开展状况将决定什么样的合理调整才具有竞争力。你可以使用一些工具，主动确定项目的规模，而不是等待项目自然的发展。以长期眼光去合理调整当前项目将使项目保持合适的规模，同时仍能实现目标。与产品开发的其他方面类似，做好准备，并预见未来的挑战将是最好的应对方式。
本文编译自Learning by Shipping
(李玮)