凤凰项目-三步工作法笔记

前言:

去年想了解DevOps的相关概念, 看了《凤凰项目》这本热荐的入门书.

虽然看起来是一本技术相关的书, 其实以第一人称的视角来讲述, 一个IT运维经理临危受命, 推动项目转型的波折和故事, 特别生动有趣, 每个人物也个性鲜明, 搞得我明明在严肃认真的学习, 却常常像看了不正经的书似的哈哈大笑…

书中还穿插各种吐槽, 有同感的是, 我也在公司年会节目上改编过一首歌词吐槽bug什么的, 不过好在大家都挺包容的… 😄 ✨

不过, 只看一遍过过瘾是不行的, 所以整理了下读书笔记. 下文中就包括《凤凰项目》的故事脉络、有趣段落摘抄、相关概念、个人感悟.

故事脉络:

主角比尔, 一家制造和零售企业的IT运维经理, 面临着被竞争对手不断超越的困境, 接任IT运维部的副总裁, 管理一个叫凤凰的电商系统项目, 以此招揽客户并拯救公司的经济危机.

可视化管理流程

刚上任就发生工资核算故障, 起因是开发部为了修补一个审计发现, 没遵照规定的流程和测试, 直接部署了个有bug的标记化应用.

暴露的问题:
- 1. 流程繁琐、响应慢, 所以申请测试环境的预算一直没审批, 而无法测试;
- 1. 各部门沟通、协调不到位;
    - 业务市场部不断压缩IT部交付部署时间、迫切想先人一步抢夺市场;
    - 运维部不能及时交付, 开发部申请的设备、环境;
    - 关于项目完成的定义不统一, 开发部没有考虑运维部署的时间, 总是匆忙上线;
    - 开发部没有提供清晰的部署文档, 使运维部无法顺利部署, 无法进行压力测试, 没有全面监控和备份;
    - 运维的关键工程师总是要处理各种故障, 没办法参与开发部的计划会议;
- 1. 没人清楚公司整体业务架构, 都在瞎忙;

为了解决以上问题, 采取以下措施:

1. 列出工作任务清单, 了解工作需求、优先级、工作进度、可用资源(如人员职责, 所需时间), 预估工作量, 并合理调配资源;
  - 识别变更冲突以及可用资源矛盾的风险, 做出相应调整;
1. 设定变更流程, 稳定工作环境, 可视化管理IT运维部里的半成品;
  - 在白板上, 列出所有的变更、相关人员. 所有人一起讨论变更的类型，然后对变更进行筛选和安排;
  - 把一部分变更审核委派给代理人, 重点关注最有风险的变更;
    - 预先定义好高风险变更目录, 列出十大最脆弱的服务、应用程序和基础架构列表, 对相关变更申请标上记号, 并详细审查;
    - 围绕这些变更建立一些标准流程(如跟业务部门确认实施变更的时机), 相关人员关注变更、随时待命;
  - 对于低风险变更(如增加Java应用程序服务器线程池容量), 仍需要提交, 但可以直接安排操作日程;
  - 对于复杂的中等变更, 变更提交者获得可能受到影响的人员许可后, 再审核并安排操作日程;

规范流程, 保护约束点

在一次排查故障问题会议上, 各部门又开始推脱责任. 而由于没有相关解决问题的知识库, 很多问题只有高级工程师布伦特能解决, 布伦特成了项目的一个约束点, 虽然也解决了故障, 但是比尔认为这次故障可能是布伦特的某次不规范操作导致.

于是, 采取以下措施:
- 记录所有的变更, 不准再出现未经授权或未公开的变更;
- 每两周组织一次排查故障的实战演练, 让每个人都养成运用合理的方式来解决问题的习惯;
  - 如召开应急处置会议之前, 就要把相关时间线搞清楚;
- 减少需要布伦特的工作中心数量, 把布伦特的工作标准化，让其他人能够执行;
  - 建立一个3级工程师的人力资源库, 由他们处理流转过来的工作;
  - 记录整理故障解决方案到知识库里, 生成能让一些工作中心自动化运行的文档;
  - 每周逐项检查工作, 不能让布伦特就同一个问题出手两次, 否则3级工程师和布伦特都要受罚;
  - 提供相关福利, 鼓励布伦特和工程师遵守新的流程;
