CTO成长之路
2022-06-14 22:45:29 1 举报AI智能生成
CTO核心能力思维导图分析
作者其他创作
大纲/内容
资料
飞书
管理工作复盘
全景图
绩效与激励体系
增强协同 - 项目管理
立项、
目标清晰：每个业务目标、产品目标、技术目标都要清晰且可量化；
责任到人：上述每个目标都要责任到人，不能都是项目经理扛，项目经理扛不了的；
承诺到位：如果需要外部组织配合，要得到外部组织的明确承诺；
项目控制、
风险管理、
结项
端到端的产品管理
战略层面
组织调整到位；
构建面向产品的组织架构
职能型研发组织架构
产品型研发组织架构
优点
第一，产品经理、开发、测试，形成了一个整体，被赋予共同的文化价值观，为共同的目标去努力，战斗力变得更强了。
第二，无论是产品经理，还是开发、测试，都开始和业务部门熟悉起来，和运营同学坐在一起，为自己的产品负责。
第三，管理者开始能通过一套统一的绩效考核体系，去考核不同岗位的团队成员。
作为管理者
业务发展和技术能力建设中间寻找平衡
IT与业务的关系
考核 IT 产品给业务创造的价值
如何考核业务价值
业务价值参照公司、部门的收入和利润进行换算；
如果出现不能直接计算的情况，按人效提升、人力节省的程度进行换算。
如何做
开源
帮助企业增长、扩大市场份额的工作属于开源类工作，这些事情能做就做，要优先处理
让企业内连接、协同效率更高，让数据共享更透明，帮助决策更高效之类的任务
节流
节流类工作的优先级次之，具体是指人效提升、人力节省等
同时考核业务部门的 IT 化水平
如何做好组织选型
第一，如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织。比如说，产品经理、开发、测试的能力很差，还有很多技术挑战不好解决，这时不要冒失转。
第二，如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构。
第三，技术管理办公室 和云办公室应用
对于 200 人以下的研发团队
研发规范管理+基础平台能力建设
如果团队规模超过 200 人
研发规范管理
基础平台能力建设
加强协同效率；
协同，就是让所有人向着同一个目标狂奔，并妥善解决奔跑过程中的合作问题
目标聚焦
原因
无论你的能力有多强，需求是永远做不完的；
因为需求做不完，所以要努力通过全局视角思考，做到战略上的“舍九取一”，进行单点突破。
现状
团队各做各的，心没往一起去，影响团队产出；
团队间互相扯皮，出了问题互相推诿，影响团队产出；
IT 团队的同学，有时候会说：你看我做了一个很好的东西，但是他没有配合好，所以没有发挥价值；
怎么改善
提高协同的手段
沟通协同：一般通过飞书等即时通讯软件来实现；
日历协同、会议协同：这里是指全员、尤其是管理者要做到日历公开，只要空白的时间段，就意味着可以预约会议，减少协调成本；
文档协同：一般通过石墨文档、飞书文档等共享文档实现高效协同；
目标协同：一般通过 OKR 来实现上下目标对齐。在彩食鲜，中高层每月、每季度对齐目标；执行层每日、每周对齐目标。
尽一切可能打造极度透明、信任的文化
不够透明的信息，最终都会花掉团队更多的时间成本。
没有透明就不要谈协同
问题必须提前暴露
问题必须暴露，不许隐瞒，这是红线。有问题不上报，发现后直接开除；
允许犯错、试错，不以指标决定绩效评分，最终以复盘情况决定绩效。
如何复盘
第一当初的目标是否清晰，业务目标，产品目标、技术目标是否清晰
第二，是否进行了详细的WBS分解，过程是如何管理的
第三，遇到了什么困难、挑战，自己是如何克服、努力的；为什么能成功，为什么还是没有做到
第四，如果结果没有做到，过程中风险管理、变更管理是如何做的
第五，ROI，团队的价值、经验教训是什么，投入了多少资源，ROI如何
第五， 下一次如何提升，上一个台阶
KPI 与OKR
确定性工作使用 KPI
不确定性工作使用 OKR
激发团队活力；
寻找同路人，管理要慎重
首要
管理者的第一个任务是找到同路人
如何做
认真规划面试工作、企业文化宣传、激励措施制定……
最关键的是，开除那些触碰底线的人，尤其是能力很强、但触碰底线的人，因为这样的人对团队其他成员的影响力很强
其他
请团队吃饭、打王者荣耀，和大家打成一片？召集大家开会，给大家发表一场振奋人心的演说？一对一和团队私聊，说说对下属的期望和规划？同步一个关于绩效和奖励的好消息？
赋予团队使命，打开考评与晋升通道
评奖、做绩效，每个团队都做，但考评赛道的划分，你的团队做了吗？划分赛道很关键。
只有频繁地重复输出，坚持言传身教，使命和愿景才能从墙上走下来。
管理游戏化，发现每个人的优点
金苹果奖：工作成绩好，业务价值高；烂草莓奖：还需要继续努力不断提升；最具协作力奖：团队协作做得好；最具契约精神奖：使命必达，保质保量完成任务；持续改进奖：敢于试错，在自己的工作岗位不断尝试，持续改进；最佳专业技能奖：专业技能强，技术第一名；最佳服务满意度奖：时刻将客户服务放在第一位；月度最突出贡献奖：当月团队贡献最大；
激活团队，重要的是细节
那么为什么要打卡呢？
管理的人性哲学
管理者如何彰显领导力
金刚之怒，菩萨慈悲
金刚之怒
办公室吵架，开除；
工作受了委屈后不沟通、不解决，一直抱怨，开除；
生产有问题时，隐瞒问题，开除；
菩萨慈悲
案例
案例一：如何与员工沟通加薪问题
案例二：如何处理员工的绩效和降职问题
全局思维和持续完善体系的建立，让团队持续成长
全局思维
一是时间维度
所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
二是空间维度
空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？这是个人所处空间上的变换
向上管理
真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通。
管理战略上的聚焦和放弃：有舍才有得
普通技术人聚焦个人成长
成长就是为了变得更优秀，而优秀的含义是：做同样的事情，表现比别人更好。
初 / 中级管理者聚焦双线成长
对于管理与技术的取舍，，如果你非常纠结，可能就说明你的技术能力还不够，两手都要抓。
舍九取一，聚焦和放弃紧密相连
没有放弃，就意味着没有真正聚焦；有舍弃，才有收获。
那么聚焦哪些，放弃哪些，如何决策呢？这就又回到了我们上一讲的内容：培养全局思维，只有看到全局，才能做好聚焦。看清问题全貌，是做好聚焦的大前提
案例分析
需求做不完，应该怎么办？
概述
对于任何一名走管理路线的技术人来说，工作状态长期过于饱和，都是一个危险的信号
在新台阶工作了一定时间后，还是很辛苦，就要好好反思自己的工作方法和认知了。
初 / 中级管理者和高级管理者应该区别看待。前者主要解决效率问题，后者主要解决价值问题。同时，效率问题要和价值问题围绕同一目标进行对齐。
初/中级管理者篇
难度最低的办法：保持专注
状况
你被迫开始高度关注团队任务的执行情况，在早期甚至需要代替下属完成部分工作；你被迫开始重视团队建设，因为缺乏“猛将”而苦恼；一般初 / 中级管理者还承担着部分一线工作任务，工作任务繁重（这里我也不建议初级管理者脱离一线任务）；
对于脑力劳动者——尤其是管理者来说，更好的方法是从月度、季度工作目标中寻找成就感。
你看，其实专注做事的认知和目标导向等企业文化，都是相辅相成的。
80 分管理者：学会时间管理
100 分管理者：思维陷阱和认知灌输
思维陷阱一：下属为何这么笨？
下属的工作能力本来就不如你，不然也不会拿着比你更少的薪水，成为你的下属。
思维陷阱二：教会徒弟，饿死师傅？
我认为作为一个初 / 中级管理者，至少要培养两名能力很强的下属，才算合格。
每当我不得不替下属完成部分工作，我都会告诉他：这是你的工作，我是在替你完成工作
高级管理者篇
对业务方
表面上公司是在为了需求积压而焦虑，实际上是在为业务发展的困境承受煎熬和困扰。
建设产品型研发组织结构，做战略上的聚焦
在“项目驱动”的模式下，可能没人对需求的价值作出负责任的回答 —— CEO 或 某事业部总经理单个人的精力不足以覆盖每一个需求；但在“产品驱动”的模式下，所有需求都应该是对产品价值的准确回答，因为这是团队共同的责任
深度干预集团战略和激励体系
问题1
CEO 对业务和产品的认知，决定了他会不会说服业务部门；CEO 应该重新定义技术部门的 KPI 或 OKR。
问题2
重新规划考核体系，并将业务部门纳入考核；重新定义激励体系，从面向需求转为面向产品。
而经过这些年的历练，我认为，追求效率要适度，追求价值则要无所不用其极。
专业能力复盘
架构决策，是技术管理者最重要的能力
决策失误，是“技术债”的主要来源
那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
选择“不作为”，往往更加可怕
举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？
给大家分析哪一种方案更好，现场拍板；
指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
一把手是团队的天花板，并为团队的所有问题负责。
做好架构决策的流程和模板
流程
当事人发起架构决策申请；由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；在产研中心部门内，或联合 CTO 办公室，完成架构评审；将结果发还至当事人征询意见；由当事人判断是否仍有疑虑，需要进行架构仲裁；若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
模板
技术管理者如何做好架构决策
第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”
这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
架构设计，专业分工和协作精神的体现
好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神。
所谓的“专业分工、充分协作”，到底是做了什么呢？
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。比如，要从零实现一个淘宝网，是相当复杂的事。但我们可以将其拆分成订单中心、用户中心、商品中心、库存中心等许多模块；订单中心还可以再拆分，比如拆分成订单创建、订单查询、订单履约等功能；如果实现仍然复杂，我们还可以继续拆分，直到能够用简洁优雅的代码去实现。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。
认知延伸：如何看待微服务和中台架构
架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。
保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来
所以，无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。
复杂架构设计如何落地执行
关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素 / 职责超过 10 个，就要进行拆分；
元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
产品思维，契约精神是基础，洞察人性才能成就卓越
产品，是企业及个人价值的最好载体
产品是企业对外提供服务的载体，也是企业核心竞争力具象化的载体。
一般来说，随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法。
培养产品思维的核心脉络
一个叫做“契约精神”，前者让你拥有入门级的产品思维
将自己的每个工作成果都当作产品，并将产品交付或售卖；
尝试理解这个产品的用户到底是谁；
在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？又承诺交付了什么？
不惜代价信守这个承诺。
一个叫做“洞察人性”，让你可以成为卓越的“产品经理”
洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，会觉得自己更棒了，让自己变得更卓越。先成就用户，然后成就产品。
产品思维六步法
实践产品思维的第一步，就是面对所有的工作，都要习惯性自问：我到底要交付一个什么样的产品？
第二步，明确产品的用户到底是谁。
第三步，明确服务契约。
第四步，将产品打磨至卓越。
卓越产品的“三个一”思考法，即“一站一键一秒”
让用户在一个位置，点击一个按键，在一秒内达成目标
第五步，要习惯于成就用户，时刻谨记：以人为本。
技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣。
第六步，关注数据，持续完善。
高可用设计，让产品没有后顾之忧
解剖高可用设计
真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。
在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠。
手段
冗余设计
降级服务
组织层面
研发管理水平的高低，决定了你在版本发布方面的成功率和信心。
研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责。
系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它。
关键在于要注意，真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。
高性能设计，一切都围绕着契约精神
契约精神是高性能架构设计的“拦路虎”
清晰描述、定义性能目标；
系统响应时间，一般指服务 / 交易处理的时间，也包括网络响应时间；
系统吞吐量，一般指系统的每秒交易量，通常需要结合并发量共同描述；
系统容量，通常代表系统的可用资源数量，包括硬盘容量、网络带宽等。
怎么明确
不明确的说明
本系统、组件、服务承诺在任何情况、任何资源、任何压力高峰下，都保证 TP 90 = 2s 。
“该架构最高支持 200 万并发流量，TP 90 = 2s 。”
有上限的“契约”才能交付
“保证设计流量内的用户 TP 90 = 2s，超出并发限制的用户，则暂时不在契约承诺的范围内。”
正确的描述
第一步，当服务器不超过 200 万并发用户时，TP 90 = 2s 。
第二步，当连接服务器的并发用户数量超过 200 万，达到 250 万时，保证有 200 万用户的 TP 90 = 2s ，拒绝其他用户的连接请求。
第三步，为设计容量外的用户提供服务器排队机制，并附带具体、明确的系统提示。
第四步，3 分钟内完成扩容，保证并发用户数量小于等于 250 万时，任何在线用户的 TP 90 = 2s。
设计并实现这个目标。
实现高性能架构的关键技术点
为架构做好“保护系统”；
保护系统，是为应对容量规划外的过载而设计的，通过流量控制来具体实现。
一种是面向连接数做控制
让用户在不断尝试连接时，有一定成功的可能
一种是面向用户数做控制
保证用户对系统的期望是一致的 —— 要么可以登录、要么不能登录。具体应该选择哪种方式，取决于业务的实际诉求
使架构具备扩容能力；
而对于扩容能力来说，一般要包括储备额外的计算资源和具备快速弹性扩容能力。
提升系统各组件处理能力。
需求早期收集容量分析估算与建模技术研究设计、开发、跟踪测试计划执行风险与绩效管理实时监控与容量管理
在这中间，有一点需要额外注意，我们称之为“对系统资源的争抢问题”。
对于无状态的服务，理论上可以通过集群扩容，无限增加系统的并发处理能力，简单、直接地解决问题；但对于有状态的数据服务
但对于有状态的数据服务而言，比如缓存或数据访问，就要考虑资源争抢问题，并针对性地设计、处理。
扩展性设计，看透业务的本质
所谓扩展性设计，就是在面向业务的不确定性做设计。
思考路径
是公司的年度或季度业务发展目标
第二个节点，是企业的产品建设
第三个节点，是企业的应用架构设计。
第四个节点，是企业级技术架构设计。
0 条评论
下一页
