大咖说 | 从《凤凰项目》谈一谈“业务IT一体化

[发表时间:2017年09月14日 18:59 来源:纸客帝国游戏 作者:纸客帝国游戏]

原标题:大咖说 | 从《凤凰项目》谈一谈“业务IT一体化

作者简介:

陈希章

微软资深技术顾问,有超过14年的应用系统研发及行业信息化经验,是中国区最早的一批中文博客作者,曾获得多次微软最有价值专家(MVP)和微软技术大会最佳讲师。坐能写代码,站可讲架构。业余热爱音乐和篮球,同时在陪伴熊孩子成长的过程中不断格物致知,学习生活的智慧。

今日大咖说看点

业务IT一体化的目标是什么?

IT能多大程度上参与到业务系统中去帮助到业务部门,甚至影响业务部门呢?

如何更好地实现业务IT一体化?

公司的COO应该出自IT背景?

这是我最近读过的一本书《凤凰项目——一个IT运维项目的传奇故事》[注1]的笔记,这本书想要讲明白的一个观点是开发运维一体化,也就是我们耳熟能详的DevOps[注②]。谢天谢地,他没有一上来就讲各种工具,各种原则,而是用小说的方式引出了一个公司在实际的转型过程中必然会出现各种矛盾、冲突,甚至一点不避讳地谈到了微妙的政治。

当然,和所有美好的童话一样,故事的结局是圆满的:在几经波折后,凤凰项目顺利上线,并且逐渐达到了每日构建的水平,持续稳定地为客户提供服务,收到了越来越多好评,打开了业务的新局面。

有意思的是,在这场残酷的战争中活下来的CEO,最终决定给主人公比尔的却不是CIO的位子——而是一个为期三年的COO养成计划。与这个有点令人错愕的结局相呼应的是,在差不多快结束的时候,作者借助一直神神秘秘的顾问的嘴说出了这样一个古里古怪的预测:未来十年内,几乎所有公司的COO,都应该是出自IT背景的,尤其是具有开发运维一体化实际经验的专业人士。

书中开玩笑的提到,CIO 代表着Career Is Over的意思,一定程度也许能反应当前很多公司CIO的生存状态。这是一本适合分享给你的CIO朋友,CIO客户一起来读的书,我觉得大家也能看到不一样的视角。

我个人觉得这样的一个预测从大体上来说是对的。现在的商业环境,要说哪一个公司的业务跟IT(信息技术)没有直接并且密切的关系,我是不太相信的。正因为如此,我认为本书的结论有点仓促了,而且格局略微小了一点—— 与其说是开发运维一体化,倒不如说是 “业务IT一体化”更来得贴切吧?

以下我基于本书中提到的一些重点内容,结合我的工作实际经验给大家分享一下如何更好地实现业务IT一体化。

IT部门管理的基本要素

工作内容四象限,约束管理五步骤

我们可以简单将IT部门的工作内容分为四个类型

业务项目

从“业务IT一体化”的思维来看,业务本身是与IT的支撑分不开的,同时IT还可以催生新的业务(价值)。

那么,对于一个COO ,或者CIO来说,在考虑如何设计业务战略以及与之相匹配的IT战略的时候,就必然要合理地考虑IT具体承担的工作内容这个现实问题。

业务项目无疑应该是重点。——这是直接决定IT在业务一体化这个过程中能产生的价值。

IT能多大程度上参与到业务系统中去帮助到业务部门,甚至影响到业务部门,你的价值就有多大。

这项工作列为紧急并且重要,是合情合理的。

IT内部的项目

不可避免地,还有些是“IT内部的项目”,有些IT部门很热衷做这方面的项目,在我看来部分原因是做这些东西相对来说是IT比较好玩或者擅长的。

这个方面实在要引起一些重视,例如不要人云亦云地做DevOps。

当然,从另外一个角度来看,也可能是重要但不紧急的工作,例如认真地研究和建立DevOps的基础环境。

变更

