摘要:研发处理BUG要工单,是合理的啊,但BUG怎么产生的,绩效管理也需要对工作质量进行啊,思维打开,与领导一起商量对策,办法会多起来的。
绩效若闭环,麻烦自然少
公司上线的软件,客户经常遇到小BUG,需要研发处理,搞绩效后,研发要让开工单才处理。如果这样的话,说明绩效是应该完善了,比如:
1,小BUG要减少
客户经常遇到小BUG,这是为啥,肯定要及时处理,而且要想办法减少。
一是这些小BUG为啥产生,是不是当初做产品时就有问题,还是研发存在什么,还是对客户培训不到位;二是不管怎么说法,一定与研发本身的工作有直接关系,自身产品不完善或管理不到位,现在遇到问题要处理,不但不及时,还非要先见工单,这是不是太过了点,于情于理都说不过去,看来不想办法收拾一下是不行的了。
就冲着“应该减少BUG”这个对公司有百利而无一害的目标,对研发进行要求,对领导进行汇报,研究下一步改善方法,一定是行得通的。
2,闭环绩效管理
搞绩效,尤其是绩效考核方案,既要对工作量或工作计划进行考核,也要对工作质量进行啊。
比如:工单要写,确实应该,但为啥存在那些BUG,是不是要考核一下“工作质量”,即客户投诉或客户要求处理BUG的次数或具体问题的大小程度等。
绩效如果从这方面去闭环,或引导研发的工作方向,研发自然就会主动联系客户,比如产品培训、问题直接沟通等,从而避免让客户直接找到公司,让问题处理既不及时,还会影响研发的绩效,当然,如果一些大的问题,公司或管理部门还是要随时检查监督,或不定期抽问客户了解情况。
3,及时汇报领导
将研发“不见工单不处理”的情况,直接上报领导或公司,商讨解决办法,提出建议。
比如:工单可以第一时间开出来,但相关领导也应当及时介入,让研发先行处理着,不能让客户一直等啊;完善绩效方案,考核工作质量,让研发更主动工作。
当然,商讨办法时,可以让研发一起参加,各提各的看法和建议,最终以领导的意见为准来实施。
4,多种方式的工单
工单如果只有纸质件的话,走完拟制/审核/审批流程,来到研发,恐怕都过了一天,如果某位领导出差或开会,还会拖更长时间,难道让工作不进行了?显然不能这样,毕竟客户是上帝啊。
所以,工单的形式要丰富,不能太单一,比如:电子件、纸质件、微信、邮件、电话等都可以,哪种快速就用哪种,只是最后都可以形成纸质件来存档,一是便于计算工时,二是方便随时追溯BUG情况。
这样的形式或要求,要形成文件,或者在售后服务管理制度中明确,既提高处理问题的速度,也完善绩效管理。
5,注意工作方法
研发提出工单要求,也有其合理的地方,题主不能认为就不对,也不宜直接就按照研发的要求去做,当面既不同意也不反对,但可以说“研究一下再看”。
然后向领导汇报情况,甚至可以拉着研发一起去汇报,这样就避免了与研发的直接产生分歧或矛盾,还可以让领导更全面或一次性了解清楚相关情况。
总之,不能让问题困于自己的这里,要学会借力用力,要明白“办法总比困难多”,自己能力或权限或思维不够时,总会有人可以处理或一起商量。