很急，十万火急！

BA不管要把需求整理好，还需要为需求排优先级。排优先级大家都会， 什么困难价值举证，MOSCOW原则等，这些都是理论，咱们还是来点干货，来看看现实世界是怎样的？

在时间充裕项目松的时候，我们可能做简单的分析和align就可以敲定优先级。但是当项目很紧的时候，排优先级就是一个硬功夫了。

我遇到一个很典型的story （rule 11 =No, missing PU#, LFD...），团队说很紧急，十万火急，不做影响很大，要紧急加到快要完成开发的一个iteration中, 于是我去看， 真的有这么紧急吗？ 首先，我们来分析一下数据， 这种类型的数据有哪些？不同Carrie是否都有？数据量是怎样的？对于产生严重后果的missing PU#, LFD, 这些数据会怎样产生影响？结果分析下来，这种类型的数据目前根本不可能触发这个严重后果，因为现有的数据是OB的，而PU#.LFD只有IB才需要。

于是大家决定把这个story的优先级马上调低了，以后有真实的业务如果有需要再做不迟。

由此，总结一下几点：

1. BA必须对业务熟悉，才能有敏感的嗅觉，知道一件事的大致情况，这样才有发言权和影响力。

2. 用数据说话，不要单看系统逻辑，系统还得基于业务，不然可能会build一些系统看起来逻辑很完美但是业务上根本没有用的东西，浪费了团队的时间，这些时间本可以用来做更有价值的事情（机会成本）。

另一个是对优先级意见不一致：

一个系统不关是要交付功能，这涉及系统能做什么，另外一个重要的方面是，系统的质量属性，比如性能，可用性， 健壮性等，

今天来和大家聊一聊可用性的问题，有一个新功能要上线（EP rollou），功能测试已经完成，但是我对其中的可能性表示担心，因为用户可能得不到想要的数据，需要手动刷新才能做， 这会导致两个问题：1）用户可能不知道要刷新，从而导致有些数据可能在用户不知情的情况下没有操作，导致额外的费用 2）就算用户知道每次要手动刷新, 这也不能保证他每次都记得去手动刷新，人难免会忘记事情的 3）手动刷新， 肯定用户体验不好， 满意度要下降。但是开发leader却认为这样的问题不是一个严重的问题，不需要在rollout之前修复，我和团队商量了好几次， 但是仍然没有排上优先级。当干系人来询问是否ready for rollout时，作为BA 我把这个系统需要手动刷新的问题告诉了干系人， 然后干系人说这个问题一定要rollout前修复，开发leader也极力说服干系人不用修复，但是最后干系人还是坚持要在rollout前修复，这就造成在iteration中要紧急加入这个修复，给team带来比较大的压力。