产品发布后的快速响应阶段，到底要不要？
产品发布的最后一公里，最后一公里听起来很少、很小，但对于场景的打穿、用户的需求场景达成至关重要。 产品经理A：产品都已经发布上线了，还要我关注干嘛？ 项目经理B：代码经过了前后端开发的自测、联调，也经过了测试的冒烟、单元、回归测试，产品和业务也都验收了，还想怎么样？ 开发者C：测试工程师不都测试过了嘛！产品不都验收了嘛！业务不也验收了！管我什么事儿？ 一、迫不及待的项目 常见的迭代结束后、甚至于迭代内容处于验收末期时，开发资源就会快速的被项目抽离。从项目管理的角度来说，加快资源日历的流转，看起来是可以提高“研发效率”的。简单的理解思路就是，快马加鞭，削短空闲时间。只要我自己奔跑，就能超过时间。 二、勇往直前的开发leader 研发人员，也不乏会有迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示在情感上不得不鼓励，但并不赞赏。如果是迫切的coding结束，提测，等待测试来发现未尽的细节。无疑是总想抬头看风景，忽略脚下的路。 三、出人意外的结果 如果是以上的背景情况，那么事实通常会是以下的状况，资源被快速抽离进入下一个迭代的进程之后，逐渐暴露出来提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码，但是如果质量不佳，不好的影响非常大： 1️⃣ 新的迭代起了头，不得不被搁置。需要一气呵成的代码逻辑，被不断打断之后难免出现纰漏（对于开发者来说，连贯的编码不被反复打断绝对是有助于产品质量改善的） 2️⃣ 开发者自身的情绪和信心波动，由于没有完整的自测和深入的代码完毕后的复盘，面对排山倒海的缺陷甚至都怀疑人生了 3️⃣ 测试、产品、开发沟通成本剧增，由于编码前的一些必要信息对齐缺失，暴露在测试阶段将会大幅度提升沟通成本，关于功能、实现逻辑等 4️⃣ 产品正常的节奏、测试的节奏受到不可控的影响，引发各个环节的时间被强制挤压，整体质量下降 5️⃣ 验收交付之后，由于资源早已投入下一个迭代，对于线上的质量问题，还要协调开发资源而不得不打断正在进行的开发工作 以上这些如果在项目资源规划层面没有正确的识别和评估，导致的结果必然是：研发节奏紊乱、团队信心波动，甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付，产品节奏紊乱，用户体验受挫。 通常能够做到对迭代正确的评估、认识、管理推进，已经是非常不错的了，这中间需要项目、产品、研发、技术的高度一致和碰撞，信息的不断对齐。同时充分相信团队成员，给予团队负责范围内的自主权利。一群人，最可怕的就是一条心搞一件事了。能做到以上，我认为就是一个好的项目管理者了，现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段，快速响应阶段应该成为一种常态，纳入到项目管理的资源规划范畴。 别看大家嘴上会说，关注下发布后的线上运行状况，可大都还停留在saysay的阶段，真正认真规划并提供应对预案还是寥寥。 四、产品发布的最后一公里 紧张的时间规划，版本上线后，产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目，导致资源匮乏，缺乏跟进，最优势的资源被撤离后，暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间，承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程，最终让整体的发布的效果大打折扣，业务因此也会受到影响。 作者：Kris_3zzz， 公众号：iSpiik产品说 本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可，禁止转载 题图来自 Unsplash，基于CC0协议 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
产品发布的最后一公里，最后一公里听起来很少、很小，但对于场景的打穿、用户的需求场景达成至关重要。
产品经理A：产品都已经发布上线了，还要我关注干嘛？
项目经理B：代码经过了前后端开发的自测、联调，也经过了测试的冒烟、单元、回归测试，产品和业务也都验收了，还想怎么样？
开发者C：测试工程师不都测试过了嘛！产品不都验收了嘛！业务不也验收了！管我什么事儿？
一、迫不及待的项目
常见的迭代结束后、甚至于迭代内容处于验收末期时，开发资源就会快速的被项目抽离。从项目管理的角度来说，加快资源日历的流转，看起来是可以提高“研发效率”的。简单的理解思路就是，快马加鞭，削短空闲时间。只要我自己奔跑，就能超过时间。
二、勇往直前的开发leader
研发人员，也不乏会有迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示在情感上不得不鼓励，但并不赞赏。如果是迫切的coding结束，提测，等待测试来发现未尽的细节。无疑是总想抬头看风景，忽略脚下的路。
三、出人意外的结果
如果是以上的背景情况，那么事实通常会是以下的状况，资源被快速抽离进入下一个迭代的进程之后，逐渐暴露出来提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码，但是如果质量不佳，不好的影响非常大：
1️⃣ 新的迭代起了头，不得不被搁置。需要一气呵成的代码逻辑，被不断打断之后难免出现纰漏（对于开发者来说，连贯的编码不被反复打断绝对是有助于产品质量改善的）
2️⃣ 开发者自身的情绪和信心波动，由于没有完整的自测和深入的代码完毕后的复盘，面对排山倒海的缺陷甚至都怀疑人生了
3️⃣ 测试、产品、开发沟通成本剧增，由于编码前的一些必要信息对齐缺失，暴露在测试阶段将会大幅度提升沟通成本，关于功能、实现逻辑等
4️⃣ 产品正常的节奏、测试的节奏受到不可控的影响，引发各个环节的时间被强制挤压，整体质量下降
5️⃣ 验收交付之后，由于资源早已投入下一个迭代，对于线上的质量问题，还要协调开发资源而不得不打断正在进行的开发工作
以上这些如果在项目资源规划层面没有正确的识别和评估，导致的结果必然是：研发节奏紊乱、团队信心波动，甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付，产品节奏紊乱，用户体验受挫。
通常能够做到对迭代正确的评估、认识、管理推进，已经是非常不错的了，这中间需要项目、产品、研发、技术的高度一致和碰撞，信息的不断对齐。同时充分相信团队成员，给予团队负责范围内的自主权利。一群人，最可怕的就是一条心搞一件事了。能做到以上，我认为就是一个好的项目管理者了，现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段，快速响应阶段应该成为一种常态，纳入到项目管理的资源规划范畴。
别看大家嘴上会说，关注下发布后的线上运行状况，可大都还停留在saysay的阶段，真正认真规划并提供应对预案还是寥寥。
四、产品发布的最后一公里
紧张的时间规划，版本上线后，产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目，导致资源匮乏，缺乏跟进，最优势的资源被撤离后，暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间，承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程，最终让整体的发布的效果大打折扣，业务因此也会受到影响。
作者：Kris_3zzz， 公众号：iSpiik产品说
本文由 @Kris_3zzz 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
你的反应是什么？
