繁杂版本跟进遇到的问题及部分处理方式

绩效管理培训会时，回忆起以前自己做绩效沟通的情况，好像有些情况还可以。也想起以前工作中遇到的困难和后来处理的情况。再想起目前的一些困难和状态，有点感慨，顺手写写

被繁杂错乱的项目节奏、各种问题、琐事折磨的很是郁闷，但是抽离的想想，很多是目前项目团队中的老大难问题，这些问题很多身在其中的人都清楚，也有人离开，诸多原因，并不是我这个角色和角度能够解决的，需要从团队内部的管理上意识到，着手处理。暂且不说

当前版本的极度琐碎，也很折磨人，不过从具体的事情里抽离出来细想一下，这是个必经过程，其实不必烦心，理清楚后，排好次序逐个处理就好。

必经的原因：

1. 版本定位为“稳定性提升版本”：

针对主要模块的零散问题定制专门的修复方案，每个模块都有多项待修复点，陆续明确修复方案，阶段性提测；多个模块

结果必然是多且散，不易计划跟踪管理

【问题】如何对多且散的版本进行管理，开发方案明确后，提测等方案同步到项管、产品、测试等角色（有可能还需要运维等角色配合）

多向同步？项管如何汇总管理？

抛开项管事宜，单独考虑测试：

明确测试对应的负责人，由负责人具体跟进，及时反馈情况、问题、风险等——可确保测试不脱节

2. 版本琐碎繁杂高，产品、测试新人等带来沟通成本高

3. 消息服务，开发人员变动较大，对业务熟悉度较低，沟通成本高、效率低；测试也由新人负责，且整体对这部分掌握的信息较少

本次完成后需进行总结，汇总信息、积累经验并分享；补充实习人力以保障后续版本测试需要

4. 过程中插入前端2.1.4、纵横平台、org重构、等其他计划外提测，需及时响应跟进，安排人员、给予基本引导、参与部分会议，了解进度等

5. 测试组内新鲜血液注入

多位新人同时加入，部分工作需要独立跟进完成。产品是新的、流程是新的、同事是新的、功能是新的，不是每个人都有人有精力全力帮带

新人加入后，需根据新人及业务线情况，调整整体的分工

内审规模扩大，占用时间较多

6. 临时减员，导致需临时调整分工及任务安排

其他问题，遗留问题，属非必经的原因：

1. 用例优化在此版本同步进行，占用精力，但尚未完成

2. 排期不统一，前端&后台api排期不同步，前端已提测，但是后台api未就绪，步调不一致，整个链路未打通，无法进行测试，且不易监管，尤其涉及到中间上线

其他：

测试计划&进度共享到可公共访问，便于更新维护的位置；测试计划虽无人要求评审，但是自己需整理明确

增加周会汇总信息，周会增加临时的分享，主要为近期经验

抽离思考的一个好处是，避免一直聚焦在具体的事情上，剥离清楚哪些是能力范围内可处理可控的，不同阶段需要关注的重点是什么，聚焦重点，不可控内容可通过有理有据的反馈推进解决。梳理手头事项，根据情况进行拆分和指派，减少必须由自己处理的非重要琐事，方便更聚焦。