聊聊产品迭代范围的管理

范围即标的,是一个迭代冲刺的目标。围绕冲刺目标,通常会有匹配的:时间窗口、前后端开发资源、测试资源、运维资源、业务资源,同时会有匹配的协同系统协同处理方案、应急处理方案。当然,背后依赖的还有整个产品roadmap,再往底层其实是商业和战略规划。

 

范围的控制不论从风险、时间、团队信心哪个角度来说都是很有必要的事情(这里不谈绝对,比如突发的bug,不修复就要挂了,那没的说绝对是重要且紧急且马上就得做)。

1、风险控制:一个想要插队的需求,如果要做,不仅是开发、测试资源日历的问题。同时需要评估和既有范围的耦合度,其本身的相关方系统、业务有哪些,明确出来需求的地图边界在哪里。前面是进行风险的识别、评估,同时必须准备风险的应对措施,如果因为插队需求问题导致的诸如需要紧急

修复、回滚等,对原迭代范围的应急方案是什么?最坏的结果,如果发生了之后,还需要去做的就是持续的关注监控,避免次生的业务和系统问题发生,比如:系统和业务不一致导致的无效数据。关于风险,因为团队内分工的不同,会存在不同岗位角色的信息差,这里最好要有开发、测试、产品、项目、业务协同进行上述风险的预判过程;


2、时间:世上不如意之事十之八九,项目管理、产品迭代又何尝不是如此。人员请假、线上问题、bug暴露、老板需求都会挤压既定的时间规划。尽管我们在做迭代评审后,项目成员都会自己评估绝对的工作量,标记自己的deadline。尽管每个人都或多或少预留了一些buff,但是通常结果是,开发的交付、测试交付基本都会达到整个范围的deadline。不能说是团队成员效率问题,或许是deadline的标的成为了大家心理的一种暗示。所以范围蔓延通常意味着时间的不可控概率大幅度上涨。


3、团队信心:一次冲刺对于每个成员来说都是整装待发重新出发的一段旅程。大家有清晰的里程碑、有清晰的目标,过程中不断的持续交付并按照节点推进,最终达成一次交付。这感觉一定程度是可以刺激人的慢性多巴胺的,让成员充满信心、并拥有成就感和责任感;无控制的范围蔓延,会打乱成员的节奏,引起团队信心的打击,团队信心就像nba2k里球员的自信值,对于投篮命中率具有牛皮的加成效果。

每个产品经理成长过程中一定遇到过,加法的过程,我们想把一些小不点搭顺风车。不乏遇到由于评估偏差导致连累正常的范围。搭顺风车其实是件小事,但是需要背后评估分析的却是一套严谨的方法体系。

发布者

Kris_3zzz

世界如此精彩,怎能置身事外

发表评论

邮箱地址不会被公开。 必填项已用*标注