02.如何做好接口人

目录介绍

• 01.为什么要有owner
• 02.开发owner的职责
• 03.owner目标的沟通
• 04.给技术员工做考核
• 05.组织技术周会总结
• 06.周会十分钟的分享
• 07.问题处理模版说明
• 08.如何去做好接口人

01.为什么要有owner

• 为什么需要owner
  • 因为服务之间的依赖，为了实现同⼀个产品需求，往往需要跨团队多服务联合升级，这时候，就需要有⼀个开发owner作为项⽬的研发负责⼈。
  • 所以该⽂档主要针对多服务联合升级的需求，制定owner相关机制。⾄于服务单独升级就能满⾜的需求，谁开发谁owner，谁对整个需求负责。
• 什么项⽬要有owner
  • 跨2个及以上团队的项⽬，必须有开发owner，没有开发owner，项⽬不能启动
  • 什么时间确认开发owner？最晚要在需求详细评审完成时，明确开发owner。
• 怎么确定owner
  • ⼤原则上（主要从上⾄下原则）
  • 项⽬中需要对接最多⽅的团队的主要开发⼈员或者负责⼈
  • 改动点最多的团队的主要开发⼈员或者负责⼈真实参与项⽬的⼈
  • ⾃愿原则

02.开发owner的职责

• 需求评审
  • 1、叫⻬需求涉及的所有开发团队，包括对应qa，参与需求评审
  • 2、评审需求内容，关注需求合理性、与其他系统的关联性、现有能⼒能否满⾜该需求
  • 3、对于需求评审过程中，需求wiki没有说清楚的地⽅，线下沟通明确给出结论，保证沟通结论及时更新wiki，并周知到所有项⽬参与者
  • 4、明确排期，遵循能提前尽可能提前的原则，排期各服务的开发周期、提测时间、联调时间、准出时间、线上回归时间
• 技术⽅案设计评审
  • 1、评估项⽬影响⾯，拉起技术⽅案评审，叫⻬需求涉及的所有开发团队及对应qa，讨论并确定技术⽅案，做到接⼝定义清晰、使⽤⽅法明确
  • 2、保证技术⽅案兼容性、⽆漏洞，具备可测性，
  • 3、需求实验⽅案，明确需求是否需要进⾏实验，如果需要，明确实验流量控制⽅案
  • 4、监控报警，规划必要的监控报警以保证严重线上问题能及时发现
  • 5、明确上线⽅案、回滚⽅案、上线时间点
  • 6、明确是否需要发起代码cr
• case评审
  • 1、case评审环节，保证case设计完整、预期正确
  • 2、明确各模块准⼊case、研发联调case
  • 3、对于⼤型项⽬，特别是需要跟第三⽅交互的项⽬，审核线下测试⽅案（包括环境问题如何解决、联调场景构造）、线上回归⽅案
• 开发实践
  • 1、定期review开发进展，对于⼤型项⽬，如果有必要，每天站会同步进展和⻛险
  • 2、按照既定排期，推进开发并组织联调
  • 3、守住提测时间，如果出现提测延期，周知各⽅delay原因、新的提测时间、delay⻛险，重新review后续的 时间节点进⾏必要调整
• 测试阶段
  • 1、跟进测试进度，把控测试完成的⻛险
  • 2、重点关注严重问题、阻塞性问题是否及时解决，
• 上线阶段
  • 1、按照技术评审制定的上线⽅案，执⾏上线过程
  • 2、关注pre回归、线上回归进度
  • 3、pre回归、线上回归过程中出现问题，严格执⾏回滚⽅案或者关闭功能开关
  • 4、线上回归发现问题情况下，制定修复⽅案、推动及时修复、问题验证和回归影响⾯评估，
  • 5、上线开流量后，观察2-3天
• owner失责的判定
  • ⽆失 没有明显的失职之处职
  • ⼀般 对标《开发owner的职责》部分，有失职 <= 3 项以内职责没有做到位
  • 严重 对标《开发owner的职责》部分，有失职 > 3项职责没有做到位