在一些正规公司的IT部门,都有严格的变更管理流程和制度。

不管是业务项目还是IT内部的项目,在它们的生命周期内,都必然涉及到变更及其管理。

无论你是烧香拜佛还是轻松惬意地把这些项目上线了,这都只是一个开始。但变更虽然不可避免,我个人觉得应该尽可能减少(至少做到可预测),并且将变更流程自动化。

计划外工作

最容易被人忽视的是“计划外工作”,它偷走了我们的时间。这就等于我们经常在讲的那些紧急但不重要,或者那些不紧急也不重要的事情。但一个尴尬的事实就是,这可能是一些还不太成熟的IT部门的主要工作,他们天天都是在救火,不知道自己到底应该干什么好。

理顺以上四项工作内容并不难,很多人可以马上列出来一长串清单。但做工作的艺术在于你知道理想和现实之间的距离,并且知道如何通过努力去拉近这个距离。说直白一点就是,你要明白自己的能力范围在哪里,可行性怎么样。

这本书的作者显然是高德拉特博士[注③]( 物理学家与企业管理大师 ) 的拥趸,在整个故事中都贯穿了高德拉特的一些思想,尤其是最著名的约束管理( Theory Of Constraints )理论。

书中有一个很有意思的人物,布伦特

这是一个我们都似曾相识的厉害角色,他在部门里面是英雄的化身,什么难题在他那里都能解决,反过来,很多事情都需要依赖他才能解决,而且其实不少问题的根源也在于他的独特地位——他太厉害,所以不屑于写文档;他太重要,所以可以随心所欲地改东西而不走流程;他太忙,所以很多事情都要排队等他的时间来做。

“‘布伦特,布伦特,布伦特! ’,比尔在忍无可忍的情况下朝手下的一线经理吼,‘难道没有布伦特我们地球就不要运转了吗?你自己是干什么的呢?’ ”

这个场景在我脑海里挥之不去。

这里当然并不是说布伦特不好,我们当然需要布伦特这样的人才。只是说布伦特成为了团队的约束点,怎么利用好他成为工作成败的关键(建立一些好的机制,确保他们能够更好地工作,而不是在一些低价值的内容上),而怎么帮助他提高到一个新的水平(或者培养更多的布伦特)才是长治久安的方法。

那么,好好想一想吧,你的团队的布伦特是谁?你为他们做了什么呢?而如果你就是布伦特,你当然有资格高兴一会儿,但建议不要躺在这个状态上,你值得更好的发展。

如何真正实现IT业务一体化

一个中心,两个基本点,三步工作法

四个工作内容和约束管理五个步骤,只是IT部门管理的最基本的两个方面。真正要实现业务IT的一体化,我们需要一些更加实际的操作建议。

首先,业务IT一体化的目标到底是什么呢?我个人总结应该是一切围绕如何实现随需应变的业务,具体来讲是快速并且可靠地交付业务需要的价值。

为了实现这个目标,从手段和形式来看,“业务IT一体化”与传统的模式有一个根本的区别,就是大量地使用了自动化的技术,减少中间环节。

自动化是一种“术”的层面,它首先满足的是“快速”的这个诉求。

而要实现“可靠”的交付,业务IT一体化的核心原则在于“信任”——不仅仅是体现在业务部门和IT部门的相互信任,还体现在IT部门内部开发、测试、运维、安全等环节的信任,甚至还体现在IT与外部世界的相互信任,毫无疑问,这个已经可以上升到“道”的层面了。

最后,要落实这两个基本点,书中借助那个神秘的顾问,提出所谓的三步工作法

第一步

从产品构想、设计、开发、测试、运维到客户,这个正向的工作流,一定要理顺,找到其中的最优路径,减少半成品(这个属于来自于制造业)意味着每一步的成果都是合格的,立即可以为下一个环节可用,而等待的问题在于如何增大吞吐量,自动化在这里体现得非常恰如其分。

第二步

从客户往回推,如何建立一个健康和高效的反馈流

