至于项目边界，这一点相对来说比较困难。因为我们在和客户签订合同的时候，只是粗条的需求，但是需求的深入以后，很多事情未必那么说得清楚。比如你显示一个财务报表，即使客户不说，你是否会安排打印按钮？一般来说，是必须的！所以，大致的边界比较容易说明，细节的边界还是很难说明。

更常规的做法是：保持和客户的持续沟通（使得客户了解将来的软件是什么样子的，并且我们哪些做错了），在能够帮助客户的地方，立即下手帮助。在一些明显超出系统范围以外，或者成本极其高昂的时候，一般以风险，成本因素和客户探讨。

在这一点上，强制给客户安上各种限制条件，是不现实的。因为从根本上来说，客户不关心你的开发成本（你说这个功能要100美元还是10000美元，如果客户和你较真，是根本不用关心的。你总不能因为自己很差的框架设计，需要客户买单吧），客户之所以关心，很大的一点，还是希望大家一起做好事情而已。

现在项目之所以难做的一个原因，不是客户认定的范围和我们不一致，而是客户实际上不是很清楚，他需要的是一个什么系统。企图使用外包项目的框架，来套用在普通商务系统的研发上，是会害死团队的。

呵呵，恕我直言，上面这篇文档实在太学术化了。我实在没有看明白，他如何能够在实际工作中落实下来。

IBM的一个Interview的题目：
你认为项目经理，最重要的技能是什么？
正常的回答是：
沟通技能。

在上面这篇文章中，我没有看见任何沟通方面的事情，这是企图用专业或者管理来弥补沟通问题，南辕北辙！

呼呼！气死了！同时感到羞耻！什么时候我们才能实际一些，而不是这么糊弄人！