03.owner目标的沟通

• 目标沟通事项
  • 目标沟通：请在填写目标前，确认已经与上级充分沟通目标传递，公开透明，形成共识，共同制定高质量目标。
  • 目标数量：以3-5条为宜，具体数量请与上级沟通确定。
• 目标制定原则：“SMART”原则
  • Specific-明确具体：目标明确不笼统
  • Measurable-可衡量：目标达成情况可衡量
  • Attainable-可行性及挑战性：注意和历史数据、竞品数据、业界水平对比
  • Relevant-相关性：与本职工作相关
  • Time-bound-时间性：注重目标完成的时间
• 优秀目标的特征：
  • 目标名称：不要仅填写项目名称或动作，如“xx项目”、“xx产品上线”，建议目标可以凸显所做事情背后的价值，并尽量鼓舞人心，有一定挑战性。
  • 关键结果：能量化的关键结果尽量量化，不能量化的尽量具体化，如明确截止时间及输出结果。
• 优秀目标举例：
  • 目标1：保障新项目(Padlet项目)高效交付，服务稳定运行
  • 衡量标准1：技术方案规范化，验证后沉淀成模板，推广到其它项目使用
  • 衡量标准2：转测、发布checklist规范化，验证后沉淀成模板
  • 衡量标准3：通过完善日志监控、保障专项，确保项目可控、服务稳定运行
  • 衡量标准4：前后端各自锻炼出一位熟练掌握研发全流程，能独立owner项目的业务骨干
  • 目标2：xxxx产品需求开发，保证符合产品预期与稳定
  • 衡量标准1：Owner整个xxx产品研发技术方案设计，研发质量、风险管理和技术问题解决保障系统稳定性与可靠性
  • 衡量标准2：从0到1搭建解决方案中心，完成解决方案中心产品需求开发V1.0和V11等版本发布与使用
  • 衡量标准3：2月底完成学情报告为展示内容的智脑管理平台的全流程串通，包括与指标平台开放平台的打通
  • 衡量标准4：3-4月份实现与其他平台能力打通，如认知计算中心，并完善方案能力运营数据统计

04.给技术员工做考核

• 考核的目的是什么呢？我能想到的考核目的有3个：
  • 让付出和回报尽可能公平。
  • 打造高绩效团队，淘汰那些不合格的员工。
  • 确保员工的个人目标与企业目标相一致，并能通过绩效考核机制激励员工完成个人目标。
  • 这3个目的看起来都比较虚，因为无法量化，无法量化就没办法考核，所以公司想要考核员工，首先得量化考核指标。
• 企业常用的工具就是目标管理
  • 所谓的目标管理就是把公司的总体目标，自上而下的分解为每个员工的个人目标。
  • 我们经常听到的KPI（关键绩效指标）和OKR（目标与关键成果）其实本质都是目标管理工具。
  • 只是KPI更注重结果，而OKR更侧重达成目标的途径，所谓的O更像是一个方向上的指引。
• 量化能力模型
  • 把个人能力分两个维度：通用能力维度、专业能力维度。
  • 通用能力分为：沟通能力、解决问题能力、执行力、工作态度四个关键能力。

05.组织技术周会总结

• 周会的目的
  • 周会作为每周例行的会议，为技术方向的所有同学提供了项目同步、问题反馈、分享交流的平台，重要性不言而喻。
  • 目前通过轮流主持的方式，让每个同学都能参与进来，随着团队规模的变大，需要一套统一的规范来保证周会流程的效率、质量和效果。
• 整体职责
  • 主持方式：按照工位顺序，轮流执行
  • 工作范围：预定会议室、创建周报模板、提醒周报更新、提前确认会议内容、主持会议、分享跟进、周报内容维护、TODO记录与跟进等
  • 下面会按照时间轴的顺序，给出团队内的周会规范的具体细节。
