周末两天参加了来自澳洲和北京同事关于Tech Leader的培训,实在是干货满满。简单总结下key points以及一些思考。
Logistics(后勤)
- WIFI: name & pass
- Photos? 询问是否可以拍照
- Timing: 培训开始前说明此次培训的时间
- Breaks: 培训过程中休息规则
- Amenities: 介绍培训中用到的一些辅助工具,比如笔啊stickers啊
..............
这是培训的第一页PPT,之所以要highlight是因为之前参与的培训几乎都没有涉及到。很专业也很方便,尤其适用于一些对外的培训。
TL 是什么?
这个模型图可以很清楚的说明Tech Leader应该具备哪些技能,从一个Tech Developer转换为Tech Leader的时候一定都会特别关注图中Developer的部分。还需要关注Architect以及多加练习Leadership部分。这张图源自https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/ 文中有详细解释。
A SIMPLE TEST FOR AN EFFECTIVE TECH LEAD...
Answer: Does the codebase look like it was written by a single person.
个人认为这一点是很难做到的。我能想到的可以帮助提升的做法有:
- 每个commit 提PR, 至少有一个人review PR才能merge。
- 定期(最好每天)做code review。
TL应该focus on?
1. Programming
主要想highlight下和Programming相关的Team Culture。有几个问题值得一直注意:
- How long does the build stay broken?
- Do people offer new ideas?
- Do people feel okay to admit being wrong?
- Do people flag when they need help?
- Do people avoid conflict?
2. People
简单说就是能力越强越应该被assign一些更有挑战的工作。
3.Process
简单说就是对于新人的指导从右至左依次是
Directing直接指导->Coaching教->Supporting支持->Delegateing委托
C4 Model - 可视化架构设计
1.系统上下文图
2.容器图
3.组件图
4.代码图
墙裂推荐仝老师对于C4的详细介绍 以及 引申阅读。
我自己在概念不清时画的图完全不知道属于哪个level,需要多加多加练习的一个key point。
CFRs/NFRs
Cross Functional RequirementS/Non-Functional RequirementS
是指一些非功能的需求,详解介绍
个人认为作为TL对于这些非功能需求一大难点是如何和非技术尤其是PM或者PO说明利用non-tech business language 阐述清楚什么是NFRs。
另一点是如何让全部Developer而不是只有TL自己理解并且尽早识别NFRs。
PATH TO PRODUCTION
两个很有用的工具/方法:
1.Architecture Decision Record
将每一次大的architecture的调整以文档形式记录,是一个好的记录以及追踪变化的方式。
2.ReleaseProcessValueStream
从release 的角度出发,按照Process, People, Tools, Artefacts几个角度将release 过程进行拆分,可以更加清晰的发现问题以及哪里需要改进。
Risk Management
Today's problem comes from yesterday's risks.
Yesterday's problem is today's risks.
what can we do about the risks?
1.Avoid(避免): Simply avoid the activity associated with the risk.
2.Contain(保留): Setting aside time/resource to pay for risks if it occurs
3.Mitigate(缓和): Take steps now to reduce containment costs and establish early warning indicators.
4.Evade(逃避): Do nothing.
四种方式取决于不同场景。
Tech Debt Wall
Influencing
有助于将stakeholders 按照接触频率,影响力进行识别。
有助于改善识别后的问题。