iSpiik产品说:产品发布后的快速响应阶段,有预留的必要吗?

常见的迭代结束后甚至于迭代内容处于验收末期时,开发资源就会被快速的被项目撤走。从项目的角度来说,加快资源日历的流转,看起来是可以提高“研发效率”的。简单的理解思路就是,快马加鞭,削短空闲时间。以为只要自己奔跑,就能超过时间。


部分研发人员,也会迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示情感不得不鼓励,但并不赞赏。他们迫切的coding结束,提测,等待测试来发现未尽的细节。


如果是以上的情况,那么事实的通常会是,资源被快速抽离进入下一个迭代的进程之后,逐渐暴露出来:提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码,但是如果质量不佳,不好的影响非常大:


1、新的迭代起了头,不得不被搁置。需要一气呵成的代码逻辑,被不断打断之后难免出现纰漏
2、开发自身的情绪和信心波动,由于没有完整的自测和深入的代码完毕后的复盘,面对排山倒海的缺陷甚至都怀疑人生了
3、测试、产品、开发沟通成本剧增,由于编码前的一些必要信息对齐缺失,暴露在测试阶段将会大幅度提升沟通成本,关于功能、实现逻辑等
4、产品正常的节奏、测试的节奏收到不可控的影响,引发各个环节的时间被强制挤压,整体质量下降
5、验收交付之后,由于资源早已投入下一个迭代,对于线上的质量问题,还要协调开发资源而不得不打算正在进行的开发工作
以上这些如果在项目资源规划层面没有正确的识别和评估,导致的结果必然是:研发节奏紊乱、团队信心波动,甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付,用户体验受挫。


通常能够做到对迭代正确的评估、认识、管理推进,已经是非常不错的了,这中间需要项目、产品、研发、技术的高度一致和碰撞,信息的不断对齐。同时充分相信团队成员,给予团队负责范围内的自主权利。一群人,最可怕的就是一条心搞一件事了。能做到以上,我认为就是一个好的项目管理者了,现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段,快速响应阶段应该成为一种常态,纳入到项目管理的资源规划范畴。


——————————
实例一则:
紧张的时间规划,版本上线后,产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目,导致资源匮乏,缺乏跟进,最优势的资源被撤离后,暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间,承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程,最终让整体的效果大打折扣,业务因此也会受到影响。

发布者

Kris_3zzz

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

发表评论

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