关于读书:读书笔记-朱赟的技术管理课

读书给我力量，有些书籍给你第一眼的感觉就是：爱了；第二眼的感觉就是：买了；第三眼的感觉就是：读完了、难受了。

本文为《朱赟的技术管理课》读书笔记。

jsliang 没当过管理者，所以文中相干心得，皆为集体粗俗见解，不形成价值参考，也不形成购买倡议。

一 目录

不折腾的前端，和咸鱼有什么区别

二 前言

人总要成长，总要走出本人的舒服区，变幻无穷的前端行业尤其适宜这句话，除非你确定将来日子能当一枚千篇一律的复制粘贴工程师，否则你就要面临各式各样的挑战。

摘抄下 jsliang 的工作笔记目录：

• Node 常用工具库（工夫解决、Markdown 转 Word、正则表达式）
• 自动化测试（Jest、Puppeteer）
• Git
• Charles
• ……

当然技术是折腾不完的。

世事总在变动，你总要挑战本人极限，这篇文章就是讲挑战自我的其中一条路线：技术治理。

这仅仅是零散的观点汇总，贴近 jsliang“私有化”，不形成参考倡议，心愿对你有所帮忙

三 精彩语录摘抄

在观看书籍的过程中，jsliang 摘抄了一些感觉十分不错的语录：

• 《04 | 如何帮忙团队成员成长》一个技术管理者的胜利并不在于本人代码多好、能力多强，他的胜利肯定建设在团队胜利的根底之上。只有团队成员一直成长，这个团队才能够做成更大的事件，而你才能够在团队的根底上，站得更高、看得更远。
• 《05 | 当咱们给他人提意见时，要留神些什么？》所以在工作中适当放低姿态，往往更容易取得尊重。不要总是试图居高临下地提意见，尤其是你在对方心里还没有建设任何信赖和威信的时候，不要贸然给他人提负面意见。

四 新人成长

在读书的时候，如果作业不会做，你能够问同学，间接 Copy 作业；你也能够问老师，失去答案或者启发和疏导。

工作了之后也一样，你能够 Copy 代码，也能够获取疏导和启发，然而总归还是取得疏导和启发比拟好的。

4.1 新人成长：我的成长

在入职金山后，作为一枚萌新，身边的小伙伴和组长确实给了我很多启发：

• 带着计划征询下级，不做无谓的探讨

人急起来往往会将本人的心愿寄托到某个人能疾速帮忙解决问题上，jsliang 也一样，在刚入职的时候就常常将一些问题抛出来征询组长或者身边小伙伴。

尽管新人成长下间接征询问题无可非议，然而有些内容还是须要本身后行探讨，再进一步征询的。

这点我一开始就做得很差。

所以前面碰到问题，我会先通过本人思考和材料查问，选出 A、B、C 几种计划，而后带着问题和计划去征询领导和小伙伴，从而获取到有用的疏导和启发，进而批改本人的计划。

这点我也尝试在给身边小伙伴们解答时应用，当然可能有些小伙伴会感觉我不够爽快，没有给最直白的答案

这点更让我印象粗浅的是一句话：雇佣你过去是做事的，安顿你做一个需要是想让你接触这类问题的解决（这不是一个紧急的问题），咱们毕竟是一个对外服务的小组，如果有问题你都问领导，那就是领导做事了，那招你过去有何用？

• 有些流程适宜解谜，有些流程适宜解答

有些问题并不是间接给你代码就好的，例如新人进来往往不会调配比较复杂的工作，都是让你适应新流程的需要（除非是招你过去要立马上手，解决重大问题的）。

可能这个问题在相熟流程的老人身上，花几分钟工夫就能搞定，而新人须要推敲很久。

然而，如果这个问题新人不去理解全流程，不去相熟它，那么前面碰到这块内容，他还是会冲突。

4.2 新人成长：治理技巧

• 不要将工夫消耗在新人上

