下周继续

加三

《架构即未来》第三章读书感悟
1：组织中的两个重要的要素：规模和结构，会影响沟通、效率、质量、标准和责任
2：经理的职责：
确保工程师们在有价值的项目上产出高
确保完成行政管理工作
确保掌握项目和问题的进展状态
3：多关注 警告的信号：沟通不顺、生产率低下、士气低落 团队规模太大的信号
不满意业务合作伙伴、微观管理的经理、过度劳累的团队成员
4：职能型组织、矩阵型组织、敏捷型组织
创新能力可以作为组织选型的一个重要评价指标
通过市场响应速度、高质量的新功能和高可用性的服务来衡量

《架构即未来》第四章读书感悟
愿景、使命和目标的组成部分都对领导力发挥着作用，而SMART 可以用来在扩展性目标的创建中发挥作用。
领导力是对组织或个人完成特定目标的影响力。
领导者，无论是天生的还是后天培养的，都可以做得更好。事实上，追求做得更好应该是一个终身的目标。
领导力可以被看作一个函数，它包括个人特性、技能、经验、行动和方法。提高任何 一个方面都会增强领导的能力。
增强领导力的第一步是要厘清现状，请下级、同级和上级帮 你做一个360度调查。
如果你想让别人怎么效份，那么就要怎么去领导，遵从你希望营造的文化。
当带领团队的时候不存在自我意识，所以要放下自我意识
领导应该大公无私
以人为本，使命为先。按时完成工作，确保照顾好手下。
道德至上。教导你所允许的事情，所教导的就成为你的标准。
所做的一切要与股东的价值一致。不要做无法为股东创造价值的事情。
变革型领导注重团队的整体，而不是个人。不参与领导与个人的利益交换，而是聚焦团队协作和合作的成果
愿景是对理想未来的生动描述。它包括以下的组成部分:
• 对理想未来的生动描述
• 为股东创造价值很重要
• 可度量
• 激动人心
• 结合信仰的元素
• 大致不变，但可根据需要修改
• 容易记忆
使命是引领你通往愿景的总路径或计划，它包括以下几个组成部分:
• 对当前状态和行动的描述
• 有目的感
• 可度量
• 一个大方向或一条通往愿景的道路
目标是通往愿量的路标，它与使命的路径一致。SMART目标是:
• 具体
• 可度量
• 可达成(但有挑战性)
• 现实性
• 时限性(或包含时间因素)
成功的因果路线图将有助于为愿景、使命和目标设定框架，同时帮助员工了解如何为实现目标做出贡献，如何为股东创造价值。

《架构即未来》第五-六章读书感悟
1：再次明确了什么是管理、管理者应该为成功铺路。成功的管理者应该把自己视为团队的关键部分，向共同的目标努力。
· 明智和合乎道德地使用手段来完成任务
· 忘记『管理风格』，想办法适应团队、公司和使命的需要，项目和任务管理是成功管理的关键。这些活动需要有能力来把一个目标分解成多个部分，确定部分之间的关系，分配任务和确定的时间点，并基于这些日期度量进展。
· 5%-95%法则：颠覆了之前对于项目计划的思考，项目管理用5%的时间指定详细的计划，用95%的时间做好应付突发事件的准备。在适当的时间聚焦取得结果，而不是生搬硬套原定的方案。
· 管理还应该处理好『人』的管理：人和组织管理活动被分解为『播种』、『施肥』、『除草 』三个部分
· · 播种是雇佣新人，目的是选拔更好的人。多数管理者在面试上花的时间太少，而且目标设得不够高。在新员工的面试中，应该包含企业文化和行为。 这里应该关注坐标系：行为和表现。
· · 施肥是培养组织内的员工。要不厌其烦地给员工提供高质量的反馈。
· · 除草是淘汰表现差的员工。这件事应该做的快，越早对团队影响越小。
· 不度量就不能提高。可扩展性的度量应该包括可用性、响应时间、生产效率、成本和质量。这块度量分的很细，感觉不太好实施这么细致的度量，粗粒度的可以通过我们当前的报表和打点。人员的不好评估。包括工作时长、请假、功能点、代码量。
· 目标树拆解法。
2：感触比较深的一个段落：
一定不要『闭门造车』
好的产品都是由那些深谙客户需求的公司创造的。好的产品团队直接与客户互动并创新，而不是从其他员工那里获得需求。好的公司清楚地了解产品团队在聚焦市场的产品创新和聚焦内部效率提升之间的差异，并能够妥善地处理。

《架构即未来》第七-八章读书感悟
第八章
详细描述了【问题】与【事故】的关系，以及如何处理，这是任何技术组织最重要的过程之一。
1：事故是生产环境的问题，问题是事故的原因。
2：快速恢复服务可能导致丢失一些取证数据，而这些数据对问题管理极为重要，思考应该给多少时间来收集数据以及收集哪些数据。
3：事故：开启、解决、关闭、 问题：开启、定位、关闭
4：定时对发生过的事故和问题进行回顾和总结。
5：一个事故总有多个根源，并不是单一问题引起的，我们推荐事后 最小化事故监控时间、最小化事故解决时间、确保事故不复发以及最小化事故风险。

