后台产品难点,需求优先级清理

144
作者 KEVIN
字数 2856 阅读 82评论 0

是否能成为墓地里最富有的人,对我而言无足轻重。更为重要的是,当我晚上睡觉时,我可以说:我们今天完成了一些美妙的事。


——乔布斯


因为在负责公司OSS(operation support system)系统整体产品设计,从事后台的产品都会一条一条的将业务需求梳理、整理出优先级。围绕着优先级落地需求设计、开发排期、上线,但上述中几个字“整理出优先级”,你是如何落地的?下面是我几点的反思


优先级的分级,P0到P?


之前有分享过关于需求池整理,其中涵盖需求优先级的划分。在工作中优先级按需求数量,其级别的细读到底需要多少级?我们若按P0为最高优先级,其P1、P2等到底要有多少数量?


在腾讯工作中,我们将需求优先级氛围P0到P5,这样的划分除了按需求本质的优先级还同时考虑了开发资源、开发难度的问题。


我建议在开发团队(前端+后台),产品形态是一个移动端产品或一个web产品前提下,可以在需求池划分为P0/P1/P2即可。三个优先级可以很快的将需求隔离,尽快的进行mvp产品上线。


紧急、重要


优先级的分级最为常见的是按紧急、重要关联词构建。每一个需求都可以区分其紧急层度、重要层度。


紧急:是否要马上做的需求

重要:是否一定要做的需求




按上图坐标轴分重要、紧急可以将其上面所说的需求优先级分为P0、P1、P2,这样的优先级在工作中最为难办的是区分P2、P3优先级。不重要却紧急的需求在产品工作中可能是一个文案的修改,移动端app偶尔出现低频率crash。


最好的需求优先级还是跟着业务走


不管需求优先级我们怎么定,在需求优先级排期中能够拍板优先级的人一定是团队具有话语权、或产品的领导。我个人在负责OSS系统搭建,我会一定要按业务的需求紧急、重要层度来完成。与移动端产品按用户需求可能不同,在后台搭建中,如果一旦不按业务的需求走,可能功能内部的人员资源、物品资源会形成浪费。


例如预约系统,如果按运营优先级分化可能会排在移动端产品的后面,为满足提供更多的流水和转化,优先把开发资源完成运营功能的开发。但开发资源都在focus移动端产品开发,如果按业务分级,如果不做预约系统可能就导致某部分公司内部资源无法run起来,甚至会产生一系列的连锁反应。


好的产品负责人或业务产品人,需要考虑企业内部资源全局的运营。一旦全部foucs某个产品线上,导致其他开发资源空闲甚至是业务人员空闲,是值得注意的问题。


好,今天在工作中的一些感悟就在这里,每周我会坚持2篇原创更新


经验分享
登录 后发表评论