不能因为本人对系统各种设计和业务逻辑相熟，所以间接给答案，或者帮忙找答案。

因为这样子会导致：

1. 在你这里容易失去答案，于是问你问题的越来越多，琐事也多
2. 你给的答案，下次有问题还来找你
3. 忽然你不答复了，那么新人会怎么想

你须要做的应该是将这个技术点通过工作模式或者其余办法公布上来，让新人自行考察，而后给予提醒和启发。

• 给答案 V.S. 给线索找答案

什么时候适宜间接给答案？什么时候适宜给线索，让对方找答案？

1. 如果是对我的项目的流程相熟，我的项目的搭建，那么就适宜给答案
2. 如果是对我的项目需要的解决，问题的剖析，那么就适宜给线索

• 如何疏导

1. 如果有计划，帮忙剖析
2. 如果没计划，诱导剖析

不要太具象，也不要太形象。

例如一个需要，应该表明本人想要的内容，UI 大略长啥样，而不是让对方任意施展，而后审查后又感觉有余。亦或者让对方先给出本人的计划，审对后再开发。

• 工作弹性

工作弹性是依据具体业务需要，让本人可能有足够的解决能力

1. 让新人正确面对本人的压力

   1. 已产生的，思考和复盘
   2. 未产生的，推敲将来打算和布局，思考不足之处
   3. 前 2 点不要一根筋

2. 当有压力的时候，要学会走出思维的误区，打造本人的弹性能力

   1. 定期 Review，看下本人的改良是否有成果
   2. 不要因为不可控因素嗔怪本人，例如公司忽然加班，也不要让这个因素让本人放弃，松持有道
3. 与积极向上的人做敌人，保持良好的心态

4.3 新人成长：我的思考

• 【解答】搭建开发环境
• 【解谜】带解决计划征询问题

五 我的项目开发

在我的项目开发的过程中，咱们可能须要关注一些点：

• A/B 测试
• Code Review
• 我的项目延期
• 线上问题

5.1 我的项目开发：工作调配

团队负责人的工作职责之一就是工作的合成和受权。

在没有建设充沛信赖的状况下，该如何调配工作？

1. 建设参考基线。在和一个人没有任何接触的状况下，通过第三方评估、集体履历以及员工做过的我的项目 | 产品来掂量能力
2. 问对问题比正确答案更重要。将工作交接到员工手中前，尽量通知他当前任务的具体情景，看他有什么问题和想法
3. 工期估算。须要多久实现，大略什么时候，须要怎么样的资源
4. 执行力。有些成员可能沟通、打算能力都很强，然而执行力比拟差，会滞后、遇难而退、头重脚轻，这些成员不适宜托付小事
5. 前期保护。我的项目的完结并不是我的项目的完结，还应包含我的项目前期的 Bug 保护，跟进用户的反馈，实现产品的迭代降级等

须要留神的一些细节：

1. 职场新人。有些新人可能很有后劲，然而经验不足。所以初期不要轻易否定他们的工作，而是更急躁地领导让他们疾速提高
2. 针对不同类型的员工调配工作。不同类型的员工会给团队带来不一样的内容，有些人可能逻辑性强，有些人可能技术性强，都会带来不一样的反馈

5.2 我的项目开发：受权

研发组长可能会参加所有的设计和探讨，甚至很多外围的代码都是本人写；组里其他人的代码也会亲自过目；无论如许忙都会参加所有的代码评审，做到对每一个改变都成竹在胸。

随着业务规模的扩充，人员的增多，事事亲为会变得越来越吃力，加班变成常态，这时候就须要带人和受权，将事件调配进来让他人做。

误区：

1. 事件能不能做好和齐全依照你的形式做好，是两码事，他人有他人的工作形式，也能把事件做好。
2. 染指和非染指并不是非黑即白，用什么形式染指，在哪些地方染指，才是要害

受权和分配任务须要留神：

