问题4.2：参见上述问题，如果业务架构师也是客户，这不就意味着业务架构师和项目经理是平等的吗？
答案4.2：绝对不是。业务架构师是一名项目成员，服从项目经理的指挥，有时也要服从产品经理的指挥。项目经理管理项目。业务架构师承担组织为其定义的责任，而不管业务架构师来自哪里（如客户、供应商、承包商或公司）。
问题4.3：只有必需的功能才应该承诺给客户，我的项目总是这样做，还有什么新的观点吗？
答案4.3：大部分人在大部分时间，都提出了多于必需的功能。你是否遇到过这样的情况；因交付日期要延迟而选择删掉某些原来计划的功能？当项目启动时，每个人都发誓所有计划的功能都是必需的。但是，随着项目的进展——远远落后于进度表——某些必需的功能看起来就不再是必需的了。
经验4.9
如果在项目的开发周期中可以删掉一些产品功能（但认为产品可以交付给客户），那么产品一开始就含有非必需的功能。
问题4.4:好的，也许你有一定的道理，但客户不应该得到他想要的吗？如果结果比“满足最小需求”的多，那就这样吧。
答案4.4:对客户承诺不必需的东西，最后不能交付，甚至连必需的功能也不能交付，对客户是很大的损害。创建达到“满足最小需求”的产品，这种方法不仅对开发商，对客户也是件好事。对客户应该承诺必需的功能。如果交付更多的功能，那是奖励，但不应该作为基本承诺的一部分。以千年虫的项目为例来说明这个观点，看看什么是正确的做法。
例如，你识别出公司程序中需要100个功能（增强或修改）。基于你分配的优先级，这些功能分为高优先级、中优先级和低优先级。你知道这100个功能全部都是希望实现的，但因为资源限制，在期望的日期内完成所有的功能是不可能的。其中40个功能在高优先级，30个在中优先级，30个在低优先级。你会创建只完成40个高优先级功能的项目计划。为什么？因为你不会将其他60个较低优先级的功能包含在计划中而导致40个高优先级的功能不能按时完成——所有优先级较低的功能，都被认为是非必需的。
你可能认为应该创建包括100个功能的计划，之后，如果项目遇到麻烦时，你总是可以撤销更低优先级的功能。这个计划会带给客户错误的期望。不要这样做！这个愚蠢的计划要求将宝贵的时间、金钱和资源浪费在其他功能上，而不是最重要的功能上。而且，当你撤销功能时，也需要成本。要创建能够明显减少返工的计划，这意味着原来的计划必须只实现必需的功能。
其他60个较低优先级的功能怎么办呢？你必须仔细检查它们，并且准备好权变措施，权变措施虽然不是最优的，但可以使你完成必需的功能，然后再采取更多实质性的行动——在未来发布中发生的行动。
但也有其他方法，选出60个功能中最重要的功能——可能是30个中优先级功能的全部或其子集，然后利用你掌握的所有资源，创建多个独立的小项目。我将这些小项目统称为“壁橱计划”。对它们的质量管理要与主项目同样小心和注意。如果这些小项目中的任何一个可以在预定日期内完成（如系统测试），并且它带给主项目的风险是可接受的，那么已完成的小项目可以合并到主项目中。这种做法有许多优点，例如，可以降低对主项目的风险，激励小项目的成员在预定日期内完成，设置的客户期望可能被满足或超越。
……
展开
