育学园 CTO 于游：用“养育孩子”的理念来管理技术团队
嘉宾介绍：于游，现任育学园 CTO ，曾就职于网易、久游，中演票务通 CTO，Groupon.cn CTO，千丁互联 CTO，万达电商 平台技术中心总经理，GITC 全球互联网大会主席团成员，GITC 全球互联网大会主席团成员，麒麟会理事。曾获得全国第 12 届运动会（辽宁）- 突出贡献奖、第二届青年奥林匹克运动会 - 票务技术总监理、2018 年 GITC 全球互联网技术大会（GITC）- 技术杰出贡献奖以及 2019 年中国教育科技大会 - 技术成就奖等。
大家好，我今天分享的主题是“用养育孩子的理念来管理技术团队”，我所在的公司名叫育学园，业务涵盖育儿记录、纪念分享、发育测评，最主要是提供母婴类育儿的知识。虽然公司用户数量不多，只有 1700 万，但是在整个母婴领域属于头部企业。
每年中国有 1500 万的新生儿，4 年也就是 6000 万左右，公司利用仅仅 4 年多的时间，就掌握了中国 1/4 的新生儿家庭。在我的工作内容范畴内，我学习了很多育儿的知识，今天讲述的内容基本上和育儿的理念相同。
今天的正式分享以一种罕见病开始，小儿甲基丙二酸血症，这是一种小儿类强染色体疾病。
它的主要表现是患者尿液和血液中含有大量的甲基丙二酸，酸性的腐蚀会影响孩子的大脑发育，情况严重一些就是脑瘫。疾病的发病率大约是十分万之 1.2-1.5，这意味着 1500 万中国新生儿有 2.6 万左右的用户得到这样的病，但是因为这是常染色体隐性遗传病，父母们常常不清楚。
在孩子出生前，隐性遗传病用常规技术手段较难检测，因此无法避免，但是它的治疗方法很简单——特殊配方粉。只要孩子在出生那一刻起，不喂母乳，不喂奶粉，只喂一种特殊配方粉就可以。
疾病的产生，防护以及治疗像极了创办新公司的过程。在这个阶段当中，创始人亦或是 CTO 没有办法避免很多意外事情的发生，不过我们可以像“喂特殊配方法的”的方法来解决这些问题。
刚才谈到上述病症的检验方法，我可以告诉大家异常简单方法——孩子出生之后，去查验一下小孩尿液中是否含有大量的甲基丙二酸。这样就可以查验出孩子是否有患病，针对性地治疗会容易很多。公司系统也是一样，很多人隐形的问题，通过一些简单的检测，可以发挥很大的作用。
这其实像极了我们在一家新公司在搭建架构的初期所犯的错误，不是每个公司的基因都是完美的，但即使是有一些小的问题，其实也可以经过后期的调整来进行弥补，所以我一直都在思考，育儿的理念能否用在公司管理和技术管理上。
今天我会以这个角度分享三点内容。
第一，我会分享从 0 到 1 搭建团队过程中容易遇到的坑，这些坑有点类似于新生儿整个生长发育过程；第二，当公司初具规模之后，CTO 应该如何进行团队的沟通和配合？这些东西会以家庭为单位形成一种养育方法；第三，简单分享一些空降 CTO 的管理方法论。
首先是新公司、新系统经常的问题，这些问题和新生儿的健康问题一样，难以避免且很难察觉。新生儿的父母应该都会有非常大的感触，孩子们看似是一个相对健康的状态，实际上体弱多病。我们的系统看是可用的，实际上有很多问题。这是为什么？
因为新公司初创之时，我们对未来没有明确的期许。对于业务和架构，没有明确的规划，只能用无限地填坑去解决以往的问题。创业初期合伙人常常会说：“你的技术不行，你的团队不行，你要去解决你团队的问题，去支持公司的业务”，但实际情况并不是这个样子。有时候甚至出现的问题是你的技术“太 OK 了”，设计出的系统足够复杂。
拿中台举例，中台的“厚”或者“薄”决策权在 CTO 手里，CTO 决策错误会造成团队的疲惫不堪。例如系统在设计之初做了多元版本，为了解决一个简单的业务需求，技术团队常常需要改掉所有多元的配置，跑完发版、上线、测试等整个全流程。这种过分设计，很难保证业务的快速迭代，修改起来非常困难，团队疲惫不堪。今年的技术顾问经理，让我认识到技术不是越高级，复杂越好，可以解决业务需求就可以。
京东最早的时候，代码就是在一个“别墅”当中写出来。当京东的业务达到一定程度的时候，它出现了巨大的问题。刘强东曾经拿了一把刀说：“我要请技术团队喝茶”。后面更换了四任 CTO，这个问题都没有解决。最后还是买了一台 oracle，才解决了问题。技术管理者选择的技术框架和技术能力不一定能够让公司得到好的结果。有时候技术人员会陷入到一个误区当中——总是认为自己的错。其实你没错，没有人错，关键是这个决策是否正确。
除去决策问题之外，公司还会有“遗传病”，公司的遗传病来源于什么？来源于 CTO 的自信，经验主义的自信。很多 CTO 将过去公司的架构，技术等照搬到新公司或者团队，造成各种“隐形疾病”，这种隐形遗传病像儿童的疾病一样，在一定时间就会雪崩。
上图展示过程大家都经历过——新生儿诞生，父母睡不好。我相信很多团队的领导都有这样的经历，所以开始上线的时候，我需要为所有系统重新评估，着手解决系统以前没有解决的问题。
能否真正解决问题与 CTO 的能力有关。在 0 到 1 的阶段，技术能力、业务能力、架构能力、产品能力以及管理能力缺一不可。
第一，技术能力。技术能力包括深度、广度、合理、敏锐度，说起来容易，但是做起来很难。我曾经为一位搜索行业的 CTO 担忧过，因为这位 CTO 对底层数据结构的时候一无所知，后来这家公司也没有做成功。有一些最基础的东西，CTO 是应该去了解。
说完深度，谈一下广度。后端需要对前端有一定的了解。最近几年前端变化比较快，H5 半年不看，就落后了一个时代。CTO 需要拓展自己这方面的知识，无需深入，了解即可。另外一个广度问题是招聘人才，想要寻找合适的人，必须有足够的知识广度，才可以招聘到团队所需要的人才。其次是合理度，这指的是公司选择这个东西是否合理。它建立在广度和深度的基础上，自然而然诞生的能力。
最后就是敏锐度，保持对市场以及生态的敏锐度。当我写代码的时候，我观察到了未来分布式的可能性，我完全采用了分布式系统，取得了非常好的效果。如果没有那样做，按照现在的数据量公司的系统早已经 Cover 不住了。这是一种敏锐度。
第二，业务能力。理解业务、推动业务的业务能力，如果 CTO 只搞技术，那这个公司很难成功。无论是 BAT，还是美团和今日头条，都是技术和业务的结合。
第三，架构能力。设计和落地，落地代表着资源、时间，还代表着团队的控制力。
第四，产品能力。这其实是跟业务能力相关的。然后就是 nice，你要对人足够的 nice，要坚持自己的原则跟他们去对抗。
第五，管理能力。在初创阶段，管理需要注意的事情，主要是团队的项目与绩效。
初创阶段， CTO “既当爹又当妈”，所以针对 CTO 的素质以及能力来说更高。谈过 CTO 所具备的能力以外，我们看看创业阶段容易犯的错误——“3 边”行动和“6 拍”运动。
“3 边”行动：边计划、边实施、边修改。
CTO 用自己行动上的勤奋掩盖了自己战略上的懒惰——我并不清楚未来是什么，先干着，我先落地吧，这个过程往往会浪费掉公司很多的资源。
“6 拍”运动。拍脑袋、拍肩膀、拍桌子、拍屁股、拍大腿。
拍脑袋，很多想法没有经过调研就直接开始做；拍肩膀，交给你去干吧；拍肩膀，交给我吧，没有问题；拍桌子，我明明想得很好，你为什么没有做好；拍屁股，员工拍屁股走人了；拍大腿，你拍着大腿说，我就不应该交给他。其实所有的错误都从拍脑袋开始，所以千万不要拍脑袋开始，一定要去调研。
除去这几个常犯错误以外，我们谈谈对齐团队目标，这是管理者必备技能。我常用的原则是 QRT。
这个原则的最后步骤是分解成小单元。有的管理者说目标不要分解到最小单元，有人说一定要分解到最小单元，但是这一切背后的原理是资源（R）、质量（Q）和时间（T），这是永恒的 3 边，没有人能做到完全的均衡，只能做到缩减。因此需要将 QRT 与目标放在一起来考量，而不是单纯地设定目标。
除去 QRT 之外，有一个常用的项目工具 WBS（工作分解结构）也不错，推荐大家使用，它是一个项目的启动计划、执行和收尾全阶段的生命周期。
做任何一个项目，我们最需要的是整个项目的执行过程，包括回收结果的方式。除了技术项目，还有产品项目、运营项目都可以进行层数的拆解。当然在项目拆解的过程当中，我们应该去考虑它的时间进度的方式和最终目标。
谈过几个“治病”工具之外，分享几点初创阶段的思考。
第一，合理的架构体系。CTO 应该去选择合理的架构、编码和协议组件。合理是可控，充分利用现有的资源，与知识去搭建。
第二，大局观。从需求的角度解决技术问题，不可以为了做技术而做技术。
第三，按方抓药。OKR 与 KPI 的选择一定要根据自己公司的情况来选择。
第四，集体智慧。发挥团队的集体智慧，随时交换意见。
第五，适当“造轮子”，例如我们公司内部约有八位程序员在开发提效工具，辅助公司发展。
第六，“背锅”环节最容易犯错误。WBS 的架构师曾说过这样一句话：“80% 运帷问题都源于初期的架构、设计、开发，别让运帷背锅了”。我们所有的技术都自带着锅的属性，不要让运维背锅，常常承担起技术的责任。
如果完成了上一步，恭喜来到第二关。刚过三岁的孩子们，母亲们应该关注的情况有两种——丧偶式育儿以及诈尸式育儿。
丧偶式育儿，作为技术领导，每一个技术团队都是你的孩子，CEO 是配偶角色，你遇到的困难如何跟他沟通，如何去解决问题。
诈尸式育儿，指的是 CEO 平时不管，突然来劲儿啦，什么都管，直接接管你的权利，这种情况最容易分神了。
比尔盖茨说：“科技总是短期内被高估，长期内被低估”。这句话是真理，当短期不被认可的时候，我们应该如何沟通，如何解决问题？
请善待你的合伙人。他们有些人不懂技术，做到有效沟通，好好说话挺困难。虽然不易，但是必须要去做。我给大家分享一项哈佛的研究——沟通效率漏斗模型。
如果我对你说一句话，但是你听见了，大部分能占到 60%。但是你听明白了，可能只占 40%。你认同我说的话，只占 20%。交互意见达成共识，只占 10%。
完美的沟通应该是一个闭环，它包括着接受聆听和反馈、发送的过程。下面是一个很好的沟通方式。
我找您有事，我希望得到什么样的解决方案，如果你不方便，请给我致电。那领导一般会第一时间提出解决方法和解决方案，并且告诉他。
这是标准的沟通方法，要说明特点、优势和利益点。
不同的人采用不同的沟通方式：对于自己的领导，可能是 CEO，CTO 等，最主要目的是为了获得支持。接收到的信息要简洁和准确，这是非常重要的过程；与下级的沟通最主要是获得信息，因为你不是所有的事都知道。要做到共同决策，明确你的授权；同级同事之间的沟通因为本位利益的考虑，常常会具备攻击性，这可是大忌，一定要出于善意沟通，减少内耗。
紧接着就是做出决策的过程，因为我不能详细地描述，所以给大家介绍一下这些书。
做出决策会有大约有四个过程，面临选择，分析选项，做出选择，接受结果，这分别有不同的陷阱，需要大家去摸索。
升级打怪的第三级， CTO 的技术团队如果不是自己培养起来的，你可能是空降兵，这是一个再婚的过程。空降的情况是非常复杂的。
我的经验是首先问自己三个问题：
我能干什么？老板期望干什么？原来的问题是什么？
这三个问题，如果能回答，其他的问题都是简单的。空降 CTO 应该对原始团队给予充分的尊重，快速识别核心人员，制定有效的绩效计划，同时空降要有老大的意识，要能抗雷。
最后分享一个小故事：
二战的时候，英军在统计飞机的时候，用了一个统计方法就是统计弹痕，得出一个结论就是飞机机翼最容易受到子弹的攻击，所以他们花了大量的成本去加固机翼，其实驾驶舱被击中的飞机根本就没有飞出来，所以这个解决方案先天就是错误的。
在空降的过程当中，大家一定要非常警惕幸存者偏差。留下的人员，留下的业务未必是适合公司的，未必是最好的，可能只是适应了这样的公司。
最后空降很复杂，要真的管不好，再生一个吧，这是最终极的解决方案。虽然说很残忍，但是确确实实是在很多场景之下的唯一解。
最终的总结是希望团队技术看成孩子一样养育，把合作伙伴作为伴侣一样看待，同时也希望对待家庭和工作一样的耐心。
我今天的分享就到这儿，谢谢大家。