Project - 凤凰项目精要 - 随笔 - 上

C-1

  • 用更少的资源完成更多的业绩，既要保持竞争力，又要削减成本
  • IT运维管理：足够的资历
  • 创建最有组织、最值得信赖的团队
  • 思考自己刚才了解到了什么
  • 注意力集中
  • 公司必须获得盈利能力
  • 团队具备兑现承诺的能力
  • 来自高级管理层稳定、持久的支持
  • 足够的预算与人力资源
  • 保持必要的“沉默”，避免做出更多愚蠢的承诺
  • 负责任的公司要“照顾”好自己的员工
  • 缺乏竞争力是阻碍事项达成的大敌

下属

  • 你最希望我做什么？
  • 最不希望我做什么？
  • 可以失败，但至少不是重蹈覆辙的那种

管理者需要这样的一个人

  • 可靠的、不怕告诉坏消息的人
  • 自己可以信任的人去做正确的事
  • 始终保持头脑清醒
  • 大家觉得你可靠、务实，而且愿意表达真实想法

管理者希望

  • IT系统运行可靠有效，为业务部门提供保障
  • 减少日常运维中的故障，让开发和业务部门集中精力去实现和产出

C-2

  • 说服他人的能力
  • 关键的联系信息
  • 流程图 ---》 信息流
  • 时间的安排与把控
  • 敏感数据
  • 任何进展的状态更新与周知
  • IT运维部门的关键流程和工具，内外部协作和沟通机制
  • 本性难移
  • 深思熟虑、善于分析、条理分明、客观冷静，对流程和步骤一丝不苟 --》 流程和秩序的执行者和维护者
  • 开放式办公区域的对团队协作和个体效能的优劣影响
  • 关注的焦点 ---》本质问题
  • 谨慎承诺，技术不能解决所有问题
  • “甩锅”的能力 ---》逃脱各种应负的责任
  • 倾听、收集和对比关键相关人的看法

问题处理

  • 以前是否遇到过类似的问题
  • 易出错又危险的环节和操作
  • 问题发生前的调整和改动，是否产生重大影响
  • 备用方案
  • 外部因素：厂商、外包、。。。
  • 最坏的打算
  • 业务部门如何看待这个问题
  • “掘地三尺”探寻根因，对问题真正了解多少
  • 问题解决的沟通协调机制、流程规范
  • 问题严重等级的划分：服务中断
  • 确定各相关事件的准确时间节点

C-3

  • 断定故障原因的依据？为什么认定它没有引发故障？这个变更经过测试吗？

  • 操作过程是否按照技术日志（步骤）在执行，符合预期结果？

  • 对于跨大版本、长久时间间隔的升级，是否足够测试？

  • 实施的维护窗口是否满足“变更和回退”的要求？

  • 重要线索的获取途径？问题的关键？

  • 严格控制紧急变更：紧急需求往往潜藏“紧急的烂摊子”

  • 任何变更都必须遵循规定的程序和流程，未通知其他人的情况下展开变更，会带来极大的麻烦

  • 找到关键相关人、盘问、弄清楚他们做了什么？梳理清楚故障的来龙去脉？

  • 同样的错误不允许再犯

  • 公司的组织架构

  • 实用有效的变更系统、流程和工具：审批、授权、跟踪

  • 变更管理经理：更好地了解情况，完整地掌握真实情况

  • 并不是每个人只要把自己的工作完成就可以获得团体性的结果！

  • 没闲工夫每出一次状况就详查一番基础性的信息！

  • 准确的时间节点 --》 易于获知事件的前因后果