1. 明确指标。让对方晓得最终想要达成的后果和对工作实现的期望值。
2. 制订打算。放弃跟进很重要
3. 给出反馈。给予对方侧面的反馈很重要，给予必定。

5.3 我的项目开发：A/B 测试

如果产品须要批改 UI 上某个模块的交互设计，疏导用户点击“下一步”按钮，而后不晓得哪一种成果更佳，这时候就须要 A/B 测试。

通过 A/B 测试，让一部分用户体验新的 UI，另一部分用户持续应用旧的 UI，再对采集回来的数据进行剖析：

• 哪种 UI 下，用户更违心持续往下走

A/B 测试须要留神的问题：

1. 不要过分置信你的直觉。将你的想法和别的工程师、设计师、产品经理深刻交换，通过沟通获取更好的抉择
2. 试验样本的数量和调配很重要。试验数量小、随机调配不均匀，都不能很好地做 A/B 测试
3. 剖析维度要全面。A 与 B 对照组，发现 A > B，然而 A 下网络提早更差，或者出错率更高，那就不是好的设计
4. 数据埋点很重要。通过前端埋点采集实时数据，后端埋点采集实时事件或者聚合数据。

5.4 我的项目开发：Code Review

开发该当对本人的代码自测，而后提交下来进行审核。

• commit：代码改变

commit 该当注明本次改变的类型：

1. feat，需要性能
2. fix，性能修复
3. ……

每次 commit 的性能应该是繁多的，例如本次 commit 批改了对应文档上的内容，下次的 commit 增加了性能代码，这些在 GitLab 等能依据具体的 commit 去查看改变，而不会乌七八糟丢在一起。

• pull request：代码提交申请

pull request 简称 PR，是指将你的代码合并到 GitLab 测试 | 线上分支的时候，须要进行的操作。

1. 失常提交：至多一个人认可
2. 重要提交：负责人认可
3. 多项改变：不同组进行各自代码审核

在 jsliang 日常工作中，如果是多语言等无关性能的提交，只须要身边小伙伴的审核；如果是新增性能，则须要组长审核；如果波及到其余部门，那么须要各自提交到组长审核。

5.5 我的项目开发：我的项目延期

影响到我的项目延期的因素：

• 产品加了个性，需要变更
• 人员缩小，开发工夫增多
• 我的项目组成员被调去紧急增援

我的项目开发过程注意事项；

• 先发问：什么时候感觉到我的项目可能会延期，在此之后你做了什么
• 建设肯定的流程。打算制订流程和打算跟进流程，每周或者每天同步会议
• 明确优先级。分好轻重缓急，将重要的事件先发展起来
• 制订我的项目共享状态表。让团队成员一眼就能够看清我的项目停顿，并放弃图表更新
• 不要漏掉任何一个人。不能因为某成员临时没有工作，就先搁置，而是当时告诉他并让他参加到工作事实跟进中
• 提供无效的反馈渠道。任何人有问题或者质疑，都能够提出并解决他的放心

5.6 我的项目开发：我的项目 Bug

当我的项目呈现线上 Bug 的时候，如何解决？

1. 用户第一，解决问题。对外的事件永远放在首位，做修复和补救，升高损失。
2. 防止重犯，追究责任。错了就是错了，该承当的责任还是须要承当的。
3. 环境监察，流程优化。人不肯定都能具备到位的，所以须要自动化测试或者多种测试，建设预警机制，避免高危操作（灾备演练）

同时，对于线上问题的公关：

• 弥补：包含但不限于发优惠券、送套餐和营销召回等

六 团队治理

6.1 团队治理：团队成员

如何帮忙团队成员：

1. 交融合作。通过领导、反馈、监督、交换、协调资源等形式帮忙上司晋升能力
2. 布置任务。合成和布置任务，包含界定需要边界、制订打算、提拔人员和工作受权等
3. 建设单干。与下级、上司和相干部门建设良好的单干

好的下级应该给予上司机会、空间和反对。

上面不可取的有：

