48.《凤凰项目－－一个IT运维的传奇故事》2016.11.20 这是一本软件工程中关于过程模式的故事书。将近10年了，竟然没有再阅读过关于软件工程的小说了。我还清楚的记得，上一本关于软件工程项目管理类的小说是《最后期限》 。过程模式指的是，整个软件从需求到验收维护过程的模式，模式就是可以抽象出来一次又一次重复的东西，简单的说就是套路。这十年八年，我不断的验证着软工的这些所谓的理论的可行性，怕是没几个人像我这样教条的。相对而言，越大的公司，在过程模式这一块做得越好，我去过的最大的公司就是亲爱的26公司，中兴，而26公司这个讽刺的说法，其实是华为的朋友说的，不过这个高级黑还是蛮有意思的。后来去的亿迅，广东电信的信息化集成商，不论是内部管控还是开发流程模式，都要比中兴差很多，能有个CMM2级就不错了。当我变成甲方的时候，基本上就不要执着于软件工程的东西了，而接触到的号称过了CMM5的乙方公司，还不如亿迅，无论是需求管理还是过程模式，错了还是没有过程模式，只能用CMM1来形容这些外强中干的公司。我想，无论如何，甲方乙方是个相互映证的角色，乙方的能力从侧面来说也反映了甲方的水平，所以并不能单方面的过多的指责乙方。项目建设已经不是我当前工作的重心，所以我更关注运维。 无论是《人月神话》，《人件》，还是《最终期限》或者《凤凰项目》，老美的工程师们总能把大道理放入一个个引人入胜的故事情节里头，让我能够通过从语言描述重现一个大企业的业务场景，结合自身的经验（这很重要），来体会这些被提炼出来的模式到底是为了解决什么问题的。小说总是比死板的大部头来得生动，按道理我应该先看完《持续交付》这本获得jolt大奖的软工类书籍，这本书正是《凤凰项目》的理论依据。书中说到，通常软件产品太不稳定，太不可用，连那些曾经强烈要求这些产品的人最终也会说它不值得上市，到最后总是IT运维部在通宵达旦的胃那些糟糕的代码买单，每小时重启一次服务器，尽可能的向世人隐瞒糟糕的真相。我管着一些业务系统，糟糕的质量让我在晚上11点接到业务处室的电话，连夜折腾开发公司，解决一些看起来很不必要的问题。在我眼中，这些问题都是可以提前解决的，但由于没有按照过程模式的要求来做，大大降低了产品的质量，增加了运维的工作量。运维在很多IT公司总是被轻视的，而从管理上说，一点不比业务流程，开发工作简单，虽然大家都说懂管理，但是能够找到瓶颈资源，并釜底抽薪的解决问题的人总是少数。书中提到管理业务项目、内部项目、变更和计划外救火工作的三步工作法，对我实际工作是有借鉴意义的，因为当前的计划外救火任务占据了我太多的时间，然而业务部门有抱怨，内部运维人员也忙疯了，变更来得太简单。第一步，理解工作从开发移向IT运维时候该如何建立快速工作流，因为那是业务部门的业务运作的关键，对业务而言，重要的是结果，而不是过程或管理；第二步，要缩短及放大反馈环路，找到约束点，在源头上解决问题，防止问题再次发生；第三步，要建立相关机制，既能鼓励探索、从错误中吸取经验，又能理解反复实践是精通工作的先觉条件。书中也提到，程序员们、项目经理每隔几年要学的东西都几近疯狂，有时候完全是全新的数据库技术，全新的编程或者项目管理方法，或者全新的技术交付模型。一个人可以有几次做到把自己原有的知识全部抛下，去迎合最新的趋势？我以前的javascript的概念，已经完全应付不了Typescript的技术了，简单的代码编辑看页面效果已经没法迎合gulp的前端整合技术了，熟悉的html已经无法支撑angular的MVVM开发模式了，不能不说，学得很辛苦，原因是我已经有了定式思维，觉得数据应该是这么走的，交互流程应该是那样处理的，反而一张白纸的小鲜肉们，不需要应付技术负载，对他们来说一切都是新的，走出自己思维模式的舒适区是需要很大的勇气的，我正在痛苦挣扎中。信息化不是一个部门，而是在整个机构中需要发展的一种能力。必须跳出IT领域才能弄清楚业务人员需要依靠IT的哪些工作来完成目标。有效的管理IT不只是一种关键的能力，也是考评一个机构业务运行的重要预测指标。