- 保护约束点, 让布伦特只做最重要的凤凰项目的工作;
  - 任何占用布伦特时间的人都要解释说明, 否则上报;
  - 过滤涌向布伦特的变更任务, 并在变更卡片上表示出来;
  - 收集直接找布伦特的名单, 给他们的上司打电话, 让上层知道有人在干扰凤凰项目;

问题频出, IT不受上层信任

因为开发没告诉运维需要打开一个防火墙端口, 而前端程序与数据库服务器通信失败, 代码无法在测试环境中正常运行, 延误了凤凰项目的上线. 以及一些接口延时, 性能相关的bug, 导致所有店内POS系统都会宕机.

暴露的问题:
- 部署运行测试的时间太长, 跟不上开发的节奏;
- 缺乏版本控制, 开发提供的是不完善的版本, 导致配置测试环境时, 浪费了不必要的时间;
采取措施:
- 代码试运行每天只能进行两次, 并限制所有影响性能的代码变更;
- 开发人员, 提交的代码必须标注对应某个性能问题的缺陷编号;

而这些问题使上层不信任IT部了, 要将IT部外包. 比尔和开发部老大克里斯因此进行了一次深入交流, 发现大家的压力一样大, 也为公司付出了不少. 克里斯说, 他们总要不断追赶新技术、新的项目管理方法, 一直疲于应付各种故障修复，无暇顾及功能开发, 业务部门还总是不跟IT部门商量可行性, 就直接下达任务.

上下一心, 重建团队信任

客户发票系统发生故障, 比尔团队通过一系列不间断的事后调查，搞清楚了故障的来龙去脉，采取了预防措施。同时开展了一系列全员参与的模拟事故呼叫，排演新的处理步骤, 一切都在有序的进行着. 但CEO史蒂夫认为IT部没有‘紧迫感’，要求所有相不相关的工程师都要‘手不离键盘，不能有闲人’, 比尔因此辞职了.
与埃瑞克沟通并反思后, 史蒂夫明白了IT对公司日常运作起到关键作用, 必须重视IT, 所以召开IT领导外场会议, 重建团队信任. 他先自曝, 从刚进部队时不被人看好, 一路奋斗到CEO的经历。然后几个IT领导也各自分享自己的故事, 到比尔的时候, 比尔说因为有个不称职的父亲, 他离家出走, 加入海军陆战队后, 明白了一个人可以通过做正确的事, 而获得奖励, 所以他关心孩子, 要当个好父亲, 也让他形成了现在这种严遵规范的行事风格.
然后大家也交流了一些现有问题, 并达成和解:
- 对‘已完成项目’的定义不统一. 开发团队没把运维部的工作列入考虑范畴;
- 运维部不能及时部署交付;

冻结项目, 根除计划外的工作

除了变更板上的任务外, 常常还有些计划外的救火工作, 而且随着时间推移, 还会不断增加, 约束点未被充分利用, 没向业务部门交付全部的可用资源. 董事会新成员埃瑞克启发, 类比工厂的库存堆积, 如果停止向车间发布工作和原材料, 工作以成品的形式离开工厂, 半成品数量下降, 交期性能会提升。在IT部, 也要考虑部门的实际工作能力和负荷量, 保证足够时间和精力开展制定计划，考虑清楚是否可以接受新的工作, 否则, 项目的可用工作周期变短，出现更多走捷径的技术债务, 更多脆弱的应用程序, 需要以计划外工作的形式来偿还那些技术债务的利息。

采取的措施:
- 清楚约束点是布伦特, 采取措施保护布伦特不受计划外工作的影响, 确保约束点从不浪费时间, 建立起一个可信赖的系统用以管理通向约束点的工作流, 根据布伦特来设定工作节奏;
- 除了功能开发，还要关注稳定性、安全性、可扩展性、可维护性、可操作性、持续性以及其他诸如此类的性能;
- 确认最主要的技术债务，开发部会对其进行处理，以减少问题应用程序所产生的计划外工作量;
- 确认凤凰项目是优先级最高的事, 接下来两周, 冻结所有凤凰外的部署工作, 继续开展其他正在进行的项目，减少IT半成品数量;

