刚解决完我们为用户创造价值的问题，又马上迎来了不能如期交付的问题，这可怎么办，按照现在的计划可是要延期半个月的。

于是，我们从项目的制约因素上想办法。项目的制约因素包括范围、时间、成本、质量。质量在我们看来是不可妥协的，我们唯有从范围、时间、成本上考量。

于倩提出需要先从成本考量，项目只有15个人，能否调一些人员过来一起参与？于是，于倩找到了老板张大牛，结果碰了一鼻子灰回来，得到的答复就是：人没有，项目还得按时交付，自己想办法。

这可为难团队了，就算加班也不可能把半个月加回来，再说加班不单单会对士气有影响，还会因为疲劳作战，造成项目质量下降。

正当大家一筹莫展的时候，马丁顾问站了出来，和我们讲述有一个好办法可以解决问题：砍需求大法，就是把需求列表拿出来再看看，排序，有什么不是非做不可的，或者可以简化做的，这样不就搞定了。

于是，大鹏准备了需求列表，陈恭组织我们开了一场需求梳理会。

在会上，我们首先把V1.0版本列出来，对“吃什么”功能进一步拆分，把“吃什么”分解为：

（1）收藏菜谱。

（2）菜谱分类。

（3）查看菜谱信息。

（4）搜索菜谱。

（5）菜谱一键下单。

于是得到这个分解后的表4-2。

表4-2 分解后的表

拆分之后，我们再来进行优先级排序，我们在这个列表之后加上一列：价值优先级。

价值排序方法，我们使用的方法是MoSCoW法，因为这种方法比较简单，所以被普遍采用：

（1）Must have（P1）：必须有。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能，比如房子就应该四面有墙。

（2）Should have（P2）：应该有。这些功能很重要，但不是必需的。虽然“应该有”的要求与“必须有”一样重要，但它们通常可以用另一种方式来代替，去满足客户的要求。

（3）Could have（P3）：可以有。这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交付时间紧张，通常现阶段不会做，会挪到下一阶段或者下一期做。

（4）Won’t have（P4）：这次不会有。最不重要，最低回报的事项，或在当下是不适合的要求。不会被计划到当前交货计划中。“不会有”会被要求删除，或重新考虑。

然后我们再根据MoSCoW排序方法，把功能和子模块依据这种价值排序法排序：排序完成之后，得到表4-3。

表4-3 排序法

通过这样的办法，我们识别出来最重要的是要优先完成P1，通过对P1的估算，我们发现P1交付可以赶在8月份完成，P2和P3如果有时间就先做P2，再做P3。

通过这场需求梳理会，我们完成了一次对竞争性制约因素的平衡。