序
这本书前后也看了一年，一方面是书中的内容太专业，不少的内容我都看得一头雾水，毕竟我在软件开发中的经验还是非常有限，另一方面，我现在所从事的工作对技术的要求与一线的技术专家并不一致，我所走的是CIO的职业发展路线，而不是CTO，因此信息化愿景与项目管理是我做的最主要的工作。
在项目管理上每每遇到问题，我都可以在我的背景知识中找到方法，至少我所采取的每一个方法都有对应的方法论支撑，实际上，有好的方法论并未一定能解决现实的问题！然而，相对专业的工作方法还是让我获得了同事们的认可，虽然我满是挫败感。
软开沉思
看完有关技术与过程模式的专家论述，我还是有不少的收获。回想起我第一次接触到CIO的角色描述时，第一反应就是，技术才应该是主导，所谓的信息官看起来就是一个官僚的设置。我一直都是一名工程师，直到我到了现在的岗位，在甲方负责信息化工作。我足足花了几年时间去调整自己的技术结构与工作方式，我曾经试过用自己掌握的专业化知识去写技术要求、结合合同规范供应商、加大对文档的审核、邀请第三方技术专家开评审会等方式，但收效甚微。
专业与业余的区别
恰好前两天，在送孩子去少年宫上课等停车位的时候，听到来吴军的硅谷来信，其中说到专业与业余的区别，结合他在约翰霍普金斯大学的医生朋友的观点与自己的体会，归纳如下：
首先，好的专业人士要在任何情况下为工作本身着想，他们不会因为看到患者是个瘾君子，态度就和对待一个社会名士有所不同，也不会因为最近自己的一些家庭变故就影响自己的工作。相比之下，我观察到那些职级和层次比较低的员工，常常把自己的情绪带到工作中。比如最近和女朋友吵了一架，一周的工作就受影响，上班路上被一个大妈骂了两句，这几天接待老年妇女就没有好脸色。这就是不专业的表现。
其次，专业素养意味着遵守流程和行业规范。约翰·霍普金斯医学院的一位名医给他女儿检查近视眼毛病时，先做了一系列的检查，排除了那些可能性极小（但是如果发生结果会很糟糕）的情况，然后一步步找出原因。在此之前，其他一些眼科大夫则显得没有章法，当然也就没有找出病因。
第三点，是否有专业素养体现在是否愿意花工夫寻找更好的答案，而不是交差了事。比如吴军的会计每年替他报税的时候都会仔细地走一个流程，不漏掉每一个能替我省税的地方。有一年他去为大学尽自己的义务做事，按照美国的税法，自己掏腰包花的钱，比如飞机票和酒店房费都是可以免税的，但是那一次用的是里程购买的机票，因此没有飞机票的发票。一般的会计可能是给他什么发票他就怎么做账，但是这个会计发现这次差旅只有酒店的发票，而没有机票的，就主动问吴军是怎么回事。了解缘由后，将里程数折算成等值的金额，省了100多美元的税。虽然100多美元不算多，但是由于他在每一个细节之处帮雇主寻找更好的省税方法，加起来每年能节省几千美元的税。相比之下，我的一些朋友为了省钱找了一些不很专业的会计师报税，那些人做事就是交差了事的心态。
第四点，专业人士常常有完整的领域知识，或者说掌握了成体系的知识，而业余人士常常只掌握了一些知识点。前者因此具有分析问题，解决未知问题的能力，后者常常只能应用所知的一些知识。比如在法律上，一个业余的有些法律知识的人如果再遇到他以前遇到的事情，比如某种情况下的财产纠纷，他知道如何处理。但是对于他们没有见过的事情，提不出任何有实际意义的建议。而专业的法律从业者则不同，他们能够应用自己广博的法律知识，找到一个可行的解决方法，即使那种方法未必是最佳的。吴军在Google时，遇到的很多专利、知识产权甚至隐私权的纠纷可谓千奇百怪，很多是没有先例的，但是专业人士能够找到解决问题的方法。
最后，也是非常重要的一点，就是具有专业素养的人是在动态中进步的。无论是当工程师、医生还是会计师，一流的从业者都是不断学习和进步的。
CTO与CIO的不同
阶段性反思，是我每过一段就会做的事情，在我的反思过程中我深深地认识到以技术为主导的CTO与以业务为主导的CIO之间有什么不同。
我认为CTO是在一个IT技术为主导的公司或科研单位中的角色，必须对各种技术的大纲与细节都要有一定的了解，
- 一方面能帮CEO把控项目开发的进度，在遇到技术难关的时候能给出对应的解决办法；
- 另一方面并对产品未来的或技术前景有着自己的把控，并对CEO负责；
CIO是在一个非IT技术为主导的公司或单位中信息化管理者的角色，对单位的业务相当的熟悉，同时了解主流的IT技术，能找到如何运用IT技术优化业务工作，提升业务的效率，这种架构下即便有CTO也从属在CIO的管辖之下。
- 一方面能用IT技术重新梳理业务流程，作为高管的一员，能够在公司决策的层面上提出信息化工作方向。
- 另一方面对单位的信息化愿景以及信息化资源有足够的把控能力，并能够使用公司的力量保证项目的顺利完成。
对于CIO来说，如何规划信息化资源，并在资金与实际效益中获得平衡，就非常重要。CIO也需要对相关的技术有一定的了解，比如了解：
- 该项技术的缘起，为了解决什么问题
- 该技术的优势，在以往的一些解决方案中起了什么作用
- 该技术在本单位或本企业中可以解决一些什么潜在性的需求
- 该技术的前景如何，未来的发展与投入应该怎么规划
- 该技术需要落地的话，应该得到项目干系人怎么样的支持，业务应该作出如何的调整以及项目风险，如何划分阶段来做技术与业务的更替融合
三足鼎立
缺乏有效的过程模式，无论在需求探索，架构设计以及进度管理上，都无章法可循，尤其是在当下设计与实施并无分开，项目招投标下来才开始做详细的需求与软件设计的无奈前提下，没有过程模式就只能是看运气了，因为即便采用了有效的项目管理方法，项目依然有一般以上的可能是失败的，项目管理者必须有一开始做IT项目就有可能失败的想法，必须保证在情况太糟糕的时候，呈现的效果不会太差。
缺乏对软件开发产品的质量评价，是大部分项目实施不如意的根本，因为当下的软件开发公司，花了大部分精力在拿项目，大大缩减了研发成本，一般而言，只会将他们之前曾经使用过的软件代码裁剪成一个符合合同要求的产品，毕竟在合同拟定的时候，那些参数要求是最基本的要求，而不是理想状态下的日常使用要求，大部分的软件产品在性能、可扩展性、易用性与易维护性上都难以满足用户的要求，即便是各个上市公司的产品。然而，放在开源社区的主流产品，一般都经过了社区的代码评审，设计得差劲不好用的产品，根本不可能形成社群，不可能有人热衷去使用与贡献代码。在当下不可能实现对项目质量进行量度的情况下，基于开源项目定制开发，必然能提高软件的质量和降低项目风险。
运维一直我们非常薄弱的环节，通常是外包团队漫不经心的交付了软件产品后，驻场的运维团队只能关注服务器是否正常运行，并不能接手这个新交付的软件产品的代码或数据库运维，从而无法解决在实际环境出现的问题，对于这些问题，开发厂家通常以无法解决，或产品不支持来搪塞用户，使得信息化团队在支撑业务工作中不断受到来自业务部门的诟病。厂家的不厚道，薄弱的运维，造成了自身力量的过分孱弱，使得每次一旦有新的用户需求，基本上都无法正常的支撑，除非动用了相对多的项目干系人才能勉强的完成。
在我看来在我们这种非IT技术为导向的单位，需要有持续集成+开源+规模化OpsDev团队，才能保证信息化项目能跟得上业务的变化，并能应对引入新技术对现有系统的影响。其中
- 持续集成是一种过程模式（方法论），针对软件生命周期的一种有效的方法，
- 主流的开源技术是针对类似业务流程的一种有质量的技术保证（优质产品），
- 规模化的OpsDev团队是能保证系统运维与开发能齐头并进且能在最快时间让技术调整能跟得上业务变化的自有力量（自有团队+外包团队）。
结语
对比起吴军提到的专业与业余，我看到了自身努力的一面，当然我不断的追求进步、计算机领域相对全面的知识储备、不断找到更优的解决办法，我的确是称职的，但是我做不到不受情绪能在无时无刻保持着专业的状态，也没能做到完全遵守流程和行业规范，明显我专业的程度是打了折扣的。
追求完美才能成就卓越，所以，除了技术，我还有很多需要修炼与学习的，有用的办法一定是根据实际的情况下想出来的，不可能在教科书和他人的经验总结中找到，那些只是灵感的来源，绝不可生搬硬套。
越来越接近那个令人生畏的35岁，但只要不想着和年轻人争饭碗，合适的年纪做合适的事情，一定要相信专业的人才是可以跨越领域的，无法跨越的时候，你要清楚的知道，你的专业能力肯定是不足。
管理学上有个著名的“彼得原理”，说的是在一个组织中，每个人都趋向于最终晋升到他所不能胜任的地位。这个原理的逻辑推理很简单：员工做得好，经过一段时间就会得到晋升；而最终晋升到的那个层级，他不能完全胜任，他的表现也不再突出，他就会停留在这个岗位上。
愿我们都不是“彼得”！