第七章：
1：过程：软件工程中，人、工具、方法的结合，解决软件工程中的问题
2：过程的成熟度：对采用持续改进的组织体现在能力级别的提高。

对使用阶梯式表达方法，体现在成熟度提升

3：确定最佳过程数：从小到大周期迭代。团队民主决定。
4：过程应该有一个负责人，定时维护。

第七章：
1：过程：软件工程中，人、工具、方法的结合，解决软件工程中的问题
2：过程的成熟度：对采用持续改进的组织体现在能力级别的提高。

对使用阶梯式表达方法，体现在成熟度提升

3：确定最佳过程数：从小到大周期迭代。团队民主决定。
4：过程应该有一个负责人，定时维护。
第八章
详细描述了【问题】与【事故】的关系，以及如何处理，这是任何技术组织最重要的过程之一。
1：事故是生产环境的问题，问题是事故的原因。
2：快速恢复服务可能导致丢失一些取证数据，而这些数据对问题管理极为重要，思考应该给多少时间来收集数据以及收集哪些数据。
3：事故：开启、解决、关闭、 问题：开启、定位、关闭
4：定时对发生过的事故和问题进行回顾和总结。
5：一个事故总有多个根源，并不是单一问题引起的，我们推荐事后 最小化事故监控时间、最小化事故解决时间、确保事故不复发以及最小化事故风险。

第九章：
危机犹如类固醇，既可以使公司更强大，也可以破坏业务，如果不积极管理危机，会毁掉公司在客户、组织及其技术应用平台与服务方面的扩展能力。
要尽快和有效地解决危机，必须采取某些措施来控制混乱。
最有效的领导人在危机中保持冷静，在整个危机管理的过程中能有力地维持秩序。他们必须有敏锐的业务头脑和技术经验，可以承受压力。
危机处理小组由危机管理者、工程经理和高级工程师组成。此外，向工程经理报告的工程团队也参与解决问题。
危机管理者的角色是维持秩序和遵循危机解决问题、升级和沟通的过程。
工程经理者的角色是管理其团队，并向危机管理团队报告进展情况。
工程团队里高级工程师的角色是帮助危机管理团队提出和审核有关问题原因的假设，并帮助确定最合适的快速解决方案
个人贡献者工程师的角色是跟着自己的团队，确定快速的降决方法。建立和评估问题原因的假设，向自己的经理报告进展状态，他的经理应该是危机管理团队的成员。
危机管理团队成员应该在作战室面对面地沟通，如果不能进行面对面地沟通，团队应该使用电话会议和聊天室。
作战室最好紧靠运维中心，以帮助处理危机。
在危机管理过程中要清楚地定义升级和情况通报。危机发生后，在处理过程中应定期提供状态更新，直到确定和修复所有问题的根源为止。
在危机的事后处理过程中应该积极检查、发现和管理一系列的后续问题，并以主事后处理和子后事处理的形式分主题进行，针对所有发现的问题全面出击。
第十章：
当员工需要触摸、旋转或者戳碰任何的硬件、软件或固件时，变更发生。
变更识别对小公司来说是简单的过程，专注于寻找最近的变化，如果发生事故可以回滚。
有效的变更识别过程的最低限度应包括变更时间、目标系统、预期结果以及联系方式。
变更管理的目的是通过控制生产发布和记录活动，限制变更的影响。
变更管理包括以下几个阶段：请求、审批、调度、执行与日志、验证、回顾。
变更请求是过程的起始，应该包含以下信息：系统或子系统、预期结果、如何执行、已知风险、已知的依赖关系以及与其他变更或子系统的关系。
在变更先进的变更过程中，变更请求还包含有关风险、回报、建议的日期等信息。
变更审批验证所有信息的正确性，只有提出变更请求的人才有权力做出变更。
变更执行和变更识别过程类似，但包括变更数据库的开始和完成时间的记录。
变更验证确保变更满足顶期效果。如果先败可以回滚，如果取得部分效果，可以升级。
变更回顾是变更管理团队对变更过程和结果的内部评审。它分析数据，从而了解变更的速度、失败率、对响应市场时间的影响等。
在变更控制会议上，会对变更进行审批、调度和执行后回顾。该会议通常由运维主管或基础设施负责人主持，每个工程团队和面向客户的业务团队作为成员参与。
变更管理过程应由变更管理小组以外的团队来评审，以确定其有效性。每季度或年度审查是适当的，审查应该由首席技术官/首席信息官和公司高管进行。
在实践持续交付的公司里，变更管理把规则通过代码集成在自动化测试系统中，以完成自动化发布。在持续交付解决方案中，风险分析、变更识别、变更审批和风险水平都是内在的。

第十三章：
1：解决闭门造车的问题：跨部门提供不同观点的组进行设计
2：JAD 与 ARB，JAR 是负责 ARB是责任
3：JAD 的成功关键在于过程是完整的，严格坚持准入与批准标准
4：ARB 成员应该被视为领导人，受到应有的尊重，并有某些应用或架构领域的专业知识