这里我总结为快速试错和迭代,收集反馈的过程本身应该是简单和高效的,而且这些反馈能直接地集成到系统的改造和完善过程中。

特别提一下客户的参与,这不是简简单单地说一句“以客户为中心”就可以的,需要有实际的措施,确保客户的声音会被听到和采纳。

第三步

我觉得是讲到点子上了—— 业务IT一体化当然是好啊,但流程再合理,工具再强大,领导再重视,如果没有一个所有员工都认同的企业文化来做支撑,都将流于形式。

没有信任来谈创新,终究是扯淡。

这里还要提到大局观,书中用生动的例子讲到在传统的模式下,各部门只关注自己的小目标,以自己干了多少事为荣,而不管这些事到底对于整个公司的目标实现意味着什么。

例如,开发部门关注的是说,他们按照日期交付了代码,而不关心他们这些成果对于后续环节的影响,例如测试部门的叫苦连天,运维部门的一筹莫展,更不要谈实际推向市场后客户的反应了。

结语

这篇笔记写在公司新财年开始之际,对于我自己来说也有一个别样的含义。我自己是有写年终总结的习惯的,过去的这一个财年,一方面公司在大力推动业务转型,亲身体会有颇多感触;另外一方面我自己也在第一线服务于客户,得以近距离观察和学习不同行业的客户遇到的挑战和不同的应对策略。

大家都知道,微软提出了一个“数字化转型”的概念和方案,提倡从“密切客户沟通”、“予力赋能员工”、“优化业务运营”、“转型产品服务”这四个方面为客户的业务转型提供动力。

过去一个财年中我自己最主要学习到的东西估计就是“数字化转型”。于我而言,从最开始只是听到一个概念,到参与微软自身的转型过程,再在和客户的互动过程中得到反馈,数字化转型逐渐变成一个一个鲜活的案例。《凤凰项目——一个IT运维项目的传奇故事》就是从实操的层面讲述了一个传统企业转型的故事,镜头聚焦的是业务和IT如何通力合作,并且通过敏捷的方式达到开发和运营实现一体化的过程。

今天我把这些心得分享给大家,也希望或多或少能有所帮助吧。

题外话

我用了大概8个小时的时间一口气读完了它,这已经是相当罕见的。与此同时,小说中提到的一些有意思的话题,也一直在吸引我进一步地思考,并且一直想结合实际工作写一篇读书笔记作为总结,今天在飞机上初步整理了一个心得,虽然不见得很成熟,分享给大家参考参考吧。

我曾经听说香港的梁文道先生一年要看400本书左右,我还看过他的专访,他提到仅就看而言,是有些技巧的——绝大部分情况下,你应该先看一下作者介绍和序言,大致了解梗概;更多的时候,你可以通过目录决定当前这本书是值得通读还是选读,精读还是泛读;还有,有的书适合从前面看,有的书适合从后面看。这本《凤凰项目》就是适合从后面看起的一本相当诡异的书,或者准确地说,书后面的几十页才是作者真正要讲的内容,而前面大概三百多页都是讲故事。我也是看完之后才发现这个状况,猛拍大腿既表示痛快也表示惋惜,当然,无论如何,小说本身确实写的还是可以的。由此可见,作者和读者之间的出发点可能是不一样的。

[注①] :基恩·金 (Gene Kim) (作者), 凯文·贝尔 (Kevin Behr) (作者), 乔治·斯帕福德 (George Spafford) (作者), 成小留 (译者) 《 凤凰项目:一个IT运维的传奇故事 》

[注②]:DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。摘自百度百科,原文链接:https://baike.baidu.com/item/devops/2613029?fr=aladdin

[注③] 高德拉特博士的著作包括《目标》,有兴趣的朋友也许可以看看。

*本文转自公众号:微软商业视角返回搜狐,查看更多

责任编辑:

分享到:

Copyright @ 2017 纸客帝国游戏 版权所有

文章来自网络整理,如有侵犯您的权益请联系网站管理员,24小时内为您处理