C-4

  • 日常沟通事项的快速处理：邮件、即时通讯工具等，固定处理时间段，优先级

  • “所有事情都那么重要”这不可能，也不应该！！！

  • “交接环节” ---》相关人，一定要形成书面材料，明确所有关键项信息！！！

  • 没有IT部门的参与，大部分业务项目将无法完成！

  • 项目管理与IT部门的协作：有条不紊、客观冷静、富有责任感

  • 干练的管理者

  • 更短的时间、更少的经费去完成并交付更多的产品 ---》 可能性？

  • 阶段的关键路径和关键人力资源，此阶段的主要任务？

  • 不能再用“常规做生意的思路”来行事，来处理非常规问题，始料未及的突发事件。

  • 尽管做了充分的思想准备，但还是会感到怒火中烧。

  • 盛气凌人、几乎都是在指责他人的工作渎职和能力不足。

  • “办公室政治”，虽然不喜欢，但也只能接收现实。

  • “甩包袱”是人性的常规操作。

  • 不要对任何建议抱有不切实际的“期待”。

  • 管控情绪，不要轻易“拍案而起”。

  • 在“落地实现”的过程中，会发现每个层面都会遇到问题。

  • 要想打破“恶性循环”，就必须从源头上解决问题，才能不再疲于奔命。

  • 催促他人被动去使用流程和工具，得到的结果可能只有抱怨和接口。

  • 采用ITIL（IT基础架构库，包含很多IT实践和流程）而不有效落地，最终只能得到一套无人遵守的纸面好流程和工具

  • 有效落地，意味着必须自上而下地贯彻执行

  • 任何规避变更管理制度的相关人都将受到纪律处分

  • CAB会议：变更审计委员会，每周召开一次

  • 流程设计不能坐而论道，而是需要真正去干实事 ---》 实用的流程

  • 为问题解决提出解决方案，而不是成为问题的一部分，我能相信你吗？

  • 如果手下的主要管理人员似乎斗得不可开交，要付出怎样的努力才能和平共处呢？

C-5

  • 推脱问题，将球扔到对方半场，只是极为短暂的临时办法

  • 如何建立一种互相尊重的工作关系？

  • 他人的事项追踪路径？

  • 内部审计与外部审计 ---》 发现和评估形势的严重性

  • 账号权限管理 --》 权责分离的要求

  • 怀疑他的立场与倾向

  • 大部分的报告其实都“大而无用”

  • 关键在于，我们在有限的时间内可以做什么，以及哪些系统是真正涵盖的？

  • 会议的目的：形成共识，达成一致意见和行动，明确下一步的工作

  • 办事节奏

  • 如果离开某个人，团队就干不成事，那就遇到大问题了

  • 真正地理解各种应用和组件如何在业务整体层面协同工作 --》 技术性全局视角

  • 弄清楚究竟需要哪些资源？如何一次性申请充足资源？凭证？

  • 承担的义务与所拥有的资源

  • 花时间培训和帮助新人，新进人员不会产生效益，而是记过3~6月才能完全发挥作用

  • 工作清单是怎样的？没有记录在案的工作是什么？为什么？

  • 清单机制：应用系统项目、基础架构项目等等，清单会有多少个？会有多长？该怎么做才能列出？

  • 对工作需求、优先等级、工作进度、可用资源、工作量估算的把控 ---》 与工作职责相对应

  • 弄不清楚现有的任务，就无法有效增加和开展新任务！

  • 一个简短的文字说明，描述工作是什么，以及完成这些工作需要多长时间？

  • 合理争取和安排更多的资源

  • 紧要任务总是在不断累加，导致原有的任务不断往后推，直到所有人都在大喊大叫，我们必须直到没有完成某项工作的真实原因！！！

  • 关键人工作清单：简明扼要地列出所有工作任务、正在做什么，以及要花多长时间来完成这些任务

  • 通过工作清单能够明确查人力资源的消耗和需要的人手

