|
项目管理者联盟
在一个与我们平行的世界中，有一个软件开发公司。这个公司所做的产品用户量近期增长的十分迅猛，但是令CTO头疼的是公司的两大部门：开发部和运维部近期也是“掐”得厉害。为解决这个问题，CTO决定倒入现在十分流行的DevOps，并且CTO还请来了Gary来当顾问。项目管理者联盟
听到这个消息，开发部经理 “小D”
在部门会上长长舒了一口气，说：终于可以解脱“猪队友”的问题了，维护人员什么也不懂，就会摆弄那些死机器，有点小问题都让我们来解决。DevOps
我了解，就是让那帮运维人员用开发人员的思维去做运维工作，这个问题终于可以解决了!”项目管理者联盟
于此同时，运维部经理“大O”也兴奋地对运维团队说：“太好了，开发团队开发的产品就是一滩屎，总是让我们擦屁股，有什么技术他们还捂着、掖着不告诉我们。DevOps要求产品质量前移，好好整整开发部，那样我们就会轻松很多了!”项目管理者联盟
很快CTO组织了一次会议，这次参会的只有四人：CTO、“小D”、“大O”还有顾问gary。在相互介绍后，CTO宣布了要推行DevOps的决定，并让“小D”和“大O”谈谈看法。项目管理者联盟
“小D”首先发言：service.mypm.net
1. 我们开发能力通过持续改进已经很强了。现在我们敏捷开发，自动化测试、集成和部署，可以每天集成，每周进行对外发布。项目管理者联盟
2.
至于运维人员我不敢恭维，水平太差。现场问题基本都透传给开发，严重影响到了我们的开发进度。那么多人都不知道在干什么?!项目管理者联盟
接着是“大O”的反击：项目管理者联盟
1. 你们每周都发布，我们每周都要维护新东西，都要现学现卖，运维要的是产品稳定，你知道我们有多大压力吗?项目管理者联盟
2. 我们运维人多是因为你们产品开发质量差、问题多，而且问题一出现就是大问题，都要修改代码，这不是我们能解决的。项目管理者联盟文章
3. 我们运维人多，但是工资低，而且还不被重视，工作也很累，要7*24小时盯着。www.mypm.net
4. 你说我们什么都不会，那是因为开发什么也不教我们运维，我们怎么会?项目管理者联盟
“小D”毕竟年纪青，有些被气疯了，指着“大O”的鼻子说:“我们开发任务那么忙，哪有时间教你们。而且，从去年起我们进行的BSC分解中，运维被定义为开发的内部客户，你们对我们有考核权，从此我们这块的KPI就没高过，你还想怎么样?!”
CTO看两人快动手了就急忙拉架，并顺势打开了去年KPI说：“来，大家都看看，去年的KPI是这个吧?”training.mypm.net
表一开发部KPI(部分)：talent.mypm.net
项目管理论坛
表二 运维部KPI(部分)：talent.mypm.net
项目管理培训
“大O”指着表二说：“看到了吧，我们运维部也背着市场和销售部门的内部满意度KPI呢!”项目管理者联盟文章
这时Gary觉得该是他出面的时候了，他稳定下情绪，心平气和地对CTO说：“你们公司的目标应该是让客户满意度提升，而不是只让你们把内部责任分解得很清楚，现在的KPI您也看到会激化部门间矛盾，所以我建议应整合两个部门，让开发和运维部共同承担对客户满意度的KPI。”项目管理者联盟
CTO想了下说：“你的意思是将开发和运维合成一个部门?”此言一出“小D”和“大O”各自惊出了一身冷汗。Gary有深意地扫了一下他们俩，对CTO说：“不，我不是这个意思。如果单纯地整合了两个部门，实际上只是将矛盾藏在了一个部门内部，没有彻底解决问题，而且弄不好新合并的部门将成为一堆烂泥，分不清楚了。而且即使合成一个部门，开发和运维的人员还是要分开的，否则开发和运维工作都搞不好。”
CTO有点晕了：“那你到底想要干啥?” Gary说：“好，让我们简单地梳理一下，我通过你们的讨论而想到的几点解决办法吧!”项目管理者联盟
1.
以后客户对产品的满意度由开发、运维两个部门应共同承担。这个满意度部分开发还是运维阶段，而是整体的满意度。我们要改变一些观念，比如：去掉“完成”概念。不要有发布了就算开发完成了和开发无关了;运维通知开发处理问题了就和运维人员无关了等等的想法。项目管理者联盟
2.
我们不光是开发质量迁移，还要运维需求“前移”。运维人员可以根据现场运维情况，提出对运维的需求，比如：对哪些常见问题的自动化监测、报警值、报警方式等等，这样会让产品可运维性大大提升。项目管理者联盟
3.
建立产品问题库，对于产品运营阶段不管是开发还是运维人员发现、处理的问题大家都可以看到，这样我们既可以及时分享处理问题方法还可以让不同的人了解大家的工作现状。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