项目冻结行动让IT得以把力量聚焦到凤凰上，七天里完成的工作比以往整个月完成的工作还要多。但项目解冻后, 面临两个问题:

1. 项目冻结解除后，发布哪些项目是安全的, 如何区分工作的轻重缓急.
  - 在完成工作之前，要先分类列出工作所需的全部前提条件, 再加上工作订单和现有资源，理解生产能力和需求是什么, 进而可以判断是否可以接受一个新工作并对其作出实际安排。而布伦特是一个约束点, 支持了多个工作中心。假如25%的工作中心都只能由布伦特来操作，而布伦特在同一时间只能呆在一个工作中心, 工作将无法按时完成. 所以先了解工作如何流经某些工作中心, 根据对布伦特的依赖程度来决定能够安全重新启动的项目。
1. 启动监控项目是否安全。
  - 期间也发生了一次服务中断, 原因是一个网络服务供应商意外对系统作了一个变更. 而一个监控关键系统是否出现未经批准的变更的项目, 可以防止服务中断, 有助于进一步优化工作流转至约束点布伦特的流程, 让工作流服从于约束点, 尽量少依赖布伦特。

围绕约束点改进, 减少等待

‘第二工作法’的一个关键部分是让等待时间可视化，使没有完成的部件，或者需要返工的瓶颈点一目了然。要把注意力从工作中心转到工作中心之间的那些空间上, 管理好工作交接。如下图, 一个给定资源的等待时间，是那个资源忙碌时间的百分比除以空闲时间的百分比。如果一个资源使用了50%，等待时间就是50/50。如果这个资源使用了90%，那么等待时间就是90/10。当一个资源使用了99%，那么等待时间就是该资源使用50%时的99倍。

在代码投产之前，还未产生任何价值，因为那只是困在系统里的半成品。要着眼于整个工作流，确认约束点的位置，并尽其所能地运用各种技术和流程知识来确保工作得到有效执行。
所以, 帕蒂参考工厂管理工作流中白板管理技术和迭代改进的方法, 找出最经常出现的任务，建立起工作中心和工作路径, 写下操作步骤以及执行这些步骤的人员，测定每个操作所需的时间, 找出可优化的步骤, 降低重复次数。把这样的日程安排表换成看板图，索引卡片的每一行写的是分配的任务, 每一行都划分成三列，标注着“待办”、“在办”、“已办”。而用不同的颜色区分不同种类的卡片, 确保大家都在做最重要的工作, 一眼就能确认工作中紫色和绿色卡片是否平衡。
关键资源所从事的任何活动都必须通过看板, 让需求和半成品可视化，限定半成品, 制止工作缺陷交接至下游工作中心, 加快工作完成的速度。规范布伦特接手工作的方式，把他的工作标准化。从上下游两个方面弄清楚布伦特的工作来源, 阻挡那些想打布伦特主意的人。能预测工作的交货时间, 能让用户满意度上升, 让大家专注工作.
管理工作流，运用约束点来控制节奏. 像工业生产控制部那样, 安排并监督所有的生产过程，确认每一个需要的工作中心都有足够的生产能力和必要的投入, 确保能够符合客户的需求。与业务项目关联的IT项目, 也根据业务价值, 安排工作. 根据全体项目主管的排序，确定了项目解冻时要发布的最重要的五大业务项目。对于内部项目, 则根据项目能否提高在约束点(布伦特)上的工作能力，只开展能减少他的工作量，或者可以让其他人接手的项目。无限期暂停对那些非脆弱系统进行基础架构更新的项目。
凤凰项目的一个任务又延期了, 因为布伦特的‘任务’是涉及多个人员的多个任务，开发部和IT运维部两个部门之间的工作交接，也涉及多个人员之间多次交接的多个步骤, 而每一次工作交接都有损耗的时间。因此, 为需要跨部门交接的‘任务’都设置一条看板追踪路径, 把这些经常性工作记录在案，将其标准化，并且熟练掌握, 提高流量，最终就能达到产品配置的一致性。同时, 新增兼有项目经理和稽查员的职能的角色, 他们要提供每一分钟的控制。让所有已完成的工作都快速有效地交接到下一个工作中心。必要时，这个人要在工作中心等待，保证关键工作完成并快速运往下一个工作中心, 减少悬而未定的项目数量，让工作流转的通路保持通畅。

