听了S总的约法三章，小M冷静了也平静了，开始跟S总商量对策。小M说：“我也知道不能加人了。但这个项目有两个后墙不倒的条件：第一，时间只有6个星期，必须赶在大规模开发之前完成，否则这个开发工具就没有啥意义了。第二，4个人的编制、6周能完成的工作也就那么多。可是他们都觉得自己的需求重要，不同意减啊！”
S总笑了笑：“这几个组长都是‘老奸巨猾’，都想用你的力量解决他们的问题！你问过他们没有，什么才叫最重要的功能？！”小M愣了一下：“这个，还真没问……”
S总说：“呵呵，之所以做这个项目，是想提高开发的效率和质量，但是这是需要投入的！重要不仅要看能带来多少好处，还要算算需要多少投入！如果投入的工作量是1人天，能省的工作量是5人天，则投资收益比就是5；如果投入的工作量是1人天，能省的工作量也是1人天，则投资收益比是1，做不做工具没什么区别。站在公司角度，投资效益比大的才是最重要的；站在三个组长角度，他们不需要投入，做什么都稳赚不赔，所以能多争取一点是一点啦！”
小M恍然大悟，怪不得三个小组都不让步，看来，应该先把“什么是重要的”这个原则定下来才有取舍的依据。商量之后S总让小M做两件事：第一，整理个表格，把所有的需求列出来。由小M评估投入的工作量；由三个组长评估能节省的工作量。第二，通知三个组长明天中午12点开会确定需求，而且S总会参加。
小M奇怪为什么选12点这个时间开会，下午1：00就要上班了，1个小时怕来不及吧。S总笑了笑：“这个时间他们没有理由请假，也没有时间扯皮。”
小M准备好表格，为了保险起见亲自拜访了3个组长，请他们评估每个需求能节约的工作量，并通知第二天中午12点参会。果然，有的组长刚开始推脱不想参会，后来听说S总参会，又找不出请假理由就只好答应了。小M心里说：S总果然英明！
晚上S总打来电话，让小M把整理好的表格先给他看看，又指点小M进行了一些修改。小M心里非常钦佩S总认真细致的工作态度。
第二天中午12点大家准时到会。小M简单介绍了情况，开门见山地说按照6周工期昨天谈的需求不可能全部做完，因此要定夺需求范围。
小M话音还没落，几个前辈纷纷表态都说自己小组的需求绝对不能砍。等大家都说完了S总才慢慢地说：“咱都是做技术的，这个小组才4个人，他们6个星期能做出点什么大家都应该心里有底吧？不减需求就要从你们的组里抽调人员了，同意吗？”一听要抽调自己的人，三个组长纷纷表示那还是减需求吧！(www.xing528.com)
S总说：“一个星期5天，6周就是30个工作日，4个人干6周也就是120人天的产能。好钢用在刀刃上，这些产能必须首先完成收效最大的需求，对不对？”看大家都提不出啥异议，S总说：“同意这个原则那就好谈了。”
于是，S总请小M拿出昨晚整理好的表格，上面列出了每个需求的工作量是多少，预计可能节约的工作量是多少，并按投资收益由高到低的顺序排列。大家对小M评估的开发工作量虽然做了一定的调整，但是排列顺序没有大的改变，见表2-1。
表2-1 投入产出评估表
接下来小M从第1个需求开始逐项往下累加投入的工作量，结果加到第6个需求的时候工作量就满120人天了。S总说：“这就是需求边界啦。”
后台和平台两个组长最先表态说没有问题，但那位难缠的前台组长一直若有所思地没开口。小M紧张地盯着他怕他又要发难了。没想到他说：“第7项需求虽然不能节省太多工作量，但是可以提高开发质量。我们前台组派一个人参加这个小组，把第7项一起做了吧。这样我们自己受益，快速开发工具也相对完整。”听到这话小M心里一块石头落了地，对前台组长油然产生了敬仰之情。
小M看了看表，昨天吵了两个多钟头没结论，今天一共才开了30分钟的会就确定了需求范围，还意外收获了一个组员。小M感慨，姜还是老的辣啊！S总没有去讨价还价，而是先定下共同认可的规则再一刀斩下，如此棘手的问题就这么迎刃而解了。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