C-6

  • 分析当前的形势，而不是一味地应对突发情况

  • 开展访谈 --》 收集数据 --》 做分析

  • 15分钟访谈：以结构式交谈获取必要信息

  • 人力资源在项目上的分配，各自的任务和工作余量

  • 知道真相总好过一无所知

  • 项目类型：内部项目、事故及故障修复工作、审计合规修复

  • 关键系统缺少高可用和冗余的情况下运行，是可以避免的隐患。

  • 预防性维护

  • 确保将关键人力资源的精力能够投入到关键项目上，而不是在无关紧要的小事上

  • 如何才能改变“游戏规则”，并获取足够的人力资源，以便恰如其分地完成所有事项呢？

  • “活跃气氛，激励他人”，固执己见式的争吵只会一事无成

  • 强化变更控制，一套可持续的流程和工具

  • 变更计划的制定者、将要实施变更的系统、一句话概述，弄清楚“变更”的定义

  • 现在建立一个有效系统之前，不断尝试，运用所有资源达成目标

  • 需要一些实用的工作方法来稳妥地计划、沟通和实施，不改进方法就无法取得效果，对经验和技巧都有要求

  • 面对现实，没人会真正遵守一套低效的流程

  • 阻止员工去做理所应当的事，将毁掉热情与支持

C-7

  • 工作视图：每周、每日

  • 避免被卷入“政治旋涡”

  • 目前为止，你的印象如何？如果想让一切重回正轨，你有什么计划？

  • “实事求是”，摸情况，工作流程与边界

  • 改进流程，从“救火模式”中解脱出来

  • 只有掌握了战术，才能实现战略目标

  • 你面临更严峻的问题，而这个问题与你所说的“效率”和“流程”毫无关系

  • 当前的问题是，你显然并不真正理解“工作”是什么？

  • 你对“工作”的定义是什么？是否达到了可以解决实际问题所需要的理解程度？ ---》对于整体组织层面的，而不是个人或管理者层面的

  • 是否真实见过“工作”是如何产生、跟踪、完成、提交和统计的？

  • 如果你没有真实见过与体会，那就没法去管理，更不要说组织、排序以及确保足额配备完成工作所需的资源了

  • 在你对工作的内涵有更好的理解之前，任何关于控制工作的讨论都是“偏离方向”的

  • “夏虫不可语冰”

  • “工厂流水线的半成品、库存”现象与影响

  • 半成品（WIP）是导致长期交付问题、质量问题和优先级不断调整的根源之一，是效率的隐性杀手

  • 最关键的机制之一：工作任务和原材料的发布，否则无法控制半成品 ---》 工作导入量

  • 有科学依据的管理运动：约束理论（TOC）、精益生产、全面质量管理

  • 不应该根据第一个“工序或步骤”的效率来安排工作，而是根据瓶颈资源所能完成工作的速度。

  • 在瓶颈之外的任何地方做改进都是假象，都是徒劳的！

  • IT是知识工作，很难以完全统一的工作标准、流程说明以及“严明纪律”来条框和涵盖。

  • 如何确保形成一条迅速、可预测、持续不断的计划内工作流，从而交付价值同时尽可能降低计划外工作的影响与破坏？

  • 稳定的、可预期的、安全的IT服务，为全局性的目标服务，而不是为某个部门的目标服务

三步工作法

  1. 理解工作，建立快速工作流，衔接客户
  2. 缩短和放大反馈环路，在源头上解决问题，避免返工
  3. 建立文化，鼓励探索，吸取教训，反复实践