从企业目标出发, 专注要事

公司最大的风险是停业破产, 目标是提高整个系统的生产能力, 而之前一直死守的‘安全性’项目会降低凤凰的项目吞吐量, 凤凰项目吞吐量是整个公司的约束点. 所以安全部的约翰, 先找到财务部的经理迪克, 了解他在公司的确切职能, 远期目标、近期目标和评估指标.
迪克认为最重要的公司远期目标, 应该从整个系统出发, 对公司系统具备根本性的认识, 始终确保在一个正确的市场里, 作出正确的产品策略, 让企业达成目标, 那样财务目标才能发挥作用.

我们有竞争力吗？
了解客户的需求和期望：我们知道要创建什么吗？
产品系列：我们有正确的产品吗？
研发效能：我们能有效地创建产品吗？
上架时间：我们能尽快把产品推向市场并占有一席之地吗？
销售机会渠道：我们的产品能带来感兴趣的潜在客户吗？
我们的效率高吗？
按时交货：我们遵守了对客户的承诺吗？
客户保留：我们是在获得客户，还是在流失客户？
销售预测准确率：我们可以把销售预测准确率纳入销售计划流程吗？

比尔他们才意识到应该把迪克的重要评估指标作为IT任务的前提条件, 真正理解IT所参与的业务系统。于是决定, 去和业务流程负责人谈谈关于迪克说的公司的目标任务，弄清楚他们的确切职责是什么，哪些业务流程是支持其目标的. 找出对公司实现长期目标危害最大的几项内容, 弄清楚IT部门所负责帮助支撑及维护的公司业务.
帕蒂和比尔将对业务流程负责人进行访谈，主题是“理解客户的需求与期望”、“产品系列”、“上市时间”以及“销售渠道”.
- 销售部总裁罗恩认为, 差劲的‘了解客户的需求和期望’影响了‘销售预测准确率’，需要知道门店里有哪些产品缺货，进而提升销售额.
- 关于销售渠道流程及其困难的问题:
  - 销售经理们很难从客户关系管理系统（CRM）中拿到需要的报告.
- 糟糕的一天是什么样:
  - 负责管理的物料需求计划(MRP)系统和电话系统都崩溃, 服务中断, 客户取消订单, 无法完成业绩指标. 比尔接着解释, 电话系统故障是因为供应商未经授权就对电话交换机更换, 等预算批下来, 就能通过监控来强制实行控制策略, 杜绝问题.
- 业务发起人玛姬说, 她对‘了解客户的需求和期望’的衡量标准是，客户是否会向朋友推荐我们, 但是订单输入系统和库存管理系统的数据总是错的, 导致不能通过销售数据知道客户想要什么.
- 假如能挥舞魔杖, 会怎么做:
  - 她希望从门店和在线渠道, 有方便易用的功能, 得到准确及时的订单信息。运用那些数据来设计市场推广活动，不断推出“A或B”产品选择测试，以发现客户认可的报价, 并在全部客户中复制推广。就能为罗恩创建一个巨大的、可预测的销售漏斗。运用那些信息来推进生产计划，管理供求曲线。让正确的产品出现在正确的货架上，并一直备好库存。平均每客户销售额将会一路冲高，平均订单金额也会上升, 最终会提高市场份额，并再次打败竞争对手。