• 周会前准备
  • 预定会议室：请在每周一早上10点预定本周四下午的会议室，优先选取下午4-6点，4点的没有再订别的时段。若都没有抢到，可与其他团队同学协商调换，会议室确认后，一定要提前发出会邀
  • 创建周报模板：请在每周四中午12点前完成本周周报模板的创建，方便下午陆续更新周报
  • 提醒周报更新/上周TODO：请根据周会具体时间，提前2h提醒大家更新周报，并将上周TODO发到群中做提醒
  • 提前确认会议内容/时间：常规的周会内容不用单独说明，但需要提前确认本周是否有技术分享等内容，合理安排好会议时间，合理周会时间为0.5h-1h。
  • 提前更新分享物料，如果有分享内容，需提前将分享内容发到群里，并托管到相应渠道：
  • 10分钟小分享：上传wiki，十分钟分享计划
  • 常规大分享：但wiki对文件大小上传有限制
  • 系列技术培训：请托管在该系列统一的技术文档下，或者写到同一个分享目录下面，例如统一的Kotlin培训、Flutter培训
• 周会中记录
  • TODO跟进：请在常规会议内容开始前，先过一遍上周周会的TODO
  • 主持会议：常规的周会内容需要区分好优先级和顺序，例如常规的性能部分，只需关注异常指标，不用面面俱到，对于线上问题部分，需要着重说明
  • TODO记录：请把本次周会所有的TODO项，及时更新在本周周会wiki的评论区中，便于下次跟进
  • 下一位主持人提醒：周会结束前，需要提醒一下下一位主持人，提前预定会议室
  • 下一位分享嘉宾提醒：周会结束前，需要确认一下下次是否有分享&分享内容
• 周会后总结
  • 再次确认分享物料是否已托管到上述管理渠道
  • 检查周报完整度：最晚在周会结束后，每位同学都需要及时更新个人周报部分，对于未更新的同学做出提醒，项目进展部分一般在周会中会涉及到，不会遗漏。

06.周会十分钟的分享

• 背景说明
  • 为了周会的内容更加有意义，我们减少受众较小的业务同步，增加更多有意义的内容同步，所以我们增加了趣味十分钟分享计划。
• 发现问题
  • 在晋升答辩中，我们发现有几个问题。
  • 自己所做的事情原因理解不够深刻
  • 沟通表述中条理性有提升空间，对讲述的内容需要有提炼能力
  • 对技术有较多的了解，但对业务的信息输入不足
  • 团队需要更多的机会增加交流和碰撞
• 改善计划
  • 基于此我们希望大家通过简短的10min中，把一件事情的Why、What、How完整讲清楚。
  • 分享者在这个过程中提升对事情的深入理解力和表达能力，听众也能获取信息的输入并且相互讨论交流，双向受益。
  • 所以从分享中希望大家有以下收获：
  • 团队增加了交流机会；对产品、技术有更多的了解；提升个人的知识提炼和沟通能力
• 十分钟分享什么
  • 内容是没有限制的，希望是多样化的，可以是某个版本的一个业务需求、最新出现的新技术简介、某一个数据指标的含义等。
• 分享形式
  • 周会中10min的分享，包含7分钟的讲解和3分钟的QA环节。可以使用PPT或者Wiki，但需要足够精炼，PPT不超过5页。
• 话题池
  • 业务概念介绍；业务流程串联演示；端迭代流程；业务指标介绍；技术框架介绍；解决问题思路等等，只要你觉得可分享内容都可以。

07.问题处理模版说明

• 问题背景说明
  • 出现这个问题的背景是什么，简单描述下业务场景。对问题归类：业务问题，产品问题，UI问题等。
• 问题核心信息
  • 阐述发现该bug的核心信息，比如那个用户反馈，问题是什么，什么时间段发生。
  • 如果有可能，麻烦提供用户手机号信息，方便查询其日志。
  • 告知用户上报日志，目前日志回捞是用户主动触发。如果有截图或者录屏，那更好。
