第九章 述职09 运维的边界
ido研发项目管理工具，确实是个好东西。我们的开发、运维支持类的事情，都通过该产品进行了有关管理，确保了研发过程的流程化，可追溯。
因为ido很“万能”，所以凡是无法通过产品解决的，大家自然都想到了这个工具。
也是因为产品存在不支持的场景，所以PM也缺少立场和用户去争辩，默默承担了很多。
因此，问题也自然产生了。上周一个单据修改的事情，想得不完整，来来去去就改了2周；本周，亮亮给我转发了客户侧的反馈，因为采购数据的调整影响了预算，被预算部门投诉了。
基于这个现状，Leader也和我交代，对于非常规性的运维，需要警惕，对于能不能做要留意，要发起讨论和对话后才能执行。我也和亮亮强调了，并规范了工作流程。
和亮亮的对话中获知，亮亮也有纠结，因为事情太多，所以很多事情做得并不好，只是在被动应对：
对于常规的运维，很容易处理掉；
对于非常规性的运维，单纯因为用户很着急，自己没想清楚，就推动研发支持了。
本次我们对第二点做了优化：
对于非常规性的运维，自己没有想清楚，那么不管用户有多着急，我们都不要启动，可以拉起部门负责人的对话，大家先共识，并对风险充分评估后再做；这样亮亮也不用把事情压在自己的手里，承担压力。
这另外还暴露了团队“同理心强”的副作用。
本来“超强同理心”是优秀产品经理的必备素质，但因为我们中型企业，产品开发工作中穿插了很多运维支持，产品经理实质承担了两个角色，导致从产品到运维的滑坡。这个状态大家都不满意，但事情却向这个方向发展，即便我给出反馈，大家也不容易改变这个现状。
亮亮作为团队产品标兵，在产品方案设计能力上很强，但也过于陷入“执行”的陷阱，对需求的判断不足；或者说，不可抗力推动着他向这个方向演变，“执行”只需要投入体力，但“建议”需要投入心力、且可能还被误解。
我也在想是否可能通过职责拆分来解决，比如单独拆出来做运维支持的人，只负责做“被授权”的运维。但尴尬的是，公司的规模难以支撑这样的团队。而且因为只做运维缺少成长性，所以我并不想让同学做这样适合外包的工作。
这个阶段暴露的问题较多，也是因为这一年的上线了好几个主要产品，工作还在磨合，所以大产品上线后的一段时间，持续的产品资源投入是必要的，当运转稳定后，问题也会得到缓解。