《凤凰项目》读后感锦集
《凤凰项目》是一本由基恩·金 (Gene Kim) / 凯文·贝尔 (Kevin B著作，人民邮电出版社出版的平装图书，本书定价：CNY 49.00，页数：362，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《凤凰项目》读后感(一)：何止IT，所有部门都值得一读
虽然这是一本运维的书籍，但我认为书中所讲述的道理同样适用于其他部门！接连不断的工作任务，日益缩紧的预算恐怕是大部分公司所有部门都面临的现状，大部分人都疲于应付日常的工作，只有很少人肯花时间思考，如何解决这种混乱，如何改变混乱，而不是迷失于其中。书中给我们指明了方法，相信仔细领悟，一定有所收获！
《凤凰项目》读后感(二)：山鸡变凤凰
一本从IT运维为楔子的现代企业管理故事。前半部把IT在传统企业的困境跃然纸上。中段，一位高人从现代化生产理论和实践融入IT战略管理、战术布局引导IT总裁拨开云雾一一确认价值、三步工作法。后半部略略涉猎DevOps。毕竟是小说，技术部份仅仅是理念的介绍。如果你不知道IT在干嘛？为何那么烂？如何提升？可以看看。作者也是个IT创业者。
《凤凰项目》读后感(三)：受益匪浅
一本深入浅出的书，即便是对于我这样不喜欢看书的人，还是被故事情节所吸引。
通过一件件具体的案例让我们知道在运维过程中遇到一些问题的处理方法和思路。
工作中因为有太多的计划外的工作，而导致计划内工作无法按时完成。
而如何管理计划外的工作，本身就是一件非常值得思考和学习的事情。只有将计划外的工作安排处理好，计划内的工作才可能按时按量的完成。
《凤凰项目》读后感(四)：devops早已深入人心
前后大概3周，利用晚上下班之后的时间看完了这本书， 总的来说故事性不是特别的强， 人物对话有些生硬掉书袋， 故事背景放到现今互联网从业者身上多少也会有些出入， 国内各大厂都有着不错的流程管理， 肯定不会像这家上市公司一样， 主人公出现之前在IT流程建设上简直一无所有。但主人公应对事态发展所展现出来的思考以及态度确是每一个互联网从业者都应该从自身出发反思，改进学习的， 总体算是一个合格的作品。 成书是在12年， 现如今开发运维的概念已经深入人心， docker等容器技术也发展的如火如荼， 感谢千万如作者一样的开发者在此过程中所作出的巨大贡献。
《凤凰项目》读后感(五)：一直在寻找的WOW
这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽.
但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。
他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验. 看这本书，就像看一本，射雕英雄传。
但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。
总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。
《凤凰项目》读后感(六)：三步工作法与个人体会
三步工作法： 第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，决不让缺陷流向下游工作中心，并且不断为了整体目标进行优化 第二工作法是关于价值流向各阶段自右向左的快速持续反馈流，放大其效益已确保防止问题再次发生，或者更快的发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量 第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提 准备好手动应急流程， 问题处理清单：需要提放的已知错误，可以获得最新状态的内部网页，如何报告新问题的操作指南。 个人体会：
提出问题的人把问题罗列出来，并给出解决方案。 自己亲自去使用，去实地考察和检验 小规模试点，再大规模铺开推广 理解项目能做什么，不能做什么
《凤凰项目》读后感(七)：交付价值的it
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。
正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。
正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银弹的
《凤凰项目》读后感(八)：如果你找不到《丰田管理》这本书……
它在这里：http://book.douban.com/subject/3871227/
并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？
我们干这行的都管Kata叫“招式”好吗？
这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？
你真当我是来看小说的吗？
当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。
《凤凰项目》读后感(九)：运维的启蒙
我刚入行一年未满。常常好奇运维的日常到底是什么？这本书完美地给了我答案。
ok，本书主要是介绍项目管理。但是主角遇到的问题大多是运维问题。
一开始，我们的主角接手了一个烂摊子。IT部门的规范一团乱，甚至连基本的变更都没有批准流程。主角第一个工作就是下令，变更操作必须得到批准，一周以后好处果然肉眼可见。
我喜欢这本书里面世外高人带主角参观工厂那段。我们这个行业的历史太短，从别的行业汲取经验是很明智的。
艾瑞克（世外高人）告诉主角，IT从事着四种类型的工作：
- 业务项目
- IT内部项目
- 变更
- 计划外工作/救火工作
上面这些话要是半年前看的话，我怕是看不太懂。但是这半年我恰巧都经历过，果然如此。有时候我在想，可能擦屁股花的时间比正常开发的时间还要的多。
另外，世外高人还有一个很重要的思想：控制半成品。半成品是以工厂的产品作为类比，比作IT项目中的不完整项目。在一些项目里，尤其是在我国的国情下，大多数项目的目的都是快速出成品，但是这个成品的质量其实很差，欠下了所谓的“技术债”。如果不察觉这种情况，迟早要吃苦头。
《凤凰项目》读后感(十)：不只是DevOps
作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。
这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？
ill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。