C-8

  • 不断提醒自己，成败取决于如何沟通好这一切

  • 对真正的工作需求和效能做分析评估，把工作的传递途径可视化

  • 在相对完整知情的情况下，决定何人应该在何时开展何种工作

  • 该做的终究都得做，谁都一样！生活是艰难的，工作也是如此！没有借口，硬上也要上！

  • 关键人力资源缺少、基础架构脆弱、改进措施见效缓慢，是原因也是问题!

  • 基准问题测试 --》 清楚差距与缺陷

  • 工作不是变魔术，会有惊艳的呈现，而是要预演最坏的情况

  • 需要有人在“头脑发热时浇冷水”，恢复一些理性思考

  • 同理心，换位思考，以同感，求共识，获支持

  • 80/20 法则：重点关注最有风险的变更，必须由CAB审核批准（每周一次的CAB会议，确切的议事规则与流程）

  • 变更种类和等级，风险性与流程环节相匹配

  • 把全局性、体系化效能问题的所有责任都压在某一方是毫无道理的

  • 数据性支持：变更的时间、成功率、相关联的故障时间 --》业务部门在更全面掌握信息的情况下做出变更的决定

  • 标准变更（低风险）：已经多次成功实施的变更，只需要提前批准就行

  • 复杂的中等变更是否恰当地通知了所有可能受到影响的人，并获得实施许可

  • 高风险的变更，密切关注问题趋势

  • 流程创建和落地阶段，更应关心流程的完整性、规范性和相关方的参与面

  • 不准出现未经授权的变更，也不准出现未公开的变更

  • 变更冲突以及可用资源矛盾，“拥挤的空域耿一凡发生撞击事故” --》“交通管制员”必须更清楚了解情况、维持秩序

C-9

  • 变更影响：明确哪些可能导致服务中断，会造成严重级别的事故

  • 不能凭感觉做事，不能主观猜测和臆断

  • 控制情绪：掩盖怒容，防止出现鲁莽的言辞和行为，陷入疯狂的状态

  • 作为事故的处理负责人，必须首先弄清楚相关事件，尤其是相关变更的时间线

  • 为基础性原则坚持态度，不软化

  • 定时组织的排查故障的实战演练

  • 合理解决问题的习惯

  • 应急处置会议之前，从时间线上搞清楚问题的发展过程

  • 对整体产生重要影响的工作，都是凸显协作效能的

  • 类型工作： 业务项目、内部IT项目、变更

  • 变更和项目的关系是什么？同等重要吗？这些变更都是从哪里冒出来的？

  • 实施变更的必要性，是否支持具体项目？

  • 从端到端的整体业务实现流程的全局视角来审视和思考

C-10

  • 最重要的任务纲要

  • 如何规避变更风险，不再为部署变更日而提心吊胆？

  • 从哪种角度去理解和解释为什么有些事情未能完成？

  • 进度报告、更新后的完成时间节点、资源需求

  • 观察并寻求理解

  • 如果一个员工“专业又聪明”“在具体事项上又显得无可或缺”，那么他大概率已经成为了一个整体效能的“瓶颈点”

  • 看起来他确实是在全心投入地解决IT问题，但实质上已成为某些人的“私交性办公同事”，高管的“私人助理”

  • “唯一一个知道问题在哪里的人”，也可能是无效忙碌的人，没有发挥关键性作用

  • “他把知识和信息当成了一种权力，不愿意分享，也确实让他成为了几乎难以取代的人”

  • “他解决了其他人无法处理的问题，引以自豪，但却使整个系统变得更加愚笨”

  • 如何才能改正大家直接来“指派和干预”某个人工作内容和顺序的坏习惯？？？

  • 必须改变工作流，流程是用来保护人和工作状态、提升整体效能的！！！

  • 记录和分享，不能反复解决同一个问题，也便于日后分析

  • 任何情况下，都不准做哪些无法在事后记录的事项

  • 解决一个问题，知识库里就应该多一篇关于如何解决某个疑难杂症的文章，而且能够实施修复的人会越来越多。

  • 为了摆脱困境，必要时采取一些极端措施

  • 定义“关键人”的新流程、新职责，周知并“警告”相关人遵守

  • 为什么他们认为自己的项目、自己的任务如此重要？

  • 如何鼓励相关人遵守新的流程？ 加强学习、分享成就、维护名誉？

  • 必须把知识全都交到真正从事这项工作的人手上，如果他们无法心领神会，那么就是责任心和技术能力出问题了。

  • 必须让从事工作的人明白他们究竟在干些什么，而不是让更多人去囤积知识。

  • 设法降低对“固定人”的依赖

