凤凰项目 凤凰项目 8.7分

与其说是关于DevOps的书,不如说是关于管理的书

耍把戏的老把戏
IT很重要
这是此书要传递的一个重要信息。在快速更新和需要提高24*7服务的今天,运维的确变得比以往更重要。但哪个角色又不是呢?设计部门常抱怨自己的想法得不到实现,QA抱怨常常背黑锅......听说过没见过的DevOps提倡的打破Dev和Ops之间的壁垒,在此书中体现的并不多。略翻了下《SRE: Google运维解密》,似乎也是主要讲运维团队。开发团队去哪儿啦?其实小团队中,开发基本把运维的事就包了。把部署作为代码的一部分,尽可能自动化,根据运维状况进行调优,迅速更新和排错,都要求IT人员和开发人员的深度参与。所谓的壁垒,是否就是这些角色不在同一团队引起的?

TOC
这才是本书的重点。以最有价值的目标为导向,找到核心问题和瓶颈问题并解决。其实换一个部门,略微修改下,估计也会把这个故事讲下去。

部门合作
这似乎是这个项目中的最大屏障,包括一些办公室政治。当然在现实中,这也往往是事实。所以很多经理主管不得不花很多精力在这些看起来不直接产生价值的会议,争吵和手段上。
对于生产的方法论很多,继流行日本的理论后,估计来自于中国的实践理论在将来也会推广。关于部门合作方面,华为的执行力就值得学习。

外场会议
...
显示全文
IT很重要
这是此书要传递的一个重要信息。在快速更新和需要提高24*7服务的今天,运维的确变得比以往更重要。但哪个角色又不是呢?设计部门常抱怨自己的想法得不到实现,QA抱怨常常背黑锅......听说过没见过的DevOps提倡的打破Dev和Ops之间的壁垒,在此书中体现的并不多。略翻了下《SRE: Google运维解密》,似乎也是主要讲运维团队。开发团队去哪儿啦?其实小团队中,开发基本把运维的事就包了。把部署作为代码的一部分,尽可能自动化,根据运维状况进行调优,迅速更新和排错,都要求IT人员和开发人员的深度参与。所谓的壁垒,是否就是这些角色不在同一团队引起的?

TOC
这才是本书的重点。以最有价值的目标为导向,找到核心问题和瓶颈问题并解决。其实换一个部门,略微修改下,估计也会把这个故事讲下去。

部门合作
这似乎是这个项目中的最大屏障,包括一些办公室政治。当然在现实中,这也往往是事实。所以很多经理主管不得不花很多精力在这些看起来不直接产生价值的会议,争吵和手段上。
对于生产的方法论很多,继流行日本的理论后,估计来自于中国的实践理论在将来也会推广。关于部门合作方面,华为的执行力就值得学习。

外场会议
书中的CEO在多数时候并没突出表现。然而举行外场会议,承认自己的错误并及时修正,而且知道创建一个相互信任的团队的重要性。就这两点来看,的确是有领导才能。要知道,绝大多数领导是做不到这点的。这个做法,是来自于书中推荐的《团队协作的五大障碍》

布伦特
主角的名字还不如这个印象深。因为被提及的太多。一个IT工程师,扫地僧似的存在,自由电子般的问题终结者,“一个优秀的工程师胜过100个平庸工程师”说的就是这样的人。他们往往也成了瓶颈。
从组织来讲,这就是典型的项目被人绑架。实际中,也有很多类似的优秀工程师,但没达到传奇的地步,因为老是困于一个项目,从而也逐渐平庸起来,离开自己的项目会做的就很少。成了人被项目绑架。
改变这种最后双输的情况,需要魄力和一点冒险精神,因为人们总是倾向保险的做法和安于现状。
另外更重要的是,能识别布伦特和用好这样的人。
1
0

查看更多豆瓣高分好书

回应(0)

添加回应

凤凰项目的更多书评

推荐凤凰项目的豆列

了解更多图书信息

值得一读

    豆瓣
    我们的精神角落
    免费下载 iOS / Android 版客户端
    App 内打开