乔新亮的 CTO 成长复盘¶
2020-11-25
乔新亮
彩食鲜副总裁兼 CTO、前苏宁科技集团副总裁、TGO 鲲鹏会荣誉导师
来自内蒙的农村孩子， 2002 年从西安电子科技大学毕业，先后就职神州数码、Vitria、BEA、IBM，并逐渐从程序员成为管理者，开始为组织的成功而承担压力。好景不长，2009 年，我确诊了重度抑郁症，当时真像生活在地狱之中。幸运的是，我走了出来，整个人的认知和生活方式被颠覆、被改变，宛若新生。康复之后，我成长得更加迅速。从苏宁、环球易购到如今的彩食鲜，我经历了总监、副总裁、CTO 等多个岗位，管理过上万人的技术和业务团队，也拿到过千万的年薪。我给自己制定的下一阶段目标是：向优秀的 CEO 学习，从 CTO 变成 CEO。
2002 年毕业，就职神州数码；2003 年就开始带团队
2008 年 -2015 年，在 IBM，从咨询经理一路做到副合伙人。
2015 年 -2019 年，在苏宁从最初一名总监，一年后晋升为总裁助理（直线管理 CTO 办公室和苏宁云研发中心，直线管理了 500 多人，虚线管理有近 5000 人），离职时担任技术副总裁
2020 年，彩食鲜
备注
【心得】本文是真的从 CTO 的视角，从全局的视角，为我们讲解技术人未来应该怎么走，是值的多读几遍的书。更为可贵的是，这本书不是传统的干货，是作者20年工作更高层面的总结，这种书只有工作多年的人才能品出味道，而且经历越多得到越多。最后记住一句话：沟通创造价值，分享带来快乐。
目录
00开篇词¶
备注
选择决定上限，努力决定下限。
管理者有三大类必须完成的本职工作:
1. 组织调整到位
2. 加强协同效率
3. 激发团队活力
管理三板斧:
1. 培养全局思维
2. 聚焦能力
3. 风险意识
做管理， 也是技术管理， 一定要贴近实际的工作，要尽在掌控，不是自己做，但自己都要懂。下属研究一个月，你要通过半个小时问到最重要的精华，这是能力。 绝对不能纯粹做人的管理，要有专业为根。
01对个人认知的复盘 (6 讲)¶
01 | 职业生涯发展规划:每五年登上一个新台阶¶
技术人的职业发展可以笼统划分为三个阶段，分别是:
1. 做事（Do）。这一阶段，你的工作偏向执行，主要负责解决个人承担的技术任务；
2. 带团队（Manage）。这一阶段，你的工作偏向管理，主要负责协调组织，让团队实现更大价值；
3. 业务决策（Lead）。此时你的工作应该是思考公司的业务发展，能站在公司的角度进行战略决策，更像一个创业者。
技术转管理需要注意什么:
1. 使用成长性思维武装自己，终身成长，接受自己的不完美，又不断努力
2. 和团队建立信任，作为管理者，团队的任何问题都是自己的问题，团队的任何一个的功劳都是自己的功劳，所以，多让团队成员体现他们的价值，这是管理者要做的事，不要和下属争功劳
3. 技术不能丢掉，还要持续学习，因为做管理，有机会和下属讨论技术，讨论方案，不懂不要装，诚心学习，请教，其实可以更快速的学习
技术的话语权有多重，取决于自己技术有多强，不强，就少点； 强，就多点。
站在更大的格局，站在公司的思考自己问题的答案，就清楚了。
接受自己，相信自己会更强，技术会更强，管理也会更强，然后去努力
好的经理:
1. 带领组织成功
2. 团队成员有发展
3. 团队氛围好，对员工有同理心
目标很重要， 涉及到认知， 所以说 认知到位；
计划很重要， 涉及到执行， 所以说 彪悍执行。
02 | 到底该怎么理解工作与薪资的关系¶
工作的糟糕状态很多时候都存在一个 “病因”:
大多是因为薪水太少，或者觉得绩效奖励不公平；
少数情况是在组织协作中受了委屈，越干越是生气；
其他原因占比一般比较少，我觉得几乎可以忽略不计。
备注
如果一名管理者的心态不好，有太多微妙的细节，会导致你走向失败。
薪资只是工作的附属，工作的真正报酬是成长。而所谓的涨薪，不代表你的工作岗位更值钱了，而是你的个人能力足以匹配更值钱的岗位。
工作的核心目标只有一个：提升能力，进而匹配更高阶的岗位需求，钱、公平，都是次要的。
成功总是存在运气成分的，但学习成功的经验则不需要运气。
备注
我经常和团队说的， 有问题吗？ 有解决不了的问题吗？ 到我这里来， 我来处理， 我来决定。
管理者为所有负责，不管下面员工出什么问题，都是你的问题； 不管下面员工有什么业绩，都是你的业绩。
03 | 看透本质: 研发出了生产事故要不要罚钱¶
体系化措施，包括:
1. 一个事故要有七个改进点：每个改进点保证 100% 不重犯；
2. 犯错的人负责牵头落实复盘，分享失败的经验；
3. 解决问题的手段产品化，人会犯错，但产品不会犯错；
4. 允许每个人犯错、试错；
5. 根据事故统计定期颁发 “烂草莓奖” 和 “金苹果奖”；
6. 管理产品化、系统化、数据化。
经验抽离: 如何看透本质:
第一，大胆假设，小心求证。
第二，刻意练习自己的思辨能力。
第三，相信所有的问题都可以被解决。如果不能解决，那一定是自己认知没到位。
通过学习来培养自己逻辑分析、数据分析的能力。这里我推荐两本书:
一本叫做《数据化决策》（道格拉斯・W・哈伯德 著）
一本叫做《深度思维》
一个优秀的架构师，必须要看全局
写代码的时候看到一个词 context
做架构有 system context diagram
绩效要简单，绩效和结果指标挂钩，就是要业务成绩
问题是过程指标，过程中管理，其实对于团队压力更大
加餐1| 大学毕业要不要留在一线城市互联网公司¶
处在激烈竞争的生存环境中，如果不成长，就只能被淘汰。
要做T型人才。 一纵是专业， 一横是架构和领导力；先纵后横，然后可以在另一个领域扎下去，自己的根基越来越扎实；还有就是要结合自己的特点，看自己做哪个更有乐趣，没有功利性，享受乐趣更容易坚持
管理的价值在于成就业务，在于通过向管理要效益，让公司发展的更快、更好。
加餐2| 工作遇到不懂的问题:何时/如何求助¶
优秀的提问习惯:
永远带着白板和白板笔，随时准备将别人的答案融入自己的体系内；
半汇报半提问，提问一定带有属于自己的观点；
最重要的是，围绕架构类的工作内容，学会按照固定的模式提问:
当下有哪些待决策的问题，影响了哪些业务？
谁或哪个部门提出了这些问题？
其他人有哪些解决方案上的建议？我们认为存在哪几种方案？
方案一、方案二……分别有哪些优势和劣势？
我们建议选择哪种方案，会带来什么样的影响？
在横向维度上，用如下步骤去思考和做决策:
1. 将复杂问题拆解成足够细化的模块
2. 针对每个模块，判断自己是否有足够能力实现
3. 根据拆解情况和实现方式，制定一种或多种技术方案
4. 对一种或多种技术方案进行快速而谨慎的验证
5. 用财务思维考量技术方案背后的成本和效益
6. 对技术方案的选择、实施进行决策
在垂直维度上，各个步骤的难度又有所不同，将其分成三大维度来理解:
1. 初级问题：一般都是纯粹的技术实现问题，只是复杂程度不同；
2. 中级问题：复杂度上升，开始涉及到多模块、多业务部门甚至是跨公司的协调，一般需要经历立项会；
3. 高级问题：需要协调多方资源，站在公司整体层面，为公司利益负责而解决的问题。
提问的时机：当思维沿着上述步骤前进，就是思考，在任何一步阻塞时间过长，都可以进行提问，这就是提问的时机。换句话说，思考应当是提问的绝对前提，在没有经过思考的情况下，我是绝不会提问的。
提问的方式：提问时，要将你的思考成果和思维路径说清楚，这就是提问的正确方式。比如你是怎么理解和拆分这个需求的？如何评估拆分后的可实现程度？具体是哪里出了问题？这样，对方会感觉你是有备而来，尊重他人的时间，不是伸手党，更愿意解答你的问题。
总结-提问方式:
1. 基础的问题自己解决
2. 有难度的问题思考后请教别人解决
3. 用为知识付费的态度来请人吃饭
加餐3| 选择决定上限/努力决定下限¶
选择不只决定了上限，还要拥抱不确定性；而努力不但会决定下限，还要负责将 “不确定性” 变成 “确定性”。
不要盲目跳槽，先问问自己：能力储备做好了吗？如果没做好储备，千万别跳槽。
整个专栏的主线之一:
1. 从主观角度，你可以理解为 “做选择 -> 努力 -> 再做选择” 这一过程的循环，成长真的太重要了；
2. 选择不是件简单的事，如果让我形容，那就是煎熬。但是即便再煎熬，也要做决策，不能逃避，要敢于拥抱不确定性，冷静地做好风险控制和分析
3. 不是「选择」之后就万事大吉了，要努力将自己的选择，变成真正对的选择。上台阶很重要，但要小心被别人一脚踹下去
最重要的是踏踏实实的做事，争取做事的机会，其他少想，少看。从全局的角度看事情，站在领导的角度思考问题，少关心政治，心中无政治，实际无政治。慢慢体会琢磨，不管有没有政治，在上面花心思都是不值得的。
02对管理工作的复盘 (10 讲)¶
管理者最重要的三件事:
1. 组织调整到位
2. 加强协同效率
3. 激发团队活力
飞轮有四个 “叶片”，其中「端到端的产品管理」、「增强协同 - 项目管理」以及「绩效与激励体系」部分，其实就分别对应着管理者最重要的三个任务。¶
07 _ 管理者最重要的三个任务1: 组织调整到位¶
一个好的立项可以大大提高项目成功的概率。那么什么是好的立项:
1. 目标清晰：每个业务目标、产品目标、技术目标都要清晰且可量化
2. 责任到人：上述每个目标都要责任到人，不能都是项目经理扛，项目经理扛不了的
3. 承诺到位：如果需要外部组织配合，要得到外部组织的明确承诺
如果上述任何一个条件没有落实到位，就不能立项；如果企业正处于快速迭代的阶段，可以适当放松要求，但开完项目启动会的一周内，以上三项都要落实到位，否则项目进入高风险关注列表。
在用人方面，要尽量提高人才密度。同样一份工作，宁可用两位中高级人才来完成，也不用三位初级人才来完成，主要原因是要考虑管理成本。
如果组织架构不调整，研发团队是一条线、测试团队是一条线、产品团队是一条线，这在 IT 团队里天然就形成了一定的壁垒和鸿沟，导致一些正确的战略决策落地执行慢，公司内团队协作效率差，容易扯皮。
备注
优先调整组织架构，从职能型研发组织结构，调整为产品型研发组织结构，也叫做 “Pizza 型团队”。
职能型研发组织架构的特征是:
每个研发中心为一个最大产品团队；
二级部门按岗位职能划分为多个专业职能部门，比如产品经理团队、研发团队，还有进一步把研发团队划分成开发团队、测试团队的；
每个人员仅归属到一个职能组织；
三级部门人员按编制无限扩充；
三级部门团队 leader 任命从岗位职能中挑选 / 竞聘，比如研发能力强的当研发团队 leader，测试能力强的当测试团队 leader；
产品型研发组织架构的特征是:
每个研发中心为一个最大产品团队；
二级部门按产品下分多个产品组织为三级部门，每个产品组织均形成一个产品团队；
每个人员至少归属到一个产品团队，暂不限制归属产品数量；
每个产品团队约为 7 ~ 8 人，人数受限，最多 10 人；
每个产品团队产品经理、开发、测试齐备，是一个可以独立作战的小分队；
三级部门产品团队 Leader 可以是团队任意成员；
产品团队 Leader 要求（综合能力）：专业能力、领导力、汇报能力；
团队 Leader 任命原则为能者居之，能上能下；
产品型研发组织架构的优势:
1. 产品经理、开发、测试，形成了一个整体，被赋予共同的文化价值观，为共同的目标去努力，战斗力变得更强了。
2. 无论是产品经理，还是开发、测试，都开始和业务部门熟悉起来，和运营同学坐在一起，为自己的产品负责。
3. 管理者开始能通过一套统一的绩效考核体系，去考核不同岗位的团队成员。
在大部分业务驱动型公司里，考核Bug 数量、宕机时间的意义真的有那么大吗？
如果业务都死掉了，系统再健壮又有什么用？
如果你的产品能给公司带来一两个亿的利润，偶尔宕机一次又有什么关系？
备注
最终一切都要变好，但在前进的过程中，如何去寻找平衡，这是管理的智慧。身为管理者，你要学会灰度管理，不断在业务发展和技术能力建设中间寻找平衡。此外，管理者要将所有人的目标调整到业务发展上，联合大家一起寻找最优解，避免各方只关注局部优势，不看全局发展。
如何在 “职能型研发组织” 和 “产品型研发组织” 间做选型:
1. 如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织。
比如说，产品经理、开发、测试的能力很差，还有很多技术挑战不好解决，这时不要冒失转型。
2. 如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构。
3. 通过设置技术管理办公室、云部门统一建设基础平台和研发管理平台，降低对于大多数开发、测试的专业能力要求。
对于 200 人以下的研发团队，设置一个技术管理组织就可以，将研发规范管理和基础平台能力建设两个功能凝聚在一起；
如果团队规模超过 200 人，就要尝试分成技术管理办公室和云部门，前者负责研发管理规范，后者负责基础技术平台的研发。
08 _ 管理者最重要的三个任务2: 加强组织协同效率¶
备注
协同，就是让所有人向着同一个目标狂奔，并妥善解决奔跑过程中的合作问题。
有两个关键指标:
一个是「目标聚焦」
一个是「顺畅合作」
4 大协同手段:
1. 沟通协同：一般通过飞书等即时通讯软件来实现
2. 日历协同、会议协同：这里是指全员、尤其是管理者要做到日历公开，只要空白的时间段，就意味着可以预约会议，减少协调成本；
3. 文档协同：一般通过石墨文档、飞书文档等共享文档实现高效协同；
4. 目标协同：一般通过 OKR 来实现上下目标对齐。在彩食鲜，中高层每月、每季度对齐目标；执行层每日、每周对齐目标。
允许试错 / 犯错、信息极度透明、事后的客观复盘、绩效评定的公开化和透明化，不断地持续做这些管理工作，团队成员会越来越互相信任。这反过来会提升组织的协同效率。
总结:
1. 协同就是向管理要效率，是管理岗位存在的基础意义
2. 管理者要通过四类工具和基础认知，时刻盯紧协同中的目标聚焦问题和意外情况
3. 效率是相对的，其关键是极度透明的文化，没有透明就谈不上高效协同
4. 工具选择只是提高协同效率的一部分工作，给团队带去有底线的安全感往往更加重要
复盘时，当事人要:
1. 当初的目标是否清晰，业务目标，产品目标、技术目标是否清晰
2. 是否进行了详细的 WBS 分解，过程是如何管理的
3. 遇到了什么困难、挑战，自己是如何克服、努力的；为什么能成功，为什么还是没有做到
4. 如果结果没有做到，过程中风险管理、变更管理是如何做的
5. ROI，团队的价值、经验教训是什么，投入了多少资源，ROI 如何
6. 下一次如何提升，上一个台阶
09 _ 管理者最重要的三个任务3:激发团队活力¶
管理是为了不管，管理的目的是为了将不那么能自我驱动的人，变得更主动、更积极，而不是当个监工，越管越严。先管，向管理要效益；然后慢慢不管，团队自律、自驱，管理逐步达到无为状态。
团队是否具备开放平等的工程师文化，这样的文化才能激发工程师的积极性。
光贴标语是不够的，只有频繁地重复输出，坚持言传身教，使命和愿景才能从墙上走下来。
划分赛道很关键，组织内是同赛道进行对比，他可能在管理赛道上是倒数，但在普通员工赛道就又是“优等生”，又变得很有竞争力。第一次做管理者，可能做得不好，降职了；一段时间后，第二次做管理者，可能就吸取了许多教训，变得更熟练了。从管理手段上讲，每个赛道就如一列高速行驶的火车，跑在前面，给火车带来动力的员工，要进行奖励，叫做“给火车头加足油”；跑在火车后面的，拖慢了火车前进的速度，就是“尾巴”，这个赛道的尾巴，要“切尾巴”，到下面一级赛道去。所以作为高层管理者，不要怕对下级管理者进行任免；作为小团队的管理者，也不要对任免心生抵触。玻璃心的成员是不适合当管理者的，华为内部讲：“板凳能做十年冷”。十年说得有点久了，一年还差不多。如果一点委屈都受不了，团队是不会有凝聚力的。有上有下，团队的活力才能被充分激发出来。
在彩食鲜，我们设置了八个奖项:
金苹果奖：工作成绩好，业务价值高；
烂草莓奖：还需要继续努力不断提升；
最具协作力奖：团队协作做得好；
最具契约精神奖：使命必达，保质保量完成任务；
持续改进奖：敢于试错，在自己的工作岗位不断尝试，持续改进；
最佳专业技能奖：专业技能强，技术第一名；
最佳服务满意度奖：时刻将客户服务放在第一位；
月度最突出贡献奖：当月团队贡献最大；
为什么要打卡:
首先，这个动作会让团队成员有时间意识；
其次，当团队的产出和工作态度出现问题时，打卡数据会成为一个参考信息。
比如项目在不停地延期，有个人还迟到早退，这样的情况就应该重点关注，看到底是家里有特殊情况，还是心态有问题需要调整？
比如项目做得又快又好，有人还是按时下班，说明他的能力已经超过现阶段的公司要求了，应该给他更有挑战性的任务，让他可以成长。
怎么从面试环节开始，尽早地识别同路人:
第一，要关注这方面内容，意识方面要有，而不仅仅是关注专业、做事、沟通、协作
第二，具体要问是否了解现在公司的方向，如何看待
第三，看过去是否有坚持的习惯，每家公司就呆1-2年的，我是大概率不招聘的
第四，询问冲突、挑战的事情，如果回答的避重就轻，说明也没有这方面的考虑，在一家公司不可能没有冲突的时刻
第五，问候选人，如果录用，是否愿意一起共同努力，得到承诺
现在很多工作都是不确定性的，定目标，看关键产出，复盘，评定绩效，尤其是复盘的公开、反馈很重要。
10 _ 管理的人性哲学: 金刚之怒/菩萨慈悲¶
金刚之怒和菩萨慈悲，就象征着管理的两面性。
当你批评下属时，越严重的批评越要选择私密场合进行
夸奖员工的时候，要指出员工可以继续提高和成长的方向；批评员工的时候，也要肯定他的努力和做得好的部分。
管理者的管理风格和个人形象是强相关的。
金刚之怒是规则，菩萨慈悲是同理心，管理者的一体两面，从建立信任出发，持续做事赢得团队信任，最终打造一支高绩效、有战斗力的队伍！
一个人最可贵的品质是真诚。唯有真诚才能建立信任，笨办法就是最好的办法。
底层的架构思维才是最重要的，就是任何事情从全局看，看核心要素，挖掘本质，这个永远都重要
管理到最后没有什么管理办法，管理最后是要建立一支完全信任的团队。其他都是手段和过程。
小善乃大恶，大善似无情——稻盛和夫：人际关系的基本要点是：要抱着爱心与人交往。但是，那并不是溺爱。有的人以为自己的孩子可爱，而对其过分溺爱，百依百顺，放任自流。这样的教育对孩子的成长极为不利。对孩子的骄纵是一种小善，结果孩子长大后变成了坏人，这是大恶。在职场里，上司和部下的关系也一样。上司缺乏信念，只知迎合部下，不严格要求，看上去很有爱心，结果却是害了部下。相反，抱有信念，对部下严格指导的上司，可能会令人感到不亲切，但是从长远来看却能培养部下，使其成长，这就是大善。施行大善时，看起来不讲情面，可以说“大善似无情”。
11 _ 全局思维和持续完善体系的建立, 让团队持续成长¶
备注
“管理三板斧”、培养全局思维、聚焦能力、风险意识
真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。
如何培养全局思维:
1. 时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。
很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
2. 空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。
比如技术人员要考虑，
站在业务部门的角度，会如何考虑这个问题？
站在财务部门的角度，会如何考虑这个问题？
站在 CEO 的角度，会如何考虑这个问题？
当发现讨论的氛围不对，言语越来越激烈时，我会说一句：我们这次讨论的目标是什么？
拉波波特批评法:
1. 说清楚对方在说什么
2. 说出对方的优点
3. 说出哪些值得学
4. 再说你的观点或评价
12 _ 管理战略上的聚焦和放弃: 有舍才有得¶
备注
这个社会不会奖励面面俱到，但都很平庸的人，光环永远属于那些有明显优势、有明显长处的人。成长就是为了变得更优秀，而优秀的含义是：做同样的事情，表现比别人更好。很多同学在极客时间是什么都学，没有目的也没有方向，最后什么都没学好。说白了，在今天这个知识爆炸的时代，学习一些基础技能很简单。
伤其十指不如断其一指，越是宏大的成长目标，越要徐徐图之。
在一定时间内，只将注意力聚焦在其中一个板块上。对于初级管理者来说，这一点尤其重要。
当你的技术深度，足以辅导团队做技术选型和决策时，就可以聚焦管理了。但具体时机，要靠你自己去判断，因为每个团队的情况都有所不同。
【真的想做管理吗】促使我转向管理岗位的直接原因，是我意识到：有许多工作价值，只能靠团队的力量实现，个人能力再强大也于事无补。我认为，管理的价值会随着团队规模的扩大而增加，在一般情况下，会超过大部分技术专家的价值。每个人不同，慎重考虑。
对于管理工作来说，聚焦的终极目标是「组织成功」，这是个体系性问题。要学会在一定程度上，忘记个人的辛苦和努力，因为那只能代表你的个人成长。
我是在 2020 年三季度末，开始接手彩食鲜的 BBC 业务。当时，整个 BBC 平台部门的人数还比较少，我接手后，直接将编制调整到原来的两倍以上。为什么呢？因为我的目标是，部门业绩要季度环比增长 70%，这个人员编制，是按我的业务目标来配置的。千万不要觉得团队有多少人，就承担多少人的工作量。如果你是这么想的，可以重读一下上一讲：「全局思维和持续完善体系的建立，让团队持续成长」
【舍九取一，聚焦和放弃紧密相连】困难的不是聚焦，而是舍弃。在大部分情况下，没有放弃，就意味着没有真正聚焦；有舍弃，才有收获。我常常说，舍九取一，只有舍弃掉 90% 干扰事项的人，才可能真正聚焦那 10% 的核心任务。那么聚焦哪些，放弃哪些，如何决策呢？这就又回到了我们上一讲的内容：培养全局思维，只有看到全局，才能做好聚焦。看清问题全貌，是做好聚焦的大前提。
【舍九取一，聚焦和放弃紧密相连】少就是指数级的多。全部事情都做是不自信的表现，是没有把握到要解决的核心问题是什么的现象
13 _ 风险管理: 世界是脆弱的, 持续管理风险非常重要¶
Trade-Off，中庸思想，灰度（控制成非常低的风险，成本是很高的）
高层应该给予团队一个关键且唯一的价值导向：我们需要并奖励那些自驱力强、有 Owner 意识、不需要我去管理的团队成员。
管理只是用专业的认知和技能，去给出位于“灰色地带”的团队协作方案。
备注
最有效的风险控制，永远是率先发生在高层的。高层战略懒惰是个很普遍的现象。大部分企业懒得都快”退化“了，却仍然没有意识到问题的严重性。因为高层每天都在干着中层管理者的工作，面对战略难题迟迟不能解决。比如通过考勤数据发现团队的问题虽然对了，但执行起来很困难，Leader要结合那么多人的打卡数据和工作产出作分析，再一对一进行沟通。这样的风险控制，工作量真的不小。所以说，管理者这个岗位，理应，也确实是非常辛苦的。也恰恰是因为这样，在实际情况中，最能偷懒的往往不是基层员工，而是高层管理者。管理者想要偷懒是很容易的：严格打卡，一个季度迟到 10 次绩效 B，迟到 15 次以上，直接协商离职。这么干多省事啊，通过数字定绩效，系统都能帮你搞定。
目标清晰:
S=Specific，目标必须是具体的
M=Measurable，目标必须是可以衡量的
A=Attainable，目标必须是可以达到的
R=Relevant，必须要与其他目标有一定的关联性
T=Time-bound，目标必须具有明确的截止期限
责任到人:
多个责任人的：将每位参与者的名字都写在文档里。
名字排在第一位的，要负责将目标拆解、分派下去
如果目标没达成，他负最终责任；
如果目标实现了，他也享有最大的功劳。
承诺到位:
有外部部门参与协作时，显得尤为重要
研发团队的产能衡量的指标太多了， 比如对于开发人员，代码数，千行代码bug率，需求响应时间，单位时间完成需求数…但这些都只是作为数据参考，最关键的是一个组织内对于业务支持的程度，比如营收增加，利润增加，效率提升，节省人员…，然后配合考核周期内的复盘流程来定。数据很重要，但不能仅靠数据就决定绩效，很多数据都浮于表象，数据是需要解读和洞察的，没有解读的数据很多是有问题的。
任何管理都不要走极端，任何事情不要用黑白思维来看，在具体的时间，它更多的是灰色的。要结合具体的情况来进行处理，比如员工确实没有达到管理要求，要具体看是什么原因，只要遵循公开、透明、公平的原则，这个时候效果应该是最好的。任何管理制度都有不适用的地方
14 _ 需求做不完应该怎么办-初/中级管理者篇¶
备注
“并发式” 工作法弊端很大，其实专注做事的效率更高。
首先，如果你一会看看钉钉（或者飞书）、一会看看邮件、一会回复个紧急需求，大脑在繁杂事项间不断切换，一天下来会很累。我认为这是导致效率降低的主要原因之一。
其次，专注做事情更有目标感，相应地也更有成就感。现在许多人都会列出一天的工作清单，但成就感往往来自任务的完成数量，比如今天划掉一大片待办事项，就会很开心。这当然没问题，也算是一种从工作中找到成就感的方法。但我认为，对于脑力劳动者 —— 尤其是管理者来说，更好的方法是从月度、季度工作目标中寻找成就感。
备注
首先要认识到需求是永远做不完的，但要尽量节约各类需求对管理者精力的影响。在此基础上，我们对管理者的工作重点进行了拆分，认为初 / 中级管理者主要解决效率问题，高级管理者主要解决价值问题。
专注做事的认知和目标导向等企业文化，都是相辅相成的。周报不能写流水账，我不想知道你今天做了啥、明天做了啥。哪怕你一周就写一件事，只要对季度目标的达成有利，我觉得都没问题；反之，哪怕你一周写了一百件事，如果和季度目标没关系，我认为可能都是白费劲儿。
80 分管理者：学会时间管理:
一个始终在处理紧急问题的管理者，不可能是一个优秀的管理者，管理者不应该是职业 “救火队长”:
1. 首先，要学会用团队力量解决部分紧急任务
2. 其次，在时间规划中，要为紧急问题预留时间
3. 最后，即便是紧急任务，也要有取舍，也要区分优先级，尤其是初 / 中级管理者。
要时刻想着自己的 KPI 、OKR 是什么
优秀的高级管理者永远希望下属有思考、有权衡，能优先做最重要的事情，能成就业务；而不是只知道听老板的话，不懂得思考
100 分管理者：思维陷阱和认知灌输:
《别让猴子跳回背上》
一般情况下，下属是解决者，管理者是监督者。
最关键的部分：授权与审查，简单说就是分配工作、检查工作。
高级岗位员工的适应时间是一个半月，给初级岗位员工的适应时间是一个季度。
如果员工始终无法满足岗位要求，那就要坚决调整。
备注
从长期看，在管理方面，你要做的就是不断重复 “授权 -> 审查” 这一流程，工作自然轻松很多。
重要
保持专注、学会时间管理、做好授权审查，在我眼中，这是初 / 中级管理者解决效率问题最有用的手段。
评论:
刚入职新公司做技术经理的时候，我就跟上司说，我在半年内一定是非常忙的且要冲到一线去，个人的和团队的，有很多问题要解决，
当时针对团队的情况，我的策略是：
1. 坚持处理线上问题半年，这个是熟悉业务最快的方式，
同时通过这个认识更多的人，也提高自己的影响力，
也能为后续做一些决策提供基础，当然也能了解团队内部和其他职能团队的问题
2. 找到团队的瓶颈
瓶颈来自人的，就解决人的问题，
瓶颈来自事的，那就推动把事情搞定；
3. 做几个大项目的技术负责人，熟悉公司的管理流程；
经过整整 9 个月的不懈努力，最近自己终于不太忙了，可以去专注的认真的思考：重要不紧急的事情了。
15 _ 需求做不完应该怎么办-高级管理者篇¶
备注
初 / 中级管理者主要解决效率问题，高级管理者主要解决价值问题。
备注
追求效率要适度，追求价值则要无所不用其极。
架构是去发现一个研究对象中最核心的、稳定的部分。架构的组成部分是元素和元素间的关系。
数据化怎么做:
1. 要有数据，对于开发人员、测试人员都有很多数据要看
2. 要去分析数据，分析数据的时候要整体来看，不要直接用数据做绩效，非常不好，分析数据还是管理者自己来做
3. 复盘，数据分析看的是数据，关注的是人，人的效能怎么提升是关键点。要激励人，而不是把团队成员放在管理的对立面
加餐 _ 如何通过演讲分享打造自己的影响力¶
“影响力建设” 方面的收获:
1. 机会更多 在每次工作变动时，都能有志同道合的 CEO 或其他朋友找上门来，让我免于待业在家，也无需苦苦等待猎头的消息 2. 信任更多 无论是初来乍到，还是空降管理，我都更容易获得团队和 CEO 的信任，拥有更大决策自由和话语权，这份信任非常难得 3. 朋友更多 每当我回归曾经工作、奋斗过的城市，总有许多老朋友约我聚一聚，喝喝酒。虽然出差永远很累，但我心里很快乐 4. 成长更快 我更频繁地被邀请到各类场合做分享、做咨询。在这个过程里，我自己也在不断复盘、总结，成长速度大大提高
沟通创造价值，分享带来快乐。
备注
影响力的产生不一定是即时性的，它可能是一个 “发酵” 的过程，要坚信：有付出就会有收获。不要因为演讲没发挥好、文章没写好，就开始退缩，让影响力 “发酵” 一会，坚持做正确的事，做时间的朋友。
03对专业成长的复盘 (10 讲)¶
17 | 架构决策: 技术管理者最重要的能力¶
备注
架构决策能力，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
一把手是团队的天花板，并为团队的所有问题负责。映射到架构决策层面，也就是一把手一定要有勇气在方案之间做取舍，并承担相应的后果。
做好架构决策的流程:
决策流程如下：
当事人发起架构决策申请；
由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
在产研中心部门内，或联合 CTO 办公室，完成架构评审；
将结果发还至当事人征询意见；
由当事人判断是否仍有疑虑，需要进行架构仲裁；
若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
注：
在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；
但对于大型企业来说，上述制度就开始变得非常重要。
架构决策的模板¶
备注
更重要的是，无论是流程还是表格，都不仅是一样工具，更是一种思维模式
技术管理者如何做好架构决策:
管理者至少需要具备两项特质。
第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”。
这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
备注
高级管理者不能总是瞎忙，如果你真的意识到，架构决策是技术管理者最重要的任务之一，就一定会为类似的决策会议腾出时间。
18 _ 架构设计: 专业分工和协作精神的体现¶
备注
一名优秀的架构师应该像个 “隐形人”，似乎什么都没干，但其负责的架构就是能快速响应业务的需求。
先拆分再合并的 “V” 字型设计过程:
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。
备注
抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。
从初级架构师到高级架构师，什么能力是一直存在并持续提升的？其实就是对复杂业务的拆分能力、对可复用部分的抽象能力、对拆分过程的颗粒度把握，以及对未来变化的考量和设计。
备注
一句话总结：对架构层面的「专业分工」和「协作精神」的理解，是一名架构师的基础与核心能力。
功能性架构设计中，最简单直接的方法和步骤抽象总结出来:
1. 关键认知
在个人视角里，整个世界都可以分为：确定性内容和不确定性内容
2. 架构将其抽象为元素和关系
元素对应着确定性内容的处理，是看待这个世界的稳定视角；
关系对应着不确定性内容的处理，是看待这个世界的响应视角；
3. 人类的理解能力有限。
包含内容过多的元素，会导致理解困难，需要将其拆分；
4. 同理，将元素归类的时候，也不能贪多，不然会导致理解困难。
优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为 “组件”。
比如，我们永远以 “元素数量为 10 ” 作为一个衡量点，只要一个组件包含的元素 / 职责超过 10 个，就要进行拆分；
5. 元素归类一般采用 “V” 字型分析法，
即流程分解为功能，功能聚合为组件；
6. 如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。
组件对外暴露的能力，我们统一称之为服务；
7. 架构的关系（relationship）建设问题
稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；
不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
8. 在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中
判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。
所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；
如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
备注
架构设计的终极目的： 快速响应业务需求，对业务达到可持续的稳定的支撑！架构的核心能力是抽象能力和分而治之的能力。抽象便于分工，分而治之便于协作。相辅相成，缺一不可。
架构设计的方法论，比如 EA 中的 togaf，组件设计等都是技术领域的方法论。
19 _ 产品思维: 契约精神是基础/洞察人性成就卓越¶
随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法:
1. 阿里孵化了自己的技术平台，那么平台成熟后，就成为了属于阿里的 IT 基础设施类产品；
2. Netflix API 做得好，那么就成为了 API 产品，不但可以服务内部，还可以对外售卖；
3. 再比如，许多大厂人才梯队建设的好，那么相应的选用育留方法论，也可以构成产品；
4. 一些公司擅长生产内容，就可以形成内容产品，比如 QCon 、ArchSummit 、GTLC 大会。
备注
构建自己的产品思维：有两个关键词最重要，一个叫做“契约精神”，一个叫做“洞察人性”，前者让你拥有入门级的产品思维，后者让你可以成为卓越的“产品经理”。
所谓“契约精神”，是指工作时，要有“一诺千金”的意识:
1. 将自己的每个工作成果都当作产品，并将产品交付或售卖
2. 尝试理解这个产品的用户到底是谁
3. 在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？又承诺交付了什么
4. 不惜代价信守这个承诺
京东物流作为一款物流时效性产品，给用户的“契约”是“当日或次日送达（偏远地区除外）”
唯品会作为一款产品，给用户的“契约”可能是“用更便宜的价格买正版的鞋服”
彩食鲜的“契约”是提供可信赖的安全食品
洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，会觉得自己更棒了，让自己变得更卓越。先成就用户，然后成就产品:
版本发布产品，大部分公司都会将发布时间设计在凌晨:
比如根据业务流量的特性，选择其他时间进行灰度发布；
比如研发建设 7 x 24 小时无人值守的发布系统，附有秒级发布、秒级回滚功能，将团队从人工监测中解放出来……
产品思维六步法:
1. 面对所有的工作，都要习惯性自问：我到底要交付一个什么样的产品？
2. 明确产品的用户到底是谁
3. 明确服务契约
用数字来组成契约，用 “SMART 原则”来检查契约。
4. 将产品打磨至卓越
卓越产品的“三个一”思考法，即“一站一键一秒”
意思是在场景和目标确定的情况下，让用户在一个位置，点击一个按键，在一秒内达成目标。
5. 要习惯于成就用户，时刻谨记：以人为本
技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣。
6. 关注数据，持续完善
产品迭代一定要有数据，要思考如何:
用数据来衡量产品的卓越程度，
用数据衡量产品的价值增长，
用数据成就伟大的产品。
备注
没有产品导向的项目建设如同没有灵魂的肉体，会让工作流于平庸；而产品思维，本质上是一种长期的利他主义思维。
20 _ 高可用设计: 让产品没有后顾之忧¶
备注
应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。那么，要实现架构的高可用，就意味着实现所有元素、连接的高可用。真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供 “降级服务” 和 “熔断服务”，优先保证高可用，其次保证高可靠。
备注
研发管理水平的高低，决定了你在版本发布方面的成功率和信心。
单就版本发布问题来说，你需要关注研发管理的三个关键点:
1. 记录系统的任何一次发布和变化，包括发布系统 / 组件、发布时间等
确保自己可以随时定位任何一个时间段内的任何元素及任何发布动作，
包括但不限于代码、配置文件、SQL 脚本、设备参数修改等；
2. 发布时不影响业务
3. 保证任何发布都可以回滚
尤其当一个大版本的发布时，能否精确识别回滚单元，并做到秒级回滚
提高系统的抗风险能力的两个问题:
1. 由代码逻辑导致的系统风险，是如何进入生产环境的？
研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正
如果异常通过了评估，审核者要对其负责
2. 生产环境出现严重故障，是不是毫无征兆地发生的？
系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它
备注
关键在于要注意，真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。
限流降级熔断，应用高可用的三板斧。
缓存升配扩容，应用高性能的三板斧。
多机异地灾备，机器高可用的三板斧。
21 _ 高性能设计: 一切都围绕着契约精神¶
高性能设计可以大体拆解为两大步骤:
1. 清晰描述、定义性能目标
2. 设计并实现这个目标
高性能架构的设计目标，是通过三类指标来具体定义:
1. 系统响应时间，一般指服务 / 交易处理的时间，也包括网络响应时间
2. 系统吞吐量，一般指系统的每秒交易量，通常需要结合并发量共同描述
3. 系统容量，通常代表系统的可用资源数量，包括硬盘容量、网络带宽等
实现高性能架构的关键技术点:
1. 为架构做好 “保护系统”
保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。
流量控制有两种具体的实践：一种是面向连接数做控制，一种是面向用户数做控制。
前者让用户在不断尝试连接时，有一定成功的可能；
后者则保证用户对系统的期望是一致的 —— 要么可以登录、要么不能登录。
具体应该选择哪种方式，取决于业务的实际诉求。
2. 使架构具备扩容能力
一般要包括储备额外的计算资源和具备快速弹性扩容能力。
3. 提升系统各组件处理能力
识别高并发情境中的资源争抢情况，同时注意保留架构的可扩展性。
对于架构负责人来说，性能设计一定要尽早开始，具体工作内容包括:
1. 需求早期收集
2. 容量分析
3. 估算与建模
4. 技术研究
5. 设计、开发、跟踪
6. 测试计划执行
7. 风险与绩效管理
8. 实时监控与容量管理
备注
任何复杂问题都可以被拆解为简单问题，只要拆解得足够细致。一定要牢记这一点，这种思维能力是技术人的安身立命之本。“天下难事，必作于易；天下大事，必作于细。是以圣人终不为大，故能成其大 “
备注
人生永远是在不确定性中寻找确定性，不断的做决策。
22 _ 扩展性设计: 看透业务的本质¶
备注
本质上，所谓扩展性设计，就是在面向业务的不确定性做设计。
要提升扩展性，需要在以下四个层面进行设计:
1. 公司的年度 / 季度业务发展目标
2. 企业级产品建设
3. 企业级应用架构设计
4. 企业级技术架构设计
交易体系处理确定性问题，一般采用 SOA 架构。
协同体系用于处理不确定性问题，一般采用 EDA 架构，且要和交易体系进行集成。
交易体系和协同体系的分离，等同于分离了业务的确定性和不确定性部分，因此非常有利于业务功能的扩展。
分离不代表完全无关，交易体系和协同体系的集成点，我称之为 CP（control point）。
一般来说，任何一个 CP 都要被监控、分析、控制，这就是企业的监控指挥体系。
监控指挥体系和公司的管理密切相关，往往是公司数据化管理的重要抓手。
例:
一个销售订单进入到仓库作业后，发现需要的5瓶矿泉水没有了，而这个是在下单的时候检查库存没有问题的。
可能因为是库存管理不准，可能是破损盘亏了，但不管是怎样，这里少了矿泉水，导致履约出现问题，会触发紧急采购。
在触发紧急采购的地方，就是一个需要监控、控制点，为什么呢，
这个地方的触发一定会导致用户体验下降，采购成本上升，要监控数据，通过管理降低这里触发，甚至是消灭。
向管理要效益。
备注
真正的扩展性设计，往往与单一维度的技术问题无关，也与某个人的架构设计能力关系不大 —— 扩展性设计，是团队整体认知、博弈与决策的结果。真正优秀的扩展性设计，建立在看透业务本质的基础上，面向不确定性，但要从不确定性中寻找确定性。
我管理的团队，做成什么样，产品经理负责，不是业务人员决定的。
产品经理要考虑业务发展，变化，但是业务的问题要解决，如何做业务没有权力做决定。
23 _ 考虑限制: 让自己的产品不入险地¶
限制产品的输入与输出¶
如果你是产品的负责人:
“输入” 就是其他人对你承诺的 “契约”
“输出” 一般理解为承诺给用户的 “契约”，指的是产品的对外能力，通常受到输入的严重影响。
具体如何考虑输入限制，有两大维度去重点评估和考量:
1. 一类叫做业务限制
2. 一类叫做技术限制
业务限制主要包括以下六点:
1. Time（时间）、Resource（资源）、Scope（范围）三要素
2. 法律法规与政策限制
3. 组织文化限制
不同的组织结构、组织文化，都会对产品的输入造成限制。
这也是管理者为什么要聚焦「管理三板斧」，建立好的企业文化 —— 没有合适的组织，一切设计都是空谈
4. 地域因素限制
5. 风险承受能力
6. 市场因素限制
技术限制具体包括五类限制因素:
1. 遗留系统限制
新系统上线的时候，架构师的一个重要工作便是做系统的上下文架构设计、明确周边依赖，
对于需要和周边遗留系统进行集成交互的组件或模块，要高度重视。
这些都是关键的限制因素，可能因为一个小小的环节疏漏，就最终影响了工作的推进。
2. 团队技能限制
团队成员本身的能力，也是一大限制
3. 现有基础设施限制
基础设施强，团队能力就强，输入限制就少；
基础设施弱，团队能力就弱，输入限制就大。
4. 标准规范限制
随着企业 IT 治理水平的提升，都会逐步建立企业范围内的标准规范
5. 实施限制
在一个项目组里，有四类角色非常重要，分别是:
1. PM（Project Manager），项目经理
2. PM（Product Manager），产品经理
3. Architect，架构师
4. Specialist，某一领域技术专家，比如 DBA ，分布式缓存专家，大数据专家等
项目在落地过程中，所有的节点监控、风险管理等工作，都依赖于 WBS，WBS 有三大分解原则：
将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
每个任务原则上要求分解到不能再细分为止；
日常活动要对应到人、时间和资金投入。
WBS 制定：PM组织产品经理、架构师、技术专家，一起分解任务；要么一人身兼四种角色，独立完成。
- WBS 制定完成后
产品经理以产品设计匹配业务需求，明确业务目标和业务流程； 架构师负责整体的框架设计，明确对应组件的整体视图； 技术专家负责扫清相关的技术难点。 最后，Developer（开发人员）、Tester（测试人员） 进入项目，解决工作量问题。
备注
【向上管理】第一件要做的事，就是利用自己的专业知识和行业一般数据，将与 WBS 有关的思考和推断表达出来，尝试让项目按照正确的节奏落地。第二点同样重要：要从更快交付的目标出发，同时将多种限制因素考虑在内，比如团队疲劳度、凝聚力、激励措施等，和老板一起想办法，把自己想象成一个专业的 CEO —— 这公司就是自己的，进而思考应该如何安排工作、如何制定 WBS。具备全局思维、让自己变得更专业、提升自己的表达能力，这一切工作都不是为了和老板在项目目标上进行博弈。我们的目的是，通过更合理的实现路径，最终达成业务的增长目标。否则，除非你非常优秀，是不可或缺的人才，不然一般都会在博弈中处于下风，对个人成长造成影响。
限制，在企业层级，也意味着在企业发展的某个阶段，选择放弃某类用户。有放弃，才能聚焦，进而倒逼自己看到全局，和企业目标对齐。聚焦当下，学会取舍；放眼长期，持续进步、持续改进。
从公司层级，项目启动的时候，项目所有人要听 PM（项目经理） 的安排，PM 要充分发挥四种角色（项目经理、产品经理、架构师、技术专家）的专业，一起制定项目的 WBS。所以权力在项目启动的时候赋予了项目经理，项目启动会其中一个最重要的目的是赋予项目经理权力，否则那不是项目经理，而是项目助理。
1. 做 WBS 分解是需要专业的，能说清楚限制背后其实也是专业在进行支撑。如果不清楚专业的内容，是不可能做一个实际可行的 WBS 的。
2. 在项目的控制层面，只有分解后的 WBS 才能真正说明进度和质量能守得住，否则其实都是瞎拍脑袋过度承诺。
24 _ 监控设计: 让一切都有迹可循¶
生产环境出现问题，原因通常只有两个字：变化。常见的 “变化” 大致有三类:
1. 外部用户请求量增大
2. 产品发布，一般包括代码发布、配置发布、SQL 脚本发布等
3. 依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等
生产应急恢复方法修改为以下 4 条:
1. 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
2. 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将 “健康” 的定义想清楚，如，响应时间是否增加超过 30% 等）；
3. 此处组织两批研发力量，并行工作。
第一批解决专业问题，继续跟进问题的定位和调试；
第二批负责消灭变化，对有变化的模块进行回退，对于外部请求数量升高的模块启动流控；
4. 恢复系统。
备注
问题的关键在于，生产环境是不允许查找 bug 的。在生产环境，研发人员应该寻找并消灭 “变化”。
如果能做到监视一切，分析一切，控制一切，“眼” 能看见所有，“脑” 能洞察一切，“手” 能一手遮天，一切业务数字化，一切数据可视化，一切控制可触发，那么，这个企业的数字化水平一定已经很高了。
备注
监控的目的是让系统一直处于健康状态，具体手段则可分为 “监视” 和 “控制” 两种；要做好控制，一个重要的方法是做好流控和版本回退。因为在大部分情况下，消除变化就等于消除异常。
25 _ 异常设计: 让错误无处遁形¶
备注
【定义】异常，指的就是那些让产品无法履行当初承诺用户契约的问题。
异常设计重要性:
假设电商平台缺货的概率可能只有 2%
但当平台用户数量达到一百万时，就会有多达两万人受到缺货问题的困扰
这两万人中，可能只有 30% 的用户有在社交平台发帖的习惯
就会有 6000 人出现在各大社交平台上，发帖吐槽该电商平台的缺货、质量问题。
但这些用户经历的坏体验，对于开发人员来说，可能只是一个简单的错误提示而已。
一、认知:
1. 异常一定要消灭
有异常，基本就意味着系统存在风险，一定要消灭异常；
2. 异常一定要管理
消灭异常是个长期工程，短期要通过管理行为来进行控制；
3. 对异常的处理水平，会极大影响产品的用户体验
用户规模越大，异常的影响往往越大；
4. 每个异常都要有具体的负责人
没有和具体的负责人一一对应，往往就意味着管理流于形式；
5. 与终端用户相关的异常，要以最高优先级处理
即便是 IT 研发，也要以用户为中心。
二、方案:
1. 异常注册内容大概分为以下几项:
a. 异常的 ID 和名字
b. 对异常的描述
c. 异常出现的代码位置
d. 负责此异常的研发、测试和产品人员
e. 异常发生时的代码版本
f. 当时使用的异常处理程序
2. 建立异常中心系统
a. 异常注册: 各个系统都要在异常中心注册异常
b. 事件触发: 一旦运行阶段出现异常，就要抛出异常事件
c. 协作流程: 抛出的异常事件触发异常处理的协同流程
d. 异常统计: 对异常消息进行归类处理，相关异常编码、响应信息实时收集、归类，保证可视化、可统计
3. 管理层也要关注异常的处理情况，包括：
a. 异常的数量
b. 异常的发生频次
c. 系统内异常数量的增速或降速
在季度末、年末，我们会对管理层进行绩效考核，并将异常管理情况纳入考核体系，以此实现异常治理的闭环。
备注
只要仔细观察一家企业是如何对待异常的，就可以判断这家企业的精细化运营和管理水平。
26 _ 上云设计: 融合云计算的未来¶
要明确地意识到，未来，专业分工一定会越来越明确，技术基座一定会不断上移，每家企业都可以忘掉底层技术细节，聚焦自己的核心业务逻辑。因此，这条思考脉络最终也会回到出发点，形成闭环：对于大部分商业公司（非技术产品或云计算公司）而言，技术只有在成就业务时，才具备真正的价值。
个人成长路径其实只有两条:
1. 成为技术管理者，进入商业公司，采用技术产品或云服务，洞察业务，帮助业务成功，实现业务价值
2. 成为技术专家，进入纯技术公司或云计算公司，设计开发技术产品，提供技术服务
结束语¶
结束语 | 做时间的朋友¶
“有用之书” 就像各类专业课程，读完了就要在当下立刻实践，光看不用，基本就算是白学了；
“无用之书” 并不是真的无用，它们一般很难即时生效，但长期看来，会对你的人生造成巨大影响，比如人生感悟类内容、哲学、艺术、高等数学，等等。
“有用之书”，如果不能实践，就等于无用；
“无用之书”，如果有时间的时候不学习，事到临头时，也很难 “抱佛脚”。
备注
复盘自己，真是一件痛苦的事儿。
备注
利他就是最好的利己；沟通创造价值，分享带来快乐。
一个 leader，要为组织成功负责，要为团队成员的发展负责。
争取理解每一个员工，我和团队管理者也说，对于管理者就是个数字，但对于员工就是全部，做管理者要有同理心，真心理解下属，但也要严格要求。
梳理自己的技能，能力体系，努力去找机会，要去实践、锻炼，扛压力中成长是最快的。已经工作了，学校不是很重要的，关键是能扛事。工作中的学习能力是最重要的