Thoughts Concerning Work¶

问题域¶

业务与架构¶

• 我的视角，这段时间做的事？
• 这样设计背后的思想？
• 业务、技术、架构三者关系

团队组织¶

• 技术团队？技术管理者？
• 树状架构与扁平化管理

敏捷¶

• 什么是敏捷
• 什么不是敏捷

业务与架构¶

我的视角，这段时间我做了什么？¶

• 我视角的业务架构

  • 战略与战术图

  

  • 战略

    • 稳定：平台模式的开发使能；作为平台，提供可靠性、安全性、可扩展性，托管客户知识洞见，反哺客户决策。
    • 敏捷：客户中心的服务创新模式；应对变化，捕捉市场变化，快速满足客户定制化需求。

  • 战术

    • 核心：业务能力（数字化时代；业务与技术协同，科技称为业务的基因）
    • Design Thinking 设计思想：以设计师的视角和系统性思考，对业务持续探索
    • Domain Driven Design 领域驱动设计：持续设计和演进业务和技术
    • DevOps: 更快速、流畅的交付，持续验证业务设计思路的正确性

• 几个月前的技术架构

  • 时间：券商工作台立项

  

  • 回顾历史，了解架构思路的演进，才能更好的应对未来；团队奋斗史，更好的参与团队文化建设。

  • 最重要的一点

    • 《黑客与画家》如果我们可以通晓未来，那么找出当代的那些表面上正确、实际上可笑的想法是一件很容易的事。但是，不可能做到这一点。幸运的是，我们可以找到一种几乎有同样效果的替代方法：回顾过去。
    • 我们可以去找那些过去被认为理所当然，如今却被认为不可思议的事情，这是用来找出我们自己正在犯下的错误的第三种方法。

• 目前前端架构的问题

  • 代码中 Bad Smell

    • 最大问题

    

  • 违背设计原则

    • 无环依赖原则
    • 稳定依赖原则
    • 稳定抽象原则

  • 混沌系统

    • 大泥球的成长之路
    • 根本原因：只关心是否能够运行；缺乏设计指导原则。
    • 俗称 “大泥球”、“shit 山”

  • 措施总结

    • 防止温水煮青蛙，任何大泥球都是经过长时间的滚动形成的，没人想设计一个大泥球架构的软件
    • 设置代码质量监控，不要留破窗户
    • 保持代码整洁，离开时要比进入时干净

• 前端架构

  • 设计图

  

  • 落地图

  

• 遗留系统解决之道与术

  • 绞杀者模式
  • 防腐层模式

背后的架构之道¶

• 软件设计复杂性的根本原因：变化。

• 架构设计的目标

  • 抵御变化——隔离变化，将变化带来的影响降到最小。

• 架构设计之道

  • “变化”与“稳定”
  • 寻找稳定与改变的隔离点，封装变化点，然后在变化点处使用设计模式。

  • 编程范式

    • 结构化编程

      • 可以用顺序结构、分支结构、循环结构这三种结构构造出任何程序。
      • 可将模块递归降解拆分为可推导单元；即，大型系统设计是可推导证明的。

    • 面向对象编程

      • 软件架构不再受系统控制流的限制。
      • 抽象 => 业务策略与具体实现分离。
      • 更好的抵御变化。

    • 函数式编程

      • 关注 “不可变性”

  • 《易经》的学问里包含一个原则，叫做 “三易”

    • 一、变易

      • 世界上的事，世界上的人，乃至宇宙万物，没有一样东西是不变的

    • 二、简易

      • 简易也是最高的原则。（不太懂）

    • 三、不易

      • 万事万物随时随地都在变的，常道不变。

架构灵魂三问¶

• 灵魂三问：为什么要有架构？我们是不是有一个良好的架构？业务、技术、架构三者关系？

• 为什么要有架构？

  • 当软件对应的业务组织架构越来越复杂，参与者越来越多，需要不同技巧的人并行工作；这时，软件需要切分，切分原则，即根据 用户访问软件的生命周期，识别核心生命周期和非核心生命周期，形成 树状架构。
  • 从分层的角度考虑时，不要破坏树的结构。有树才有分层，有分层不一定有树。
  • 架构拆分永远是 顺应业务生命规律 的一种拆分，始终围绕着业务核心生命周期进行，结果只有一个：无论如何拆分，依然是树。

• 我们是不是有一个良好的架构？

  • 我们是不是有一个良好的架构？目前mindera技术架构的不合理，其根本原因是技术管理的不合理。
  • 维护架构的合理性，往往无法中指标衡量；真正需要交付时，往往很难用数据衡量自己的价值，吃力不讨好；团队中总得有人坚持做难而正确的事。

