Team - 杂谈杂记

---

01 - 从IT运维到IT运营

主动式运维相比被动式运维，其关键在于从被动解决问题变为主动防控风险，在于持续总结优化，将运维活动延伸到系统运行全周期，形成改进闭环。
通过总结、反馈、优化等活动避免问题再次发生。

具体体现在从“从IT运维到IT运营”的转变。

传统的IT运维管理更多是被动式“维待＇，面向基础设施、软硬件等，更关注稳定、安全和可靠，注重故障修复。
随着传统信息架 构的变化，需要一种全新的IT支撑模式来解决信息系统异构、数据融合、管理分散造成的新问题，即IT运营。
IT运营相比IT运维，更加主动地对系统进行全面的分析和评价，面向“经营＂、业务、服务，但本质是面向用户，更加关注体验、效率和评价。

---

02 - 互联网意识

必须站在用户的视角，基于用户需要什么来设计产品，对外提供服务。
同时为了快速响应用户需求（甚至快速试错与纠错），内部的IT服务也必须高效敏捷。

---

03 - 成熟度模型

• 作为判断组织是否处于一个特定规模和组织需要实现哪些工作
• 定义5个不同的类别来表示在实现持续交付时需要考虑的关键方面:文化和组织、设计和架构、构建和部署、测试和验证、信息和报表
• 识别在每个活动中需要采取的步骤以及所选定的每个时间周期的特定目标，也就是“一定周期内达到的状态”
• 需要对现有系统进行怎样的更改？对未来整体业务计划的影响？
• 合规性：质量、测试阀门、数据安全

---

04 - 快速响应与实现

## 尽早变更
产品先以一个可视的原型展现，越早发现问题，做出修改的代价就越小。

## 缩小决策范围
建立一个快速有效的决策机制，让“一线指战员能够呼唤炮火”。
决策的人级别越高，效率就越低。但如果决策的人级别太低，又可能造成大量的意见，不能服众。
应该让那些有决策能力的、对产品特别熟悉的人中最低级别的人来做决策。

## 设置优先级
所有的任务都设置优先级，当做出承诺的时候，只承诺高优先级的时间计划。

# 自动化一切
要做好自动化测试、一键发布、灰度发布、故障快速定位跟踪、故障快速恢复等措施，以应对频繁变更。

---

05 - 团队规模导致的问题

随着团队规模的扩大，通常出现的严重问题

## 缺乏信任和协作的“墙”
由于人数众多，难于管理，只能通过制度、流程、规范、绩效来做约束。
也许组织的执行力看起来确实很强，员工绝对服从，流程制度上不容易出错，但是效率却非常低下。
因为在实现层面，员工都是以KPI为前提的，很难推动那些没有事先与KPI关联，但又十分重要的工作。
尤其在跨部门沟通和协调的时候，效率太低。

## 没有责任感
除了管理者，没有人愿意去决策和适度跨界，因为一旦失误将是非常大的责任，所以很多人都是在被动等待。
于是很多人依靠严格的流程，严守自己的关口，忽视整体效能，否则出了问题自己要“背锅”。
员工只关心KPI，而KPI是由上级主管一级一级来决定的，所有人都为了“不犯错”，结果“自卖自夸”的汇报成为了“重中之重”。
结果就会出现大量汇报材料和空泛的文档，取悦管理层的优先级高于了业务盈利的优先级，而管理者则被推入到“各种决策会议”之中。

## 不尊重专业人士
少数人的“一言堂”，管理层和决策层的话会被过度地仔细推敲，忽略领域专家的观点。

## 管理层级太深
管理者不知道也无法理解下面的人在干什么，为什么这么干？
只能通过汇报，去了解进度、识别风险、评定绩效、实施奖惩等，又导致了很多会议和形式上的汇报文档。

可行的解决方法：

• 管理层应该在项目和团队管理工具上直观地看到事项进度和资源动态，比刻意的汇报内容要更真实快捷
• 整体业务的盈利和卓越的团队才是真正的效能，启用“多级评估系数”，例如，个人绩效=公司业绩系数*部门业绩系数*个人绩效系数
• 使用项目和团队管理工具时，区分事项的优先级和重要程度，指定明确的负责人和关联方，公示事项的判定标准等等
• 评价基于连续性的客观事实数据（项目和团队管理工具）
• 启动“环评”，“谁干的好”应该由和他事项相关人的评价来佐证

---

06 -