C-11

  • 变更日程表
  • 为什么变更没有完成？
  • 是谁批准了所有这些工作进入了系统？
  • 如何对汹涌而来的工作说“不”?是否应该接受这些工作？又凭什么做出了决定？
  • 我们需要更好地理解，什么工作将会成为“关键人”的头号任务？
  • 确定事项的优先级、分类？确定相关的变更是什么、有多少？

C-12

  • 代码在测试环境下通过各项关键检测

  • 软件缺陷报告

  • 配置和设置的一致性：测试环境与生产环境

  • 如何配置齐备的端到端测试环境？

  • 必要时，对团队和流程进行全面的管理检查

  • 了解关键人对目前形势的看法？从你的角度看，事情进展得怎么样？

  • 找些彻底了解那些事情的人，问问他们的想法？

  • 弄清楚我们自己应该置身何处？现在的方位又是怎样的？

  • 完善的软件版本：版本编号？软件包管理？

  • 测试流程的可控性：终止 或 回退 ？对于临时加入内容的应对？

  • 流程的“单向性”：无论是提交新代码、例行发布、文档记录，都只能是“单一入口”的！！！

  • 试运行的进展情况 --》明确风险与隐患、获得建议、进行讨论

  • 是否充分理解变更的可能带来的副作用和风险？

  • “谁”是这场自杀式混乱的始作俑者？？？

  • 事已至此，事态愈发不可收拾，糟糕程度不断突破原本的底线。此刻，别无选择，只能最后一搏，阻止这疯狂的行为！

  • 需要对形势有一个全面的了解：其他相关事项的进展如何？

  • 相关人都发一份摘要，尽可能地概述发生的事情，并就如何快速获取指示，形成共识和一致行动。

  • 面对现实，这是一场持久战。

  • 数据修改：审计轨迹、恰当地管制，保证数据的完整性和安全性

C-13

  • 履行职责，意味着有问题时，挺身而出，首当其冲；面对结果时，难辞其咎，对成败负责！

  • 你对整件事该负怎样的责任？ 没有人能够代替你思考和下决定！

  • 要怎样才能摆脱困境、恢复正常的业务运营？

  • 找到那个行事可靠、认真负责的人！

  • 提交的代码必须对应某个特性或缺陷编号，没有标注的都要退回

  • 限制所有影响性能的代码变更

  • 很想看看他们是怎么干的，暂且观其后效，再下定论。

  • 演练业务流程，了解运作情况，理解问题的严重性

  • 尽我所能，当别人能够通情达理确实相信我们已经没有余力的时候，心理上其实得到了一些认可。

  • 技术资源库 --》 专家组？？？

C-14

  • 解决方案 --》带着实际解决方案（即使是临时性的）来汇报和沟通

  • 有些时候，有些场合，说出真实想法可能会招来斥责

  • 项目的梦魇：最后一刻变化的需求

  • 从IT角度去说服业务部门去做正确的事情越来越难，谁都不愿意为不确定结果的代价买单。

  • 对重大事项的可行性调查

  • 敏锐的直觉 --》判断是否可以相信人？？？

  • 什么样的改变？IT行业技术日新月异，变化之快几乎很难让人跟上了，每隔几年要学的东西都几近疯狂。

  • 一个人可以有几次做到把自己原有的知识全部抛下，去迎合最新的趋势？

  • 最有可能搞死你的不是前期投入和搭建，而是后续永无休止的后台运行和维护。

  • 工程师一直疲于应付各种故障和日常事项，根本无暇顾及根本性的改善与提升。

  • 为满足多种业务和功能需求的实现和进度，正迫使我们去走“短平快”的捷径，但这些捷径正逐步导致日益恶化的整体效能。

  • 迟来的真相总比永远被蒙蔽好，说真话总是“很艰难”。

  • 做好应对被动地“背黑锅”的准备，总会有些人会想法设法把所有责任都推给我们

  • “稀奇古怪的政治手腕”

  • “宁愿虽败犹荣也不会坐以待毙”

  • 与关键相关人至少保持每周一次的沟通：聚餐、聊天、碰一下想法，想一想得做些什么？

  • 鼓励每个人都去露下脸，体会参与感！

  • 建立人情往来，哪怕只有半小时。