- 对于上市时间, 玛姬认为要控制在6个月内, 要不断降低周期时间, 不断整合来自市场的反馈, 增强回收成本的能力，最好从消费者那里直接回收成本.
建立起价值链, 包括IT方面的所需的价值链，把迪克的目标任务与IT对这些目标任务的影响关联起来，收集以前IT问题如何影响那些目标的具体案例, 对业务绩效指标产生影响的IT风险，就要着手制定更好的业务决策。弄清楚达成迪克期望结果所需要的业务能力和流程；那些业务流程所依赖的IT系统；IT系统或数据可能会发生的故障；防范那些故障发生的应对措施，或者至少能够侦测并作出回应的措施。
通过与业务负责人的访谈, 理解了哪些是重要的工作, 让业务部门相信, IT的应对措施有助于他们达成目标, 和他们一起开展把IT融入其绩效指标的工作采取措施:
- 对于“客户的需求和期望”, 目标是数据的完整性, 凤凰修复了很多这方面的问题, 还需要控制由上游产生的问题; 预测评估指标包括遵守变更管理流程、监督审核生产变更、完成定期维护，以及排除所有已知单点故障; 创建一份完整的清单，把所有支持罗恩的应用程序和基础架构都列出来。只要其中有任何脆弱的应用程序或系统，就要把它们添加到替换清单里;
- 对于“市场营销的需求和期望”，评估指标包括凤凰支持每周报告并且最终支持每日报告的能力，市场营销部生成的有效SKU比例等;
- 把发布变小变短，减少半成品和功能, 更快地回笼资金，达到内部最低预期资本回收率;
约翰研究业务部门的安全控制环境, 了解到一个拥有技术背景财务人员, 她分析一个财务方面的重要会计科目中的主要业务流程的端到端信息流, 发现, 在一个人工对账步骤中检测到重大错误，在这个步骤中，来自一个源头的账户余额和账户值要和来自其他源头的逐一比对，一般是每周一次。如此一来, 检测重大错误所依靠的控制手段是人工对账步骤，并非上游的IT系统, 所以审计师撤回他们的IT发现.
针对调研, 知道了审计安全的关键落脚点是, 确保财务报告的可靠性，符合法律法规，以及运营的效率和效果, 并提出建议:
- 大幅度缩减安全合规项目的范围;
- 弄清楚生产薄弱点一开始是如何产生的，调整部署流程，杜绝此类情况再次发生;
- 在变更管理流程中，标记出所有列入合规审计范围的系统, 避免可能危及审计工作的变更, 创建持续记录文档;
- 通过清除所有存储或处理持卡人数据的东西，来缩减PCI合规项目规模;
- 用节省下来的时间，偿还凤凰的所有关于战略风险、运营风险、严重的安全与合规风险的技术债务, 关乎关键评估指标;

形成反复实践和勇于尝试的团队文化

对需要团队合作的事情，训练成习惯，不断重复可建立起信任感和透明度。定期回顾小结，对工作开展情况以及需要改进的方面进行自我评估, 同时邀请开发部的人参加服务中断根本原因分析会.
类比跨国货运公司，要达成客户满意度和按时交货的目标。为降低更换机油会导致车辆故障, 而影响按时交货的风险，就要为车辆运营建立一个每行驶五千英里就要更换一次机油的协议, 还有已经按要求更换机油的车辆百分比, 因为如果只有50%的车辆遵守了必需的保养策略，卡车和包裹就可能会抛锚在路边，那么按时交货KPI就会大幅下跌。同样, 为了达到公司的按时交货的关键性绩效指标（KPI），也要建立一个新的前瞻性KPI，预防性供应商补丁程序以及变更管理政策就好比是预防性机油更换以及车辆保养策略。‘第三工作法’就是要让我们不断给系统施加压力，适当提高预防性工作, 从而不断强化习惯并加以改进, 形成不断改进的文化, 加强系统的健壮性. 所以, 安全部开发了一些工具, 在日常工作中, 对测试和生产环境持续不断的攻击和压力测试.
虽然由于布伦特又一次没按流程, 部署了萨拉的一个供应商项目, 导致凤凰项目第二次部署遇到困难, 但最终还是完成了部署, 帕蒂发出部署是“成功”的通知, 并提醒需要提防的已知错误，提供一个可以获得凤凰最新状态的内部网页，以及如何报告新问题的指南, 全体人员随时待命，准备对业务提供支持. 这次部署失败证明, 批量规模还是太大了。要在IT部门创建一个单一向前的工作流, 让生产能力最大化，同时让变化幅度最小化。一旦看到工作向后移动，也许是由于不合格品、缺少规范，或者返工导致, 都得开展修复工作.

让最小可行产品(MVP)加速接受市场的考验

凤凰归根结底就是为了帮助客户快速、大批量地买走东西, 最近的两次发布也为此打下了基础, 但凤凰项目延误了太多真正提升销售的功能, 这个季度的盈利是不能指望凤凰了, 所以决定从凤凰主团队里分出一小队人，组建一支叫独角兽的特别行动队，聚焦于生成良好的客户推荐, 并让市场营销部门能够开展促销活动，把库存里现有的盈利产品卖掉, 尽快达到收入目标, 然后把探索出来的成功实践复制到凤凰中.