1. 固定的眼光看一个人，成员的晋升看不到，也不去开掘
2. 过重看天才而非致力
3. 关注谬误而非让你在谬误中成长
4. 认为团队比每个人成长更重要

可取的是：

1. 一次失败能够容忍，然而屡次失败应该警觉
2. 问题很辣手，然而容许你尝试
3. 工作要求对系统比拟理解，然而让你做也能晋升你的理解

值得帮忙成员晋升的中央：

1. 技术如何晋升到更高层次
2. 后劲在哪，长处在哪，如何造就和开掘
3. 如何让他改良和共事的关系
4. 谬误哪些，毛病在哪，如何修改和改良
5. 建设不善于畛域的信念
6. 解决各种压力和矛盾

本身反馈：

1. 和本人对话，反思下面可取和不可取的点
2. 将一些场景的心田 OS 写进去，不便回顾
3. 跟组员和下级沟通，交换和听取倡议
4. 哪些事件能够交给组员的，然而本人却承当下来了

6.2 团队治理：降职

对于团队成员的降职，能够思考到以下几点：

• 技术晋升规范 ：这个人是否在过来的半年或者一年里，依照下一个级别的规范在工作（我须要的晋升点在哪，我本人的思考、组长的评论、好友的倡议）
• Code Review：是否对本人的需要开发、工作实现有对应的记录，并将这些内容统计分析进去

6.3 团队治理：倡议和意见

共事展现或者汇报工作成绩，说完会示意“有意见只管提”，然而这是一个大坑！

如果你特地诚实间接说了一堆负面倡议 / 意见，很大可能会不欢而散。

所以，沟通是门艺术。

• 大多数人对于负面的反馈和意见，心理上或多或少都有些排挤感

提意见的形式：

1. 思考由你提出这个意见是否适合。是不是换成领导比拟好，或者技术问题由技术比拟厉害的人提出比拟好
2. 提出这个意见的机会是否把握好。他人忙得焦头烂额，或者失恋了等场景，提这个倡议 / 意见和加一把刀有什么区别
3. 提出这个意见的地点是否把控好。是否在人员密集场合提出这个问题，是否在会议场合提出问题
4. 提出的倡议或者曾经对事不对人。防止让他人感觉你这是针对他，而是针对这个事件

多侧面反馈，80% 的侧面反馈 + 20% 的改良倡议，会让一个人有更好的能源。

听取意见的形式：

1. 理解本人心田，是否在认真听取意见。看重提意见的人？意见个人化？情绪因素？对方态度因素？
2. 克服本身阻碍，防止情绪影响到听取。不要试图从恶的角度推测对方，先假如是善意的，并表明本人的感激
3. 理解倡议细节，将关注点放到改良处。
4. 过滤倡议信息，将改良处落实到具体。

6.4 团队治理：一对一沟通

建设一对一的沟通机制，能让团队更加谐和：

1. 每一周或者每两周和团队成员进行一对一沟通
2. 谈话的内容没有定式，通常以上级为外围，对我的项目停顿、工作中的挑战、技术、业务和人事关系等进行具体摸索和沟通
3. 通过信息分享，会晋升团队成员的工作品质，你也能够学习理解到更多的常识
4. 不要为了沟通而沟通，这样会毫无意义
5. 能够先为沟通设定一下话题：产品晋升、工作哪些方面能够改良、技术方面如何晋升

6.5 团队治理：冀望与被冀望

管理者和被管理者之间，最须要防止的状况之一，就是期望值。

• 团队成员 A 平时很致力，心愿能拿到优良的绩效，后果拿到合格
• 团队成员 B 实现了一个很重要的我的项目，感觉能够升职加薪，却落到其余成员头上
• 管理者 C 感觉本人和团队成员单干很欢快，后果成员心愿换组甚至跳槽
• ……

这些状况都会给感觉意外的一方带来冤屈。

校准管理者和被管理者对彼此的期望值：

