将陷入可怕的范围蠕变 ( scope cre 叩 ) 中， 如果你不能有意识地管理要求。这个词总会让我想起一个景象：一个雪球向前滚了一英寸 — 接着又是一英寸 — 每一次滚动都会捎带上更多的雪，直到冲到山脚下。这个过程中，雪球变得越来越大，也越来越难以阻止它与这个景象相同的每一个额外的要求看上去并没有增加太多的工作量，但是当它汇集到一起的时候，整个项目就会失去控制地膨胀，结束时间遥遥无期，而费用预算正不可避免地朝着最终的分崩离析飞奔而去。

　　就像慢跑或练习钢琴一样。而我做的另一些事情是因为其产品具有价值，做的某些事是因为其过程具有价值。就像做一块蛋糕或修理一辆汽车。定义项目范围就包括了这两方面：一个有价值的过程导致一个有价值的产品。

　　当整个事情还处在假设阶段的时候，过程 ( pro “ss） 价值在于。能迫使你去考虑潜在抵触和产品中一些粗略的点。可以确定现在整个的网站建设网站建设中能解决哪些事情，而哪些必需要再迟一点才能解决。

　　给了整个团队一个参考点， 产品 ( product ）价值在于。关于在这个项目中要完成的全部工作，也提供了一门共同的语言，用于讨论这方面的事情。定义好你要求能保证在开发过程中不会出现模棱两可的情况。

　　但还是没准备好向真正的用户推出。用我方法去做的许多事情都是不对的技术不稳定、好像根本不了解用户，曾经设计过一个似乎永远是Beta 版 网页应用系统：差不多。同时我整个企业中唯一一个在开发网页方面有一些经验人。

　　当我所有的人都在同一个办公室里工作时，但是这些都不能解释为什么我不能推出这个产品。最大的绊脚石是没有一个人愿意去撰写一个文档。终究。记下每一件事是很麻烦的除此以外，产品经理也需要把他精力集中在新功能的思考上。

　　就产生了一个不断变化的混合了完整产品的各个阶段功能的产品。只要有人读到一篇新文章或一个新的想法， 这样做的结果。都会启发这个产品的负责人的灵感，然后考虑增加另一个功能特性。倒是有一个固定的工作流程，但是没有日程布置，

　　项目也看不到尽头。因为根本就没有人知道这个项目的范围，没有里程碑。又怎么能知道它应该在什么时候结束呢 ?

　　这件事很麻烦，用文档来说明项目要求。但是必需要做。

　　这是由于以下两个主要原因：

　　原因一：这样你才知道正在建设什么。

　　但是对于正在建设某个应用网页应用 顺序的团队却是一个惊喜。如果详细地记录下你正在建设的内容，这似乎很明显。每一个人就会知道这个项目的目标是什么，什么时候达到这个目标。最终产品不再是一个停留在产品经理头脑里的不定形的图像，变成了一种在企业内部的每一个级别的每一个人都触手可及的东西，从高层管理人员到入门级的工程师，人人都能参与进来。

　　项目很可能会变成一个叫做 “ 电话 ” 校园游戏 — 团队中的每一个人都得到一个关于产品的印象， 如果没有文档的要求。然后通过口口相传的方式传送进来，每个人的描述都略有不同。甚至更糟的可能是每个人都认为他人肩负着管理产品关键环节的责任，但事实上这个人并不存在

　　能让你把责任分配得更清晰， 拥有一系列明确的要求。这可以大大提高协作的效率。解了一个详细策划的完整范围之后，就可以看到各个相对独立、也不显著的要求之间的内在联系。早期的讨论中，支持文档和产品规格表可能看起来像是独立的功能内容，但是把它作为要求确定下来，会让这种有所交叠的事情更加明显，并且同一个小组的人可以把它都负担起来。

　　原因二：这样你才知道不需要建设什么

　　但是对于项目的战略目标并不是必需的此外， 许多功能听上去都相当诱人。所有在项目开始如火如茶地进行时，关于功能的各种各样的可能性都会浮现出来。当这些想法出现的时候，用一个文档来记录它可以为你提供一个评估这些想法的架构。

　　找到一种适宜的方式，解 “ 不需要建设什么 ” 也就意味着知道哪些是不需要马上去建设 ” 东西。把这些杰出的想法收集起来。让它符合你临时规划，这才是真正的价值所在确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在未来功能囤积起来，只有这样才干用一种更慎重和有意识的途径来管理整个设计过程。

来源于风采网络科技有限公司官方