• 业务、技术、架构三者关系

  • 技术 是人类对 业务目标 不断提高时产生，其 目的 是为了获取更大利益。所以，技术是为了解决业务问题而产生，没有业务，技术没了存在的前提；好的技术存活，差的低效的技术被淘汰，一切遵从人类利益诉求。
  • 先有 业务问题，后产生 技术 解决问题；业务壮大拆分，并行提效，形成 架构。
  • 三者关系：业务是核心，技术是解决业务问题的工作，架构是让业务长大的组织方法。 三者共生，最终合体。

• 合适的架构师该做什么？

  • 允许不合理

    • 架构设计核心目标是支持业务，有时候不合理的存在是合理的。应用架构存在的首要目标是支持业务，很多成长型企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度而导致企业错过发展时机。
    • 在互联网型企业很常见常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。

  • 确保合理

    • 对于架构师而言，要保证整体企业应用架构的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比较小。如果大框架有偏差，修正的代价会非常高。对于产品线负责人而言，要保证局部框架的合理性，避免出现由于设计不合理造成的返工和补救工作。
    • 很多时候架构师或产品线负责人要做出判断，是做一套新系统还是修改老系统，若是前者则新系统如何定位，若是后者则老系统如何调整定位。另外还考虑：数据如何流转，系统之间如何关联，底层数据如何打通；是否要复用其他系统模块，是否要将某些模块抽象化、服务化、平台化。对于产品经理，要在系统级别的粒度做出类似问题的判断，能够识别出可能存在的系统演变风险，及时升级控制不了的问题，进而避免做出错误决策。

• 再回答：什么是架构？

  • Architecture = Components + Relationships + Principles & Guidelines

  • The fundamental organization of a system, embodied in its components, their relationships to each other and the enviroment, and the principles governing its design and evolution.

团队组织¶

技术团队？技术管理者？¶

• 搞清楚你管理的的是一群什么人？

  • 技术管理就是这么一种组织团队共同进行研发的工作，它是一门细分工种，随着社会的进步、人类思维的开放、经济水平的提升，被管理者（工程师们）逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感，他们逐渐对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣，而不是仅仅满足于金钱的多少。
  • 同时，被管理者之间还存在紧密的社交关系，能够随时保持沟通，分享对在该公司或组织工作的切身感受，分享对于管理者个人能力、品德的认识。

• 技术管理者

  • 管理者就像图书管理的书，书的评价随着时间的流逝趋于稳定，由书本身的品质所决定。哪些品质 呢？
  • 一位管理者最重要的是给团队指明方向，包括技术方向和业务方向，还有个人成长方向。
  • 与下属相比，领导者的优势不只在于他的专业能力，还在于他的眼光和胸怀。既然选择做技术管理，你就要有成就他人的心胸，同时还要有超出一般人的眼界，能够给予团队正确的方向。
  • 同时，要保持对技术的兴趣，多关注新技术的发展，否则你很难在重大的技术决策上做出正确的决定。

• 持续学习技术

  • 对于聪明人来说，有实践机会，管理可以在短时间内达到一个不错的水准，但技术永远需要长时间积累。
  • 一个技术领导，更多是通过对技术领域的探求，打磨自己的技术敏感度和技术决策力。
  • 持续思考：什么阶段引入什么技术，什么时候重构，什么时候重写，如何利用技术驱动产品，如何构建技术平台…… 这些都是技术领导需要思考并确定的问题，这些都将依托你强大的技术背景。

• 非技术出身的管理者

  • 不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。
  • 对于整个研发过程的管理，不懂技术的人很容易完全从产品角度考虑，忽略研发团队面临的困难和风险，忽略技术人员对于技术的憧憬，造成团队超负荷工作、技术团队缺少技术愿景等情况发生。
  • 团队领导可以不是对口的专业出身，但是他必须对技术有热情，必须有开发经历，需要对技术有敬畏之心

  • 总结为两点

    • 知识方面：基础知识和理论知识非常重要，多多使用已有的且成熟的方案是关键。
    • 心态方面： 对技术要有一颗严谨和敬畏的心，想清楚了再干，坚持高标准，很多事情都急不来。

以人为本¶

• 人才

  • “人、产品、利润。人是第一位的。”
  • 应当以人为本。如果你有卓越的人才，并给予相应的尊重和鼓舞，让他们能够积极参与工作，那么你会做出卓越的产品。如果你有卓越的人才和卓越的产品，利润就会随之而来。

• 人才成本

  • 前苏联著名物理学家郎道 “衡量物理学家水平的郎道等级” —— 世界上的物理学家分为了五级，即第一等物理学家的贡献是第二等的十倍，第二等是第三等的十倍，依此类推。
  • 从成本上看，一流工程师的收入可能是二流工程师的两三倍，但是，前者的贡献可能大十倍，从经济的角度来讲，采用最优秀的人才是最合算的。

