需求优先级

晚上在整理630版本的业务需求，总共130多项，部分需求在MRD阶段已经被毙掉，主要是时间点不匹配，需求明显不是这个阶段应该做的，但也有非常多的需求没有非常明确的判断来说明是否现阶段做，产品可能认为没有到这个需求上线的阶段，但业务认为做了这个需求可以帮助我解决一些问题，所以就统一纳入了630版本。

但即使MRD评审了，也并非明确了630就一定会上线，资源总是紧缺的，时间总是有限的。

需求优先级如何划定呢，结合商家和运营两个视角，我把需求做了划分，站在商家视角，菜鸟提供的服务无非分为2C渠道端服务，2B物流端服务，专注供需匹配的共享菜园服务，再加上关乎用户体验的服务顾问以及最终密不可分的结算和账单能力。站在运营视角，还是回归到仓/干/关/配能力升级上。单纯的运营能力升级的需求由负责的业务方各自排序，说清楚需求对运营带来的价值即可，根据价值来决定优先级或者直接按照业务方提交的优先级来支持。站在商家视角，有影响商家引入的，影响商家留存的，影响商家周转的，影响商家体验的，业务方最关心哪个指标，那就可以把对应的需求优先级可以提到最高，当多个需求都影响到同一个指标时，则可以让业务方自行判断哪个需求对业务价值最大，那优先级就最高。

当然，还有一些可能并不是直接影响业务单量等，但这些需求是搭建一些通路，是很多需求实现的前提，那么这种需求无疑是最高优先级的。

优先级排序是一个大项目或大战役最难达成共识的点，但也是必须要突破的点，否则后续的项目推进就会陷入不断推翻优先级，不断提高优先级，每个需求都最优先的混乱状态，也就会导致产技始终应接不暇，也就很难快速支持业务发展。