建立反馈回路, 持续交付

丰田公司有一个引擎盖冲压工序，最初转换时间约为三天, 仔细观察了换模所需的全部步骤后，提出了一系列预备和改进措施，把换模时间降至十分钟以内。相应的, 根据第二工作法，建立一条反馈环路，一直往回通向产品定义、设计及开发的最初环节, 延伸到产品生产流程的更早阶段, 在初始阶段就筹划产品的质量。开发部和运维部, QA和业务部门一起协同工作, 持续不断地降低批量规模, 对创建环境所需的每一样东西都进行版本控制, 从代码签入到投产的整个价值流, 创建‘部署管道’，在其中自动创建测试和生产环境，把基础架构当作代码一样对待, 构建一步到位的生产环境和部署流程, 缩短准备时间并排除故障, 更快的获取反馈, 才能跟上客户需求和开发部的各种工作节奏.
业务敏捷度重点是捕捉和适应市场变化并为此承担更大风险的能力, 要持续不断的尝试，越快把那些功能推向市场接受考验，也能更快地为公司收回成本。要达到一天十个部署的目标, 那部署可包括故障修复, 让市场营销部修改他们自己的内容或业务规则，或者启用更快速的试验和A/B对比测试.
为了找到可自动化的步骤, 分析从‘代码提交’开始，到部署成功的所有步骤, 和之前上线期间存在问题的步骤, 得出返工和准备时间过长问题的来源有两个：
1. 环境: 在部署流程的每个阶段，部署环境总是没有就绪，即使已经准备就绪了，也需要大量返工才能让它们彼此同步
1. 部署: 代码打包流程。尽管开发团队尽可能地记录代码和配置，但总是在IT运维部进行版本控制，然后生成部署包部署之后，代码无法在环境中运行, 才发现有遗漏东西。
采取措施:
- 收集从错误中吸取的各种教训, 编一本关于部署运行的书
- 设置一个通用构建过程，每个人都使用自己的工具来创建自己的环境，开发人员能在一个与生产环境相似的环境下编写代码
- 运维直接拿到准备部署的打包好的代码, 一旦代码被标记为‘准备测试’，就生成并提交代码包，触发一个QA环境的自动部署, 及后续生产环境的自动部署。

清除异党

市场部莎拉急于讨好上层, 又因为以前IT经常不能完成并交付她所需要的东西, 找供应商开发第三方服务, 这些看起来是战略性, 但实际不遵守关于数据隐私的法律法规，订单输入和库存管理系统出现更多的数据完整性问题, 还得向供应商开放产品数据库，向他们解释这些数据库是如何构建的，开展众多防火墙变更，等大量额外的工作, 阻碍了聚焦凤凰项目, 这些都是对公司不利的。
在独角兽项目的关键时刻, 迪克和财务团队要调走布伦特, 让他加入制定拆分公司方案的特别工作组。但只要完成季度指标, 保住凤凰项目, 就不需要拆分公司了. 了解客户的需求和期望，拥有正确的产品系列，保留客户，以及最终提高营业收入和市场份额，才是最重要的, 所以比尔把布伦特截回来, 在史蒂夫的帮助和众人的努力下, 独角兽项目上线后促销活动的客户转化率很高, 通过了市场的考验.
理解技术能够做什么、不能做什么，是公司里每个部门必须具备的一种核心竞争力。最后, 不能融入公司新文化的莎拉离职了.

————————–—以上为暂时梳理的故事脉络, 笔记还会多次迭代————————————-

有趣段落摘抄:

俗话说得好, 如果你的同事主动告诉你他们要离职, 那多半是自愿的.但如果是其他人告诉你的, 那他们一定是被迫的. 所以说, 我的上司和上司的上司刚刚被炒了.

“比尔, 我知道你没有申请这个职位, 但公司已经命悬一线. 我需要你来帮助我拯救这家伟大的公司. 我能指望你吗?”
啊, 我的天哪! 还没来得及礼貌地谢绝, 我突然听到自己说:“ 可以, 你可以指望我.”

迪克打断了她: “这是IT部的比尔.他说他是被派来收拾这个这个烂摊子的, 或者准备在收拾的过程中壮烈牺牲, 我是这么理解的.”