• 成熟的人

  • 独立的更加彻底、而又联系的更加紧密
  • 重视诺言、不夸夸其谈、有学识而含蓄内敛、心胸宽广、不以自我为中心、勇于承认错误、意志坚定。
  • 衡量一个团队的凝聚力是否强大，看看这类员工的占比就知道了，缺少这类员工的团队一定不会有什么了不起的成绩。

• 面试

  • 一流人才招聘一流人才，二流人才招聘三流人才。”——史蒂夫·乔布
  • 你必须明白，你在招聘过程中的表现在一定程度上体现了你的团队价值观，所以请无限高度重视招聘。
  • 面试过程体现了一家公司的技术能力、思维和管理能力，绝不可以轻率应付，你代表着公司，而不仅仅是你个人，如果你不够资格或者本不想做，那请让位，让合格的人做。

树状架构与扁平化管理¶

• 树状结构（金字塔结构）

  • 7 ± 2 法则

    • 工作记忆：流体智力 (工作记忆/智商/推理能力和短时记忆力)
    • 「神奇的数字7加减2：我们加工信息能力的某些限制」：一般人工作记忆容量约为7 ± 2 个单位。
    • 所以，通常有超过7人向你汇报，你要么会对第8个人的汇报失去判断力，要么会忘了第1个人说了什么；这时你的判断力倾向于被自己感兴趣的事或轻松氛围所决定，而不是理性与正确。
    • 频繁的决策，是让人感到疲惫的根源；自律的本质，就是减少决策频次。（比如乔布斯，多件同一款衣服；渡边淳一《钝感力》）
    • 无关大局的小事情，不要参与决策；把有限的资源留给更重要的事；这样才能在重大决策上保持洞察力和专注。

  • 主好要则百事详，主好详则百事荒。《荀子-王霸》

    • 对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要「引导程序员自己做出正确的决定，而不应该自己就把决定做了」。
    • 这样做可以帮助下属员工培养技术、积累经验、建立自信，还能获得具体执行决定的员工的认同。
    • 如果你发现自己经常需要讨论非常具体的命令以及如何执行，说明你没能很好地利用你的管理技能，或者没能赋予下属员工足够的权利。
    • 记住，优秀的主管要有足够的自制力，不在下属工作时瞎指挥。

  • 架构和树的关系

    • 我们每次谈到架构，都需要谈论树状结构，那么树状结构有什么好处呢？

      • 树状结构特别适合增长。
      • 二叉搜索树 (查询复杂度logn)，沟通 代价最小，最适合 增长，且在指数级增长中依旧能保持其 稳定 的数据结构。
      • 树状的增长，成本方面最低、沟通的路径也没有显著的增长，带来的效果最好。树的结构也保证了分支的能量汇集到树干，保障了整棵树的生长。而架构恰恰是为了应对增长的，自然而然架构都是树状的。

    • 康威定律，一个团队的 组织沟通结构 最终会以 软件架构 的形式表现出来；所以，如果沟通结构是混乱的，软件架构必然如此。

      • 技术团队人员管理问题：调配，经常性的就是这里缺人，往这里挪一个人，那里缺往那边挪。（峰伊：宁可自己重新写一套，也不愿改别人的bug。）

• 解决问题行动主体模型

  • 团队的构成要素总结：目标、人、定位、权限、计划。
  • 领导者：界定和提出问题的人；输入企业愿景，在愿景与现状的落差中寻找矛盾点、机会口，输出一个好问题。
  • 管理者：接收问题，输出可执行方案的人；输入模糊、无结构的问题，输出一个清晰的、有结构的解决方案。
  • 执行者：接收方案输出行动的人；需要更细分的专业能力。
  • 概念技能（高层抽象能力） vs 技术技能（低层实现能力） ⇒ DIP

• 扁平化管理

  • 雷军：“小米团队是小米成功的核心原因。和一群聪明人一起共事，为了挖到聪明人可以不惜一切代价。如果一个同事不够优秀，很可能不但不能有效帮助整个团队，反而有可能影响到整个团队的工作效率。真正到小米来的人，都是真正干活的人，他想做成一件事情，所以非常有热情。来到小米工作的人聪明、技术一流、有战斗力，这样的员工做出来的产品注定是一流的。”
  • 扁平化的好处，它更容易让能干的人冒出来。理论上来说，通过减少管理层次、压缩职能部门和机构、裁减人员，使企业的决策层和操作层之间的中间管理层级尽可能减少，以便使企业快速地将决策权延至企业生产、营销的最前线，从而为提高企业效率建立富有弹性的新型管理模式。
  • 为什么过去没有这么强烈的诉求？因为中国的IT起步较晚，人才的出现、累计需要很多年，现在已经出现了大规模的知识型员工。
  • 知识型员工的一个鲜明特点就是，对专业的忠诚大于对所服务的企业的忠诚，选择企业的目的是致力于寻求能够实现自身专业成就最大化的成长平台。知识型员工群体的兴起和“去中心化”的信息传播方式，这两者结合，对企业管理提出新的要求，同时，这部分群体对企业的绩效发挥着越来越大的影响，而知识型员工又是社群自组织和传统组织混合协作的主要群体。