C-15

  • 什么是“最重要的人”? --> 工作上？生活上？

  • 无论工作怎样，都应必须保持生活上的正常状态！

  • 倾听来自家人的声音，不要对工作太过全神贯注，更不要陷入“心力交瘁”的状态

  • 成为极少数能够兼顾家庭和事业平衡的人：养家的人（养家糊口）、家长、伴侣、突发事件的应对者

  • 不得不日复一日地应付各种不可能完成的疯狂要求，这值得吗？

  • 更糟糕的是，要面对很多让你厌恶甚至憎恨的“疯子”和“精致利己主义者”

  • 别太有“圣人心”，我们做好本职工作便是责任心，至于拯救团队和整个公司。。。别想太多

  • 预防措施：很少能明确知道究竟避开了哪些灾难？

  • 问题故障：无视它们的存在是没法蒙混过关的

  • 临时性的工作：计划外的工作，最具破坏性的一类工作，“救火的事情”

  • 计划外工作阻碍了其他类型工作的完成：业务项目、内部项目以及变更的有序进行

  • 计划外工作的破坏性以及可避免的本质

  • 计划外工作是恢复性工作，几乎总是让你远离目标，知道你的计划外工作从何而来尤为重要！！！

  • 想方设法采取一切必要步骤，阻止大家去做错误的工作，更确切地说，计划外的工作

  • 计划外工作会让你丧失开展计划内工作的能力，必须不惜代价地根除计划外工作的最大源头！！！

  • 可视化工作管理工具：着手稳定工作环境、营造工作氛围、建立快速工作流

  • 管控“约束点”，提高流量，约束点可能很大程度上未被充分利用

  • 约束点（瓶颈），决定了整个系统的产出

  • 如果没有还清技术债务，那么随着时间推移，你遇到的问题和计划外工作量一定会不断增加。

  • 别对你无法控制的事情怨天尤人。在其位，谋其政。

聚焦步骤

  1. 确认约束点：对非约束点的任何改进都只是幻觉
  2. 利用约束点：永远不要让约束点迁就别的资源而干等着，专注计划内事项
  3. 把约束点置于次要地位：弄明白如何根据约束点来设定工作节奏，怎样有效控制约束点的工作量
  • 非功能性需求：稳定性、安全性、可扩展性、可维护性、可操作性、持续性
  • 那个最了解技术债务欠在哪里和如何构建代码的人，应该发挥真正的关键作用。
  • 区分与业务相关或无关的工作，将无用的工作剔除系统更为重要
  • 你应该知道，与实现企业目标息息相关的是什么 ---》 重要的是结果，而非过程、管理，或者你完成了哪些工作。

C-16

  • 重大故障：叙述整个事件，说明过去72小时里的全部变更，理清故障的时间线并推理可能的原因.

  • 未经批准，什么都不准碰

  • 不要各种猜测，而是基于事实的推理，将时间线和数据汇总起来，进入深入的调查

  • 事故调查应该井然有序，有条不紊，拿出防止再发生类似情况的办法

  • 开展全员一系列全员参与的模拟事故呼叫，排演新的处理步骤

  • 事故处理过程中的定时状态报告，了解进展情况

  • 面对不确定因素，理清利害关系，妄下结论会将事情弄得更糟糕 --》现在最重要的是我们得了解全局

  • 能告诉我你在想什么吗？局面在我掌控之中，你现在还需要什么？

  • 公开透明：为团队成员开放接触上级和业务部门的渠道，是存在一定风险的

  • 摆脱对某个人的强依赖

  • 充分训练如何处理服务中断，考虑情况的复杂程度和不确定因素

  • 和二级下属直接交换意见？ --》沟通的顺序和渠道？

posted @ 2024-07-23 10:07  Anliven  阅读(11)  评论(0)  编辑  收藏  举报