企业IT系统产品团队,在无项目、日常运维阶段,难免做的事情无法体现价值,缺少方向。将运维工作,美名曰去手工。既体现了为业务带来的价值,也通过量化指标、价值分析倒推团队每月版本计划。
维护去手工作业清单,包括
版本月份
手工类型
优先级
建议方法
关联系统
需求部门/角色
手工操作内容
业务现状
建议方法
案例
预期收益
开发人员
状态
备注
当然不是每一项都是必填信息,其中关键的是角色/现状/解决方法,从而确定需求。已经预期收益,可通过手工耗时、所占工作比例、操作人数来体现。预期收益指标,既是排优先级的一个关键考量因素,也是到了团队总结工作时价值的体现。
其实去手工的本质,是在解决数据问题。信息化系统本来玩的就是信息流。数据问题,体现在四个方面
缺失
拉通
提升
手工计算->系统计算
最能带来价值的,是前三项。最后一项,是运维阶段最常处理的,但却是最拿不出的结果,带来的往往是效率的提升。因此在梳理去手工需求时,需有意识的按照数据维度分类,注重解决数据缺失、拉通以及提升数据质量的需求。
另一个在梳理需求阶段需注意的,是业务提出的针对顽疾的解决需求,往往是打补丁的需求。因为长期困扰业务的问题,往往不是简简单单能解决的。不然业务早就解决了,还能长年留在那里?因此当业务代表提出,这个需求很重要,能解决公司的长期痛点时,要留意确实是优化方案、改善业务,还是打补丁方式的“歪门邪道”方法?打补丁没价值、浪费开发资源不说,更严重的是若考虑不周,反而会起到适得其反的影响,导致陷入到这个问题中,成功背锅。
以供应链降库存运动为例,为何每次降库存运动的结果,是短期内指标下来了,长期看库存不降反增?就因为针对降库存的举措,指标不治本,把表面问题处理下,供应商先别发货,能发给渠道商的都推出去。短期内看数据确实变好了。但业务模式没有改变,产销会没有,物料需求计划不准,没有替代料关系,封存库存呆滞。过一段时间库存又会上来了。而且之前的解决方案,使系统产生的应激反应,导致复原的问题只会比之前更加严重。
以纯业务举例,看似与IT系统的运维工作无关,其实道理是相同的。针对系统顽疾,往往对应的是业务顽疾,贸然打补丁,只会在你想不通的其他场景,产生更多更严重的问题。顽疾问题,先出优化方案,确定了可行性再去做,拒绝打补丁工作。当然,优化方案,往往就意味着启动一个项目了,而不属于运维工作范畴内。