《凤凰项目一个IT运维的传奇故事》读后感

1、故事背景
主人公比尔，在一家汽车公司担任技术总监，工作状态以及小日子都还不错，但是公司内部已经是风云突变、危机四伏，由于比尔一直以来深受领导信任，在这个紧要的关头，临危任命IT运维部门副总裁，接管公司发展至关重要的IT改造项目--凤凰项目，项目旷日持久从、预算超支、困难重重，并且只留给比尔90天的时间，这种情况下比尔如何凤凰涅槃。

2、混论的工作流
SAN系统变更导致工资核酸发放系统故障，在规定时间内员工工资未按时发放。由此问题，主人公比尔意识到，目前的变更流程，以及变更的规范性有多么欠缺。每个人只想着干好自己的事情就万事大吉，完全没有考虑正在计划和实施的变更项目，进行相互沟通。

3、四种工作模式
四种工作类型 ：
01、业务项目
这是多数开发项目所包含的业务举措，通常隶属于项目管理办公室。项目管理办公室跟踪管理公司内的所有正式项目。

02、IT内部项目
包括可能由业务项目衍生出的基础架构或IT运维项目，以及内部生成的改进项目（例如创建新环境和部署自动化）。这些项目经常并非集中跟踪，而是属于预算所有者（例如数据库经理、存储管理经理和分布式系统经理）。
当IT运维成为瓶颈时，这会导致问题，因为不能轻易查明已经在内部项目中投放了多少生产能力。

03、变更
经常由上述两种类型的工作引起，往往在报修系统中被跟踪（例如IT运维补救、用于开发的敏捷计划工具）。事实上，在价值流的两个不同部分中存在两个工作跟踪系统，这会引起问题，尤其是在交接工作的时候。
偶然情况下，在一些兼具功能开发和服务交付职责的专门团队中，所有工作都处在同一个系统之中。这样做有一些好处，因为操作层面的故障会和功能缺陷以及新的特性功能一起，在存量工作和现行工作过程中显现。

04、计划外工作或救火工作
包括操作事故和操作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。

4、个人感悟
01、自我现状：
目前公司产品的公司，负责公司产品实施落地。因为我们公司是Tob的业务，与客户打交道相对较多，加上自己本身比较喜欢沟通，所以感觉还不错，随着在公司待的时间越长，发现已经违背的自己当初进入公司的意愿、以及初心、，很多时候我希望自己是一个技术性的角色，但是慢慢的发现，每天工作其中有多达%80的时间在做沟通。随着对产品的熟悉，以及参与越多项目的实施，发现自己不能禁锢在交付工程师的角色，也对自己的职业规划做出了一定的思考。
02、公司定义：
随着公司领导的一次次谈话，以及季度的述职，慢慢的领导也看到了我对自己职业规划思考，但是领导也表示公司也对我们的职业路线做出了规划，由工程师到交付经理，然后在再根据每个人不通的选择以及自己擅长的东西，往项目经理或者是架构师的角色转变，当然这个过程一定会异常的艰难，如果简单的话从公司随便拉出来一个人就都是经理级别的了。当然交付经理、项目经理有时候和我们理解的不大一样，虽然他们挂经理二字，但是却和经理没有实际上关系，更多层面上他是一个岗位。人总是要进步的，每个人肯定都让自己的level更高一点，或者是技术更厉害一点，以及钱赚的更多一些。
03、自我思考：
我很感激自己的经历，他们都从某种层面上去帮助了我，甚至是激励了我。24岁是最容易塑造一个人的年纪，当自己没有主观意识，或者是没有深度思考的习惯，别人的观点表达的很清晰或者是很强烈的时候，下意思的就会觉得别人说的很对。在我们公司有很多大佬，他们的思维逻辑以及说话的水平都很高，也很有道理，向大佬学习的过程中，我还是觉得自己要走主管意识。虽然大佬说的很对，但是我们不能照抄，拿来即用，还是要去思考的，不是去追究一个事情的对错，而是自己去做这件事，自己说出同样的话，自己的一个心理历程是什么样的。

I will win,Just watch!