工程师的职责与困惑

• 在成长的各个阶段，需要承担什么角色
  • 解题专家
  • 新人的导师
  • 业务的规划师
• 普遍的困惑—团队没有因我而不同
  • 没有明确的项目任务，不知道该干什么
  • 各种资源的限制，问题解决不了
  • 技术规划无法被认可，无法落地

规划篇-人事合一

短期

• 目标
  • 快速赶超，无暇顾及团队成长
• 手段
  • 不限
• 职责
  • 亲自上线做事，至少也要做好后援

中期

• 目标
  • 更加系统化的解决问题，兼顾团队成长
• 手段
  • 技术合理性触发
• 职责
  • 充分论证，静心打磨坑（人和topic）的数量合质量

长期

• 目标
  • 技术水平稳居行业前列，构建强大的技术梯队
• 手段
  • 跟踪前沿技术进展及其落地可能性
• 职责
  • 向上向下的呈现，工程化前期的实验和对应资源的储备

业务布局对团队管理的极端重要性

• 布局：先事，后人
  • 先事（挖坑）
    • 要有很清晰的短期目标（最好能和产品体验挂钩）
    • 要有相对清晰的长线目标
  • 后人（填坑）
    • 入门的新人，事情要细，checklist要多，要看过程
    • 上手后的人，事情要粗，多放手，看结果
  • 留有余地的业务划分
    • 前沿探索
    • 效率提升
• 布局 不等于 派活
  • 切忌团队目标明显冲突（资源 or 性能）
  • 切忌团队职责灰色地带（架构 or 策略）
  • 单个任务，无论大小，都要有是否做得好的量化标准
  • 一个问题，如果leader没有任何idea，交给新人就是不负责任

设计可控的复杂系统

• Why
  • 可理解的系统实现
  • 可预期的用户体验
  • 可管理的技术团队
• How | 可控系统设计要点
  • 分场景，分环节，独立评估，无损传参
    • 每个环节职责明确，优化目标也要明确，因此都需要有各自的评估手段
    • 每个环节都需要有独立的容错考量，而不是有输入就非要有输出
    • 上游的输出最好是概率分布，而不是一个定值
  • 监控常态化
    • 指标越多越好，宁可误报，不可漏报
    • 每日用海量的case来自动化回归效果
    • 反复琢磨如何通过用户行为来自动化监控效果
  • 更多tips
    • AI是手段而不是目标，扩展：技术是手段而不是目标
    • 努力复用现有资源，不轻易造轮子和重构
    • 机器所给出的每一条结果，都要有置信度
    • 对于人类公识的常识，系统中要有兜底
    • 系统一旦出现问题，要能在监控指标体现，而不是等着用户报bug
    • 兄弟团队的优化目标，要形成合理，而不是相互打架
    • 不要惧怕复杂，完美系统的底层实现一定很复杂，关键是怎么分层抽象表达

为何我提出的宏伟蓝图无人支持

• 自下而上的论证，自上而下的推动
• 团队对现在的当务之急的认知和你是否一致
• 规划需要说明白解决业务问题的量化预期
• 越超前的事情，能想明白的人越少，越要主动推动
• 先做好小事，才能得到更多的兵

解题篇-唯快不破

先做正确的事

• 短期救火，从实际case入手，反向归纳关键问题
• 相信一线同学对短期优先级的「群体性判断」
• 简历广泛认可的全局评价体系，让各topic的top问题重要性「可比」
• 中长期逐步转化为技术合理性驱动

快速对现状认知

• 基于尝试构建对系统的假想，想好需要进一步核实的关键点
• 基于大量观察（case）构建假想与现实的矛盾
• 先针对核心认知矛盾进行突破（读代码，做调研），而非事无巨细的学习

解决问题

• 确定性高德技术方案，才能得到广泛支持
• 广泛调研同行手段，复用现有资源
• 大部分时候没有捷径和大招，细化才是王道
• 缺人的时候，leader要自己上，而不是等着加人
• 始终把自己的作用最大化，步入正规后，及时撤出精力
• 找到团队可以顶替自己位置的人，自己做大的事情

辩证看待定量的分析