“他摇摇头继续说：“要说服业务部门去做正确的事情越来越困难。他们就像走进糖果店的小孩子。他们在飞机杂志上读到，可以在云端管理整个供应链，每年只要499美元，然后这突然就成了公司的主要行动。当我们告诉他们，事实上没那么简单，并演示做好这个要花什么样的代价时，他们就不见了。他们去哪儿了？去和维尼表兄或者其他推销外包服务的家伙谈了，那些人许诺，能用十分之一的时间和价格做成这件事。”

“我脑海里立刻浮现出这样的景象，约翰问了一些愚蠢的问题，或者说了一些愚蠢的话，彻底激怒了迪克，迪克当场解雇了他，为绝后患，就把我也解雇了。
然而，我发现自己说的是：“好的，我会去的。”

“他剃了头，看上去像瘦了十五磅。他穿着一件我只能描述为“欧洲式样”的衬衫和一件马甲。和他平常穿的略为宽松的衬衫不同，他身上那件粉色衬衫非常修身。再加上那件马甲，他看起来像是个……时尚模特？伦敦夜店男？拉斯维加斯赌场发牌员？”

个人感悟:

也许大家都想把工作做好, 也为此付诸行动, 但是有没有在做正确的事就是另外一回事了. 这就需要切入顶层的上下文中考虑, 因为公司的存在就是要产生商业价值, 大家的工作就是要为业务服务. 而工作的完成, 也是多方合作的结果, 任何一个职位都很重要, 而且协调沟通还会影响整体的效率.
问题的存在不可怕, 当问题发生时, 要做的是找出应对的措施, 积极改进, 而不是推卸责任, 否则最终受累的也是自己.
而理论再完美, 最终还是需要不断尝试, 找到适合自己的解决方案, 只有实践了才知道有哪些问题, 下一步要如何调整.
将所有的工作分类, 不同的工作安排不同的优先级和处理方法.
其实这本书除了能了解开发运维、管理相关价值观之外, 同时也能学到些为人处事的方法, 比如主角总会深呼吸或者倒数几秒, 让自己迅速冷静下来, 因为情绪会阻碍正确的决策, 使问题得不到解决.
多看书太重要了, 因为当自己的视角不够高不够广, 而在一条错误的路渐行渐远时, 有人给予正确的提点自然是最好的, 但实际情况是, 那样的概率很小, 相当于两手一摊, 等着“神啊, 告诉我怎么做吧”, 所以就需要自己多主动吸收前人的优秀经验, 反思自己的行为, 不断调整, 或者以此理解自己领导作出的决策.
说实话, 以自己现在的水平, 还不能很好的吸收书中的理念, 后续还得反复研读, 细细咀嚼书中的案例, 还有最重要的, 用到工作和生活中.
最后, 作为一个学生时代就习惯性逃避写作文的人来说, 整理这篇笔记还挺不适应的, 不过, 不熟就多练嘛. If it hurts, do it more often.

凤凰项目-三步工作法笔记

前言:

故事脉络:

可视化管理流程

规范流程, 保护约束点

问题频出, IT不受上层信任

上下一心, 重建团队信任

冻结项目, 根除计划外的工作

围绕约束点改进, 减少等待

从企业目标出发, 专注要事

形成反复实践和勇于尝试的团队文化

让最小可行产品(MVP)加速接受市场的考验

建立反馈回路, 持续交付

清除异党

有趣段落摘抄:

相关概念:

精益理论

DevOps

三步工作法

IT从事的四种工作类型

约束理论5个方法步骤

个人感悟:

凤凰项目-三步工作法笔记

前言:

故事脉络:

可视化管理流程

规范流程, 保护约束点

问题频出, IT不受上层信任

上下一心, 重建团队信任

冻结项目, 根除计划外的工作

围绕约束点改进, 减少等待

从企业目标出发, 专注要事

形成反复实践和勇于尝试的团队文化

让最小可行产品(MVP)加速接受市场的考验

建立反馈回路, 持续交付

清除异党

有趣段落摘抄:

相关概念:

精益理论

DevOps

三步工作法

IT从事的四种工作类型

约束理论5个方法步骤

个人感悟:

感谢您的鼓励支持！