• 减少彼此的理解。外向内向、自信自负、跟本人较劲还是和别人攀比
• 半年或者一年进行一次对于期望值的深度对话。趣味是什么；退出团队心愿做什么；将来两三年职场打算怎么；做了哪些致力并且正在致力哪方面；目前做哪些工作，还想做哪些工作，还能做哪些工作；想承当什么样的责任；你对他的冀望置，并示意本人会尽大可能提供机会和反对；明确示意如果对方以前的承诺指标没有达到，那就临时不回给予更有挑战的机会
• 继续跟进。设置一些检查点，一周或者两周进行一次查看，依据单方的判断进行调整

6.6 团队治理：职场布局

对于团队成员，须要留神成员的集体布局：

1. 集体价值观是什么，最在意什么？在意独立解决能力，在意挑战他人做不到的事件，在意共事间的沟通气氛良好关系
2. 长期志愿是什么，五年甚至十年后，你心愿成为什么样的人？
3. 为了达到目标，你还须要哪些技能或者教训？技术广度、深度，产品零碎理解
4. 劣势和短处是什么？合作性、独立思考、口头迅捷、良好的产品思维

成员心愿领导提供怎么的反对：

1. 须要能证实本人的我的项目
2. 须要能带本人的老员工
3. 心愿有更多练手的机会
4. 须要专一造就本人的技能
5. 须要让本人接触更多的业务或者架构
6. 须要加入零碎的培训

当然，在提供这些反对之前，须要先证实本人。

例如心愿参加能证实本人的我的项目，那么在这之前你有没有参加各个我的项目的开发，脏活累活有没参加，从而能力取得须要的机会。

例如心愿能带本人的老员工，那么你是否做等同反馈，例如帮忙做一些力不从心的杂活，让老员工能更轻松地帮忙你。

不应该脱离实际去申请反对。

实现职场布局须要：

1. 晓得本人想要什么，晓得事实的你和现实中的你差距在哪里
2. 和领导者沟通，失去一些反馈和帮忙
3. 设定指标，指定你和你的领导者都批准的打算和期限，确保打算会让你和指标更靠近
4. 让打算变得可执行和可追踪，循序渐进实现和跟进，继续改良

七 其余

7.1 其余：说“不”的技巧

如果什么事件你都说 yes，你可能是万能的，然而你总会有栽跟头的一天。

1. 分清事件的轻重缓急，有些紧急的事件和优先级高的事件很难回绝
2. 正确评估本人的能力和工夫资源

7.2 其余：后续日子的思考

1. 下一步路怎么走？

   1. 本人生疏畛域开拓新天地
   2. 善于畛域持续精进
   3. 转岗

2. 思维是一种积淀，时过境迁当前你可能再也写不进去了

   1. 忙到后续再补笔记不是借口
   2. 不会做笔记也不是借口

八 总结

兴许有的小伙伴看完会感觉一脸懵逼，这写的都是什么和什么。

然而在读原文和此时回顾之前写的读书笔记（2021-04-13），我还是感觉有些点是十分值得关注的，例如：团队成员的降职。

尽管咱们很多人都心愿本人能降职到下一个职级，然而有时候想想本人是否满足下一个职级的技术栈，并依照这个技术栈严格要求本人了？

当然有时候会感觉本人是不是被洗脑了，然而如果降职不是依照一套流程走的，那么开了口子后团队治理是不是乱了。

除此之外，外面还有内容值得拉进去沉思，这里不一一例举。

我是 jsliang，咱们下本书读书笔记见。

不折腾的前端，和咸鱼有什么区别！

jsliang 的文档库由 梁峻荣 采纳 常识共享 署名 - 非商业性应用 - 雷同形式共享 4.0 国内 许可协定 进行许可。<br/> 基于 https://github.com/LiangJunrong/document-library 上的作品创作。<br/> 本许可协定受权之外的应用权限能够从 https://creativecommons.org/licenses/by-nc-sa/2.5/cn/ 处取得。