• 提出问题模版，问题描述模版如下
  • 问题的背景：简单描述一下发生问题的背景
  • 问题是否必现：1(必现)；2(非必须)
  • 问题所在版本：App版本是多少
  • 问题复现步骤：简单描述一下出现该问题的步骤
  • 问题场景说明：1(刷卡)；2(扫码)；或者其他
  • 问题出现的时间点：描述一下出现问题的时间点
• 认真对待每个反馈
  • 群里问题反馈，准确表达问题，减小沟通成本。
  • 技术接到反馈，12小时内回复。对问题归类，分配，这个可以由一个童鞋分配
  • 排查和解决问题，利用5why分析法，追查到问题根本原因，先止损后修复。给出最终解决方案！

08.如何去做好接口人

8.1 接⼝⼈定义说明

• 负责⼀个业务⼦⽅向，作为业务团队和外界沟通衔接的桥梁。
• 对内：需要带领⼩组完成业务需求⽀撑、项⽬管理、问题发掘和技术⽅案落地⼯作
• 对外：以团队视⻆进⾏沟通协调、解决问题，并将信息传递给组内同学

8.2 接⼝⼈⼯作说明

• 接口人工作，针对天
  • 关注线上问题、把脉、项⽬⻛险情况
  • 对接产品、设计、QA、外部部⻔等团队的问题咨询
  • 参与需求评审，和产品⼀起讨论，给出合理解决⽅案
  • 团队问题收集、跟进、对外反馈
• 接口人工作，针对周和月
  • 负责版本迭代和项⽬管理的全流程，确保项⽬按时⾼质量交付
  • 架构和技术⽅案的调研、制定和实时落地
  • 团队建设，包括成员指导、流程完善、⾯试等
  • 每个⽉回顾做的事情，根据团队DDO制定下个⽉规划，保证⽬标达成
  • 发现问题主动承担推进，不设边界，补位意识

8.3 接口人能⼒模型分

• 能力模型划分：专业能⼒（40%）；项⽬管理（15%）；沟通协调（7.5%）；业务理解（15%）；团队规划（15%）；成员指导（7.5%）
• 专业能⼒：架构能⼒；⼯程化能⼒；稳定性建设；全栈能⼒；能够独⽴负责⼦系统（业务复杂度）
• 项⽬管理：流程问题发现优化；关键点把控；⻛险识别；问题推进；Owner意识；资源预估和协调
• 协调沟通：解决问题，不拆台；不制造⽭盾；充分协调外部/内部资源，合理上升；主动获取信息和主动传递，建⽴良好
• 业务理解：接需求，有⾃⼰理解；业务数据理解；业务未来规划理解；横线业务关注；分享业务信息
• 团队规划：⽉度级别资源规划；季度级别资源规划；技术规划⽀撑业务；分⼯合理，针对不同同学的发展有中期的计划
• 团队指导：⽇常项⽬、技术指导；指导新⼈；辅导他⼈；沉淀⽅法论；团结团队，凝聚⼒

8.4 接口人能力模型画像

• 能策划、推进⼀个⼦系统⽅向，如Android客户端开发一个独立模块设备管理(设备绑定，解绑，设备查看，设备内容页，音视频播放等子模块)
• 业务理解，能够对于产品的需求有理解，能提出改进意⻅，不是被动接需求；
• 专业上，能给出⼦系统的合理架构⽅案、核⼼难点攻关，良好的⽀撑业务，组内有技术影响⼒，⽐如App通用视频播放器、H5混合开发容器；
• 承担项⽬管理⼯作，建⽴项⽬流程，识别出⻛险并机制推动各⽅解决，及时补位，保证项⽬顺利交付，如版本⽕⻋、流程建设；
• 能结合团队⽬标和⼦系统业务⽬标，制定短期规划，并保证规划落地，如⼀个季度的规划；
• 团结组内同学，指导新同学融⼊团队、传递已有的流程和⽂化，能够给出技术专业性的指导；_