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

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

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

jsliang 没当过管理者，所以文中相关心得，皆为个人粗鄙见解，不构成价值参考，也不构成购买建议。

一 目录

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

目录
一 目录
二 前言
三 精彩语录摘抄
四 新人成长
4.1 新人成长：我的成长
4.2 新人成长：管理技巧
4.3 新人成长：我的思考
五 项目开发
5.1 项目开发：工作分配
5.2 项目开发：授权
5.3 项目开发：A/B 测试
5.4 项目开发：Code Review
5.5 项目开发：项目延期
5.6 项目开发：项目 Bug
六 团队管理
6.1 团队管理：团队成员
6.2 团队管理：晋升
6.3 团队管理：建议和意见
6.4 团队管理：一对一沟通
6.5 团队管理：期望与被期望
6.6 团队管理：职场规划
七 其他
7.1 其他：说 “不” 的技巧
7.2 其他：后续日子的思考
八 总结

二 前言

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

摘抄下 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 国际 许可协议 进行许可。
基于 https://github.com/LiangJunrong/document-library 上的作品创作。
本许可协议授权之外的使用权限可以从 https://creativecommons.org/licenses/by-nc-sa/2.5/cn/ 处获得。