这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。
书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的销岁？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想如何去调整，用哪种调整方案最简单？结果表面上是以经解决了，可过不了多久此类情况又会发生。其实遇到这种问题应该先想想，库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这种情况再次发生？现在该做些什么？应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消，重新开过单据。还有一次，财务部提出采购部在采购单上更新了价格，但出入库记录的金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将采购单上更新的价格导出给财务部，方便快速。但没有想到问题的起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前就把价格填上，在入库的时候就会自动获取价格，而不是给财务部导出价格。
书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，回想过去的工作，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。如果采购部一直都是后补单价的话，就更本不会意识到饥桥后补单价是一种错误的方法。
因为时间的关系我没有全部看完这本书，有时间还需要经常翻看。在今后的工作中，需先将问题定义清楚，找到真正的问题，再去找寻解决这个问题的最佳解决方法：解决后产生的问题，没有解决前的棘手且最不棘手的解决方法。
书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。在一个烂斗猛项目的进行过程中，我们不可避免的要和用户之间沟通和交流，当然，在交流过程中，会遇到一些问题。不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。
《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目，如何选择项目经理和能解决问题的项II团队，如何用WBS，PERT，CPM和甘特图编制项目计划，如何设计项目控制系统，如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有效沟通，如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理现象的内在含义，又简单明了地介绍了实践中具体应该如何 *** 作，很好地实现了理论性和 *** 作性的结合。
美国著名项目管理专家刘易斯为我们提出16步管理模型。从16步管理模型中可以看到项目的战略计划所处的位置：概念确立。就是对所要做的事情有一个框架性的设计，有一种思想；问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化；生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路；战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施；项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程；签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理；执行项目计划。执行项目就是正式开展计划，进展这个项目；监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义；对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修正你的项目战略；项目的实施计划。具体的计划工作流程、对一些细节要进行评审，有问题就进行修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴；结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。
书中指出项目在结束时失败，而是在开始时失败。在我们开始一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。确定是否要进行此项目。当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括：做什么、谁来做、何时、何地、多长时间和怎么做。
其次要对项目进度进行详细计划。项目进度计划编制既是一门科学，又是一门艺术。关于进度计划，真正的重点是为在最短的时间完成项目，找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。但是，同首次进行项目人力资源分配应用的技术相比，其结果差不多。
另外，资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。
此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。
在项目即将结束之时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：（1）项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。（2）项目管理系统中的失败 。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：不胜任的项目经理 ；忽略了项目的系统本质 ；管理技巧不恰当或者错误的运用 。（3）在计划和控制过程中的失败 ：项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终止的计划很拙劣 。同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。 除此之外，组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。
《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时，只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。
软件项目被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征，就是发明阶段的不确定性要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。可是在发明阶段，就不能以此类推。在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。
本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。 在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能推出的产品。分阶段完成有以下好处：关键功能更早出现；早期预警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成均衡了d性与效率。阶段性完成的做法听来似乎毫无缺点，其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过是一点小小的付出而已。
《微软研发：制胜策略》一书中，作者详细描述了他在美国领导项目的各种实际的策略方法，教我们如何开发高质量的软件。卓越的领导者从不同的角度看世界。若是公司被大火烧得精光，他非但不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面角度来思考。就因为凡事都看光明面，卓越的领导者并不把失败当失败，反将其当作学习克服障碍的经验。正因如此，卓越的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成功，他只把这次经验当成获得信息的方式之一。这种领导人不一定要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是能将理想实现的卓越领导者。坐着告诉我们开发项目要制定详细的目标，包括你要求的输入和输出的目标、长期和短期的目标，项目组要时刻被各个具体目标的实现所鼓舞和激励；不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它；人们开口要求的东西未必是他真正想要的，处理他的要求之前，请务必先确定他究竟想要做什么；如果您能够先明确定义自己的需求，再向别人提出，这是避免在沟通上发生误会的好方法；任何不能改善产品的工作，都是浪费时间或偏离方向；项目组每部分的进度要协调一致；一旦发现错虫就立即清除掉，别拖延；程序设计前要先确定它的优先级表，比如稳定性、可移植性、速度和效率等；绝对不要答应别人自己做不到的事情，这样对双方都有益无害；注意定期会议的价值，确定它是否值得每个人放下手中的工作召开会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的；会议尽量安排在一个时段的最前面或最后面，尽量减少工作的中断与时间的切割；最会误导项目发展、伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还会迫使组员做出愚蠢的决定；为了保持创意的活力和团队士气，必须让每个小项目都有令人兴奋的结果；不要让设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。组员的技术和知识应该精益求精；员工应积极学习新的技术、养成良好的工作习惯，做事更有效率，把握有限的时间，增加你个人对公司的价值；不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长；不要给使用者次品，宁愿延期交货，务必追求质量完美；将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作；如果您创造了一项资源，并且让别人知道，那么总有一天会派上用场的；主管应该把自己视为团队的一分子，与其他人平等，而不是高高在上；健康的生活是一切创意的源动力。这些经验也同时告诉我们做人的道理。
《人月神话》一书对我的触动很大。作者详细讨论了包括工期规划、团队组成、文档、排错等软件项目进行全程中的方方面面。当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。
1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。
3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。
以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）
如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。
《凤凰项目》是一本由基恩·金 (Gene Kim) / 凯文·贝尔 (Kevin B著作，人民邮电出版社出版的平装图书，本书定价：CNY 49.00，页唯灶数：362，文章吧我精心整理的一些读者的读后感，希望对大家能有帮助。
《凤凰项目》读后感(一)：一直在寻找的WOW
这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽.
但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。
他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验. 看这本书，就像看一本，射雕英雄传。
但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。
总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。
《凤凰项目》读后感(二)：如果你找不到《丰田管理》这本书……
它在这里：//book.douban/subject/3871227/
并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？
我们干这行的都管Kata叫“招式”好吗？
这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？
你真当我是来看小说的吗？
当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。
《凤凰项目》读后感(三)：聚焦最大的瓶颈
烂摊子，没人没钱，怎么办？怎么用有限的人力显著地提高系统的质量？一个物理学家提出了一个简单理论：TOC
TOC（Theory of constraints），我更喜欢称之为瓶颈理论：任何系统至少存在一个制约因素/瓶颈，系统最终的产出受限于系统内部最薄弱的环节。要想显著提高系统的产出，就必须找到系统最大的瓶颈解决掉。所以，持续优化过程就是：
(1) 先找最大的瓶颈。
(2) 最高优先级地解决掉这个瓶颈。
(3) 然后再找新的瓶颈，重复上述步骤。
这个过程渗透着3个问题：应该在什么环节改善？改善应该带来什么成果？怎样推行改善？
我在百度工作的时候，大家都把自己的工作内容用便利贴粘到画板上，每项任务都需要提交申请，通过在画板上的需求栏、执行栏、完成栏之间移动便签纸呈现项目各个环节的状态，不仅让团队成员参与其中，还能清晰地展现出哪个环节最容易成为瓶颈。
书本上提到的三步工作法，按我工作经验理解就是：
(1) 确保工作流水线不要中断。比如，需求、开发、测试、小流量实验以及推全这些环节中有一个中断了，那就降低了整体的效率。
(2) 出现问题，就要找到问题的源头，从根源上解决掉。比如，线上出BUG，根源很可能是系统code混乱到需要重构，不只是测试的问题。
(3) 持续地尝试改进系统，不要把全部人败山拿力用在功能开发上，留有20%人力改进非功能性需求。
《凤凰项目》读后感(四)：企业IT结构
虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。
掌握整个企业流程，而非盲人摸象作为一名技术察搭人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。
迅速的从0到1，而非制造很多的0.5书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造0.5，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。 对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个0.5.
开发到运维的一体化运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员 *** 去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。
部门间永远有冲突，分清是恶意还是无意开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！ 自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。
技术储备这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。 所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。
关于“布伦特”布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。 在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。 很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。
《凤凰项目》读后感(五)：运维的蜕变，很有参考意义。
阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。
这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。
本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。
而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。
每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。
尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。
得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。
ill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。
虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。
这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。
或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？
《凤凰项目》读后感(六)：不只是DevOps
作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。
这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？
ill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。
《凤凰项目》读后感(七)：做好运维有方法
比尔临危受命，被CEO任命为IT运维部副总裁，并要求一定要完成凤凰项目。刚上任因为历史遗留问题工作上总是出现各种各样严重问题，然后他就想办法改变这种现状。做凤凰项目过程中，CEO不让招人、不花钱买设备，业务部门又步步紧逼，强制让项目时间提前上线，结果损失严重。在比尔迷茫时遇到一位世外高人艾瑞克，艾瑞克给他指导方向，教他三部工作法，四类工作类型等等。功夫不负有心人，经过艰难的改进、创新，最终完成了凤凰项目，创造了奇迹，并受到了CEO的赏识。
这本书作者写的很精彩，看到书中的一些场景，让我想起了往昔的苦逼岁月。刚开始做运维工作时，开发、业务那边很强势，自己很憋屈，比如：制定好的规则和流程形同虚设；新项目上线总是等到最后一刻才告知；生产环境有问题总说是运维问题，因为在他们本机测试是正常的；部署文档及其简单，不知所以然......因此，书中比尔每当遇到抓狂的问题时，我感同身受。里面的解决方法部分是我已经做过的，很认同，同时也学习了很多。
列几点书中的精彩部分。
1、约束点，即瓶颈。
布伦特是个技术牛人，很多问题只能他来解决。当出现计划外意外问题时，救火工作会占用他大量时间，因此计划内的工作常常耽误。
如何解决约束点问题？
第一步，确认约束点。假如约束点找错了，无论做什么都无济于事。对非约束点的任何改进都只是幻觉。
第二步，利用约束点，就是确保不让约束点浪费任何时间。永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项。计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，墨菲法则确实存在，因此总会有计划外工作，但你必须高效的处理它们。
第三步，把约束点置于次要地位。队伍里最慢的A君决定了整支队伍的行军速度，为了防止队伍拉大距离，要把A君调到队伍的最前面。A君是约束点，要保证其他人的速度和他的速度一致。根据约束点来控制工作节奏。
第四步，相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要。
第五步，增加节点，经过更多的环节流向约束点。
2、三步工作法
第一工作法，从开发部移向IT运维部时该如何建立快速工作流。做法：用持续交付。
第二工作法，如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。
做法：在部署管道中失败就停止；日复一日的持续改进日常工作；在开发和运维之间建立共同的目标和共同解决问题的机制；让每个人都知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
第三工作法：如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复的实践是精通工作的先决条件。
3、四类工作类型：
1 业务项目,开发部所做的公司项目。
2 IT内部项目，为了业务项目而产生的运维内部项目，如部署自动化、监控。
3 变更，经常由上述两种类型引起，会出现问题，交接工作时问题最多。
4 计划外工作或救火工作，包括 *** 作事故和 *** 作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。
4、看板方法
看板方法它是工作任务的可视化管理，每项任务处于何种状态（“待办”、“在办”、“已办”）一目了然。如果在看板图上，就要迅速完成。
半成品（即在办状态）是个隐形杀手，要减少半成品。（半成品是引起长期 *** 货期限问题、质量问题以及导致督办员每天都得调整优先级的根源之一）
5、资源忙碌百分比
资源忙碌百分比图标显示，等待时间是工作中心中某个资源忙碌程度的函数。艾瑞克用这张图表来说明为什么布伦特的30分钟简单变更要耗费几个星期才能完成。原因很显然，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，每次交给他的工作都只能在队列里苦等，如果不进行加速或升级处理，就永远不会完成。不知道这幅图的来历，有人认为这幅图是李特尔法则的简化版本。
书中强调了持续交付的重要性，比尔团队因为实现了它并创造了好几个项目的奇迹。它不是小说里随便写写凭空想象出来的，而是真实情况的体现，的确很有效果。如今在运维的世界里DevOps很流行，它是持续交付的实现并延伸。我们强调重复的 *** 作用机器来实现，每次相同的 *** 作必然得到同一个结果，不出现任何意外。在处理重复无聊的事情上，机器确实比人靠谱多了。
是一本好书，推荐给所有的IT从业者，相信读完它你会有很多收获。
《凤凰项目》读后感(八)：交付价值的it
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。
正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。
正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银d的
《凤凰项目》读后感(九)：与其说是关于DevOps的书，不如说是关于管理的书
IT很重要
这是此书要传递的一个重要信息。在快速更新和需要提高24*7服务的今天，运维的确变得比以往更重要。但哪个角色又不是呢？设计部门常抱怨自己的想法得不到实现，QA抱怨常常背黑锅......听说过没见过的DevOps提倡的打破Dev和Ops之间的壁垒，在此书中体现的并不多。略翻了下《SRE: Google运维解密》，似乎也是主要讲运维团队。开发团队去哪儿啦？其实小团队中，开发基本把运维的事就包了。把部署作为代码的一部分，尽可能自动化，根据运维状况进行调优，迅速更新和排错，都要求IT人员和开发人员的深度参与。所谓的壁垒，是否就是这些角色不在同一团队引起的？
TOC
这才是本书的重点。以最有价值的目标为导向，找到核心问题和瓶颈问题并解决。其实换一个部门，略微修改下，估计也会把这个故事讲下去。
部门合作
这似乎是这个项目中的最大屏障，包括一些办公室政治。当然在现实中，这也往往是事实。所以很多经理主管不得不花很多精力在这些看起来不直接产生价值的会议，争吵和手段上。
对于生产的方法论很多，继流行日本的理论后，估计来自于中国的实践理论在将来也会推广。关于部门合作方面，华为的执行力就值得学习。
外场会议
书中的CEO在多数时候并没突出表现。然而举行外场会议，承认自己的错误并及时修正，而且知道创建一个相互信任的团队的重要性。就这两点来看，的确是有领导才能。要知道，绝大多数领导是做不到这点的。这个做法，是来自于书中推荐的《团队协作的五大障碍》
布伦特
主角的名字还不如这个印象深。因为被提及的太多。一个IT工程师，扫地僧似的存在，自由电子般的问题终结者，“一个优秀的工程师胜过100个平庸工程师”说的就是这样的人。他们往往也成了瓶颈。
从组织来讲，这就是典型的项目被人绑架。实际中，也有很多类似的优秀工程师，但没达到传奇的地步，因为老是困于一个项目，从而也逐渐平庸起来，离开自己的项目会做的就很少。成了人被项目绑架。
改变这种最后双输的情况，需要魄力和一点冒险精神，因为人们总是倾向保险的做法和安于现状。
另外更重要的是，能识别布伦特和用好这样的人。
《凤凰项目》读后感(十)：这是一本项目管理的书，跟DevOps没什么关系
1 - As titled...
2- 翻译很烂，常常需要根据中文来猜英文，往往联系上下文觉得终于明白了是什么意思的时候有一张“翻译，你出来我们俩聊聊，我保证不打死你”的冲动
3- 故事其实就是记录一个传统的运营团队如何转变成为一个agile的团队，并在struggle中如何琢磨出了一套适合自己的agile的工具，对于参加过这么多次agiletraining的我来说，这些理念实在太小儿科，有时候读着读着会自己笑出来，觉得在浪费时间，
4- 小说其实写的很啰嗦，神一样的Eric在现实生活中不会存在，其实换个角度，他更像一个agile的coach，目前的市场上，agile已经是一个很成熟的体系，市面上各种coach，training， 以及书籍，完全不用像书中描述的那样通过一个又一个的mess来琢磨出一套agile的工具集，所以对于大多说的IT从业者来说，直接去读一本agile的书，或许收获会更大。
5- ‘比一名开发人员更危险的就是开发人员和信息安全部门的人联手。这样的组合把给我们添乱的动机、手段和机会都弄齐全了’ 黑的漂亮
6- 四类工作 ： 业务项目，内部项目，变更，以及计划外工作。我虽然没有完全明白他所谓的变更，但是我同意这种分类方法，我觉得变更这个事情或许会更加针对DevOps一些，而对于一个普通的project team来说，更多的是剩下三种类型的工作
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）