【读书笔记】朱赟的技术管理课阅读笔记

技术管理

1.引导

1.给答案与引导的时机

2.如何引导

2.事故的处理

1.追责非惩罚->善后与反思

2.事故的根因分析

3.事故中良性关系的建立

4.如何再错误中成长

• 1.错误的构成

  • 1.伸展错误-再主动探索中的犯错，容易成长
  • 2.无知错误-主观上未意识到会犯错，忘记等原因导致，通常新人易犯，不会重复犯，但要注意不在不同类型任务上犯同一类型错误
  • 3.粗心错误，容易一犯再犯
  • 4.高风险错误，类似于伸展错误，是主动探索中犯的错，容易再犯

• 2.错误的收益，12类错误容易成长，3，4类收益很小

• 3.错误的规避

  • 1.伸展错误，依赖于培训机制
  • 2.无知错误，依赖于信息透明与共享
  • 3.无知错误，需要有一定的复盘机制
  • 4.高风险错误，在做决定时可以增加备用方案

3.AB测试的原理

1.测试方法的确定

• 1.最终指标？单次指标？识别率？捕获率？
• 1.不同人员的意见，产品经理，开发的，测试的意见

2.注意AB实验数据的分配

3.问题分析的维度

4.其他组改动对AB测试的产生的影响

5.AB测试结果趋势是收敛的，而不是发散的

• 1.月度版本的指标应该是收敛点
• 2.测试环境应该是稳定时间的
• 3.可以关注极端条件下的指标是否正常

6.数据埋点与采集-即需要关注的数据

• 1.性能数据是否异常
• 2.多拍数据是否异常等

7.AB测试形成流程与工具

• 1.可以简单对应为仿真测试的指标数据
• 2.外场测试的指标数据
• 3.形成工具和流程，事半功倍
• 4.让数据埋点和采集形成工具

8.每个测试结果需要合理解释

• 1.对结果进行预期
• 2.结果即使高于预期也需要进行解释

9.必要时需要重新设计AB实验

• 1.关键版本迭代时数据埋点和采集可能需要重新设计

10.对不同平台需要分开测试

• 1.警惕前端结果可以直接在后端使用的思想
• 2.警惕不同平台效果会一致，无需测试的思想

4.如何帮助团队成员迅速成长

1.能力的提升，包括指导，反馈，反馈，交流，协调资源

2.明确的分解与布置任务

• 1.需求边界的制定-需要做什么和怎么做
• 2.计划的制定
• 3.人员的确定与授权

3.建立有效的合作关系

• 1.对于团队成员不要陷入静态的思维评价，定期更新评价和交流
• 2.站在团队成员的角度，交流和分析如何提高他的能力
• 3.评估团队成员时，把内心想法写出来，与之前的想法做对比，是否需要改变

4.团队需要的几大能力，及能力等级

5.提意见与接受意见

1.接受意见假定对方的善意出发，确定对方出发点以及希望我们改进的地方

6.幂等

幂等：一个操作多次执行与一次执行的影响相同；在工作中如何通过做好所有的细节来实现任务的幂等？—关键节点的细节

7.一对一沟通

1.频次，主题

2.沟通主题-1.话题讨论-以沟通对象的意愿为主 2.工作相关-技术业务人事 3.创意想法相关

3.沟通杠杆原理：三十分钟的沟通可以提升1-2周的工作品质？

4.沟通需要有效

• 1.场所安静，安全
• 2.专注
• 3.眼神交流
• 4.无批判性反馈
• 5.沟通内容的交流-形成交流效果
• 6.内容保密

8.大数据时代的算法

9.管理与被管理

1.期望值的管理

2.期望值的跟踪与反馈技巧

10.项目延期

1.项目管理中的流程

2.项目过程中的任务优先级

3.项目状态共享表

4.项目状态更新知会道所有相关人

5.项目状态问题的反馈渠道搭建

11.如何进行工作任务分配

1.建立能力参考基线

2.对任务会提出什么样的问题；对于参考意见的反馈

3.工期估算-时间1

12.根据组员的选择进行任务分配

1.愿意与家庭待在一块的，分配稳定业务的迭代和改进。

2.愿意全身心投入的，分配挑战项目

3.愿意尝试不同技术的，分配预研和前瞻性任务

4.尽量做到双方期望保持一致

13.业务拆分

1.业务简单时，单一业务框架效率较高；业务复杂到一定程度后，进行业务拆分才能提高效率

2.三个进行业务是否需要拆分的判定

• 1.业务量是否足够达，是否复杂到一定需要拆分，水平扩展是否已不起作用，代码互相影响，部署时间长是否已是切肤之痛
• 2.开发的水平和经验是否充足，是否不会让拆分后的测试，修改，变动成为拦路虎
• 3.拆分过程几乎不可逆，分容易，再合一则相当复杂，需要谨慎

14.项目管理中的任务分配技巧

1.任务的细分重组