• 因为不够定量带来的低效决策
  • 两个方案各有利弊，究竟选那个
  • 观察到部分异常，是普遍的还是个例的
  • 影响整体用户体验因素太多，需要能精确的估计各自的影响
• 兼顾效率合效果地产出量化的结论
  • 让ab test来说明问题
  • 善用间接推理
  • 切忌单线顺序推理，尽量要交叉验证
  • 不迷信大数据，多个独立小数据得出结论一致，很可能结论就是对的

导师篇

慧眼识才

• 招聘有潜力的人
  • 激情：爱不爱这个事？
  • 技能：有没有能力做这个事？
  • 经验：做没做过这个事？
    • 更多的细节
  • 业余喜欢做什么
  • 是否出淤泥而不染
  • 表达时的条理性
  • 是否注重细节的准确性

怎么长期留住人（升了一级，该干些什么新的事情）

• 广度
  • 正向路径：模块级，子系统级，产品线级，公司级
  • 能力要求：知识渊博，善于找问题，善于沟通
  • 逆向思考：说出整个产品中你认为最差的业务模块，你能不能上阵？
• 深度
  • 正向路径：满足要求，国内领先，引领世界
  • 能力要求：能聚焦，有耐心，攻坚能力强
  • 逆向思考：给出你做的东西天下第一的依据，如果不是，差在哪里？需要什么资源？

带头营造技术氛围 | 好的技术团队是什么样的

• 极度注重代码质量
• 遇到矛盾追根问底
• 自建工具提升效率
• 普遍可以相互补位

导致需要精通业务 | 不是真正的内行，指导是肤浅的

• 新老文献，每日阅读
• 行业动态，了如指掌
• 向上汇报，独立上阵
• 问及规划，信口道来

一线指导，高效纠错

• 第一步，快速发现疑似错误
• 第二步，纠正新人的错误
  • 明确标准：建立对结果好还是坏的工人量化标准
  • 厚积薄发：请新人充分阅读经典文献、文档、书籍、代码等资料
  • 文档阅读或Code Review：从根源证明设计的不合理性
  • 返例枚举：找出大量特定场景的bad case，证明新人的方案考虑欠妥
  • 亲自上阵：导师实现更好方案，AB测试证明信任方案效果不好
  • 将错就错：照新人说的做，限时快速实现主干，以自评收益欠佳证明这么做不ok

指导中信任关系的建立

• 倾听
  对方的困惑点是技术，还是事，还是团队
• 亲自示范
  • 不能只说你是错的，还要告诉他那里不对
  • 不仅要告诉他那里不对，还要告诉他什么是对的
  • 不仅要告诉他什么是对的，还要告诉他为什么这么做是对的
• 深度利益捆绑
  • 说我们，而不是你们
  • 替对方背书
  • 你的KPI就是我的KPI

以身作则，共同提升软素质

• 不忘初心
  • 当接到需求，冷静思考，这是不是为了用户体验的体验提升？
  • 当各种新技术，新理念袭来时，冷静思考，对业务究竟有没有价值
• 量化理念
  • 当大量负面case出现，如何判定主流体验究竟是好的还是不- 好的
  • 与其他角色陷入争论时，想想究竟有没有站在同一个量化标准上看待同一件事物？
• 极致探索
  • 问题是偶发的，那么从根本上，是什么因素导致偶发？
  • 对于单线正向推导出的结论，有没有习惯性的怀疑，并且想方设法交叉验证？
• 积极主动
  • 遇到灰色地带的需求，推还是接？
  • 走出部门，放眼世界，主动出击，合作共赢

知行合一，用好高阶影响力 | 关键时刻，榜样的作用超出想象

• 绝不将『做不到，人力不够』作为口头禅，对不确定性保持乐观
• 多讨论业务，少评论人以及各种「圈内八卦」
• 对不熟悉的领域，不要想当然做跨界的技术判断
• 不形式化的challenge，多提实质性建议
• 公开的鼓励和认同
• 主动承认并纠正判断，计划和规则的错误

总结

与业务和团队共同成长

• 中短线团队需求驱动，长线技术趋势驱动
• 长时间一线工作是精准技术判断力的保证
• 抱有共赢心态，人事合一
• 用好你的影响力，批量复制出优秀的团队
• 正能量来源于热爱，找到爱做的事情，才会无怨无悔的付出