• 矩阵化管理的看法：复利（Compounded Interest）

  • 爱因斯坦：复利（Compounded Interest）是这个世界上的第八大奇迹，那些理解并学会使用它的人将最终获得巨大的财富；那些不理解它的人会付出巨大代价
  • 变化是复用的天敌，软件设计目标：「管理变化，提升复用」

  • 两个维度 Trade-off

    • 功能特性维度

      • 从功能特性维度上来说，90% 的都是图表指标方面的问题可以培养一个领域专家的角色，专门负责这一块功能逻辑
      • 优势：能更好的保证代码逻辑的高耦合低内聚和复用性。
      • （负责人：花较少的时间，把控和优化一下几处关键结构的代码，调整在整体上违背设计思路的地方。)

    • 项目维度

      • 从项目维度上来说，找一个专门盯长江项目，专门对接联调，能前后端联调响应更及时，合作更丝滑
      • 优势：更好的保证项目进度和项目本身的质量。

      • 劣势

        • 沟通是技术团队中成本最高的地方；
        • 每个负责人对相似功能的设计思路不同，代码最终无法合并；无法利用软件的复利效益；软件开发最终会演变成劳动密集型工作；
        • 出现版本一致性问题。
        • 对于相同模块的业务需求改动，每个项目里都会改变；「猫咪」在整个项目中乱窜。

敏捷¶

什么是敏捷¶

• 1. 定义

  2. 项目管理流程的框架，适用于复杂、变化、不确定性多的项目环境。

  

• 1. 第一原则

  2. 关注 value or outcome，而不是 output。

• 1. 机制

  2. 由一个个重复循环的迭代组成，每个迭代称为一个 Sprint；每个迭代一到三周，小步快跑，保持同样节奏。

• 一个sprint

  • 迭代计划 Sprint Planning

    • strategy, sprint goal, Execution Plan

  • 评审会议 Sprint Review（产品本身）

    • 工作内容，交付的产品，总结学习心得

  • 回顾会议 Sprint Retrospective（团队交流）

    • 1. 起讨论工作方式，沟通交流方式
    • 1. 制定改善行动

    • 改善行动遵循 SMART

      • • Specific
      • • Measurable （if you can't measure it, you can't manage it.）
      • • Attainable
      • • Relevant
      • • Time-based

  • 反馈机制 Feedback（核心理念）

    • 反馈：沟通方式、工作方式、产品设计、甚至组织架构等。

常见 Bad Case¶

• 业务方收到了客户的压力，本来可以通过向客户解释来减少研发的压力和风险，但是选择直接施压研发）。这时候，你的这位不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，我们后面有时间再重构和完善（当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的），这样的想法本质上是错误的。
• 一些人喜欢将缺少需求分析、技术设计环节解释为“这是敏捷开发，和你们的瀑布式不一样”，这是对敏捷开发的误解，敏捷开发是很好的一套开发流程。
• 敏捷开发的实质是为了解决需求快速变化的情况，需要快速响应需求提出方，快速搭建产品原型用于验证实际效果，而不是说有了敏捷就可以忘记软件工程理论，不管三七二十一，先随便写一堆代码再说，这是不合理的。
• 任何软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计缺失的情况下开始编码，因为这个时候没有人知道究竟如何编码。

什么不是敏捷¶

• 现象

  • 景观上

  

  • 实质上

  

• 以人为本

  • 不是指导做事，而是指导做人

  • 关注团队的情绪价值

    • ESVP

    

    • Safety Check
    • Safety Improvement Workshop

• 敏捷三层次

  • 招式：估点，开各种会议，各种原则
  • 心法口诀：要自组织，以人为本，吸收反馈，要拥抱变化，要迭代
  • 内功：树立敏捷理念，信任团队，信任反馈机制

• 结论

  • 一流团队学内功，敏捷方法只是工具，遇到问题知道如何调整。敞开暴露问题，团队共同承担，见招拆招，持续调整，持续改进。
  • 二流团队学心法，知道以人为本，拥抱反馈，持续改进，但执行时，却浮于表面，吸收反馈却得不到落实。
  • 三流团队学招式，学来 Scrum 的各种会议，却没发挥作用。老板指派任务，团队闭口不言，等最后暴雷大家相互甩锅。