• 1.考虑因素

  • 1.先评估能力，再分配任务，能力与任务难度匹配
  • 2.每个人完成任务所需时间尽量平等，达到负载平衡
  • 3.每个人的任务里，有意思的或与脏活累活比例相当
  • 4.每个人的任务里，需要有一部分有挑战的内容，也不能太难以至于望而生畏
  • 5.任务之间如果有依赖性，在分配时就要合理分配
  • 6.让每个人的任务里有一条主线，完成完整的开发，进而形成就感

2.工期估算

• 1.双方要就工期达成一致，截至日期是最好的效率工具
• 2.日期的估算最好参考技术领导给出的意见
• 3.最好能预留出缓冲时间，考虑到测试，上线等工作

3.实时跟踪，并准备好B计划

• 1.通过在细分重组中把工作分成小块，在完成过程中设立各种里程碑，既要有大里程碑，也要有1~2周的小里程碑，通过里程碑来跟进项目的进度
• 2.出现延迟时，管理人与责任人一同分析原因，确定是否能赶上进度；影响较大则需要启动B计划；例如，调换执行人员，提供额外资源，分析执行方法，调用其他组支援，甚至重新考虑项目进度。

15.管理的颗粒度问题

1.颗粒度因人而异

• 1.简单例子，对于刚毕业的新人，需要有经验的人去带，才能获得最快的成长速度；对于工作多年的工程师，则只需要给出指导性的建议合准则即可

2.颗粒度因事而异

• 1.对于紧急项目，在“怎么做”方面没有太多的发挥余地，需要更多的介入，但在接入之前，需要让对方理解为什么需要频繁沟通。
• 2.对于不在关键时间线上的任务，可以放手让组员尝试独立完成，给予试错和创新的机会
• 3.如果整个项目时间都特别紧，则需要思考，如何规划整个项目时间和人员的安排，尽可能的创造一个让组员发挥的空间；如果什么都不能放手，即打消员工积极性，个人的精力和时间也会受限，进而会进入无法扩展的工作轨道。

3.跟进的粒度

• 1.在完全放手和事事推进中找到平衡

• 2.参照因人因事而异的原则，做到几点

  • 1.制定目标，确保传达
  • 2.多给指导，少亲手做
  • 3.设定频率，保持跟进
  • 4.交流难点(阻塞点)，给出建议

4.交流的重要性

• 1.交流时需要明确哪些是需求，哪些是建议；要求是没有回旋余地的，建议是有空间的，对方可以思考后自己决定怎么做；

16.职场规划

1.个人价值观：什么情景或状态会让你有幸福感或者自信心。更在意哪一点？独立解决问题的能力/挑战别人做不到的事/受欢迎的程度/更在意自由的，健康的家庭生活。

2.长期愿景是什么，五年/十年后希望自己成为什么的样的人？

3. 为了达到目标，还需要哪些技能或经验？短期内发展什么技能能让你走的更远？为了在职场上获得成功，还需要哪些必备的技术技能？哪些技能不是必须的，但又很大的好处？

4.自己的优势和常熟是什么？是合作性、独立思考、快速行动，还是良好的产品思维。目前的工作能否让你展现长度，又是如何展示的？

【5】、思考以上四个问题后，需要思考，你需要获得领导者什么样的支持？exp:一个证明自己的项目/一个能带自己的老员工/更多练手的机会/专注培养自己的某一项技能/接触更多业务或框架相关的讨论/参加一个系统的培训

【6】、做职场规划的四个步骤。

• 1.知道自己要什么，知道自己和理想中的差距在哪里
• 2.和领导者沟通，得到一些有前提的或者回馈的支持与帮助
• 3. 设定目标，制定一个自己和领导都同意的计划和期限，确保计划会让自己和目标更接近
• 4. 让计划可追踪和可执行，根据执行情况完善不合理的地方持续改进。

17.如何激发团队责任心

18.既有产品思维，又有数据思维的工程师

19.如何做Code_review

1.review除了保障质量外，另一个是帮助别人成长而不是帮助他写代码

• 1.从对方写的代码，如果不好，需要找到原因，是对业务部熟悉，对编程语言不熟悉，还是对公司代码的整理架构部熟悉。找到原因才能持续进步

2.代码Review前需要理清这段代码的目的，针对性审核

• 1.Bug修复，结合Bug单看
• 2.代码优化
• 3.系统迁移
• 4.新系统或新功能，对照设计文档看

3.代码的提交注意事项

• 1.单次提交的目的性要单一，除非极为明显的错误，规范修改和功能修改不要合一

4.审核的关注点

• 1.代码格式
• 2.代码可读性
• 3.业务边界和逻辑死角
• 4.错误处理
• 5.测试用例覆盖到所有的功能路径
• 6.代码质量和规范
• 7.代码架构 文件组织方式等

20.技术人需要注意的几个点

1.公司层面的事都不是小事

2.人事变动的宣布一定要谨慎

3.技术活业务问题，不确定就千万不要给答案

4.技术错误可能导致产品的错误决定

21.弹性机制

1.对负面情绪的处理

2.积极向上

22.说不-守住技术底线，如何艺术的说不